The day I became an Engineering Manager, I thought my job was to make sure good code shipped. I spent the first three months optimising for code quality, delivery velocity, and technical decisions. I was wrong about almost everything.
The unit of work changes
As an engineer, your unit of work is code. You write it, review it, ship it. The feedback loop is fast and mostly visible. You know when something is working.
As an EM, your unit of work is people and systems. You’re not shipping code — you’re building the conditions under which code gets shipped well. The feedback loop is slow, often invisible, and significantly delayed. The best thing you did this quarter might not be visible until next year.
This is disorienting. Most new EMs don’t have language for it, so they default to what they know: being the best engineer on the team. This is a trap. A manager who stays in the code gives their team less ownership, less growth, and less clarity about who is responsible for what.
Technical judgment transfers. Technical execution doesn’t.
The skill that made you a great engineer — the ability to write and review good code — doesn’t scale. You can’t review everyone’s code. You shouldn’t.
What transfers is technical judgment: the ability to ask the right questions in an architecture review, to sense when a technical approach has hidden risks, to understand the engineering trade-offs in a product decision. This judgment is genuinely valuable in an EM.
The mistake is using technical judgment to substitute for engineer ownership. Your job is to ask the question that prompts the engineer to see the risk — not to see it for them.
Clarity becomes your primary output
The single highest-leverage thing an EM can do is make expectations explicit. Who owns what. What good looks like at each level. What the team’s priorities are and why. What decisions they can make independently and which ones need escalation.
Most engineers have never had a manager who wrote these things down. Most assume they’ll figure it out through observation. Some do. Many don’t, and they spend months performing to a standard they’ve had to infer rather than one they were given.
Your job is to remove that ambiguity. Every time an engineer has to guess what you want, you’ve failed a part of your job.
The thing I’d tell myself
Your value is no longer in what you produce. It’s in what your team produces. That shift takes longer to feel comfortable with than it takes to understand intellectually.
Give it time. And write things down.