This is about the specific, repeatable mechanics of taking a junior engineer and moving them in roughly six months from "needs review on every task" to "leads a feature stream from intake to deploy with no hand holding." I have trained many technical and non-technical people and finally succeed with this framework. I've done this method twice, with two different engineers, at the same company. Both progressed faster than expected. Both, two years later, are still senior engineers somewhere doing well. I cannot claim everything I did was right. I can tell you what worked. 

A European IT company where we built and maintained a multi-tenant .NET application serving high-traffic hospitality clients. I was the senior engineer running the rebuild. Both juniors were 1–2 years into their careers. We had real customers, real deadlines, and zero budget for a formal mentoring programme. Everything I did had to fit inside the normal sprint cadence.

The first conversation: What "ready" means 

First of all, I had a 30-minute one-on-one with each engineer that I now think of as the most important conversation. I asked them one question: "What does being a feature-stream owner actually mean to you?" Both answered confidently, but both were wrong, not in a bad way, but in the way that every junior engineer is wrong. They thought it meant being able to write code without supervision. That's about 20% of it. I had a flip-chart sheet ready with what I thought it actually meant: 
You can read a vague business requirement and ask the three questions that surface scope ambiguity 
You can decompose a feature into stories with explicit acceptance criteria 
You can identify which existing code needs to change and which doesn't 
You can write the code, the tests, and a deployment runbook 
You can review a peer's Pull Requests against the feature and catch architectural drift 
You can present what shipped to a non-technical stakeholder in five minutes 
You can say "this is not done yet, here's why" to a product manager who wants to release on Friday 

We talked about each point. They wrote down where they thought they were on each. The honest self-assessment from both was strong on (4) and parts of (5), weak on the rest. The point of this conversation was not to score them. It was to align on the destination. Six months later, when we were two-thirds of the way through, I could point at the flip chart and say "you've moved from beginner to comfortable on items 1 through 5. Items 6 and 7 are the next focus." Without that initial conversation, "mentoring" becomes a series of disconnected interventions. With it, every interaction has a target.

Pair programming: structured, not improvised 

Most pair programming I've seen is two people sharing a keyboard for an hour, with the senior doing 90% of the typing and the junior watching. That doesn't work. The junior learns nothing they couldn't have learned from a recording. 
The structure I used had three types, picked deliberately per session: 

Type A - Driver/navigator with role reversal. 
Junior drives the keyboard. I navigate. I do not touch the keyboard. If they go down the wrong path, I ask "what does that achieve?" rather than telling them. After 25 minutes, we swap. After two more 25-minute blocks, we stop and review what we built. 

Type B - Watch the recording. 
I write a non-trivial piece of code while they watch. They take notes on three questions: what surprised me, what decision did I make that they don't understand, what would I have done differently. We then go through their notes. 

Type C - Ping-pong TDD. 
They write a failing test. I write code to make it pass. I write a failing test. They write code to make it pass. Repeat. This is the highest-density mode and the most exhausting. Two hours of this is more than a full day of normal coding. 

The mistake I made early on was defaulting to Type A all the time. Type A is the most "fairfeeling" but it's not the highest learning rate. Type B is what teaches design intuition. Type C is what teaches discipline. I learned to read the engineer's current weakness and pick the mode that addressed it.

Written code review: The highest leverage tool you have

Pair programming scales to about two engineers. Written code review scales to a whole team and produces a permanent record that the engineer can re-read months later.
What I committed to:

Every pull request, structured written feedback within 24 hours. No exceptions. If the pull request was small, the review was small. If the pull request was large, the review was longer. But it always landed within a day.

Three categories of comment, clearly labelled. must: (blocker, won't merge), should: (strong suggestion, push back if you disagree), nit: (cosmetic, take it or leave it). This explicit labelling removed about 80% of the social friction around code review.

At least one specific positive comment per review. Not generic "looks good." A specific call-out of a decision that I thought was particularly well-made. This builds the habit of seeing good work, not just defects.

A weekly summary at the end. Every Friday I'd send a private message: "this week I noticed you're getting much sharper on test coverage; the area you're still wobbly on is null handling at boundary points." Two sentences, no more.

The weekly summary was the highest-leverage thing. It compresses the diffuse signal of dozens of PR comments into a single, actionable, retrievable artefact. After three months of weekly summaries, the engineer could read back their growth.

Progression markers I watched for

I had three signals that told me the engineer was ready for more autonomy:
They started disagreeing with me in code review, with reasoning. Not just "I prefer my way" citing patterns, citing implications, citing what would happen six months from now.
They started writing tests before they wrote code, unprompted. Not because I told them to. Because they realised the test was where the design conversation actually happened.
They started catching things I missed. The first time a junior pointed out a race condition I'd overlooked in my own commit, I made a private note in my journal. That's the moment.

When all three signals were consistent for at least three weeks, I increased their scope. When they regressed, I scaled back temporarily and named the regression specifically. Never as criticism as a data point.

The mistakes I made

I over-corrected too early. In the first six weeks, I gave too much detailed feedback on every pull request. The engineer became dependent on my review and stopped exercising their own judgement. The fix was deliberately leaving lower-priority issues unflagged on smaller PRs, so they had to develop their own taste for what mattered.
I confused "questions" with "Socratic questions." When I asked "what does this code do?" I sometimes meant it as a teaching prompt and sometimes meant it as a genuine question because I didn't understand. The junior couldn't tell the difference and felt tested. I started saying explicitly: "I'm asking because I'd like to talk this through" vs "I'm asking because I genuinely don't understand."
I waited too long to give a real promotion conversation. Both engineers reached technical readiness for the senior role about a month before I had the courage to push for the title change. I now believe that moment of recognition is the single biggest accelerator. Don't delay it.

What "six months" actually looked like

Months 1–2: Heavy pair programming (3–4 sessions per week). Detailed code review. Both engineers shipping tickets I had decomposed for them.
Month 3: Engineers start decomposing their own tickets. Pair programming drops to twice per week. Code review still detailed.
Months 4–5: Engineers start owning small features end-to-end (intake, decomposition, build, ship, monitor). Pair programming reduces to one session per week, focused on harder problems. Code review remains.
Month 6: Engineers leading a feature stream each, decomposing for one another. Pair programming on-demand only. I'm reviewing PRs but not gating them.

The whole process is heavy at the start and tapers. The mistake managers make is keeping the cadence flat, which prevents the engineer from ever feeling the weight of ownership.

What I'd do differently if I started today

I'd add an explicit "skill matrix" a visible document, agreed at the first conversation, that lists every competency expected of a senior engineer in the team, scored 1 to 5. The engineer self-scores monthly. I score them quarterly. The gap between the two scores is its own teaching moment.

I'd also add structured exposure to other parts of the business. Both my engineers were strong on code but weak on customer empathy and commercial reasoning. A monthly 30-minute conversation with someone in sales, support, or finance would have closed that gap a year faster than osmosis did.

If you're a senior engineer being told to "mentor someone" with no structure, my suggestion is: ignore the advice that mentoring is mostly emotional support. It's mostly structured technical work, repeatedly, on a calendar. The relationship follows from the work, not the other way around.