Skip to content
    Hiring & growing leadersChapter 47

    Mentoring and Team Development

    How to grow engineers, run useful one-to-ones, and create a culture of knowledge sharing.

    Original guideworking25 minevergreen · reviewed Aug 13, 2026
    Tech Lead
    Engineering Manager
    Chapter outline

    Brief

    The essential idea

    Mentoring is a way to make the team stronger as a system, not a collection of occasional tips for junior engineers. The leader acts as a catalyst by clarifying expectations, creating opportunities at the right scale, shortening feedback loops, and providing safe guardrails so people become more autonomous rather than more dependent on the mentor.

    A useful one-to-one connects the person, current work, and growth in 30–45 minutes; status belongs in the tracker. A short 6–10 week individual development plan treats growth as a hypothesis, names the target behavior or responsibility, defines evidence such as an ADR, metric, demo, or stakeholder response, and pairs a real assignment with review checkpoints.

    The most durable learning happens inside delivery: principled code review, pairing and shadowing, design documents, postmortems, ownership rotations, and on-call work. Stretch assignments succeed when delegation grows in stages—from following a standard to proposing options, deciding together, deciding and informing, and finally taking full ownership.

    Feedback should be immediate and actionable. SBI separates Situation, Behavior, and Impact; feedforward turns the conversation toward the next attempt. A 30–60–90 day rollout can diagnose needs, establish one-to-ones and development cycles, then distribute ownership and codify reusable guides and templates.

    Decision lens

    Key takeaways

    Growth needs expectations, opportunities, feedback, and safe experiments working together.

    One-to-ones are the primary interface for trust, context, blockers, and development.

    A development plan should target the next level of autonomy and produce observable evidence.

    Delivery practices are learning environments when leaders explain principles rather than only corrections.

    Stretch work grows competence only when success criteria, checkpoints, rollback, and support are clear.

    Fair access to important assignments is part of a leader's development responsibility.

    Feedback delivered only at performance review arrives too late to support learning.

    Workplace experiment

    Apply it at work

    1. 1

      Diagnose autonomy, knowledge bottlenecks, aspirations, and missing engineering guardrails over one or two weeks.

    2. 2

      Move status out of one-to-ones and end each conversation with one or two concrete growth actions.

    3. 3

      Create a 6–10 week development hypothesis tied to a real owned deliverable and observable evidence.

    4. 4

      Use a delegation ladder and agree on design, midpoint, and pre-release checkpoints for stretch work.

    5. 5

      Introduce SBI plus feedforward after relevant work episodes instead of waiting for a formal cycle.

    Choose one action, define the observable effect, and keep the first test small enough to reverse.

    Evidence

    Sources and further reading

    This is an original editorial chapter. No external primary source is attached to the Russian edition.

    Previous chapterHow Senior Engineers Can Keep GrowingNext chapterPerformance Review Fundamentals