Many little things can bother me when friends pick me up at the airport, although I’m always appreciative that they do.
But maybe they parked far away from the entrance, for example, or they went grocery shopping and had barely any space for my bag. Sometimes, these things happen. However, none of that matters at the end of the day — I’m just glad they picked me up, and I’m more than happy not to complain.
But I’m not like this when using Uber. I’m paying for the service, so expectations are much higher. It’s easier to leave a review over a bad experience because I don’t know the driver personally, and I’m not afraid of offending them. I don’t want to make anyone’s life harder, but my goal is to improve the quality and overall experience.
But if you’re the engineering manager of a former teammate, your Uber driver is your friend. Suddenly, you need to give feedback to someone you know and have worked with, likely for years.
The question is how?
Transition your mindset from engineering to engineering management
So long as it didn’t affect you, you probably didn’t care much when your team members missed deadlines, or their code was messy.
But when you start managing them, you see problems you didn’t notice before. One individual contributor (IC) will work too slowly, perfectionism will paralyze another, and a third won’t be able to solve problems independently.
As an engineering manager, you can’t turn a blind eye to this anymore — your job is to help your team improve and evolve. And your work will be judged by what your team, as a whole, produces, so there is value in doing this. It’s the same as with Uber drivers. Your engineers are not going to improve (or even know how they can improve) unless they receive honest feedback.
And the one who can best give that feedback is you.
But a transition period is only natural. Some of your engineers will wonder how much they can get away with because you’re “one of them.” Others may feel betrayed the first time you lay down the law. This feels disorienting and lonely, especially if this is the first time you’ve experienced this kind of transition.
But it doesn’t have to. You have ways to improve workflows and relationships. You just need to tap into your experience as an engineer to build empathy and communicate in a language your team understands.
Highlight agency and collaboration
A manager in my company worked with a designer who liked to do everything at once. The designer didn’t want to wait for V3 when they could layer different features right into V2. While this wasn’t a problem for them, it caused all sorts of headaches for the engineers.
The last thing we wanted to do was criticize them for taking initiative. Criticism often demoralizes team members and makes them feel less able to figure things out for themselves.
Instead, the manager took them aside and explained the complications that can emerge when we make unplanned changes or don’t follow the iteration schedule. Then the manager asked them about how they would address the issue.
This is a different kind of conversation. It’s not condescending — it shows that you’re in this together. The team member in question has an opportunity to come up with an idea, which gives them more motivation to see it through. Together, you refine the solution until you both feel satisfied it’s worth trying out — it’s a collaborative process that avoids a harsher, top-down approach.
In that case, the designer took initiative in thinking of a solution and carrying it out. The manager’s job was to follow up and discuss further if necessary.
Focus on problems, not people
Sometimes, the core of an issue goes beyond misunderstood expectations, like when genuine mistakes are made, or an engineer lacks the required skills. In this case, you need to intervene more directly.
Remember that direct criticism makes people feel attacked. This will lead them to shut down, and it damages your credibility. A smart way to proceed is to focus on the issue rather than the mistake or the person who made it.
For some more perspective, look at these two conversation starters:
One: “Why didn’t you make the deadline last Friday?”
Two: “If we don’t catch up immediately on this task, the other team’s work will be backed up. What can we do to resolve this?”
The second one emphasizes collaboration rather than confrontation — there, you’re framing the problem as an issue the team faces together.
You’re telling a different story: we’re allies, not enemies.
Another difference is a focus on agency. The second conversation starter offers your engineer a way to contribute to resolving the situation, as opposed to the first, where they may feel trapped, helpless, or punished.
As a former engineer who understands the tasks and pressures involved in the job, you’re again sending a clear signal you’re with them, not against them. When done right, this builds trust and solidarity. It also lays the groundwork for a relationship where engineers feel comfortable coming to you with issues — they’ll trust you’re not there to blame or shame them but to help them unlock results.
Practice radical candor
Giving more extended feedback on something that’s not working can be intimidating, especially if you’re new to the role. Radical candor, developed by Kim Scott and explored in her book of the same name, is a helpful model. This approach combines necessary feedback with empathy for the person receiving it.
You can break this feedback down into four actionable steps:
- First: Set the scene by describing the situation to the engineer as you see it. This helps create a sense of the stakes involved.
- Second: List the engineer’s precise actions in regard to the situation — use as neutral words as possible. Do it as if you’re making an observation rather than interpreting their behavior or applying judgment. Both of these tend to shut conversations down and damage your relationship.
- Third: Recount what impact their actions (or inactions) have had on you, the team, and, importantly, the engineers themselves. Remember the previous section — the consequences of their actions are an issue you face together rather than a means to shame or punish them.
- Finally: Suggest concrete advice for what they can do differently.
Part ways with grace
Sometimes, even the most constructive, candid feedback can’t solve a deep-seated problem. Parting ways with the team member can make the most sense in those cases.
Regardless, this is never an easy decision.
Letting someone go is hard, expensive, and often traumatizing for everyone involved. It’s better to do everything you can before you get to that point, thus all of the above advice. But if a problem persists, then it may be the only step you can take.
Doing this with grace and candor means communicating it isn’t because either one of you is a bad person. You simply weren’t a good match, and there’s no point in staying in a tense, unhappy situation.
Even if some engineers leave the team or you have to remove them, you’ve still built a culture of healthy feedback and communication. Your engineers will see you have their backs and view you as a support and resource, one who does your best to understand them.
The short version: tap into your superpower
Giving feedback to former teammates is never easy, but you can do so effectively.
One necessary step is shifting your mindset from engineering to management. As an engineer, you weren’t as concerned with your peers’ work. As a manager, you need to pay attention to any issues when they arise.
A second is by focusing on agency and collaboration. Ask engineers to think of solutions to the issues they’re involved in and let them take initiative in addressing them.
A third is focusing on problems, not people. Specifically, show your team you’re focused on solving problems, not punishing mistakes. Show your engineers you’re on their side with your words and actions, and they’ll be on yours.
A fourth is practicing radical candor, a model developed by Kim Scott. Essentially, you’re following a series of steps combining feedback with empathy. First, you describe the situation as you see it, and then you list the engineer’s actions in regard to the situation as neutrally as possible. Next, you explain the impact of their actions on you, the team, and the engineer. Finally, you give concrete advice to help them change for the better.
Finally, you may need to part ways. This should be a last resort, only used when all else has failed. Even then, you can do so empathetically, showing your engineer you weren’t a good fit instead of blaming them.
Together, these steps and actions are your feedback superpower. Using them doesn’t guarantee a 100% success rate, but it does greatly improve your chances at one.
Want more tips on leading effective software engineering teams?
Join my newsletter if you’ve found this content useful
Originally published on Medium.com