Grow a Mid to Senior — Mentoring Engineers, Part 8
Mentoring Engineers · Part 8
A mid-level engineer is handed their first ambiguous problem: "Checkout abandonment went up after the redesign. Figure out what's going on." Two weeks later they come back with a solid caching change that cut the payment page's load time by 40%. It's good work. Abandonment doesn't move.
When the lead digs in, the answer has been sitting in the analytics the whole time. Most of the new drop-off happens on the shipping-options step, which the redesign made mandatory before the price is shown. It was never a performance problem. The engineer did what mid-level engineers are trained to do: they found a technical problem they knew how to solve and solved it well. They skipped the step that defines senior work, which is establishing what the problem actually is before choosing what to build.
That's the gap this part is about. Junior to mid (Part 7) is independence at a given size of work. Mid to senior is different in kind: senior engineers are trusted to frame problems nobody has framed yet, and to move decisions across people they don't manage. Both are judgment, and judgment can be coached, but not by handing over bigger tickets.
Before you start
Read your ladder's senior and staff descriptions side by side. Note which phrases are about scope ("multi-quarter", "multiple teams") and which are about behaviour ("handles ambiguity", "influences direction"). The behaviour phrases are where mid-level engineers stall.
List the last three problems your mentee was given. For each, who wrote the problem statement: them, or someone else?
Find one real ambiguous problem on your team's backlog that nobody owns yet. You'll need it in Step 2.
Step 1: Separate scope from judgment (10 min)
The usual move is to give a mid-level engineer bigger features and wait. Bigger features build stamina and coordination, but a well-specified six-week project still has someone else's thinking at the top. The engineer can deliver it perfectly without ever making the call that defines senior work.
Judgment shows up in three behaviours you can observe:
Behaviour | Mid-level version | Senior version |
Problem framing | Takes the problem as given | Questions the framing, gathers data, restates the problem before solving it |
Trade-off calls | Lists options, asks which one | Recommends one, states what it costs, owns the outcome |
Influence | Persuades within the team | Moves a decision across teams without positional authority |
Will Larson's Staff Engineer (2021) and Tanya Reilly's The Staff Engineer's Path (2022) both make the point that work above mid-level is less about output and more about choosing the right work and getting others aligned behind it. Senior is where that starts.
Test you can run: for your mentee's last three projects, who wrote the problem statement? If the answer is "someone else" all three times, they've had no practice at the first row of that table.
Step 2: Hand over an unframed problem, and coach the framing (20 min)
Give them a real problem with the framing deliberately left out, and ask for a problem statement before any solution. One page, three parts:
What we observe: the data, with sources. (Abandonment up 18% since the redesign, from the funnel dashboard.)
What could explain it: at least three hypotheses, including non-technical ones.
What would tell them apart: the cheapest check for each hypothesis.
The coaching happens in the second section. Mid-level engineers usually list only hypotheses they could fix with code. Push for at least one that's about the product, the data or the users. In the checkout example, the hypotheses should have included "the new flow asks for something before showing the price" and "the measurement changed with the redesign", alongside "the page is slow".
The third section is the discovery move: find the cheapest data that separates the hypotheses before committing weeks to one of them. A funnel breakdown by step takes an hour and would have pointed straight at shipping options.
Don't solve it for them. When they bring the draft, your questions are: "What else could explain this?" and "What would you look at first if you could only spend a day?"
Test you can run: read their problem statement. Does it contain a hypothesis they couldn't fix with code? Does it name a check that costs under a day? If either answer is no, send it back once before they build anything.
Step 3: Require a recommendation, not a menu (15 min)
A mid-level engineer brings options: "We could use a queue, or batch it nightly, or call the vendor synchronously. What do you think?" A senior engineer brings a recommendation: "Nightly batch. We lose same-day freshness, which product confirmed is acceptable, and we avoid the vendor's rate limit entirely. If freshness becomes a requirement, the queue is the next step, and here's what it would cost."
Make the second form the norm in your 1:1s and design reviews. When they bring a menu, ask: "Which one would you choose, and what are you giving up?" The "what are you giving up" part matters most. A recommendation that names no cost is a preference, not a trade-off call.
Writing helps. An architecture decision record gives the recommendation a fixed shape: context, decision, consequences. Our ADR template is a good starting point.
Test you can run: in their last three design proposals, did they recommend one option and name its cost? Count how many did. Two or three out of three is senior behaviour.
Step 4: Give them a decision they have to win across teams (15 min)
Influence can't be practised inside a team where everyone already trusts them. Find a decision that needs another team's agreement: a shared API change, a common library upgrade, a standard for logging. Make them the owner of getting it decided.
Then coach the mechanics, because most engineers have never seen them written down:
Find who decides, and who can block. It's rarely the same person.
Talk to the blockers one by one before the meeting. A design review where the key objection is raised for the first time usually ends without a decision.
Write the proposal so a reader can disagree precisely. Numbered points, explicit trade-offs, a clear request.
Close it. Record the decision, who agreed and what happens next.
The gap this exposes is usually step 2. Engineers expect a good argument to win in the room. In practice, decisions across teams get made in the conversations before the room.
Test you can run: after the decision, ask them who they spoke to before the meeting and what changed in the proposal because of it. If the answer is "nobody" and "nothing", the decision was luck, or someone else carried it.
Step 5: Make them grow someone else (10 min)
Pair them with a junior engineer for a quarter, with a specific goal: for example, take the junior from task-size to feature-size independence (the scale from Part 7). Then coach their coaching. After each session: "What did they get stuck on? What did you do? What would you do differently?"
This step tests whether their judgment can be passed on. An engineer who can only make good calls themselves stays a strong individual. An engineer who can grow judgment in others multiplies the team.
Test you can run: at the end of the quarter, has the junior's independence measurably changed? Use the size-and-direction baseline from Part 7.
Step 6: Read the signals honestly, and keep the IC track open (10 min)
Senior-ready signals are things other people do, not things the engineer says: others bring problems to them, their framing is used in planning, another team asks for them by name, and their recommendations are adopted without you in the room.
Not-ready signals are just as observable: they wait for problem statements, bring menus, avoid the cross-team conversation, or get stuck when the first framing turns out to be wrong.
Be explicit that senior isn't a step toward management. Many engineers do their best work as senior, staff or principal engineers, and ladders such as Dropbox's publish IC levels up to senior principal. Pushing a strong senior engineer toward management because it's the visible next step is a common way to lose them.
Worked example: the checkout problem, framed properly (composite scenario)
Context. A mid-level engineer, three years in, strong on delivery. Their lead wants to make the case for senior within a year.
First attempt. The caching change from the opening: well executed, aimed at the wrong problem. The lead didn't treat it as a failure. They used it as the teaching case.
Intervention. The lead asked for a problem statement on the next ambiguous item, a rise in support tickets after a billing change. The first draft listed two technical hypotheses. Asked "what else could explain this?", the engineer added a third: the invoice email had changed wording. A one-hour sample of 50 tickets showed most of them quoted the new email.
What happened next. The engineer recommended rewording the email over the engineering fix product had requested, and named the cost: the underlying proration logic was still confusing and would need work next quarter. They then had to win that decision with the billing team, which owned the email templates. The first pre-meeting conversation surfaced an objection about legal wording. The proposal was revised before the review, and it was approved in one meeting.
Evidence. Support tickets on the topic dropped back to their previous level within two weeks of the change. In the promotion case, the lead listed three framed problems, two adopted recommendations and one cross-team decision, each linked to the written artifacts.
Lesson. The engineer had been capable of senior judgment for a while. They had never been asked to show it before choosing a solution.
Seniority brings its own blind spots; The Senior Engineer's Blind Spot is worth reading alongside this.
Trade-offs to make deliberately
Choice | You gain | You risk |
Hand over an unframed problem | Real practice at senior judgment | A slow or wrong first framing, so time-box it and review early |
Assign a cross-team decision | Influence skills that can't be built any other way | A visible stall, so coach the pre-meetings |
Pair them with a junior | Tests whether their judgment transfers | Takes delivery time, so plan for it |
Promote on scope alone | Fast and easy to justify | A senior title without senior judgment, which shows up later as stalled staff progress |
Common failure modes
Bigger tickets as the growth plan. Scope grows, judgment doesn't.
Accepting menus. The engineer never practises making the call.
Solving the framing for them. It's quicker, and it removes the only exercise that matters.
No cross-team exposure. Influence stays untested until the first staff-level project, when it's expensive to learn.
Treating management as the next step. You lose senior ICs who would have grown into staff.
Final takeaway
Mid to senior is about framing problems and moving decisions, not about shipping bigger things. Hand over real ambiguity, ask for a problem statement before a solution, require a recommendation with a named cost, and give them a decision to win across teams. Your next action: take the unowned ambiguous problem you found before starting, give it to your mentee, and ask for the one-page problem statement before any design.
Sources
Larson, W. (2021). Staff Engineer: Leadership Beyond the Management Track. Self-published.
Reilly, T. (2022). The Staff Engineer's Path: A Guide for Individual Contributors Navigating Growth and Change. O'Reilly Media.
Dropbox. Dropbox Engineering Career Framework (published openly). dropbox.github.io/dbx-career-framework.
Continue the Mentoring Engineers path
Previous — Part 7: Grow a Junior to Mid-Level
Part of the Mentoring Engineers learning path. Related: The Tech Lead Transition.
