There’s a version of engineering management that shows up in a lot of technical writing: the EM as scorekeeper. They track metrics, run processes, attend meetings, and get out of the way of the engineers who do the real work. In this view, a great engineering team almost doesn’t need a manager – and a manager who does too much is probably just creating noise.
That view is wrong, and the teams that operate on it tend to show it eventually.
The engineering manager’s primary job is to create the conditions where each person on the team can do their best work. That sounds straightforward. It isn’t. It requires understanding what “best work” means for each individual, what’s currently in the way of it, and what you can actually do about it – which is not always as much as you’d like.
Caring personally is not a soft skill Link to heading
Kim Scott’s Radical Candor introduces a simple framework: good management sits at the intersection of challenging directly and caring personally. Most technical managers are reasonably comfortable with the challenging part – giving feedback, holding standards, pushing back on poor decisions. The caring personally part is where things get uncomfortable, and where a lot of technically-minded managers under-invest.
Caring personally doesn’t mean being liked. It doesn’t mean avoiding hard conversations or tolerating poor performance. It means treating the people who report to you as complete humans whose lives extend beyond their PR output, and whose ability to contribute at work is affected by how they’re doing as people.
I’ve seen this dismissed as soft management – the kind of thing you do when you can’t hold people accountable. In my experience it’s the opposite. You can’t give someone genuinely useful feedback if you don’t understand what they’re optimizing for. You can’t identify whether someone has a performance problem or a support problem without knowing them. You can’t retain the people you want to keep if they feel like interchangeable resources.
Different people need different things Link to heading
This is where the work actually is. Not every engineer on your team has the same needs, the same blockers, or the same idea of what good looks like.
One engineer needs technical challenge and will quietly disengage if their work stops stretching them. Another needs clarity – they perform best when they understand exactly how their work connects to the bigger picture. Someone else is going through something personally that’s affecting their focus, and the most useful thing you can do is acknowledge it and give them some room. Another person doesn’t need any of that – they’re heads-down, they’re fine, and the best support you can offer is removing organizational friction and leaving them alone.
None of this is captured in a metrics dashboard. You find it out by paying attention, by asking, and by genuinely listening to the answers.
The claim that engineers can be assessed and managed primarily through code output misses this entirely. Output metrics are one signal among several, and they can’t tell you why someone is underperforming – only that they are. The why is almost always a people question.
The pragmatic limits Link to heading
This is also not a license to overreach, and it’s worth being honest about what you can and can’t do.
You’re not a therapist. There are real limits to what you can fix, what you should try to fix, and what’s yours to fix at all. But that doesn’t mean you close the door. Sometimes an engineer just needs to vent – about a frustrating project, a difficult stakeholder, something going on outside work. You don’t need to solve it. Being present, listening without judgment, and acknowledging that things are hard is often enough. That’s not therapy. It’s just being a decent human being, and it matters more than most management frameworks acknowledge.
The line is roughly this: listen freely, support where you can, and know when to point someone toward resources that are better equipped to help than you are. Most people aren’t looking for you to fix their life. They just don’t want to feel like they’re carrying it completely alone.
Personal problems that fall outside work are ultimately the individual’s to handle. You can offer flexibility where the organization allows it. You can be human about the fact that life happens. But you’re not equipped to solve problems that belong in a different context, and trying to will create its own issues – for them and for you.
Organizational constraints are real too. You can’t always give people the projects they want, the compensation they think they deserve, or the promotion timeline they’re hoping for. Being honest about what’s within your control – and what isn’t – matters more than pretending you have more leverage than you do. People can handle bad news. What damages trust is the gap between what they were led to expect and what actually happened.
And throughout all of it – the hard conversations, the honest feedback, the constraints you can’t change – be kind. Not soft, not conflict-averse, not unwilling to hold the line. Kind. There’s rarely a situation in management where a little basic human decency makes things worse.
Why this connects to everything else Link to heading
The posts I’ve written about performance metrics, test strategy, and talent assessment all have something in common: the right answer is contextual, and context is a people problem.
Choosing the right metrics requires understanding what your team actually needs to improve. Calibrating your testing approach requires trusting your engineers to make judgment calls. Assessing talent fairly requires knowing the individual well enough to distinguish between a capability gap and a support gap.
None of those things work if you’re managing from a distance, measuring outputs, and treating people as interchangeable.
The actual job Link to heading
If you’re an engineering manager, your primary output is not code, and it’s not process. It’s the performance of your team – and that performance is built from the individual performances of the people in it.
Getting the best from a team means getting the best from each person in it. That requires knowing them, investing in them, being honest with them, and creating an environment where doing good work is actually possible. That’s the job. The metrics and processes are in service of it, not the other way around.