Senior is less about years and more about scope: you own ambiguous problems, make sound technical decisions others rely on, and make the people around you more effective. Pick work with real uncertainty, write down your decisions and trade-offs, invest in others, and make that impact visible to the people who decide promotions.
What people tell me
I have been a mid-level developer for a few years. I deliver features reliably and people come to me with questions about the parts of the system I know. But I am still not considered senior, and when I ask what is missing I get vague answers like 'more impact' or 'more ownership'. I do not know what that means in practice or how to show it.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Senior engineers are trusted with ambiguous problems, not just well-defined features.
- Your judgement becomes the product: design choices, trade-offs and saying no to the wrong work.
- Making others better counts: reviews, mentoring, documentation, better processes.
- Translate vague feedback like 'more impact' into two or three specific behaviours with your manager.
- Write things down. Design documents and decision records make senior-level thinking visible.
Why "more impact" feels so vague
At mid-level, success is fairly concrete: take a feature, build it well, ship it. At senior level, the job changes shape, and that is why feedback becomes fuzzy. Managers often know what senior looks like when they see it, but struggle to describe it.
Here is a more concrete version.
| Area | Mid-level | Senior |
|---|---|---|
| Problems | Well-defined features | Ambiguous problems that need framing first |
| Decisions | Implements agreed designs | Proposes designs, explains trade-offs, gets agreement |
| Scope | Own tasks and features | A system, or a cross-team piece of work |
| Risk | Flags risks when noticed | Anticipates risks and plans for them |
| Others | Helps when asked | Actively raises the level of the team |
| Communication | Updates on own work | Writes for and aligns several people |
| Saying no | Rarely | Pushes back on low-value or risky work, with reasons |
Step 1: turn vague feedback into specifics
Take the table above to your manager and ask:
"Of these, which two would make the biggest difference to how you see me? Can you give an example of someone doing them well here?"
Write down the answer and agree how you will check progress. This removes most of the vagueness.
Step 2: take work with real ambiguity
Senior engineers get the messy problems: "checkout is slow sometimes", "we need to replace this old service", "the data sync keeps breaking". Ask for one. Then:
- Frame the problem. What is actually happening, for whom, how often, and what does good look like?
- Explore options. At least two, with costs and risks.
- Recommend one and explain why.
- Deliver it, including the boring parts: migration, monitoring, documentation.
Step 3: write your decisions down
A short design document or decision record is one of the clearest signals of senior thinking. Include the problem, options considered, the choice, the trade-offs, and what would make you revisit it. It invites review, shows your reasoning, and creates a record that outlives the meeting. How do I explain technical ideas to other engineers? helps with the writing side.
Step 4: raise the level of the people around you
- Give code reviews that teach, not just approve. How do I give constructive feedback without creating conflict? covers tone.
- Pair with a newer engineer on something tricky.
- Fix the recurring pain: flaky tests, slow builds, missing runbooks.
- Share what you learn in a short write-up or team session.
Step 5: make it visible
Keep a record of work with outcomes. The brag document approach works at every level. At senior level, include decisions you influenced and problems you prevented, not just features you built.
A six-month plan
| Months | Focus | Evidence |
|---|---|---|
| 1 | Agree the two or three gaps with your manager | Written summary of expectations |
| 2 to 3 | Lead one ambiguous project from framing to delivery | Design document, delivered result |
| 4 | Mentor one person, improve one team process | Their progress, before-and-after metric |
| 5 | Drive one cross-team conversation or decision | Decision record with agreement |
| 6 | Collect evidence, ask for a promotion discussion | Brag document with dated examples |
The Mid-level to senior roadmap breaks these into stages, and the blog post Twelve Moves That Take You From Mid Level to Senior adds more specific moves.
Common mistakes
- Chasing complexity instead of impact. A clever rewrite nobody needed is not senior work.
- Being the hero who fixes everything alone. Senior engineers make themselves less necessary, not more.
- Avoiding writing. If your thinking is only in your head, nobody can see it or build on it.
- Waiting for permission to lead. Most senior behaviour can start before the title.
- Ignoring the company's context. At some companies, senior means depth; at others, it means breadth across teams. Ask.
If the company cannot promote you
Sometimes there is no senior slot, no budget, or no path. If you have done the work and have evidence, it becomes a strong case for a senior role elsewhere. I have years of experience but feel lost. What should I do next? may help if you are weighing that.
If you are still stuck
Read The Software Engineer's Guidebook for a longer look at each level. If you want your promotion case looked at by someone who has seen many, join Sefism. It is free to learn, you get credits when you join and your first roadmap is free. Members can ask their own question or book a 1:1 session.
Was this answer helpful?
Read next
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open: sign up and your account is active shortly after. Prefer to talk? A free call works too.