Sefism Mid-level to Senior Roadmap

What this roadmap is

The Sefism Mid-level to senior roadmap is a plan for the hardest promotion to get by working harder: the step from shipping reliably to owning outcomes. It treats seniority as scope rather than years, meaning how much ambiguity and responsibility you can handle without being told what to do, and walks through the six habits that show it.

By the end you should have:

• The expectations for the next level, from your manager, in writing, and a monthly check against them.
• One unowned problem fixed end to end, with before and after numbers.
• Design docs and decision records that turned technical debates into decisions.
• A visible effect on your team's output through reviews, mentoring and tooling, not only your own tickets.
• A brag document and a habit of regular updates, so your manager and peers can describe your impact.

There is no course to finish here. Most of the roadmap is work you do in your current job, with Sefism supplying the order, the checklists and the vocabulary.

Who it suits, and who should start elsewhere

It suits engineers with a few years of experience who ship reliably and are now hearing "you need more impact" or "operate more independently" without knowing what that means in practice. It also fits newly promoted seniors who want to do the job well.

If you are in your first year, Your first tech job covers the earlier habits: pull requests, asking for help, visibility in a team. If you are already senior and thinking about staff roles or engineering management, Staff and leadership picks up where this one ends. If the honest answer is that your current company cannot offer next-level work, Job search is the practical companion to stage six.

Prerequisites and realistic time

You need a job on an engineering team and a manager you can talk to. There are no technical prerequisites beyond being comfortable in your codebase.

The six stages add up to about 145 hours. At Sefism's default of about 5 hours a week that is roughly 29 weeks; at 8 hours a week, about 20 weeks; at 12 hours a week, about 15. In reality the calendar is set by your work: several milestones ask for something sustained, such as a quarter of mentoring or three months of a brag document, so stages overlap.

A sample week while working full time (about 5 hours on top of your job): 30 minutes on Friday for the brag document and a note on what moved; one hour of reading for the current stage; two to three hours inside your normal work spent on the stage's milestone, such as measuring the flaky test suite or drafting the design doc; and one 15-minute slot in your one-on-one to check progress against the bar.

A sample week for someone between roles or on a lighter load (about 8 hours): add a deeper reading block on design docs or reviews, write up one past project as practice for a design doc, and use the stage six exercise to decide which direction you want next.

Stage by stage

1. Seniority as scope, with a clear bar (10 hours)

Topics: seniority as scope, not years; handling ambiguity; impact over output; your company's level framework; the gap to the next level; getting the expectations in writing; monthly progress check-ins; and, optionally, performing at the next level first. The checklist has you read your company's career ladder (or Engineering Ladders if there is none), rate yourself against the next level with one real example per rating, ask your manager what separates your work today from the next level, and send their answer back as three to five written expectations.

Milestone: a one-page document, confirmed by your manager, listing what separates you from the next level and two or three pieces of work that would demonstrate it. Tauseef's note: hoping to be noticed is not a plan, and if your manager cannot describe the bar, that tells you something too.

2. Ownership and leverage (30 hours)

More tickets and longer hours have a ceiling. Topics: what ownership means, leverage as impact per hour, finding unowned problems, choosing the problem and saying no, measuring before and after, root causes over workarounds, automation and internal tooling, and optionally simplicity and fewer dependencies. You list five recurring pains (flaky tests, slow builds, manual steps, noisy alerts, neglected services), agree with your manager that you own one, measure it first, fix the cause and add a check so it does not come back.

Milestone: fix one unowned problem on your team end to end and share a short write-up with before and after numbers.

3. Own the design: write to decide (40 hours)

Debates settled by opinion come back every quarter. Topics: what a design doc is for, goals and non-goals, trade-off analysis, one-way and two-way doors, estimates as ranges rather than promises, running a design review, architecture decision records (ADRs), and optionally design patterns and SOLID as shared vocabulary. A design doc with one option is a sales pitch, so the stage asks for alternatives, ranges with written assumptions, and a review from a senior engineer and from someone on a dependent team.

Milestone: write a design doc for a real change on your team with at least two rejected alternatives, get it reviewed, and record the final decision as an ADR in the repository.

4. Multiply the people around you (30 hours)

Your own output has a ceiling; your team's does not. Topics: becoming a force multiplier, code reviews that teach, coding standards that end style debates, using design principles in review comments, mentoring a less experienced engineer, unblocking and pairing, direct and kind feedback, and optionally documentation that spreads knowledge. Automate formatting so reviews stop covering style, give the reason in every comment that asks for a change, and spend 30 minutes a day unblocking someone.

Milestone: mentor one engineer for a quarter with fortnightly sessions towards a goal they chose, and get your team to agree written code review guidelines.

5. Visibility without politics (15 hours)

Good work that leaves no trace is invisible at promotion time. Topics: keeping a brag document, regular updates to your manager, writing up incidents and outcomes, asking for peer feedback, sharing work beyond your team, mentors and sponsors, writing a self-review, and optionally promotion packets and calibration. The habit that matters most is small: add to the brag document every Friday while details are fresh.

Milestone: keep a brag document for three months, send your manager a monthly update, and collect written answers from two peers on what you should do more of and less of.

6. Influence and choosing your direction (20 hours)

Senior engineers get things done without authority, through clear writing, sound reasoning and trust. Topics: persuasion through writing and reasoning, talking one to one before the meeting, building trust across teams, disagree then commit, choosing deep, broad or leadership, IC and manager tracks (optional), and knowing when to move on. If there has been no next-level problem for a year and your manager cannot find one, the roadmap is clear that moving is a legitimate choice, not a failure.

Milestone: get a change adopted by another team through a written proposal, and write a one-page two-year plan naming deep, broad or leadership, with the evidence behind the choice.

How it works on Sefism

The public page at /roadmaps/career-growth/ shows all six stages, with the first two stages open to read: topics, milestone, Tauseef's advice, the checklist and the resources picked for each stage, such as the Path to Senior Engineer Handbook, Engineering Ladders, Software Engineering at Google, Google's engineering practices and Julia Evans on brag documents.

Everything here is free to learn from. Adding the roadmap to your dashboard uses credits: your first roadmap is free, and new members get starting credits for more. Once added, every stage opens, you can tick off topics and milestones, each topic gets a self-check question and an AI prompt that quizzes you instead of answering for you, and the companion cheat sheet comes with it. Career questions rarely fit a template, so you can send Tauseef a question about any stage, or book a 1:1 session to talk through your two-year plan. Create a free account to start.

The companion cheat sheet

The Mid-level to senior cheat sheet follows the same six chapters with 47 concepts, from scope and level frameworks to calibration, sponsors and disagree-and-commit, plus a design doc outline and a sample ADR. Use it to revise each stage and before your own promotion conversations.

Related on Sefism

• How to go from mid-level to senior software engineer
• How to get promoted faster in a large company
• How to think like an engineer instead of just completing tasks
• How to give code review feedback without creating conflict
• Tech lead, engineering manager or individual contributor
• Twelve moves that take you from mid level to senior
• Library: Path to Senior Engineer Handbook, Engineering Ladders, Get Your Work Recognized: Write a Brag Document
• Related roadmap: Software design if stage three shows a gap in design fundamentals

What you can do afterwards

You will be able to point at specific evidence for each line of a senior level description: a problem you owned with numbers, decisions you wrote down, people you grew and a change another team adopted. That evidence serves a promotion case at your company or a move elsewhere. From here, Staff and leadership covers architecture across teams, leading projects and incidents, and communication at a wider scope.

FAQ

How long does it take to go from mid-level to senior? The roadmap estimates about 145 hours of focused effort, but the timing is set by your organisation: a promotion needs sustained evidence, such as a quarter of mentoring and three months of documented impact. Ask your manager whether the next level is realistic in the next 12 to 18 months.

Is seniority about years of experience? No. The roadmap defines it as scope: how much ambiguity and responsibility you can handle without being told what to do.

Do I need to be the best coder on the team to be senior? The roadmap puts the weight elsewhere: owning problems, writing decisions down, multiplying the people around you and earning trust. Strong code is assumed, not the differentiator.

What if my company has no career ladder? Use a public framework such as Engineering Ladders, then agree three to five written expectations with your manager.

Should I change jobs to get promoted? Sometimes. If there has been no next-level problem for a year and your manager cannot find one, moving is a legitimate choice. Try the in-place route in stages one to five first, so you have evidence either way.