I know the feeling when you ship more than anyone on your team and you know the platform better than your manager, and someone else still gets the lead role.
It feels like the rules changed and nobody told you, because you do more work than anyone else and the promotion keeps getting pushed to the next cycle.
When someone in the data (and sometimes in the engineering) org is up for a lead role, I’m one of the people who vote on whether they get it. We are usually a small committee of 2 to 4 people, and when a senior’s name comes up, what I want to know is whether they make their manager’s week lighter or heavier. How much they ship barely comes into it.
Your manager’s week is a plate, and everything you send them gets served onto it. Eating some of that dinner yourself is good for both of you, and that’s what this piece is about.
Read to the end, because I put together a set of scripts and AI prompts for the moments when a senior adds to their manager’s workload without meaning to.
Subscribe now to unlock today’s resource right here.
How to become a lead engineer as a senior engineer
You become a lead by taking work off your manager’s plate. You want to be a low-maintenance person for your manager, and being the best and fastest engineer on your data team doesn’t make you one, which is the part strong seniors hate hearing.
You become lead when you cost your manager less than you take off them.
The usual advice tells you to become a force multiplier, mentor juniors, and own a project. Fine, do all three. Just make sure none of it becomes more work for your manager, because that’s where I see strong seniors lose it.
You start mentoring a junior, and now your manager hears about the junior’s progress from you, settles the disagreements you two have about code style, and answers the junior’s questions you didn’t feel like answering. You own a project, and every scope question, every slipped date and every annoyed stakeholder on it still goes up to your manager for a call. You did everything the advice says, your manager got three new things to look after, and you got a nice line in your self-review.
So the advice is incomplete. Mentoring and owning things only count when the work around them stops at you, and if it doesn’t, all you did was add to the pile.
I know the objection, because I’d have made it myself. “Isn’t my manager supposed to deal with that stuff? That’s literally their job“. It is, and the person who becomes lead is the one who starts doing that job before anyone asks, because the lead role is mostly that job.
Does AI change how senior engineers get promoted to lead?
Yes, because AI made your output the cheap part of you, so a senior heading to lead doesn’t get there by becoming better and faster at coding. That is what we have AI for.
Everyone on your team ships more than they used to, and so does everyone else up for the same role, so output stopped telling us who’s ready a while ago. Twice the tickets closed this quarter means shit if the person you’re up against closed twice as many too, with the same AI open in another tab.
What you can’t hand to a model is the call on what to do next. And when I look at a senior, I look at how many of those calls still end up with their manager.
Give a model a vague problem and it hands you five options and asks which one you want. That’s useful when you’re the one choosing, and it’s exactly the behaviour I don’t want from a lead. If you take the five options to your manager and ask them to pick, you’ve turned yourself into a slower version of the tool.
Which is why the gap between seniors moved out of the code. Two seniors with the same model write roughly the same pipeline. One of them decides which pipeline to build, tells the stakeholder why the other one waits, and moves on. The other one asks. The first one is cheaper for their manager, and that’s the only difference I can see when I vote.
You still have to be good at the code, and a lead who can’t read a pull request is a problem of its own. Good code is the entry ticket now. It gets your name onto the list and does nothing to move it up.
Who decides whether a senior engineer becomes lead?
Usually four people decide whether a senior engineer becomes lead in our data org. Nowadays it’s me, my manager, our HR BP, and one business stakeholder who works closely with the data team. All four of us ask one question about the senior, whether they make their manager’s week lighter or heavier.
Keep that in mind the next time you go to your manager to complain about a stakeholder. Your manager remembers every one of those complaints, and the stakeholder you complained about might be the fourth vote. So now your manager has to smooth things over with that person before they can argue for you with that person voting.
Look at what each of those people sees. Your manager sees your week and theirs. The HR BP sees how often your name comes up in conversations they’d rather not have. The stakeholder sees whether working with the data team got easier or harder since you started handling their requests. And I see the pattern across all three. None of us sees your commit history, and none of us asks for it.
That stakeholder vote is the one seniors forget. You think of the business side as the people who send you badly written tickets. In the committee, they’re the person who says whether you’re someone they’d want to deal with every week as a lead. If every conversation they’ve had with you ended with “I’ll check with my manager”, they already have an answer.
Somebody still writes the case for you, and it still matters, but all four of us read it through the same question.
The question about you is whether you make your manager’s week lighter or heavier.
A great case about a heavy senior reads like a list of reasons to wait. A plain case about a light one barely needs defending, because everyone in the committee already knows what it’s like to work with them.
What makes a strong senior engineer high-maintenance?
If you ask me what makes a strong senior high-maintenance, it’s loads of issues with stakeholders, and more questions than decisions.
Being strong makes it worse, which is a bit unfair. The strongest engineer on the team sees the most problems and has the most ideas and the most questions about all of them, and every single one gets served to the manager.
Nick is the extreme version. He’s a much better programmer than the guy who got the team, and when I asked the CTO why, the answer was “Nick codes a lot“. I wrote the whole story up in why you’re stuck at senior because of what you believe your work is for.
Nobody calls it heavy, either. Your manager won’t tell you “you’re expensive”. They’ll tell you you’re doing great, the timing isn’t right, maybe next cycle. And they mean it, because each single question or complaint is small and reasonable. It’s the pile that costs them, and you never see the pile because you only see your half of it.
Here are the three things that build the pile fastest.
Ideas you bounce to see if one sticks
Don’t just bounce ideas all the time. When you throw an idea at your manager, they have to figure out if it’s worth doing, who it affects and whether now is the time, and all you did was add one more thing to their plate.
The annoying part is that plenty of your ideas are good. Your manager still spends as much time judging the good ones as the bad ones.
Do the maths from their side. You have five ideas this week, one of them great. To find the great one, your manager has to think through all five, and then they still have to figure out who does it. You had the fun part. They got the homework, and next week you’ll have five more.
Some ideas do need your manager, because they know where the budget is going or what their own manager wants this quarter. Take those to them with your call already made, something like “Here’s the idea, here’s what I’d do with it, and here’s the one thing you know that I don’t“.
The last line tells your manager you’ve already done the thinking you could do, and you only need them for the bit nobody else has. It turns a 30-minute discussion into a 2-minute answer, and it shows them you know where your knowledge stops, which is a lead skill in itself.
And the ideas you drop without telling anyone? That’s fine. Nobody promotes you for the list of things you thought about.
Stakeholder problems you hand to your manager
Stop complaining about stakeholders. When you complain, your manager gets the problem and the job of fixing it, and the fixing is what eats their week.
Most of what annoys you about a stakeholder you can fix yourself. A missed expectation, a request nobody wrote down, a priority they don’t know you have. Go fix those. Take your manager only what really needs them, like a budget or a fight about priorities between two teams, and tell them what you’ve already done about it.
I get why you vent. The stakeholder changed the requirements again, or escalated something that was never urgent, and you want someone on your side to know. But your manager can’t just listen. Once they know, it’s theirs. Now they have to decide whether to say something, to whom, and how, without making it worse for the team. You feel better for ten minutes and they have a new job for a week.
And remember who might be voting. Every complaint is also your manager learning that you and this person don’t work well together, and that’s the opposite of what they need to say about you later.
The fix is boring, and it starts with talking to the stakeholder before you talk about them, because when your stakeholder is wrong, it’s usually your fault for not checking what they assumed. Write down what they asked for, say what you can do and when, and send it. If it still goes wrong, you come to your manager with a much better story, one where you’ve already tried and they only need to step in for the part you can’t.
If you’re about to vent, run it through script 2 in the package first. It turns the vent into a message you can send to the stakeholder directly.
Questions without a decision
Come with decisions. A question with no answer attached means your manager does the thinking and then the deciding too, which is a crap deal for someone who already has their own week to get through.
“What should we do about the late finance dashboards?“ is a question. “The finance dashboards are late because their load runs last. I want to run it first from Monday, and nothing else moves. Okay?“ is a decision they can approve in one word.
The second version names the cause, so your manager doesn’t have to dig, and proposes one change with a start date. It also says what the change costs, which is nothing, so they don’t have to go check what else breaks, and it ends on a question that only needs a yes. You did nearly all the work, and they still get to own the call.
The objection here is fear of being wrong. What if you propose the wrong thing? Then your manager says “no, do this instead”, and you’ve lost a minute. That’s still cheaper for them than starting from a blank question.
Some questions only your manager can answer, about money or about what their own manager wants. Ask those once, and say which answer you’d pick if it were your call. Making that call without every answer in hand is the job, and strong leaders take executive decisions the same way.
What does a low-maintenance senior engineer do differently?
I was literally trying to manage myself. I took stakeholder management and mentored new joiners.
Both were my manager’s work, and the lead role is mostly that work, which is why a new lead who keeps doing their senior job struggles. Every stakeholder I dealt with and every new joiner I mentored was one less thing on their plate, and that’s all light means. Your manager stops doing something because you do it now, which is what eating their dinner looks like in practice.
Light has nothing to do with tickets, hours or a clever architecture, and you can be light while shipping less than the person next to you. The test is one question. Can you name one thing your manager did a month ago that they don’t do anymore because of you? If you can’t, you’re not light yet, however good your quarter looks.
It has to be your manager’s work, though. If a teammate keeps dropping their interruptions on you, that’s a different problem, and redirecting work that isn’t yours still holds.
Taking on everyone’s leftovers only makes you busy. Your manager doesn’t feel any of it, and you burn out doing work nobody in the committee will ever hear about.
Own the tool and the people who use it
To me, owning a tool or two and knowing the account managers before your manager has to are the same thing.
When you own a tool, you own everything around it. The renewal, the price increase, the vendor’s account manager and the business users who complain when it breaks. If you own the tool and your manager still takes the vendor calls, you got the fun half and they kept the shit half.
Knowing how the tool works is the technical half, and your manager never cared much about that half anyway. What they care about is the email from finance asking why the bill went up, the call with the vendor about the new pricing tier, and the business user who says the dashboard is broken when it’s the tool’s outage. That’s the half that eats their week, and it’s the half you have to take.
So meet the account manager yourself, before there’s a problem. Know when the contract renews and what it costs. Know who uses the tool and what they’ll yell about. When the renewal comes, your manager should get a short note from you with what you recommend, before the vendor ever gets a meeting into their calendar.
Don’t wait to be handed work
Don’t wait for your manager to give you work. Somebody has to find that work, explain it and check on it, and that somebody is your manager, so waiting is a lot more expensive for them than it looks.
The obvious objection is that you’ll pick the wrong thing. Sometimes you will. Pick something that clearly needs doing, tell your manager in one line that you’re doing it, and start. If it’s wrong, they’ll tell you, and that’s still one sentence of their time instead of a planning session. I go further into it in how to stop waiting for permission to lead.
Ask “What can I help you with?”
Always ask, “What can I help you with?“ Ask it any time, in Slack, at the end of a call or in a quick message, and don’t save it for a 1:1.
Asking is easy. Finishing the thing without going back for instructions is where most people fail. If you come back with a list of questions about the work you offered to take, you made the week heavier and called it help. When it’s done, tell them once, where it lives and that there’s nothing left for them to do.
The first few times you ask, expect a vague answer or “I’m fine, thanks”. Managers aren’t used to the offer, and handing work over takes trust they haven’t built with you yet. Ask anyway. Take the small thing they finally give you, finish it completely, and the next answer gets bigger. That’s how the plate moves to you, one finished thing at a time.
And pay attention to what they hand you. The tasks your manager gives away first are the ones they hate most, and those are usually the ones a lead ends up doing anyway.
Script 3 in today’s resource contains the exact words and a prompt for when your manager’s answer is vague.
Final thoughts
I didn’t even aim for a lead role, I just wanted a better future for the team. It happened naturally.
I’m not sure “naturally” is something I can teach you. What I can tell you is what I look at when your name comes up, and it’s your manager’s week.
The whole promotion, from the case to the number you ask for, is in Design Your Promotion, the course that comes with the paid subscription.
Before your next message to your manager goes out, ask whether it takes something off their plate or serves them more. Then send the one that takes something off.
—
Until next time,
Yordan
PS: If you want help with your own case before your name comes up for lead, take the founding membership. It’s everything in the annual membership, plus three one-to-one calls with me during the year.