👋 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.
Where is your engineering team on the AI adoption ladder? (sponsored)
Find your stage, spot the one bottleneck holding you back, and see what to fix next.
Thanks to re:cinq for sponsoring this newsletter!
I became an EM almost a decade ago and since then I’ve spent time managing teams at startups, as well as more established unicorn companies in London.
Back then, managing a team of 8 engineers really meant managing one team.
Today, it feels more like managing 4 teams.
I don’t think that’s because engineering has become more complicated.
I think it’s because the bottleneck moved.
It moved from engineering... to product.
When I started, being an EM would typically mean that you’d get a team of 6-8 engineers, a Product Manager, maybe a designer, and you’d all work together. In the good old days, you’d also get a Delivery Manager who made sure you’re “agile” (and in most cases would also facilitate all your meetings).
The roles were clear. Everyone knew what they were responsible for. Very simply put:
the PM was responsible for the WHAT: what we’re working on
the designer was responsible for the look and feel of that
the engineers were responsible for figuring out the HOW and building the thing
The role of the EM was about making sure engineers were having career growth conversations, had clear goals on how to progress, and were well positioned to achieve those goals.
The EM was also pretty much always held accountable for the technical decisions that the team made.
Experienced EMs who wanted to progress their own career were equally involved in bringing positive organisational change (improve how teams worked together, drive an initiative that the CTO was really keen on but couldn’t find the time to lead, etc).
Teams had a fairly simple operating model.
Your PM would tell you what they wanted in a semi-prioritised list and ask you how long each piece would take so you can make an informed prioritisation call together.
You’d then do a bunch of research and spikes to surface unknowns, run something like a t-shirt sizing exercise with the engineers to get a rough sense of timelines, and end up with a prioritised roadmap.
From that point onward, the team would be ready to do something like a quarterly kick-off, commit to projects, assign project leads, and make sure everyone had context on what we’d achieve in the next three months.
As an EM you’d stay very close to the team.
You’d coach and mentor engineers on the day-to-day, make sure important decisions were documented, help resolve conflicts, keep delivery moving, and make sure people were growing.
And because the team usually only had one or two meaningful projects happening at any given time, it was fairly easy to stay in the details.
You knew what was going on.
You had enough context to coach people effectively.
That’s not the case anymore.
A team of 8 engineers working on one or two projects just doesn’t feel like the norm anymore.
Instead, it increasingly looks like multiple groups of two engineers working on different initiatives in parallel.
AI has massively increased what a couple of engineers can deliver.
Features get built faster.
Iterations happen faster.
Experiments are cheaper.
The engineering bottleneck has reduced dramatically.
But product thinking hasn’t sped up at the same rate.
Product Managers still need to discover opportunities, validate ideas, prioritise work, align stakeholders, and define what success looks like.
That work still takes time.
So we’ve gone from engineering being the bottleneck (hence the 8-to-1 ratio of engineers to PMs)...
to product thinking becoming the bottleneck.
The interesting consequence is that a team of 8 engineers doesn’t really behave like one team anymore.
It behaves more like four.
Instead of one roadmap, you now have four workstreams.
Instead of one project lead, you have four.
Instead of one set of stakeholders, you have four conversations happening in parallel.
Instead of keeping track of one technical context, you’re switching between four.
That’s what has changed the Engineering Manager role more than anything else, at least in my experience.
PMs are stretched just as much as EMs are.
And maybe our team structures haven’t caught up yet.
Maybe the old-school structure isn’t quite right anymore.
Maybe a group of 8 engineers doesn’t need one PM.
Maybe it needs four.
But that also creates a new problem.
An EM suddenly isn’t supporting one team anymore.
They’re supporting four.
Something has to give.
Is it the “people” side of the role?
Or is it the “engineering” side?
In my opinion, it really shouldn’t be the people.
Career growth, coaching, feedback, hiring, difficult conversations... those things become more important as organisations move faster, not less.
So perhaps someone else needs to own more of the engineering side.
A Staff Engineer might be the answer.
Maybe the model evolves from:
Engineering Manager
Product Manager
Designer
8 Engineers
to something like:
Engineering Manager
Staff Engineer
4 Product Managers
2-3 Designers
8 Engineers
I’m not saying this is the answer.
I’m not even convinced this is what every team should look like.
But I do think we’re starting to optimise around a different constraint than we were ten years ago.
For a long time, engineering capacity was the limiting factor.
Today, I think product capacity increasingly is.
And if that’s true, I suspect the Engineering Manager role will continue evolving over the next few years.
I am not sure.
We’re all figuring this out together as we go, and these are simply my thoughts today.
Tomorrow they might differ.
If you have views or observations to contribute to the topic, please reach out.
I always enjoy learning from people who are seeing different things in their own organisations.
See you in the next one,
~ Stephane