👋 Hey, it’s Stephane. I help engineers become great engineering managers - whether you want to become one or are already leading a team.
Paid subscribers get 50 Notion Templates, The EM’s Field Guide, and access to the complete archive.
A manager was asked to estimate how long a project would take.
He talked to some engineers and figured Team A would need to do 3-4 weeks worth of work. Then he talked to the rest of the teams that were involved. 4 weeks for Team B, 4 weeks for Team C, 4 weeks for Team D, and 4 weeks for team E.
20 weeks in total.
The thing is… all teams needed to make the same changes to the same API!! Three or four weeks of work in total.
Dave Anderson, who ran engineering at Amazon, tells this story about a manager he calls Lawrence.
Lawrence had inflated his headcount ask by roughly 5x and had no idea.
“Lawrence was never on top of the details. He delegated all technical decisions to his team, to the point that he didn’t understand the critical decisions he was approving.”
How technical is technical enough?
This question is a bit tricky.. The problem is that “technical” means absolutely everything and nothing.
Will Larson makes this point:
“’Being technical’ has lost whatever definition it once had and has completed its devolution from demarcation to slur.”
There’s something to that.
What’s the last time you thought someone wasn’t “technical enough”? What is it exactly that they couldn’t do?
Understand the system architecture?
Challenge an estimate?
Help during an incident?
Have a healthy debate in an architecture review?
The research is a bit confusing
Google’s Project Oxygen looked at what separated their highest-rated managers and technical skills came last out of eight areas.
Laszlo Bock, who was running People Operations, said:
“It turns out that that’s absolutely the least important thing.”
Then you have research from Artz, Goodall and Oswald which found that a boss’s technical competence was the strongest predictor of worker job satisfaction.
So... which one is it? I think probably both can be true.
Google was comparing managers inside Google, where people have a pretty high technical bar. Technical ability wasn’t necessarily what differentiated the best managers because most engineers already had that.
Also.. “least important of eight things that correlate with being great” isn’t quite the same as “unimportant”.
You should certainly NOT be the best engineer
You’re not there to make every architectural decision. If you’re constantly making those yourself, you’re also taking opportunities away from the senior engineers in your team.
Sean Goedecke says:
“I have never once wished that my manager was picking up tickets and shipping code alongside me.”
You absolutely don’t need to know more than your engineers. In fact, you only need enough understanding to know when something doesn’t quite add up.
There is more pressure for managers to be hands-on though. LeadDev’s Engineering Leadership Report 2026 found that 37% of engineering leaders are doing more hands-on technical work.
It also expires
Being great on the technical side five years ago doesn’t automatically make you technical enough today.
There’s a deterioration at roughly 3-5 years.
Maybe we should not really be asking “How technical should I be?”, but instead:
When was I last close enough to the work to catch something?
If you can’t remember... maybe you want to give give this area some attention.
The good thing is that fixing it doesn’t mean learning another programming language or spending your weekends doing LeetCode.
I use a much simpler test.
The test
For me, the bar is roughly this:
👇👇👇 (access with a paid subscription)