Leading engineers who know more than you
The job isn't to add knowledge. It's to subtract what's in their way.
👋 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.
Last week I saw a post on Reddit from a Tech Lead who was very concerned.
He’s been working at his company for eight years and doing pretty damn well. Two of them as a tech lead for a small team of juniors. Then his company decided to move him to a different team that was more complex and only had senior engineers.
His expectations remained the same in principle, leading the team - but he was freaking out.
“I have never led senior developers before, so I am going crazy thinking about how I am supposed to lead a team that knows more than me.”
That initial panic is natural and makes sense. But when you realise that a leader’s job is not to be the most knowledgeable person in the team, then the feelings of panic start to dissipate.
On a team of juniors, you can lead effectively by knowing more and teaching it. On a team of seniors, it’s exactly backwards. Leading seniors is actually lighter work than leading juniors.
Leading seniors is a subtraction game
For most of your career, your value was what you added. Your code, your answers, your knowledge of the system. Promotion to lead a junior team rewarded the same thing: you were the person who could unblock anyone because you knew the most.
A team of seniors has different demands. They already know more than you about their corner of the system. If your value is the technical knowledge you add, you have almost nothing to offer on the thing you used to be measured on.
So stop trying to add. Start subtracting.
I love these quotes:
“Never tell people how to do things. Tell them what to do, and they will surprise you with their ingenuity.” ~ Patton
“It doesn’t make sense to hire smart people and then tell them what to do; we hire smart people so they can tell us what to do.” ~ Steve Jobs
Your job is not to be the smartest. Your job is to clear the path so the smart people you’ve got can operate effectively.
Your output stops being measured in things produced and starts being measured in things removed.
The cost of adding yourself
Subtraction isn’t a soft, feel-good idea. The thing you’re removing has a price tag.
Gloria Mark’s work at UC Irvine put a number on interruption: after you’re pulled off a task, it takes an average of 23 minutes and 15 seconds to get fully back into it. Now multiply that by a team of senior engineers doing the most cognitively demanding work in your org. Every “quick question”, every status meeting you didn’t need to schedule, is a 23-minute tax on your most expensive people.
Microsoft’s Work Trend Index found weekly meeting time up 153% since 2020, with most knowledge workers reporting they don’t have enough uninterrupted focus time.
70% of the variance in team engagement comes from the manager. You are the single biggest variable in whether your team does its best work or not because you control how much friction reaches them.
The three things worth removing
If your value is subtraction, what exactly are you subtracting? Three things, in order of how much they cost the team.
One: ambiguity. Seniors don’t need you to tell them how to build. They need you to tell them what’s worth building and why. That means turning a vague leadership ask into a crisp problem statement, killing the three competing priorities so one survives, and saying what the team is not doing this quarter. The skill here is making the implicit explicit. This is the work behind the question no one on your team will ask - usually because asking it has been made too expensive.
Two: politics. The instinct is to be a shield: absorb all the organizational nonsense so the team never sees it. Jade Rubick has a warning about that in his “shit shield” piece - pure shielding turns you into a bottleneck and infantilizes senior people who are perfectly capable of navigating the org themselves. You don’t have to absorb politics. You need to translate it. Make the organizational friction visible and navigable, decide which parts the team genuinely shouldn’t spend attention on, and hand them a clear map of the rest. When a senior stakeholder keeps bypassing you to go straight to your engineers, or your PM keeps overcommitting on the team’s behalf, translation is what protects them without making them dependent on you.
Three: your own “how”. You see a senior making a technical call you’d have made differently, and every instinct tell you to step in. Don’t reach for the “how”. This is also where I’ll disagree with the people who say technical credibility doesn’t matter at all. Charity Majors is right that the best engineering leaders stay close to the work - you do need enough technical depth to follow the conversation. But you spend that depth on framing the problem, not dictating the solution. Will Larson’s rule for staff-plus engineers is the one to steal: hand them the problem space, not the answer. The military calls it commander’s intent - the leader owns the what and the why, the people executing own the how. Netflix calls it “context, not control”. On a senior team it’s the only thing that works.
The moment you reach for the “how” with a senior, you break the exact thing you hired them for. I went deep on that failure mode in you hired senior engineers to think, but you keep telling them what to do. And because every senior needs a different amount of context, treating them all the same is not fair - calibrate per person.
So what do you actually do?
Knowing what to subtract is the easy part. Doing it in a brand-new team, in your first 90 days, without either overstepping or disappearing, is the hard part.
So I built a week-by-week plan for the first 90 days that’s built entirely around removing friction, earning trust, and installing an operating rhythm a senior team will actually find valuable.
Here’s the first-90-days subtraction playbook, week by week:
