The role
Leading senior engineers when you are new to the job
A newly promoted lead's first instinct is usually to demonstrate value, and with senior engineers that instinct is almost exactly wrong. They do not need your technical direction, and several of them know the system better than you do. What they need is a set of things only the role can supply, and almost none of it looks like leadership from the outside.
What a senior engineer is actually short of
Ask a senior engineer what slows them down and you will rarely hear anything about their own skill. You hear about waiting: for a decision, for access, for another team, for someone to say which of three things matters most. That is the job description.
| Scarce for them | What the lead supplies |
|---|---|
| A decision that is actually made | Make it, or name who will and by when. An open question costs more than a wrong answer that can be revisited |
| Priority among things that are all “important” | An ordering you will defend upward when it is questioned |
| Context they cannot see | Why the work exists, what changed, what the business is actually worried about |
| Uninterrupted stretches | Absorbing the interruptions rather than forwarding them |
| Their work being visible to people who matter | Saying, accurately, who did what |
The first mistakes, in the order they usually happen
- Reviewing to prove you still can. A new lead who leaves the most comments on the most pull requests is telling the team where their attention went. Review where you add something nobody else can — architectural consequence, a cross-team implication, a risk the author cannot see from inside the change.
- Taking the interesting work. It is the fastest way to lose a senior engineer, and it is almost always rationalized as urgency.
- Relaying pressure instead of absorbing it. Passing a deadline down unchanged adds nothing; a lead's value is in what they convert — into scope decisions, sequencing, or a conversation upward that should have happened before the date was set.
- Managing disagreement as a threat. A senior engineer arguing with you is usually doing the job. The thing to worry about is the one who stops.
Disagreement is the whole skill
Most of what makes this hard is one situation: a senior engineer thinks a decision is wrong and you have to decide anyway.
A workable sequence is to separate three questions that get tangled. Is this reversible? If it is, bias hard toward letting them try it — the cost of being wrong is a week, and the cost of overruling is a person who stops offering. Do we disagree about facts or about values? A factual disagreement has an experiment; a values disagreement (speed against durability, coverage against velocity) does not, and pretending otherwise produces a rigged experiment. Whose call is it? Say so explicitly, before the discussion, not after it goes badly.
When you do overrule, say that is what you are doing and why, and do not dress it as consensus. Senior people can work with a decision they disagree with. What they cannot work with is being told they agreed.
One-on-ones change shape
The status-update one-on-one is worse than useless with senior engineers — you both already know the status. See one-on-ones for the general shape; with senior people the useful material is different:
- What is blocked that they have stopped mentioning because nothing happened last time.
- What they think is going to break in six months. They usually know, and usually have not been asked.
- What they want to be doing in two years, which is the only reliable way to keep them.
- Where they think you are wrong. Ask directly; it does not arrive unprompted.
Growth without a promotion to offer
Senior is where the ladder gets narrow, and a lead often has no next rung available. Pretending otherwise costs credibility. What is usually available: ownership of something consequential end to end, the design authority on a problem rather than a task, mentoring that is recognized as work rather than added to it, and exposure to the people whose decisions constrain them. See career ladders for how those map onto levels, and measuring engineering work for why individual output metrics behave badly at this level in particular.
A note on AI-assisted work
Senior engineers are frequently the most skeptical of assistant-generated code and frequently the most effective users of it, which is not a contradiction — they are the ones who can tell when it is wrong. Treat their skepticism as review capacity rather than resistance, and be specific about what the team's policy actually requires. See AI coding assistant policy and reviewing AI-generated code.
The test
A short one, after six months: do the senior engineers on your team bring you problems before those problems are visible elsewhere? If they do, the relationship works. If you are finding out at the same time as everyone else, the issue is not their communication.
Last reviewed 2026-09-20