👷 Nikol Got The Promotion But Kept Doing Her Old Job
The more senior you get, the less your tech skills carry you, but nobody tells you that before the promotion
This article is part of the Lead & Grow playlist. Click here to explore the full series.
This is not how you lead a team. You got the title, but are still thinking and acting like a senior engineer, who gets paid more.
I was harsh, but Nikol needed to hear this.
She came to me asking why her manager, and her own team, do not like working with her. I heard her side of the story, and my answer was instant.
I was harsh, but Nikol needed to hear this.
She came to me asking why her manager, and her own team, do not like working with her. I heard her side of the story, and my answer was instant.
I have seen this exact pattern too many times. I lived it myself.
How The Trap Sets In
You are the best engineer on the team. Every hard task goes to you, and nothing feels impossible with enough time. You help the junior engineers get unstuck before they even ask their manager.
So you get promoted. Not because anyone taught you how to lead, but because you are clearly the strongest engineer in the room, and the company had to put that title somewhere.
You don’t get any handover, training or mentor.
Everybody expects you to figure it out, because obviously you are the best engineer they have.
And while we are on the topic, bookmark Your First 60 Days as a Data Engineering Lead. I did this for leads who are never going to get a mentor handed to them.
The Promotion Changes The Job
Suddenly you own every project timeline on the team. You inherit:
roadmap conversations
headcount requests
standups you used to sit through half listening
You join stakeholder meetings and one to ones that used to belong to someone else. And underneath all of it, you are still trying to do the engineering work you did before, because that is where the real output is.
Nikol told me she was still reviewing every pull request on the team personally, the same way she did as a senior engineer.
I used to do the same. When a project slipped, the instinct kicked in, I got nervous, and made a comment about someone’s code quality or their speed, in front of everyone, in the standup.
Then I took the ticket back and finished it myself, faster than they would have.
That feels like leadership, but isn’t.
What This Looks Like Week To Week
It rarely looks dramatic from the outside. It looks like a string of small decisions that add up.
You rewrite a teammate’s PR instead of leaving a comment explaining what to change
You pull the ambiguous stakeholder request into your own inbox instead of pushing your team to scope it themselves
You stay the on call escalation point months after you should have handed it off
You measure a good week by how much you personally shipped, not by whether your team unblocked itself without you
Together, they tell your team you don’t trust them with the job you were supposedly promoted away from.
From Engineer To Operator
As an engineer, your output is your code, but as an operator, your output is your team’s code, and most of your day goes into things that do not look like work: conversations, decisions, unblocking, and deciding what not to build.
The instinct that made you a great engineer, write more, ship more, prove it yourself, is the instinct that now holds your team back. Here is what actually has to change, one reflex at a time.
Your Output Stops Being Your Own Work
The fastest way to check where you actually are: look at last week’s calendar. If most of it happened inside a codebase and not inside a conversation, you are still operating like an engineer with a bigger title.
The new measure is not how much you personally shipped. It is whether the work landed, whether your team is better than it was last quarter, and whether your manager can stop checking on your project without you noticing.
Stop Being The First Responder
You are the fastest debugger on the team, so you jump in and fix most incidents before anyone else even opens the alert.
That instinct solves the incident once. It also teaches your team to wait for you every single time, because you keep proving that waiting is faster than trying.
Nikol was the fastest responder on every incident her team had. That is not why her team resented her, but was one of the reasons nobody else on the team ever got faster.
Stop Translating Requests Into Tickets Yourself
A stakeholder asks for something vague, and you are the person who turns it into a scoped, technical ask in five minutes.
This is not your job anymore.
Every time you do the translation yourself, your team gets instructions instead of context. They stay one layer removed from the actual business problem, and you become the one person who cannot take a vacation without something breaking.
Sit in the stakeholder meeting. Let a senior engineer take the first pass at scoping the request. Correct it after, not before.
My team hates this, because this actually requires more effort than writing code. But this is how they grow.
Stop Avoiding The Conversation
Nikol never told her team their scope was wrong or their pace was too slow. She took the ticket back and fixed it herself, every time it happened.
The conversation is uncomfortable exactly once. Doing the work quietly and resenting your team for needing you to repeats every single sprint.
I recently read a post by Ryan Murphy asking if you can be a good manager if you hate conflict. An yes, you absolutely can. But you can’t avoid it.
As a leader you can’t avoid hard conversations. Not with stakeholders, not with your manager, and definitely not with team members. You are getting paid to have these conversations.
The more you avoid them, the deeper problems get. Bu do it with respect.
What Actually Makes You Effective Now
Here is the part that took me the longest to accept. The more senior you get as a leader, the less your technical skill is the thing carrying you.
At some point the job stops rewarding the person who solves the hardest technical problem personally, and starts rewarding the person whose team solves problems without them.
This is a completely different job.
Nikol is still leading with the one skill she trusts, because nobody told her the other skill exists. Nobody told her that her team was slow because she had never once told them, directly, what she actually needed from them.
What Making The Shift Actually Looks Like
The next time a project slips, do not open the ticket.
Ask what got in the way, not to assign blame, but to find the actual blocker. It might be unclear scope, a missing dependency, or a skill gap you can now train for instead of working around.
Then say the thing you were avoiding. Something close to:
I expected this by Thursday. It is Monday and it is not done. Walk me through what happened.
That sentence takes ten seconds, and does more for your team than three hours of rewriting their code ever will.
I built the resource library I wish existed when I was 25 years old.
Career scripts. Business translation templates. Stakeholder playbooks. Meeting frameworks.
Every single one came from real situations, real mistakes, and real results. Paid members get the whole thing.
The Operator Audit
Nikol did not fix this in the one conversation where I called it out. This change doesn’t happen overnight. But in the 2 months we worked together she got significantly better. She has the tools to deal with it now.
Here are the five points Nikol and I were working on. Run this audit occasionally and go wild. Score yourself if needed.
1. Your output
Did you write code this week to prove a point, not because nobody else could do it?
Before you open your IDE (I use neovim, btw), ask whether a teammate could do the task with the right context. If yes, give them the context instead of doing it yourself.
2. First responder
Were you the first person on the last incident, even when someone else was on call?
Next time, wait ten minutes before touching anything. Let the on-call engineer make the first move. Step in only if they ask.
3. Translating requests
Did you personally turn a vague stakeholder ask into a scoped ticket?
Next request, bring a senior engineer into the conversation and let them draft the first pass of the scope. Correct it after, not before.
4. Avoiding the conversation
Did you skip a hard conversation and hope the problem would resolve itself?
Book fifteen minutes this week with the person whose work you have been quietly redoing. Name the specific gap you have noticed. Ask what is actually blocking them.
5. Measuring effectiveness
Do you know if your team is better this quarter than last, without checking their commit history?
Write down one thing your team now does without you that they could not do three months ago. If you cannot name one, that is this month’s actual project.
Answer honestly on all five. Then pick one action and do it this week. Not all five. One.
—
Until next time,
Yordan
PS: Reading about the operator shift is free, but the guides, scripts, and frameworks that make it happen live in the paid tier.
PPS: If you are living Nikol’s exact situation right now, that is what coaching is for. Book a call and let’s build your plan instead of guessing your way through it.
Let’s Connect
Connect on LinkedIn: https://www.linkedin.com/in/ivanovyordan
Work with me: https://www.ivanovyordan.com/coaching
Start journaling: https://www.dearself.ai