The Leadership Shift No One Explains to New EMs
What "being technical" means when you're no longer the one writing the code
When new Engineering Managers look up at Directors, VPs, and CTOs, they often feel a quiet contradiction.
On one hand, they’re told:
“As you grow, you need to think more systemically.”
On the other, the industry celebrates:
“Very senior leaders who are still deeply technical.”
If you’re a new EM, this creates an uncomfortable question:
Should I stay close to the code to remain credible?
Or step back and risk becoming vague, generic, or irrelevant?
This post is an attempt to resolve that tension.
It’s based on patterns I’ve seen in mid-to-large engineering organisations.
It is not universal truth. And it absolutely breaks down in some contexts, which I’ll name explicitly.
First, a clarification
This is not an argument that senior leaders shouldn’t be technical.
And it is not a defence of managers who hide behind words like “strategy” or “systems” to excuse technical decay.
Those people exist.
They are harmful.
And they’re not what this article is describing.
What is real - and often misunderstood - is that the nature of technical work changes as scope increases. If that distinction isn’t clear, the rest of this doesn’t land.
Scope: when this applies - and when it doesn’t
This framing generally applies when:
You’re in a mid-size or large org (roughly 40+ engineers)
There are Staff+ engineers owning deep technical decisions
The work involves coordination, trade-offs, and long-term constraints
It breaks down when:
You’re in a 10–20 person startup
Leaders must code to keep the company alive
There is no meaningful separation between execution and system design
If you’re early-stage: keep coding. A lot of this won’t help you yet.
The most common misread: “Directors are just scaled EMs”
Many new Engineering Managers assume Directors are basically:
EMs with more people, more meetings, and less time.
If that’s your model, you prepare in predictable ways:
You stay close to delivery “to be safe”
You personally unblock, decide, and smooth things
You take on ambiguity so others don’t have to
You optimise for being useful and reliable
That makes sense - if the job is the same job, just bigger. It isn’t.
What actually changes
An EM’s core question is:
“How do we get this team to ship?”
A Director’s core questions look more like:
“Why do three teams keep tripping over the same dependency?”
“Who actually owns this decision — in practice?”
“Why are we rewarding behaviour we say we don’t want?”
“Which of these trade-offs matters this quarter vs next year?”
In a week, that difference shows up clearly:
EM: resolves escalations, unblocks work, keeps delivery moving
Director: notices patterns, clarifies ownership, changes constraints
The EM fixes problems.
The Director changes the conditions that keep creating them.
The key distinction
This doesn’t mean Directors work less, or think “higher level.”
It means:
EM impact comes from direct involvement
Director impact comes from where they intervene and where they don’t
When new EMs assume the roles are the same, just scaled up, they train the wrong muscles:
They get better at throughput instead of judgment
They become indispensable instead of creating leverage
They solve today’s problems instead of reducing tomorrow’s
Seeing this early doesn’t change how hard you work.
It changes what you practice getting good at.
Why the “very senior and still technical” story is misleading
The industry loves stories about senior leaders who still code, review PRs, or design systems.
These stories are compelling because they resolve a fear many EMs carry:
“If I stop being technical, I lose legitimacy.”
But when you look closely, most of these examples fall into one of three categories:
Founders or original architects, whose technical authority is historical
Public thinkers, rewarded for articulation and taste more than operating ownership
Exceptionally disciplined leaders, who intervene rarely and deliberately
Those people exist and are also rare and misunderstood.
The mistake is assuming their visibility reflects the work most senior leaders are actually paid for.
What “technical” actually means at Director level
“Technical judgment” gets waved around a lot, so it’s worth grounding it in observable behaviour. Being technical at this level is not hands-on throughput.
At Director level, being technical usually means you can:
Read code and designs well enough to follow the argument, even if you’re not writing them day to day
Tell which decisions are expensive to reverse (data models, interfaces, regulatory choices) and which are cheap
Recognise when a proposal breaks known constraints - scale, latency, reliability, compliance before shipping
Distinguish healthy disagreement from confusion, and know when alignment is missing rather than insight
Ask the questions that surface trade-offs early, before weeks of work are committed in the wrong direction
It’s about being technically fluent enough to:
understand what’s being proposed,
see where the risks really are,
and intervene at the few points that actually matter.
If you can’t follow the conversation, you can’t lead it.
A concrete example of where this goes wrong — and what should have happened instead
At a payments company I worked with, a Director made a point of joining most architecture reviews. From the outside, this looked like a senior leader “staying technical.”
The group already had two Staff+ engineers who owned the domain and had strong proposals. The reviews weren’t blocked by lack of expertise.
The problem was how the Director participated.
He would:
suggest alternatives based on older experiences,
ask probing questions without closing them,
occasionally express concern without saying whether it was a hard constraint or a preference.
After a few meetings, a pattern emerged.
Engineers stopped moving forward after reviews. Instead, they waited and asked each other:
“Was that a direction or just a thought?”
“Do we need to revise this before proceeding?”
“Should we run this by him again?”
One architectural decision - already broadly agreed by the Staff engineers - sat in this state for three weeks. No one felt blocked explicitly. No one was told “no.” But no one felt authorised to say “yes” either.
Staying close to architecture gave the Director something concrete to contribute, while the harder work - forming and communicating a clear platform point of view - was still unresolved. Without that clarity, his presence added ambiguity instead of direction.
What should have happened instead was simpler, and harder.
The Director didn’t need to participate in every design discussion.
He needed to:
be explicit about which decisions the Staff engineers owned,
name the few non-negotiable constraints that mattered at his level,
and state clearly whether his input was direction, concern, or optional context.
In other words, his leverage wasn’t in having opinions on the design, but in creating the conditions where the right people could decide and move on.
This is what “being technical” looks like when it’s used well at senior levels:
less presence, more clarity.
Where new EMs often overcompensate
One place this misread shows up early is in how new EMs handle chaos.
Most EMs learn quickly that part of the job is buffering:
translating unclear goals,
smoothing rough edges,
absorbing organisational noise so the team can keep moving.
That instinct is healthy up to a point.
The problem is that, over time, many new EMs start doing this reflexively. They take on ambiguity not as a temporary tactic, but as a standing role. Decisions that should be clarified upward get quietly worked around. Gaps in ownership get patched locally. Conflicting signals get reconciled privately. From the team’s perspective, things look calm. From the system’s perspective, nothing ever improves.
The organisation never feels the cost of its own ambiguity.
Senior leaders never see where decisions are unclear.
And the EM slowly becomes the permanent shock absorber.
Why this matters when you look up the org chart
If you assume senior leaders are just “doing your job at scale,” it’s natural to think your growth lies in absorbing more:
more context,
more mess,
more responsibility for making things work.
But Directors don’t create leverage by absorbing ambiguity.
They create it by forcing ambiguity to be resolved - through clearer ownership, sharper trade-offs, or changed constraints.
New EMs don’t need to stop delivering to learn this.
They just need to notice a few things alongside the work:
Which problems keep coming back, sprint after sprint
Where decisions slow down because no one is clearly accountable
When they’re fixing issues that aren’t really theirs to fix
Those moments are signals that say the system needs to be addressed.
What this means for new EMs — practically
If you’re a new EM, this isn’t a call to stop shipping or “think strategically” instead.
It’s an invitation to:
Notice which problems keep recurring
Pay attention to where decisions stall
Ask “who owns this?” more often than “how do we fix it?”
Experiment with not being the final line of defence every time
You still need to deliver this quarter.
Just don’t confuse heroics with trajectory.
A note on humility (and reality)
Some senior leaders genuinely do:
Stay deeply technical
Operate strategically
Avoid becoming bottlenecks
They exist. They’re impressive. And they are disciplined about when they intervene.
The point isn’t that you can’t do both.
It’s that doing both well is harder and rarer than the industry admits.
The question worth keeping
When you look up at Directors and above, don’t ask:
“How do I become a Director like them?”
Ask:
“What problems are they paid to notice that I’m only just beginning to see?”
That question will serve you better than any myth - technical or otherwise.