# Technical Mentoring — Growing Engineers on Your Team

<!-- hint:slides topic="Technical mentoring: mentoring vs coaching vs sponsoring, Dreyfus skill model, Socratic questioning, and SBI feedback" slides="5" -->

## Mentoring vs Coaching vs Sponsoring

These three roles overlap but serve different purposes:

| Role | Focus | Example |
|------|-------|---------|
| **Mentoring** | Sharing experience, advice, and guidance | "Here's how I approached this; what would work for you?" |
| **Coaching** | Asking questions to unlock mentee's own thinking | "What have you tried? What's blocking you?" |
| **Sponsoring** | Actively advocating for visibility and opportunity | "I'm putting you up for the architecture review lead." |

Effective mentors blend all three: they share experience when it helps, ask questions to stretch thinking, and sponsor when the mentee is ready.

```mermaid
flowchart LR
    subgraph Roles["Mentor's Toolkit"]
        M[Mentoring: Share]
        C[Coaching: Ask]
        S[Sponsoring: Advocate]
    end
    M --> R[Mentee Growth]
    C --> R
    S --> R
```

## The Dreyfus Skill Model

The Dreyfus model describes how people move from novice to expert. Your mentoring style should match the stage:

| Stage | Characteristics | How to Support |
|-------|-----------------|----------------|
| **Novice** | Wants rules; overwhelmed by context | Clear instructions, checklists, safe practice |
| **Advanced Beginner** | Starts seeing context; still rule-focused | Guided decisions, explain *why* rules exist |
| **Competent** | Can prioritize; handles routine well | Give stretch assignments; debrief afterward |
| **Proficient** | Intuition kicks in; wants principles | Challenge with ambiguity; share mental models |
| **Expert** | Intuitive; invents new approaches | Get out of the way; sponsor for bigger scope |

**Example:** A novice might need "Always validate input at the API boundary." A proficient engineer benefits from "Where does validation belong in this architecture, and why?"

## Socratic Questioning

Instead of giving answers, ask questions that lead the mentee to the insight. This builds ownership and deeper learning.

**Instead of:** "Use a hash map here for O(1) lookups."  
**Try:** "What's the complexity of repeated lookups in a list? Is there a data structure that would improve that?"

**Socratic patterns:**
- "What would happen if...?"
- "What have you already tried?"
- "What's the constraint you're working around?"
- "How would you explain this to someone who hasn't seen it?"

## Pairing and Stretch Assignments

**Pairing** builds skills through real-time collaboration. Rotate who drives; the mentor observes and questions. Good for: debugging, design decisions, unfamiliar codebases.

**Stretch assignments** push the mentee slightly beyond comfort. They should:
- Have clear success criteria
- Include support (you're available but not hovering)
- Be scoped so failure is recoverable

**Example:** A competent backend engineer gets a stretch assignment: "Own the design for the new notification service. I'll review your proposal and pair on the trickiest part."

## SBI Feedback

**Situation, Behavior, Impact** keeps feedback specific and non-accusatory:

| Part | Example |
|------|---------|
| **Situation** | "In yesterday's design review..." |
| **Behavior** | "...you proposed a solution before hearing others' ideas." |
| **Impact** | "The team felt their input wasn't valued, so they disengaged." |

Follow with: "What would you do differently?" or "What support do you need?" This makes it actionable.

```mermaid
flowchart LR
    S[Situation: When/Where] --> B[Behavior: What happened]
    B --> I[Impact: Effect on others/outcome]
    I --> A[Ask: What next?]
```

## Psychological Safety

Mentees need to feel safe to ask "dumb" questions, admit mistakes, and try things that might fail.

**Practices:**
- **Admit your own gaps** — "I don't know; let's figure it out."
- **Normalize mistakes** — "I've made that error; here's what I learned."
- **Separate person from code** — "This design has a flaw" not "You're wrong."
- **Create low-stakes experiments** — Pair first, then solo with review.

**Red flag:** If a mentee never asks questions or admits uncertainty, they may not feel safe. Check in: "What would make it easier to bring up when you're stuck?"

## When to Answer vs When to Question

| Context | Prefer | Why |
|---------|--------|-----|
| Urgent production issue | Answer | Speed matters; learning can follow |
| Design decision | Questions | Ownership and deeper understanding |
| First-time concept | Answer + explain | Build foundation before questioning |
| Recurring pattern | Questions | They likely know; need to retrieve it |
| Mentee is stuck and frustrated | Answer or pair | Reduce overload first |

## Mentoring Plan Template

A simple one-page plan keeps mentoring intentional:

1. **Stage** — Where are they (Dreyfus)? What evidence?
2. **Goals** — 2–3 learning goals for the next quarter
3. **Stretch assignment** — One project or ownership area
4. **Feedback cadence** — How often? What format?
5. **Revisit** — When will you adjust? (e.g., mid-quarter check-in)

---

## Key Takeaways

1. **Mentoring ≠ coaching ≠ sponsoring** — Use all three as needed.
2. **Match style to stage** — Novices need rules; experts need space.
3. **Socratic questions** build ownership; direct answers build speed.
4. **SBI feedback** is specific, non-accusatory, and actionable.
5. **Psychological safety** enables risk-taking and growth.
6. **Stretch assignments** with clear criteria and support drive learning.
7. **Document your plan** — A one-page plan keeps mentoring intentional.