mentoring-engineers git:20260720.adc529aA

Immutable. This exact content is served forever at /api/v1/blob/994770d0745e86d9.

---
name: mentoring-engineers
description: Grow engineers through goal-anchored mentoring, calibrated stretch work, and questions before answers. Use when mentoring individuals or building a team's growth practice.
---

# Mentoring engineers

Mentoring converts your experience into their capability. The core
tension: doing it for them is faster today and slower forever; the
craft is calibrated struggle: enough support to prevent drowning,
enough difficulty to force growth.

## Method

1. **Anchor on their goal, made concrete.** "Senior in 18
   months" decomposes into observable capabilities (leads a
   project end-to-end, unblocks others, writes designs that
   survive review: see staff-engineer and
   engineering-manager-role ladders for the vocabulary);
   write the 2-3 current development edges down and revisit
   quarterly (see one-on-one-meetings' career cadence).
   Mentoring without a target degrades into pleasant chat.
2. **Teach by question first.** "What have you tried? What
   does the error actually say? What would you test to
   distinguish those theories?" (see scientific-debugging's
   method: you are installing it): the goal is their
   reasoning loop, not this ticket's fix. Give answers
   freely for trivia and true blockers; give questions for
   anything that builds judgment. Tell them which mode you
   are in; mystery Socratic method reads as withholding.
3. **Assign stretch with a safety net.** Work at the edge of
   their ability (first design doc, first incident lead,
   first gnarly migration: see design-doc-google-style,
   incident-commander-role for the scaffolding), with
   checkpoints framed as the norm ("everyone's first design
   gets three drafts") and failure containment sized so
   mistakes teach without maiming (see
   automation-guardrails' blast-radius thinking, applied to
   growth). Shielding people from all hard work is the
   quiet way seniors stunt juniors.
4. **Feed back specifically, both directions.** Praise
   named behaviors ("your PR description let me review in
   ten minutes": see giving-feedback's specificity rule)
   so they compound; correct in private, promptly, with
   the situation-behavior-impact shape. Solicit feedback
   on your mentoring too: "what should I do differently?"
   models the receiving skill (see receiving-feedback).
5. **Sponsor, not just advise.** Say their name in rooms
   they are not in: the visible project, the conference
   slot (see conference-talks), the review panel;
   sponsorship moves careers where advice only orients
   them (see promo-packet: your evidence of their impact
   belongs in it). Track that stretch opportunities
   distribute fairly across the team, not to whoever asks
   loudest (see hiring-loop-design's bias vigilance,
   internally).
6. **Transfer ownership progressively.** Watch-me, then
   do-together, then do-while-I-review, then own-it:
   per capability; the endpoint is them mentoring the
   next person (see agent-handoff-protocol's spirit,
   human edition). A mentee still dependent on you after
   a year is a mentoring failure wearing loyalty's
   clothes.

## Boundaries

- Mentoring is not performance management: capability
  gaps that threaten someone's role belong to their
  manager through formal channels (see
  one-on-one-meetings' boundary), and mixing the two
  poisons the safety mentoring needs.
- Respect the mentee's goals over your template; the
  path you took is one sample, and "become me" is not a
  development plan.
- Time-box the investment honestly (an hour a week,
  bounded office hours); resentful over-commitment ends
  mentorships worse than honest limits do.