Mentoring

Mentoring is one of the highest-leverage activities a senior engineer does. A team where the senior is the only one who can debug the hard problems has a single point of failure. A team where mid-level engineers reliably catch what the senior would have caught has been multiplied.

Mentoring is not the same as code review, training, or one-on-ones — though it uses all of them. The distinguishing property: it changes what the mentee can do without supervision.

What Mentoring Is For

• Capability transfer. The mentee learns to do something they could not do before — diagnose a class of bug, design a class of feature, run a class of meeting.
• Calibration. The mentee learns where the bar is — what "good enough" looks like, what gets through review, what does not.
• Judgment. The mentee learns how to decide — when to refactor, when to ship, when to escalate, when to push back.

The first is the obvious one; the third is the hard one. Capability without judgment produces engineers who can build anything they're told to.

What Mentoring Is Not

• A status meeting. If every session reports on tickets, it is a 1:1, not mentoring.
• Doing the work for them. The mentor demonstrates, the mentee does — switching that round is faster in the moment, but does not transfer capability.
• One-way. The mentor learns too — what's unclear in the codebase, what's missing from documentation, what's hard about being new.

Who Mentors Whom

Mentoring runs in more directions than the org chart suggests:

• Senior → mid-level. The classic case. Focus on judgment and design.
• Senior → junior. Heavier on fundamentals; pair often, review every PR.
• Peer → peer. Two seniors in different domains can mentor each other. Don't assume only juniors need mentoring.
• Mid → junior. The mid-level engineer practices teaching, which is how they level up to senior. Don't reserve all mentoring for the most senior.
• Junior → anyone. Newcomers see things long-tenured engineers have stopped noticing. The exchange is part of healthy onboarding.

A senior who only mentors juniors misses the highest-impact lane: helping mid-level engineers cross the senior boundary.

The Modes

Pairing

Sitting (or screen-sharing) on the same problem. The most powerful and most expensive mode.

When it works:

• Driver / navigator — one types, one talks through what should happen. Switch roles every ~25 minutes.
• Ping-pong TDD — one writes the test, the other writes the implementation. Useful for getting both into the same test-first habit.
• Show / shadow — the mentor demonstrates a workflow (debugger, profiler, deployment) and the mentee takes notes; next session they drive.

When it doesn't:

• All driver, no navigator — the mentee watches but doesn't internalize.
• All instruction, no doing — the mentor tells, but doesn't watch the mentee try.
• Daily, indefinitely — pairing is intense; reserve for hard problems and learning moments, not all work.

Code review as mentorship

The biggest leverage mentoring tool, because it happens many times a week.

To turn review into mentoring:

• Explain the why. "must: this leaks because the listener is added in componentDidMount but never removed in componentWillUnmount." More useful than "must: fix the leak."
• Suggest the next-level concern. "This works. Consider also: what happens when two of these run at once?"
• Praise specifically. "praise: love the named constant here — the magic number was confusing in the old version."
• Let things go that don't matter. A mentee whose every PR comes back with 30 comments stops attempting larger PRs.

Calibrate the volume to the mentee's experience. A junior wants more comments; a senior wants fewer, sharper ones.

Design review

Sit with the mentee before they implement, not after.

• Ask them to describe the problem and proposed solution in their own words.
• Ask "what would change if [constraint] were different?"
• Identify the load-bearing decisions, not the cosmetic ones.
• Let them disagree with you. Sometimes they're right.

The output is a sharper design and — more importantly — a mentee who has practiced articulating one. The next time they design something, the senior may not need to be in the room.

1:1 mentoring conversations

A standing 30-60 minutes, separate from the manager 1:1.

Topics that work:

• What's hard right now? Not what's busy — what's hard.
• Walk me through a recent decision. Probe the reasoning, suggest alternatives.
• What did you learn last week that surprised you? Surfaces the gaps the mentee already knows about.
• What's a problem you wish you understood better? Sets the agenda for upcoming sessions.

Avoid turning it into a project status meeting. The manager 1:1 covers status; the mentoring session covers growth.

Reading and reference

A senior's bookshelf is part of the mentoring toolkit:

• A specific paper or book chapter, given as homework with a follow-up discussion, transfers concepts faster than ad-hoc explanation.
• An ADR or design doc in the codebase, read together, explains a decision better than a hallway re-narration.
• A diff from history showing how a hard refactor was done, walked through together, beats writing a tutorial.

Frameworks for Growth

The Dreyfus model

Useful for calibrating expectations:

A mentee at "advanced beginner" who is given expert-level autonomy will fail predictably. A mentee at "proficient" who is given novice-level procedures will disengage. Match the mode to the stage.

Situational leadership

Same idea, different vocabulary. Adjust how much direction and how much support based on the mentee's competence and confidence:

• Low competence, high confidence (junior with bravado) — high direction, moderate support.
• Low competence, low confidence (junior who's intimidated) — high direction, high support.
• High competence, low confidence (mid-level with imposter syndrome) — low direction, high support.
• High competence, high confidence (senior) — low direction, low support; trust and delegate.

The same person needs different modes in different areas. A senior backend engineer learning frontend may be "low competence, high confidence" on naming and "low competence, low confidence" on layout.

Pitfalls

Hero mentoring

The mentor solves every problem, swooping in to debug for the mentee. Feels helpful in the moment, but creates dependency. The mentee learns "ask the senior" as a skill, not the underlying skill.

Counter: ask "what have you tried?" and "what would you try next?" before answering. If the mentee has tried nothing, the right answer is "try the first two things and come back."

Stealth performance review

Mentoring blends into evaluation in some orgs. If the mentor will write the performance review, the mentee will not share weaknesses, and the mentoring is hollow.

Keep them separate. If the senior is also the line manager, designate someone else for the explicitly-growth conversations.

Mentoring as cloning

The mentor tries to produce another version of themselves. Different engineers have different strengths; useful mentoring helps the mentee become a better version of themselves, not a worse version of the mentor.

One-size mentoring

Treating every mentee the same. A senior who's been mid-level recently needs different conversations from a senior who skipped that stage years ago.

Burnout

Mentoring is real work. A senior who mentors three people and ships features is not doing four jobs at half-capacity; they are doing four jobs at quarter-capacity. Account for it in capacity planning, or stop expecting both.

Measuring It

Mentoring outcomes are slow. Useful proxy signals:

• The mentee starts shipping work that previously needed the mentor's involvement.
• The mentee gives useful code reviews on areas they were once unsure about.
• The mentee starts mentoring others.
• The mentee disagrees with the mentor and is sometimes right.
• The team's bus factor (people who can debug a given area) goes up over time.

If none of these are visible after six months, the mentoring is not landing — diagnose and adjust the mode.

Team-Level Capability Uplift

A senior engineer's mentoring obligation extends past 1:1 work:

• Run brownbags or learning sessions on a topic the team needs to level up on. The act of preparing forces precision.
• Pair with rotating partners rather than the same person every time.
• Write ADRs and design docs that capture not just the decision but the reasoning — these become teaching artifacts.
• Make tools and templates that encode learned patterns. A good ESLint rule or a project scaffold transfers capability at the team level.
• Open up code reviews to more reviewers so that the senior is not the only one giving high-signal feedback.

Mentoring at scale is partly individual conversation, partly institution-building. Both are part of the job.

Practical Patterns

A few patterns that have worked across teams:

• 30-minute weekly mentoring sync. Standing time, agenda set by mentee. Skipping a few in a row is fine; canceling permanently is a signal.
• "What I would have done differently" review. Each week, mentee writes a paragraph on a recent decision and what they would change about it. Mentor responds. Builds reflective practice.
• Shadow → reverse-shadow. Mentee shadows the mentor through a hard task (debugging, on-call incident, design review). Later, mentor shadows the mentee doing the same kind of task. Catches gaps neither would have noticed.
• The "explain it back" check. After teaching a concept, ask the mentee to explain it as if to a third party. Reveals what stuck and what didn't.
• Promotion-readiness conversation. Specifically for mid → senior, walk through the gap between current behavior and the bar. The conversation surfaces what to work on; the work fills it.

Pre-Commit Question

Before ending a mentoring conversation:

Did the mentee leave able to do something they couldn't do an hour ago?

If yes, the session worked. If no, ask what the next-best topic is — the current one is not landing.