The jump from senior engineer to engineering manager: what nobody tells you

21 April 2026 7 min read

The most common reason engineering managers struggle in their first year isn't lack of technical ability — it's that they're still trying to do the wrong job. They were promoted because they were excellent engineers. They keep trying to be excellent engineers. But that's no longer what the role requires.

Your output is now your team's output

As a senior engineer, your value was measured in the things you built, the problems you solved, the code you shipped. As an engineering manager, your value is measured in what your team ships. This sounds obvious, but the implications take time to sink in.

It means that the most valuable thing you can do on a given day might be a one-to-one conversation with an engineer who is stuck, or removing a process blocker, or having a difficult conversation with a product manager about scope. None of these things feel like "real work" when you're used to measuring yourself by commits and features. They are absolutely real work.

The hardest version of this is staying out of technical decisions that your team is capable of making. The instinct to jump in and fix things is strong when you have the technical ability to do so. But every time you override a technical decision, you undermine the engineer who made it and signal that their judgement isn't trusted. Your job is to build the conditions for good decisions, not to make all the decisions yourself.

One-to-ones are your most important tool

Regular one-to-ones — weekly, half an hour — are the primary mechanism by which you understand what's actually happening on your team. Not the standups, not the sprint reviews, not the status reports. The candid conversations that happen in a low-stakes, consistent, private setting.

The mistake new managers make is treating one-to-ones as status updates. They ask "what are you working on?" and "is anything blocked?" That's a standup, not a one-to-one. A one-to-one is for the things that don't come up in group settings: Is this person engaged? Are they growing? Is something outside work affecting their performance? Do they feel valued? Do they trust the direction we're going?

Come with an agenda but be willing to abandon it. Ask "what's on your mind?" and mean it. The answer to that question is usually more important than anything you had planned to discuss.

Managing underperformance

New managers often wait too long to address underperformance, then address it too abruptly when they do. The result is an engineer who feels blindsided and a manager who has made the situation worse.

The framework that works: be specific, be early, be direct. Specific means naming the behaviour you've observed, not a general judgement ("the last three PRs have had significant gaps in test coverage" rather than "your code quality isn't good enough"). Early means raising it as soon as you notice a pattern, not after six months of hoping it will improve. Direct means saying it clearly in a one-to-one, not burying it in a performance review.

Most underperformance has a cause. The engineer is overloaded and cutting corners. They're working on something outside their current skill level without adequate support. Something in their personal life is affecting their concentration. Find out what it is before deciding how to respond.

Building trust before you need authority

New managers sometimes confuse their title for authority. They can direct their team in a technical sense, but genuine influence — the kind that makes people go the extra mile, flag problems early, tell you the truth — comes from trust, not hierarchy.

Trust is built in small moments: following through on things you said you'd do, being honest when you don't know something, taking responsibility when something goes wrong rather than deflecting, remembering what people told you matters to them and acting on it. None of this is complicated. All of it takes consistent effort over time.

The managers I've coached who've made the transition well share one characteristic: they became genuinely interested in the people on their team as people, not just as resources. That sounds soft. It's the hardest and most important part of the job.


Back to Insights

Related reading

DevOps

Flow metrics: measuring what DORA can't

7 May 2026 · 8 min read

DORA metrics tell you how fast and safely you deploy. Flow metrics tell you where your work gets stuck before it ever reaches deployment. Used together they give you a complete picture of engineering delivery.

Read article
AI & Engineering

AI-assisted development in practice: lessons from building four products

1 May 2026 · 8 min read

Over the last eighteen months we used AI-assisted engineering to build four production products. Here's an honest account of what worked, what didn't, and what the experience changed about how we build software.

Read article