You've just shipped something genuinely hard. Your manager knows it. Your team knows it.
The promotion doesn't come.
So you do what makes sense: you pick up a new framework, tackle a harder problem, push your code quality higher.
It still doesn't come.
The issue isn't your skills. It's that your manager is assessing you on things nobody put in writing.
So what can you actually do about it?
Learn to think like your manager.
You might still be thinking: "But we have a career ladder. I know exactly what Senior looks like at our company." You probably do. And your manager is still using mental models on top of it - consciously or not. Two of those models do most of the work.
Influence + Contribution
Everyone starts influencing, well, no one but the code.
Gradually, you move to influencing your peers, then your team, then the teams around you, then your department. And as your sphere of influence grows, so does your contribution - from individual tasks to a portfolio of projects.
There is no standard job title beyond Senior (here)The model's value is that it gives you a concrete way to evaluate where you actually are - not where you think you are.
Here's the exercise: list everything you've delivered in the last six months. For each item, ask who it actually affected. Your own output? Your team? Teams outside yours?
That's your current operating level. More importantly, it shows what would need to change to move up.
Clarity
"What's the plan for that service refactor?"
"We're still working on it."
Wrong answer. Not because you don't know - but because your manager was hoping you'd already figured it out for them.
As you grow, the ambiguity grows with you. A junior developer shouldn't expect much of it: the problem is defined, the solution is clear, the implementation is spelled out. But further up, the blank space expands.
Managers live in that blank space. The more of it you fill, the more valuable you become.
Think about the decisions your manager still makes that you could be making. The tickets that come back to you half-formed. The proposals nobody volunteers to write. Every one of those is an ambiguity you haven't claimed yet.
Setting your goals
The smartest move is to bring both models into your next performance conversation and translate them into concrete objectives.
Take whatever fits your situation - but notice what the examples have in common. None of them prove you can code harder. They prove you're already thinking at the next level.
Specificity matters here. "Increase my influence" is not a goal. "Lead the design session for the platform migration, document the decision, and present it to the team leads" is.
Putting it all together
Here's the process.
Reflect on everything you've shipped in the last six months. For each piece of work, place a checkmark in the diagrams: where does it land on influence, contribution, and clarity? You'll end up with an honest picture of where you're operating today.
Then write your new goals in terms your manager would use, not terms your IDE would recognise. Bring them to your next 1:1 and ask for feedback.
Whether or not you're already exceeding expectations, taking that step matters - because it signals that you're already thinking beyond your current level.
That's precisely what a promotion is supposed to confirm.
Does this guarantee one? No. Nothing does.
But it changes the conversation from "I deserve this" to "here's the evidence." And that's a much better place to start.
Post inspired by Laura Tacho, Gergely Orosz, and Ryan Peterman - worth reading if you haven't already.
Filipe Albero Pomar is an engineering manager and speaker based in London. He writes about AI adoption, engineering leadership, and software delivery. Find him at alpomar.dev.
TechLeadConf 2026 · GenAI London 2026
Top comments (0)