Junior → Mid Python in 18 months: a concrete promotion plan

The promotion equation

In every engineering org we've seen, junior → mid is decided on a small set of signals. Code quality is one of them, but it's not the limiting factor for most juniors — the limiting factor is scope and ownership.

A mid-level engineer can be handed a meaty problem and come back with the right thing built, without their manager needing to translate, unblock, or rescue. That's the bar. Code quality is necessary but not sufficient.

Six behaviours that move you up

Each of these is observable, and managers actively look for them in promo packets. Pick three and practise deliberately for a quarter — that's enough to start showing up in feedback.

• Write the design doc before writing the code. Even half a page. Especially when not asked.
• Take a ticket nobody wants. The legacy migration, the flaky test suite, the alert nobody owns. Visible, defensible, undeclined.
• Review other people's PRs. Not just LGTM — substantive comments, kind tone, specific suggestions. Cross-team is even better.
• Mentor a newer junior. Even informally. Promotions love 'made the team better'.
• Pre-empt your manager. 'Here's the status, here's the risk, here's the next step' before they ask.
• Write small public artifacts — internal blog posts, RFC docs, runbooks. They compound.

The 18-month timeline

Aggressive but achievable for a motivated junior in a healthy team. The pace assumes you're shipping production work, not just on a training programme.

• Months 1-3 — ramp. Onboard, ship 2-3 small features, learn the dev loop and the team's culture. Don't try to change anything yet.
• Months 4-9 — own. Ask for a mid-sized project — one you'd own end-to-end. Default to writing a one-pager before starting. Take at least one cross-team ticket.
• Months 10-15 — scope. Volunteer for the 'we should clean this up' kind of work. Mentor a newer hire. Write at least one internal post.
• Months 16-18 — promote. Build the packet with your manager: list of projects with outcomes, list of behaviours backed by feedback, list of peers who'd vouch. Promo committees love specifics.

What you should be reading

Specific, opinionated. None of these are 'optional reading' if you want to skip ahead.

• 'Staff Engineer' by Will Larson — the senior+ playbook. Read it as a junior to understand what's coming.
• Charity Majors' blog posts on observability and on-call. The 'I'm not on-call but I want to be ready for it' tier.
• The High Growth Engineer by Jordan Cutler — practical career moves, no fluff.
• Your own org's engineering wiki. Most juniors don't read it. You should.

What to stop doing

These are time sinks that feel productive but rarely show up in a promo packet.

• Chasing every new framework. Pick what your team uses and get sharp.
• Polishing your dotfiles for the 14th time.
• Side projects in isolation. If you do them, ship them, share them, write about them.
• Tutorial-binging when you could be doing the harder work of writing your own design doc.

What to do when promo gets denied

First time is common. Second time is a signal. Either way, the move is to leave the room with a written list of what would have made the difference — and a 90-day plan against it.

If your manager can't tell you what's missing, that's its own data point. Engineers who can't get specific feedback about what's blocking their promotion often need to switch teams or companies to grow.