Grow a Junior to Mid-Level — Mentoring Engineers, Part 7
Mentoring Engineers · Part 7
Eighteen months in, a junior engineer asks their lead what they need to do to get promoted. The lead says, honestly, "Keep doing what you're doing. You're close." Six months later they ask again and get the same answer. At month thirty they accept an offer elsewhere, as a mid-level engineer, at a company that wrote down what mid-level meant.
Nothing was wrong with the engineer's code. The problem was that "close" was never turned into evidence. The lead had a feeling about the gap but had never named it, so the engineer couldn't close it.
Junior to mid is the most teachable promotion on the ladder because the gap is concrete: it's independence on work of a defined size. This part shows how to make that gap visible, grow it on purpose, and know when it's closed. The working claim: most juniors don't stall on coding skill. They stall on scoping: turning a vague ask into a plan they can execute without coming back for direction.
Before you start
Get your company's written career ladder, if one exists. If it doesn't, Dropbox publishes its engineering career framework openly, and it's a reasonable reference for what each level is expected to own.
Pull the last ten pieces of work your mentee shipped. For each, note how big it was and how often they needed direction. You'll use this as a baseline in Step 1.
Book a recurring 1:1 if you don't have one. Growth conversations need their own slot. Run Effective One-on-Ones covers the format.
Step 1: Define mid-level as independence at a size (15 min)
Ladders describe mid-level in phrases like "delivers features independently" and "operates with minimal supervision". Those are true and hard to coach against. Turn them into something you can observe: the size of work the engineer can take from a vague ask to production without needing direction.
A practical scale:
Size | Typical ask | What independence looks like |
Task | "Fix this bug", 1–2 days | Ships it with normal review |
Feature | "Let users export reports", 1–2 weeks | Breaks it down, finds the edge cases, ships it |
Multi-part feature | "Add multi-currency to invoicing", 3–6 weeks, touches two other teams | Writes a short plan, coordinates the dependencies, ships in increments |
A junior is independent at task size. Mid-level means reliably independent at feature size, and starting to handle multi-part features with support.
Now grade the ten pieces of work from your baseline. For each, mark the size and whether they needed direction partway through. "Direction" means you, or someone else, had to say what to do next, not that they asked a good question.
Test you can run: if your mentee is independent on most tasks but needed direction on most features, you've found the gap. It's specific, and you can show it to them.
Step 2: Grow scope one size at a time (15 min)
The common mistake is to jump straight from tickets to "own this project". The engineer flounders, the lead quietly takes over, and both conclude they weren't ready.
Grow one step at a time instead, and stage the support:
You scope, they build. You write the breakdown. They implement it and flag what you missed.
They scope, you review before they build. They write the breakdown; you spend 20 minutes on it with them before any code is written.
They scope and build. You review at the end. You only see the PR and the outcome.
Each feature-sized piece of work moves them down one stage, but only when the previous stage went well. Two clean features at a stage is a reasonable signal to move on.
Test you can run: for your mentee's last three features, which stage were they at? If all three were "you scope, they build", they've had no practice at the skill that defines the level.
Step 3: Teach scoping as a written artifact (20 min)
Scoping is invisible when it happens in someone's head, so you can't coach it. Make it a short written artifact. For feature-size work, one page:
Goal: what the user can do when this ships, in one sentence.
Out of scope: what we are deliberately not doing.
Unknowns: things I need to find out before I can estimate.
Steps: 4–8 increments, each shippable or testable on its own.
Risks: the one or two things most likely to go wrong.
Estimate: per step, with the uncertain steps flagged.
The section that teaches the most is Unknowns. Juniors tend to estimate the work they can see and get surprised by the work they couldn't. A plan that lists unknowns first, then resolves them with short spikes, is how mid-level engineers stop missing estimates. It's also the discovery move: most feature overruns start with a question nobody asked in week one, such as "does the export need to include archived reports?"
Review the first few plans with one question: what will you learn in the first two days that could change this plan? If they can't say, the unknowns section isn't finished.
Test you can run: compare your mentee's estimate with what actually happened on their last feature. If the overrun came from something they could have found out in the first two days, scoping is the skill to work on, not speed.
Step 4: Build judgment through review and on-call (15 min)
Two activities build mid-level judgment faster than more feature work.
Reviewing code. Have them review real PRs in an area they know, with a senior also reviewing. Then compare: what did the senior catch that they didn't? Over a month, the gap between the two reviews is a direct measure of their judgment. Coach the misses specifically: "You approved this, but the retry loop has no backoff. What would you look for next time?"
On-call, staged. Shadow first, then primary with a named backup, then the normal rotation. On-call teaches what features do in production, which is the context juniors usually lack when they scope. The timing depends on your systems and how heavy your on-call is. Don't attach dates to it. Move them on when they can handle the previous stage without escalating routine issues.
Test you can run: over their last ten reviews, how many substantive issues did they raise that the senior reviewer didn't? Zero after several months means they're approving, not reviewing.
Step 5: Name the gap in writing, with an observable bar (10 min)
Back to the opening: the lead's mistake was keeping the gap in their head. Write it down in your 1:1 notes, in terms the engineer can check without asking you:
Gap: needs direction partway through feature-size work (3 of last 4 features).
What "closed" looks like: next two features scoped in writing, reviewed once
before build, shipped without mid-course direction.
Check-in: end of next month.
Notice what's absent: personality ("needs to be more proactive"), comparison with others, or an open-ended "keep going". Correll and Simard's 2016 analysis of performance reviews in technology and professional services firms found that vague feedback, not tied to outcomes, held people back, and women in particular got more of it. A written, observable bar is the fix for everyone.
Test you can run: could your mentee read your notes and tell, without asking you, whether they've closed the gap? If not, rewrite it until they could.
Step 6: Assemble the promotion evidence as you go (10 min)
When the gap closes, the case for promotion is mostly already written, because you've been recording it. Keep a running document with the engineer: each feature, its size, the stage they were at, and one line on the outcome. Add review catches and on-call incidents handled. Then help them write the promotion packet themselves. Writing a case for their own work is a skill they'll need at every level after this one.
Celebrate the promotion visibly when it happens. It's the first time the engineer finds out that the ladder is real and that effort turns into recognition. A lot of retention rests on that one moment.
Worked example: "you're close" becomes a date (composite scenario)
Context. An engineer 20 months into their first job on a platform team, strong at bug fixes, frustrated by "you're close".
Baseline. Their last ten pieces of work: seven tasks, all independent. Three features, and all three needed mid-course direction. In each case the redirect came from an unknown that surfaced late: an API rate limit, an existing consumer of the data, a permissions model nobody had checked.
Intervention. The lead named the gap in writing (Step 5) and introduced the one-page plan (Step 3). The first plan listed no unknowns. In review, the lead asked "what will you learn in the first two days?", and the engineer found two. A one-day spike resolved both before any feature code was written.
What happened. Over the next two features, they moved from "they scope, you review first" to "they scope and build". Both features shipped within their estimates, with no redirects. Their review catches went up as on-call exposed them to the failure modes in the services they were changing.
Evidence. The promotion case listed the three features before and the two after, with sizes and stages. It passed calibration on the first submission, about five months after the gap was first written down.
Lesson. The engineer had been ready to learn scoping for over a year. Nobody had named it as the skill.
Trade-offs to make deliberately
Choice | You gain | You risk |
Stretch assignment early | Faster growth, motivation | A visible stumble if support isn't staged |
Stay at current size longer | Safety, a clean track record | Boredom, and the "you're close" stall |
Formal written plan for every feature | Visible, coachable scoping | Bureaucracy on trivial work, so use it for feature-size work only |
Promotion as soon as the bar is met | Retention, trust in the ladder | Calibration pushback if the evidence is thin, so build it as you go |
Common failure modes
"You're close" with no written gap. The engineer can't close what they can't see.
Jumping from tickets to projects. They stumble, the lead takes over, and confidence drops on both sides.
Coaching speed when the problem is scoping. Faster coding doesn't fix late surprises.
Reviews as approvals. No comparison with a senior reviewer, so no growth in judgment.
Building the promotion case at the end. Evidence written from memory is thin and easy to challenge.
Pairing is one of the main tools here; Pair Programming That Helps covers the driver/navigator shape that teaches while it ships.
Final takeaway
Junior to mid is about independence at feature size, and the skill that usually blocks it is scoping: finding the unknowns before they find you. Measure the size of work they can own, grow it one stage at a time, make scoping a written artifact, and write the gap down in terms they can check themselves. Your next action: grade your mentee's last ten pieces of work by size and by whether they needed direction, and bring that table to your next 1:1.
Sources
Dropbox. Dropbox Engineering Career Framework (published openly). dropbox.github.io/dbx-career-framework.
Correll, S. J. and Simard, C. (2016). Research: Vague Feedback Is Holding Women Back. Harvard Business Review, April 2016.
Fournier, C. (2017). The Manager's Path: A Guide for Tech Leaders Navigating Growth and Change. O'Reilly Media.
Continue the Mentoring Engineers path
Previous — Part 6: Coach Through Failure
Next — Part 8: Grow a Mid to Senior
Part of the Mentoring Engineers learning path. Related: Delegate Without Lowering the Bar.
