Using Effective Feedback and Communication to Boost Developer Confidence
I'm spending the week at Render Atlanta, a large tech conference that draws people from all over the world and all levels of experience. It's been an amazing opportunity to meet like-minded engineers from so many diverse background and talk about the things that matter to us in our field.
Of course we all talk about the usual - frameworks, tools, platforms, and languages that we work with and what our preferred "tech stack" is. As I've chatted with more people and gotten to know them, two other things keep coming up in conversation - imposter syndrome and success metrics (including manager feedback). Software development is a career that even when you're performing highly, it doesn't always feel like it. This can be really difficult and lead to undue stress or high turnover rates - especially for people trying to break into the field for the first time.
In this post I'm taking bits of the conversations I've had around this topic so far, and writing about the dynamics and culture that myself and other engineers find important for success.
Know What Kind of Feedback is Valuable
We all know that everyone is different. Software engineering is a massive field comprised of many types of people. That means that your style of work and receiving feedback is probably different from your teammates. For example, I like continuous assurance that what I'm doing is valuable and that the work I'm doing is good. I like to be told this in 1:1s and publicly during demos, so that I have a good gauge for how I'm doing. This also helps me fight imposter syndrome through continuous reassurance. Without this feedback, it's easy to lose confidence. I do not want to work in a vacuum.
That might not work for you, however. I've talked to a number of people this week who don't like being praised publicly, and would prefer feedback be in private only, even if it's positive! Sometimes it can be stressful to be in the spotlight.
From the management side, this means that it's important to understand your engineers and how they want to receive feedback. Do they like to be praised publicly or privately? Do they work well with harsh feedback on their work, or do you need to take a more gentle tone when giving constructive criticism? These are all important things to understand.
Know How to Deliver Feedback that Yields Results
Giving feedback can be complicated - even once it's given, it's possible not to know what direction to take. I've been told before that my solution to a problem "sucked" and that it needed to be reworked, but wasn't given much direction other than that. Thankfully, I knew what needed to be done and my second attempt at the feature worked much better, and I was very proud of the result. I grew a huge amount in that moment and established some principles I still follow to this day, to make sure nothing I work on has the same outcome. That said, the original feedback wasn't very actionable. That worked for me, but I've told that story a few times this weekend to different people, and many had different reactions.
Some people in a hypothetical situation like the one I described expressed that they'd have no idea where to go from there. If something is wrong, it is important for them to have clear direction on what can be done to remedy the issue. Many people I spoke with learn better this way, rather than the harsh and sort of non-specific criticism that often works for me. Again, everyone is different and it's important to know who you're talking to and give the right kind of feedback.
Know How Success Should Feel
Okay great, good feedback that's tailored to each engineer's needs is being given. The last step here is to know what success looks like. How should I feel while I'm working? Do I want to feel like my hand is being held through the process, or do I want to feel like I've been dropped in the deep end? Do I want to be super busy, or should I feel like I have some extra capacity? Again, everyone is different here. Personally, I don't like to feel like I'm receiving too much support - I learn best when I'm thrown into a hard challenge and forced to put in hard work and long hours to solve it. For others I've talked to, that idea scares them and they'd prefer a much more supportive approach.
Continuing to evaluate how you feel as an engineer is important - and it's important to communicate that to whoever manages you. Similarly, if you're managing engineers it's important to understand how they expect to feel, and then you can provide the resources to enable that. There's no way to know if a team is healthy and receiving good feedback without knowing what "healthy" means.
Everyone I've talked to has expressed a similar sentiment - when their needs are met in terms of communication, support, and both positive and critical feedback, they feel more confident, excited for the role, and more prepared to either confidently enter the industry for the first time, or grow their career.
This has continued to be an amazing conference to network, meet others, and talk about more than just the code we write - but how it gets written and how we can support each other through that process. I can't wait for more to come!
A quick tip for events like this: Have a wallpaper on your phone lockscreen with QR codes to important links - be it your LinkedIn, Twitter, or website. Here's mine for reference. I just whipped it up in Figma while between talks and it's been great!
