I want you to think about the best manager you have ever had. Not the most technically impressive one, not the one who shipped the most features, but the one who made you genuinely better at your job. I know who that person is for me, and I bet you know who that person is for you too.
Odds are good that person did not micromanage your work. They probably did not hover over your PRs or tell you exactly how to solve every problem you brought to them. What they likely did was ask you questions that forced you to think more clearly. They gave you feedback that was specific enough to actually act on. They took your career seriously in a way that felt genuine rather than performative. They helped you see the gap between where you were and where you were capable of getting, and then they helped you close it.
That is coaching. And it is the most underused and underdeveloped skill in engineering management.
Most engineering managers are never taught how to coach. They come up through the IC track where performance is individual, then they get promoted and suddenly they are responsible for other people's growth without any real framework for how to do it. The instinct that fills the gap is usually managing - telling people what to do, reviewing their work, tracking their progress - rather than coaching - helping people develop the capacity to figure out what to do themselves.
That distinction matters more than it might sound. A team of engineers who are managed well will execute against a clear plan competently. A team of engineers who are coached well will grow, take on more complex work, make better decisions independently, and stay longer because they feel like they are actually developing as professionals. The output difference between those two teams compounds significantly over time.
So let's get into what coaching actually looks like in the day-to-day context of engineering management.
The one-on-one is your primary coaching surface. Not a status meeting. Not a task review. The one-on-one is where you develop your understanding of what this person is working on, what is getting in their way, what they are learning, and what they are ready for next. Done well, it is where the most important growth conversations happen.
Most one-on-ones fail because they do not have a clear purpose and the manager ends up driving the conversation around whatever is top of mind for them - team updates, upcoming deadlines, process concerns. Flip that. The one-on-one belongs to the engineer. Open with something like: "what is on your mind this week?" or "what do you most want to talk through today?" Then actually follow their lead.
What you are listening for is not just the content but the subtext. An engineer who says "this sprint has been a bit slow" might be telling you they are bored. An engineer who says "I have just been heads down in the ticket queue" might be telling you they feel disconnected from meaningful work. An engineer who mentions a difficult interaction with a product manager three times across different conversations is probably telling you something important without saying it directly. Coaching requires learning to hear those signals and respond to them honestly rather than staying on the surface.
Questions are your most important tool as a coach. The instinct for most technically strong managers is to give answers. Someone comes with a problem and you tell them how to solve it. That feels productive and it often is in the short term. But it creates dependency. Every time you give someone an answer you had the chance to help them develop the capability to generate that answer themselves, and you declined it.
The shift is to respond to problems with questions. Not in a frustrating Socratic way where you refuse to ever be direct, but in a way that draws out the engineer's own reasoning before you add yours. "What have you already tried?" "What do you think is causing it?" "If you had to guess at the best path forward, what would you say?" These questions accomplish two things simultaneously: they give you information about how the engineer is thinking, and they often help the engineer arrive at the answer themselves, which is a much more durable outcome than being told the answer.
When you do share your perspective, frame it as a perspective rather than a directive. "Here is how I would think about this" rather than "here is what you should do." That keeps the ownership with the engineer and signals that their judgment is part of the equation, not just an obstacle between them and the right answer.
Performance conversations are where a lot of engineering managers lose their nerve, and that avoidance does real damage. When someone's performance is not where it needs to be, the kindest thing you can do is tell them clearly and specifically, with enough context that they can actually act on it. Delayed feedback is not compassion. It is conflict avoidance dressed up as patience, and it ends up being far harder on the engineer in the long run.
The structure that works for performance conversations, whether they are corrective or developmental, follows a consistent pattern. Specific observation first - not "your code quality has been slipping" but "the last three PRs you submitted had significant issues that were caught in review and would have caused problems if they had gone to production." Then impact - why this matters for the team, the product, or the engineer's own growth. Then genuine curiosity - what is going on from their side, what might be contributing to this, what do they think they need. And then a clear shared understanding of what improvement looks like and a timeline for revisiting it.
The specific observation part is what most managers skip or soften into meaninglessness. "I just want to flag that some people have mentioned concerns about collaboration" is not actionable feedback. "In the incident last week, two engineers told me they felt their concerns were dismissed when they raised them in the thread - I want to understand what happened and work through it with you" is actionable feedback. Specificity is the thing that makes feedback usable rather than just uncomfortable.
Growth plans are one of the most underutilised management tools I know. Not the formal HR document kind that gets filled out once a year and then filed - the real kind, where you and an engineer have an honest conversation about where they want to go, what is in the way, and what you are both going to do about it.
A useful growth plan starts with a genuine conversation about what the engineer actually wants. Not what you think they should want, not what the standard career ladder says they should be aiming for. What do they actually want? More technical depth? Leadership experience? Exposure to a different part of the stack? The answer to that question changes what kinds of opportunities are meaningful to them and what kinds of stretch assignments will actually develop them rather than just adding to their workload.
From there, you build backward. If someone wants to move toward a staff-level role, what does the gap between where they are now and what that role requires actually look like? What specific skills, what visibility, what demonstrated impact would they need to show? Get specific enough that both of you could look at a piece of work and agree on whether it counts as progress toward the goal.
Then identify the opportunities. Not abstract goals - specific opportunities in the actual work ahead. This project coming up would give them the technical leadership visibility they need. This initiative has a coordination component that would develop their cross-team communication. This piece of the codebase is complex enough that owning it would give them the depth that is currently missing from their profile. When you can connect growth goals to real work, growth planning stops being a separate activity and becomes part of how you think about the team's work anyway.
Revisit the plan regularly. Not in the annual performance review - in one-on-ones, every few weeks. "How is the work on that service going - is it giving you what you were hoping for?" That regularity signals that you are actually invested in the plan rather than using it as a box-checking exercise.
Career development conversations are different from growth plans in a specific way: they require you to engage with the engineer's ambitions beyond their current role, and sometimes beyond your team. This is uncomfortable for some managers because it feels like you are helping someone leave. In reality, you are building the kind of trust and loyalty that makes people want to stay.
The engineers who leave most readily are the ones who feel invisible - whose manager has never asked where they want to go, who cannot see a path forward from where they are. The engineers who stay in companies that would otherwise lose them are often the ones who have a manager who takes their development seriously enough to have honest conversations about what they want, even when the answer is complicated.
If an engineer tells you they want to move into management, help them explore that seriously rather than steering them back toward IC work because you need their technical contribution. If someone tells you they want to work on a different kind of problem than your team addresses, help them think through what that could look like internally before they start looking externally. That kind of engagement builds a relationship where the engineer feels like their interests are actually considered, not just tolerated.
Feedback culture within a team starts with how the manager gives feedback, but it does not stop there. If you want engineers to give each other honest, constructive feedback - in code review, in design discussions, in retrospectives - you need to model it and you need to make it safe. That means appreciating directness when you see it even when it is directed at you, and explicitly naming feedback behaviours you want to see more of when they show up.
One habit that is underrated: giving positive feedback with the same specificity you bring to corrective feedback. "Good job on that feature" lands with almost no impact because it tells the engineer nothing about what specifically was good. "The way you handled the rollback plan on that deploy was exactly the kind of thing I want to see more of - you anticipated the failure mode before it happened rather than waiting for it" - that lands. It tells the engineer something specific about their performance and it communicates something about your values. Both of those things are useful.
The gap between a manager who manages and a manager who coaches is ultimately a gap in how they think about their job. A manager who manages thinks their job is to get work done through their team. A manager who coaches thinks their job is to develop people who can get increasingly complex and important work done without needing to rely on the manager as a decision-making crutch.
The first version of that job has a ceiling. The second version compounds.
Engineers who work for coaches become more capable over time. They take on bigger problems, mentor more junior colleagues, contribute to the team in ways that go beyond their individual output. They are also, in my experience, far more likely to speak honestly with you about what is working and what is not - because the coaching relationship is built on genuine engagement rather than authority, and that changes what people are willing to say.
That honesty, in the end, is one of the more valuable things you can build. Because you can only fix the problems you know about.
Next in the series: Technical Debt - When to Fix, When to Ship. A framework for making trade-off decisions and communicating them to stakeholders who care about outcomes, not architecture.
Top comments (0)