How to Grow a Junior Engineer Into a Senior One

2026-08-04 · 11 min read · Career & Promotions

Most managers describe the junior-to-senior journey as a single arc: they get better at coding, they take on bigger things, eventually they're senior. That description is accurate and almost useless, because it doesn't tell you what to do on any given Tuesday.

In practice it's three distinct transitions. Each one requires a different thing from the engineer, and — more importantly for you — a different thing from you. Managers who treat it as one continuous ramp tend to over-support during the first transition and under-support during the third, which is exactly backwards.

This article is about the development practice: what you actually do, week to week, to move someone along. It assumes you already have some definition of levels — if you don't, or yours isn't working, start with building a career ladder first. And it deliberately stops at Senior, because the Senior-to-Staff transition is a different kind of change rather than more of the same; that one is covered in what a Staff Engineer actually does.

The Real Progression: Task → Feature → Ambiguity

Transition 1: From task to feature

A junior engineer starts by completing well-defined tasks. Someone else decided what needed doing and roughly how; their job is to implement it correctly.

The first transition is to owning a whole feature — including the parts nobody specified. This sounds like a small step. It isn't, because it's the first time the engineer has to make decisions where the correct answer isn't determined by the ticket. What should happen when this API call fails? Does this need pagination? Is this edge case worth handling now?

What they're actually learning: that most of engineering is deciding things, not typing things.

What you do here: be available and be specific. This is the phase where high-touch support is appropriate and effective. Pair, review early drafts, answer questions quickly. The mistake managers make in this phase is under-investing — assuming that a competent junior will figure it out and that asking a lot of questions is a bad sign. It isn't. Question volume is high here by design and it drops naturally.

What "ready for the next one" looks like: they start making the small decisions themselves and telling you what they decided rather than asking what to do.

Transition 2: From feature to project

The second transition is scope. A project is several features, usually spanning more than one part of the system, often with a dependency on someone else's work, and lasting long enough that things change mid-flight.

This is where a specific and very common failure appears: an engineer who was excellent at features struggles badly at projects, and both of you interpret it as a performance problem. It usually isn't. Project work requires skills that feature work never exercised — sequencing, identifying risk early, communicating status to people who aren't watching, and knowing when to escalate rather than push through.

What they're actually learning: that delivery is a separate skill from implementation, and that most project failures are communication failures rather than technical ones.

What you do here: shift from answering questions to asking them. The highest-value thing you do in this phase is ask "what's the riskiest part of this and when will you know if it's a problem?" — repeatedly, until they start asking it themselves. Resist the urge to sequence the work for them. If you break the project into a plan and hand it over, they've done feature work in a trench coat.

What "ready for the next one" looks like: they surface risks before you ask, and their estimates start being roughly right.

Transition 3: From project to ambiguity

The final transition is the one that actually makes someone senior, and it's qualitatively different from the first two. It's not a bigger scope. It's a different relationship to the problem.

A senior engineer is given a problem, not a project. Sometimes barely that — a symptom, a complaint from another team, a vague sense that something isn't working. Their job includes figuring out what the actual problem is, whether it's worth solving, and what solving it should look like, before any of the work you'd recognise as engineering begins.

What they're actually learning: judgment. Specifically, judgment about what deserves effort — which is the thing that no amount of technical skill substitutes for.

What you do here: this is where most managers over-help and stall people out. The instinct is to clarify the ambiguity, because you can, and because watching someone struggle with a poorly-defined problem is uncomfortable. But the ambiguity is the exercise. If you resolve it, you've removed the thing they need to practise.

What you should do instead is stay close on the consequences rather than the process. Let them define the problem wrong, and then have a real conversation about why the definition didn't hold. That conversation is the development. It's much slower than telling them, and it's the only version that works.

What "senior" looks like: you can hand them something genuinely unclear and stop thinking about it.

The Weekly Practice

The transitions above happen over quarters. What you do about them happens weekly, and it's mostly unglamorous.

Assign for growth, not just for throughput. The single highest-leverage lever you have is who gets which work. Most managers assign work to whoever will complete it fastest — which is locally optimal and developmentally flat. At least some assignment should be deliberate: this person gets this piece specifically because it's slightly beyond what they've done before.

The heuristic that works is roughly 70% work they can do confidently, 30% work they can't do yet. Below that, they stagnate. Much above it, they flounder and lose confidence, which sets them back further than the stretch gained.

Debrief the work, not just the outcome. A shipped feature is an opportunity that most managers waste. "That went well" is not a debrief. "What was the hardest decision in that, and how did you make it?" is — because it forces them to make their own reasoning explicit, which is how tacit judgment becomes transferable.

Give feedback about judgment, not just execution. Most feedback juniors receive is about output: the code, the tests, the delivery. The feedback that actually accelerates people is about their decision-making — "you spent three days on the caching layer before validating that caching was the bottleneck." That's uncomfortable to give and it's the thing that moves them. See feedback that lands for the mechanics.

Track the trajectory, not just the snapshot. Growth is slow and mostly invisible week to week. If you're not writing anything down, your assessment at review time will be dominated by the last month and by whatever was most visible. Logging impact stories as they happen solves this and gives you the evidence base for the eventual promotion document.

Where People Get Stuck

The competence plateau. Someone becomes genuinely excellent at their current level and stops moving. Everything they're given, they do well. This looks like success and is often rewarded as such, which reinforces it. The cause is almost always that they've stopped being given work they can't already do — usually because they're so reliable that you keep giving them the things that need to land.

The fix is uncomfortable for both of you: give the reliable work to someone else and give this person something they might not pull off.

The specialist trap. An engineer becomes the person who owns one system. They go deep, they're indispensable within that boundary, and their growth in every other dimension stops. This is comfortable — for them, because they're an expert; for you, because that system is covered.

It caps them at senior-in-one-area, and it's fragile for the team. Rotation is the only real fix, and it costs short-term velocity. Do it anyway, before the dependency becomes structural.

The invisible contributor. Someone is doing genuinely senior-level work — unblocking others, catching problems early, doing the unglamorous maintenance that prevents incidents — and none of it is visible in a form that supports a promotion case. This disproportionately affects quieter engineers and, systematically, engineers from underrepresented groups. See the hidden cost of ignoring low-visibility engineers for how to catch this.

Mistaking tenure for readiness. Three years in the role is not evidence of senior capability, and treating it as such is how you end up with an engineer who has the title and not the judgment. The reverse error is more common though: holding someone back because they haven't served enough time despite consistently operating at the level.

The AI Complication

There's a new failure mode that didn't exist five years ago, and it specifically targets this journey.

Junior engineers develop judgment by struggling productively. The confusion when your approach doesn't work, the hour spent tracing why, the eventual realisation about how the system actually behaves — that friction is the mechanism. It's not an inefficiency in the learning process; it is the learning process.

AI assistance can remove exactly that friction. The model provides a working answer before the struggle produces understanding. The output is fine. The developmental value is zero.

This produces an engineer who ships at a respectable rate and has no foundation underneath — which is invisible for a surprisingly long time, because most work doesn't require the foundation. It becomes visible when they hit something genuinely novel, or when they're asked to make a design decision, or when they move into the ambiguity transition and have nothing to reason from.

The answer isn't to ban the tools; that's neither enforceable nor good for them. It's to be explicit that some work is deliberate practice:

For the broader team-level version of this problem, see what changes when AI writes most of the code.

How Long Should This Take?

Roughly two to four years from junior to senior for someone on a healthy trajectory, with enormous variance based on the environment more than the individual.

The environmental factors that matter most:

Rate of meaningful reps. A team shipping real things to real users every couple of weeks develops people several times faster than a team on annual release cycles. The number of complete build-ship-learn cycles someone experiences is probably the single strongest predictor.

Access to people who are better than them. Not formal mentorship — proximity. Reviewing code written by strong engineers, being in design discussions, watching how a senior person approaches a problem they haven't seen before.

Exposure to consequences. Engineers who never see what happens after their code ships don't develop judgment about what matters. On-call rotations, ownership of production behaviour, and involvement in incident review compress this timeline substantially.

If someone is stalling, look at these three before concluding it's about the person. The most common cause of slow growth is an environment with few reps, little exposure to stronger engineers, and no feedback loop from production.

The Thing That Actually Matters

The transition from junior to senior isn't accumulating knowledge. Plenty of engineers know a great deal and aren't senior. It's the accumulation of judgment — knowing which problems deserve effort, which risks are real, when to go deeper and when to ship, and when the elegant solution isn't worth what it costs.

Judgment is built from consequences. Every time an engineer makes a call and finds out whether it was right, judgment accrues. Every time you make the call for them, it doesn't.

The best thing you can do for a junior engineer is give them decisions to make and let them find out how those decisions went — with enough support that failure is survivable, and enough distance that it's genuinely theirs.

Once they're consistently making good calls on problems you didn't define, they're senior. What comes after that is a different kind of change — the Staff transition is about scope of influence rather than scope of work, and it's not simply more of this.

Emtricks lets you track each engineer's growth alongside 1:1 notes, goals, and GitHub activity — so the trajectory is visible long before review season. Try it free for 30 days.