@shaykec/bridge 0.4.24 → 0.4.26

package/modules/technical-debt/walkthrough.md

@@ -0,0 +1,94 @@
+# Technical Debt Walkthrough — Learn by Doing
+
+## Step 1: Recognize the Metaphor
+
+Debt has principal and interest. So does tech debt.
+
+**Task:** Pick a piece of code in a project you know (or imagine one) that's hard to change. Estimate: (a) how long to fix it properly (principal), and (b) how much extra time each change in that area costs (interest per touch).
+
+**Question:** If you touch this code 10 times a year, is the total interest more or less than the principal? When does it become worth paying down?
+
+**Checkpoint:** The user can distinguish principal (one-time fix) from interest (recurring cost). They recognize that high-touch code has higher interest.
+
+---
+
+## Step 2: Place Debt in the Quadrant
+
+Fowler's quadrant: deliberate vs inadvertent, prudent vs reckless.
+
+**Task:** For each scenario, place it in the quadrant and explain why:
+1. Team ships without tests to hit a deadline, plans to add tests next sprint
+2. Junior dev writes a 500-line function; doesn't know better
+3. Team chooses a quick prototype that becomes production; never refactors
+
+**Question:** Which scenario is "prudent deliberate"? Which is "reckless deliberate"? Why does the distinction matter for how you talk about it?
+
+**Checkpoint:** (1) Prudent-deliberate if they actually add tests. (2) Prudent-inadvertent (didn't know). (3) Reckless-deliberate (knew but never paid). The user can explain the quadrant.
+
+---
+
+## Step 3: Identify Code Smells
+
+Smells are signals, not proof — but they point to debt.
+
+**Task:** Look at a file in your codebase (or a sample online). List at least 3 potential smells: long functions, duplication, deep nesting, unclear names, etc.
+
+**Question:** Why is each a "smell" rather than necessarily bad? What would you need to verify before calling it debt?
+
+**Checkpoint:** The user lists concrete smells and understands they're indicators. They recognize that some "smells" might be acceptable in context (e.g., a simple 100-line script).
+
+---
+
+## Step 4: Measure What Matters
+
+Different metrics reveal different aspects of debt.
+
+**Task:** For a hypothetical module that keeps having bugs: what metrics would you collect to make a case for paying down debt? List at least 3.
+
+**Question:** How would you explain "cyclomatic complexity" or "churn" to a non-technical stakeholder? What's the business impact?
+
+**Checkpoint:** The user suggests metrics like: bug count by module, complexity, files changed per feature, cycle time. They can translate at least one into business impact (e.g., "slows releases by X%").
+
+---
+
+## Step 5: Prioritize Paydown
+
+Not all debt is equal. Prioritize by interest and risk.
+
+**Task:** You have three debt items:
+- A: Rarely touched, ugly code (principal: 2 days)
+- B: Touched every sprint, moderate mess (principal: 5 days, interest: 1 day/sprint)
+- C: Security concern in auth module (principal: 3 days)
+
+Order them by paydown priority and explain your reasoning.
+
+**Question:** When might you fix A before B? When would C always come first?
+
+**Checkpoint:** User likely orders C first (risk), then B (high interest), then A (low interest). They can articulate when risk trumps interest.
+
+---
+
+## Step 6: Communicate to a Manager
+
+Stakeholders need outcomes, not jargon.
+
+**Task:** Write a 2–3 sentence pitch to your manager for paying down debt in module X. Include: what's wrong, what it costs now, what fixing it would unlock, and a simple ask (e.g., "1 sprint").
+
+**Question:** What would make a manager say yes? What would make them say "we can't afford it"?
+
+**Checkpoint:** The user's pitch uses business language (time, risk, roadmap), not just "code quality." They have a concrete ask.
+
+---
+
+## Step 7: Choose Refactor vs Rewrite
+
+Different situations need different strategies.
+
+**Task:** For each scenario, choose Refactor or Rewrite and justify in one sentence:
+1. 50-line function doing 4 things
+2. Legacy monolith, 10 years old, no tests, wrong architecture
+3. New feature needs different data model; current one is workable but awkward
+
+**Question:** What's the main risk of a full rewrite? When is "strangler fig" better?
+
+**Checkpoint:** (1) Refactor — extract functions. (2) Often rewrite or strangler — but strangler is safer. (3) Refactor or incremental migration. User understands rewrite is risky and refactor is usually preferable.

package/modules/technical-mentoring/content.md

@@ -0,0 +1,128 @@
+# 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.

package/modules/technical-mentoring/exercises.md

@@ -0,0 +1,84 @@
+# Technical Mentoring Exercises
+
+## Exercise 1: Map a Mentee to Dreyfus
+
+**Task:** Think of someone you mentor (or a hypothetical junior engineer). Using the Dreyfus model, place them at a stage. List 2–3 observable behaviors that support your assessment. Then write one change you'd make to your mentoring style based on that stage.
+
+**Validation:**
+- [ ] Stage is identified with reasoning
+- [ ] Behaviors are concrete and observable
+- [ ] Style adjustment is specific (e.g., "more questions, fewer answers")
+- [ ] You could explain your choice to a peer
+
+**Hints:**
+1. Novices ask "what do I do?"; experts ask "what matters here?"
+2. Look for: reliance on rules vs intuition, handling of ambiguity, need for context
+3. Stage isn't fixed—someone can be novice in one area, competent in another
+
+---
+
+## Exercise 2: Turn Answers Into Socratic Questions
+
+**Task:** Pick a common technical question you get (e.g., "How do I debug this?", "Which library should I use?"). Write the answer you'd usually give. Then rewrite it as 3–4 Socratic questions that lead the mentee to the same conclusion.
+
+**Validation:**
+- [ ] Original answer is clear and correct
+- [ ] Questions build logically (each sets up the next)
+- [ ] Questions don't give away the answer
+- [ ] You can articulate when you'd use questions vs direct answer
+
+**Hints:**
+1. Start with "What have you tried?" or "What do you already know?"
+2. Use "What would happen if...?" for exploration
+3. If the mentee is blocked or stressed, direct answer may be better
+
+---
+
+## Exercise 3: Design a Stretch Assignment
+
+**Task:** For a mentee you know (or a hypothetical competent engineer), design a stretch assignment. Include: what they'll do, why it's a stretch, what support you'll provide, and how you'll know they succeeded.
+
+**Validation:**
+- [ ] Scope is clear and achievable in 2–4 weeks
+- [ ] Stretch is justified (what's new or harder for them?)
+- [ ] Support is explicit (availability, check-ins, review)
+- [ ] Success criteria are measurable or observable
+
+**Hints:**
+1. Stretch = slightly beyond comfort zone, not drowning
+2. "Own the design" or "lead a small project" are good stretch types
+3. Define "done" so both of you agree when it's complete
+
+---
+
+## Exercise 4: Write SBI Feedback
+
+**Task:** Recall a situation where you gave (or wished you'd given) technical or behavioral feedback. Write it using SBI: Situation, Behavior, Impact. Add one follow-up question: "What would you do differently?" or "What support do you need?"
+
+**Validation:**
+- [ ] Situation is specific (when, where)
+- [ ] Behavior is observable (what they did, not intent)
+- [ ] Impact is clear (effect on outcome or others)
+- [ ] Follow-up invites action, not defensiveness
+
+**Hints:**
+1. Avoid "you always" or "you never"—stick to one instance
+2. Impact can be positive too: "That helped the team move faster"
+3. End with a question, not a prescription
+
+---
+
+## Exercise 5: Create a One-Page Mentoring Plan
+
+**Task:** Create a one-page mentoring plan for a mentee (real or hypothetical). Include: their Dreyfus stage, 2–3 learning goals for the next quarter, one stretch assignment, how you'll use questions vs answers, and how you'll track progress.
+
+**Validation:**
+- [ ] Plan fits on one page
+- [ ] Stage, goals, and stretch are aligned
+- [ ] Questions vs answers approach is explicit
+- [ ] Progress tracking has a cadence (e.g., biweekly check-in)
+
+**Hints:**
+1. Goals should be learning outcomes, not project deliverables
+2. "Track progress" can be simple: debrief after stretch, 1:1 check-ins
+3. Revisit the plan mid-quarter—plans should evolve

package/modules/technical-mentoring/module.yaml

@@ -0,0 +1,41 @@
+slug: technical-mentoring
+title: "Technical Mentoring — Growing Engineers on Your Team"
+version: 1.0.0
+description: "Mentor effectively: Dreyfus model, Socratic method, pairing, feedback (SBI), and creating psychological safety."
+category: leadership
+tags: [mentoring, coaching, leadership, career-growth, team-development, feedback]
+difficulty: intermediate
+
+xp:
+  read: 15
+  walkthrough: 40
+  exercise: 25
+  quiz: 20
+  quiz-perfect-bonus: 10
+
+time:
+  quick: 5
+  read: 20
+  guided: 50
+
+prerequisites: []
+related: [one-on-ones, code-review, technical-debt]
+
+triggers:
+  - "How do I mentor junior developers?"
+  - "How do I help my team grow technically?"
+  - "What's the difference between mentoring and coaching?"
+  - "How do I give technical feedback without micromanaging?"
+
+visuals:
+  diagrams: [diagram-mermaid, diagram-flow]
+  quiz-types: [quiz-matching, quiz-timed-choice]
+  slides: true
+
+sources:
+  - label: "The Manager's Path by Camille Fournier"
+    type: book
+    url: "https://www.oreilly.com/library/view/the-managers-path/9781491973882/"
+  - label: "An Elegant Puzzle by Will Larson"
+    type: book
+    url: "https://lethain.com/elegant-puzzle/"

package/modules/technical-mentoring/quick-ref.md

@@ -0,0 +1,74 @@
+# Technical Mentoring — Quick Reference
+
+## Mentoring vs Coaching vs Sponsoring
+
+| Role | Focus | Example |
+|------|-------|---------|
+| **Mentoring** | Share experience and advice | "Here's how I approached this." |
+| **Coaching** | Ask questions to unlock thinking | "What have you tried? What's blocking you?" |
+| **Sponsoring** | Advocate for visibility/opportunity | "I'm putting you up for the lead role." |
+
+Use all three as the situation demands.
+
+## Dreyfus Stages — Style Guide
+
+| Stage | They need | You do |
+|-------|-----------|--------|
+| **Novice** | Rules, checklists | Clear instructions, safe practice |
+| **Advanced Beginner** | Context for rules | Explain why; guided decisions |
+| **Competent** | Stretch, debrief | Assign ownership; review afterward |
+| **Proficient** | Principles, ambiguity | Challenge; share mental models |
+| **Expert** | Space, sponsorship | Get out of the way; advocate |
+
+## Socratic Question Patterns
+
+| Pattern | Example |
+|---------|---------|
+| "What would happen if...?" | "What if we didn't validate at the API?" |
+| "What have you tried?" | Opens reflection; avoids re-explaining |
+| "What's the constraint?" | Surfaces assumptions |
+| "How would you explain this?" | Tests understanding |
+
+## SBI Feedback Template
+
+```
+Situation: [When and where—specific]
+Behavior:  [What they did—observable, not intent]
+Impact:    [Effect on outcome or others]
+Ask:      [What would you do differently? / What support do you need?]
+```
+
+## When to Answer vs Question
+
+| Context | Prefer | Why |
+|---------|--------|-----|
+| Urgent / production issue | Answer | Speed first |
+| Design decision | Questions | Ownership, deeper learning |
+| First-time concept | Answer + explain | Build foundation |
+| Recurring pattern | Questions | They likely know |
+| Mentee stuck/frustrated | Answer or pair | Reduce overload |
+
+## Stretch Assignment Checklist
+
+- [ ] Clear scope (2–4 weeks)
+- [ ] Slightly beyond comfort (recoverable if it fails)
+- [ ] Success criteria defined
+- [ ] Support explicit (availability, check-ins)
+- [ ] Debrief scheduled
+
+## Psychological Safety Practices
+
+| Do | Avoid |
+|----|-------|
+| Admit "I don't know" | Acting like you have all answers |
+| Normalize mistakes | Punishing or hiding errors |
+| Separate person from code | "You're wrong" |
+| Create low-stakes experiments | High-stakes first attempts |
+
+## One-Page Mentoring Plan
+
+1. **Stage** — Dreyfus level + evidence
+2. **Goals** — 2–3 learning outcomes this quarter
+3. **Stretch** — One assignment with criteria
+4. **Cadence** — How often you'll check in
+5. **Revisit** — When to adjust (e.g., mid-quarter)

package/modules/technical-mentoring/quiz.md

@@ -0,0 +1,73 @@
+# Technical Mentoring Quiz
+
+## Question 1
+
+What is the main difference between mentoring and coaching?
+
+A) Mentoring is for juniors; coaching is for seniors
+B) Mentoring shares experience and advice; coaching asks questions to unlock the mentee's own thinking
+C) Mentoring happens in 1:1s; coaching happens in meetings
+D) There is no difference—they are the same
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Mentoring involves sharing knowledge and experience. Coaching focuses on asking questions so the mentee arrives at their own insights. Both are valuable; effective mentors use each when appropriate. -->
+
+## Question 2
+
+According to the Dreyfus model, how should you support a *novice* engineer?
+
+A) Give them ambiguous problems to build intuition
+B) Provide clear rules, checklists, and safe practice
+C) Get out of the way and sponsor them for bigger projects
+D) Challenge them with stretch assignments
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Novices are overwhelmed by context and want rules to follow. Clear instructions and checklists reduce cognitive load. Ambiguity, sponsorship, and stretch assignments are better for competent or expert stages. -->
+
+## Question 3
+
+What does SBI stand for in feedback?
+
+A) Specific, Brief, Impactful
+B) Situation, Behavior, Impact
+C) Start, Build, Improve
+D) Support, Behavior, Improvement
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: SBI is Situation (when/where), Behavior (what happened—observable), Impact (effect on outcome or others). It keeps feedback specific and non-accusatory. -->
+
+## Question 4
+
+When is it better to give a direct answer instead of Socratic questions?
+
+A) Always—mentees prefer answers
+B) When the mentee is stuck, stressed, or the situation is urgent
+C) Never—questions always lead to better learning
+D) Only when the mentee explicitly asks for the answer
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Socratic questions work best when the mentee has bandwidth to think. When they're stuck, frustrated, or there's a production fire, a direct answer reduces overload. You can debrief and explore afterward. -->
+
+## Question 5
+
+What is "sponsoring" in the context of mentoring?
+
+A) Paying for a mentee's conference ticket
+B) Actively advocating for their visibility and opportunity
+C) Assigning them stretch projects
+D) Giving them SBI feedback
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Sponsoring means using your influence to advocate for the mentee—putting them forward for projects, visibility, or promotions. It goes beyond advice and stretch assignments; it's active championing. -->
+
+## Question 6
+
+Which practice best supports psychological safety for a mentee?
+
+A) Only give feedback when they ask for it
+B) Admit your own gaps and normalize mistakes
+C) Avoid assigning challenging work
+D) Review their code before every commit
+
+<!-- ANSWER: B -->
+<!-- EXPLANATION: Admitting "I don't know" and normalizing mistakes shows that learning and uncertainty are expected. This makes it safe for mentees to ask questions and take risks. Avoiding challenge or over-reviewing can undermine growth. -->

package/modules/technical-mentoring/resources.md

@@ -0,0 +1,33 @@
+# Technical Mentoring — Resources
+
+## Books
+
+- **The Manager's Path** by Camille Fournier — O'Reilly. Covers mentoring, 1:1s, and growing engineers. [Amazon](https://www.amazon.com/Managers-Path-Leaders-Navigating-Growth/dp/1491973897)
+- **An Elegant Puzzle** by Will Larson — Stripe Press. Systems of teams, leveling, and technical leadership. [Amazon](https://www.amazon.com/Elegant-Puzzle-Systems-Engineering-Management/dp/1732265186)
+- **Radical Candor** by Kim Scott — Giving and receiving feedback; caring personally while challenging directly. [Amazon](https://www.amazon.com/Radical-Candor-Revised-Kickass-Without/dp/1250235375)
+
+## Articles
+
+- [The Dreyfus Model of Skill Acquisition](https://www.infoq.com/articles/dreyfus-model-skill-acquisition/) — InfoQ. Overview of the five stages and implications.
+- [Socratic Method in Software Development](https://www.thoughtworks.com/insights/blog/socratic-method-software-development) — Thoughtworks. Applying Socratic questioning to technical mentoring.
+- [The Art of Giving and Receiving Advice](https://hbr.org/2015/01/the-art-of-giving-and-receiving-advice) — Harvard Business Review. Why advice fails and how to improve it.
+- [How to Give Feedback That Actually Works](https://www.atlassian.com/blog/inside-atlassian/giving-feedback) — Atlassian. Practical feedback techniques including SBI.
+- [Psychological Safety at Work](https://hbr.org/2023/11/what-is-psychological-safety) — Harvard Business Review. What it is and why it matters for teams.
+
+## Videos
+
+- [Radical Candor: The Surprising Secret to Being a Good Boss](https://www.youtube.com/watch?v=4yODalLJy2M) — Kim Scott (Google Talks). Feedback framework.
+- [The Skill of Giving Feedback](https://www.youtube.com/watch?v=FGjTbcTgH_s) — Farnam Street. Clear, actionable feedback.
+- [Socratic Method in Practice](https://www.youtube.com/watch?v=PaqbOPk5aGw) — Teaching Channel. Classroom application; principles apply to mentoring.
+
+## Tools & Frameworks
+
+- [SBI Feedback Model](https://www.ccl.org/articles/leading-effectively-articles/constructive-feedback-the-situation-behavior-impact-model/) — Center for Creative Leadership. Official SBI reference.
+- [Dreyfus Model — Wikipedia](https://en.wikipedia.org/wiki/Dreyfus_model_of_skill_acquisition) — Academic background and stages.
+- [Manager Tools — Mentoring Series](https://www.manager-tools.com/) — Podcasts on mentoring and 1:1s (subscription).
+
+## Further Reading
+
+- [The Coaching Habit](https://www.amazon.com/Coaching-Habit-Say-Less-Ask-More/dp/0978440749) by Michael Bungay Stanier — Seven questions to coach effectively.
+- [Thanks for the Feedback](https://www.amazon.com/Thanks-Feedback-Science-Receiving-Well/dp/0143127136) by Douglas Stone & Sheila Heen — Receiving feedback; useful for mentees and mentors.
+- [The Five Dysfunctions of a Team](https://www.amazon.com/Five-Dysfunctions-Team-Leadership-Fable/dp/0787960756) by Patrick Lencioni — Trust and psychological safety in teams.

package/modules/technical-mentoring/walkthrough.md

@@ -0,0 +1,65 @@
+# Technical Mentoring Walkthrough — Learn by Doing
+
+## Step 1: Map Your Mentee's Stage
+
+**Task:** Think of someone you mentor (or would mentor). Using the Dreyfus model, place them at a stage. List 2–3 behaviors that support your assessment. Then write one change you'd make to your mentoring style based on that stage.
+
+**Question:** How might you be over- or under-supporting? What would "just right" look like?
+
+**Checkpoint:** You've identified a stage and one concrete style adjustment.
+
+---
+
+## Step 2: Turn One "Answer" Into Questions
+
+**Task:** Pick a common technical question you get (e.g., "How do I debug this?", "Which library should I use?"). Write the answer you'd usually give. Then rewrite it as 3–4 Socratic questions that lead the mentee to the same conclusion.
+
+**Question:** When would you use the questions vs when would you give the direct answer?
+
+**Checkpoint:** You have both the answer and the question sequence; you can articulate when to use each.
+
+---
+
+## Step 3: Design a Stretch Assignment
+
+**Task:** For a mentee you know (or a hypothetical junior engineer), design a stretch assignment. Include: what they'll do, why it's a stretch (what's new or harder), what support you'll provide, and how you'll know they succeeded.
+
+**Question:** How do you prevent it from being too easy or so hard they give up?
+
+**Checkpoint:** Assignment has clear scope, support, and success criteria.
+
+---
+
+## Step 4: Practice SBI Feedback
+
+<!-- hint:card type="concept" title="SBI: Situation (when/where), Behavior (what you observed), Impact (effect on team or outcome)" -->
+
+**Task:** Recall a situation where you gave (or wished you'd given) technical feedback. Write it using SBI: Situation, Behavior, Impact. Then add one "What would you do differently?" or "What support do you need?" follow-up.
+
+**Question:** How does SBI change the tone compared to "You did X wrong"?
+
+**Checkpoint:** Feedback is specific, non-accusatory, and actionable.
+
+---
+
+## Step 5: Create a Mentoring Plan
+
+<!-- hint:list style="cards" -->
+
+**Task:** Create a one-page mentoring plan for a mentee. Include: their Dreyfus stage, 2–3 learning goals for the next quarter, one stretch assignment, how you'll use questions vs answers, and how you'll track progress.
+
+**Question:** How will you revisit and adjust this plan? What signals would trigger a change?
+
+**Checkpoint:** Plan is concrete and covers stage, goals, assignments, and tracking.
+
+---
+
+## Step 6: Consider Your Senior Engineers
+
+<!-- hint:celebrate -->
+
+**Task:** List 2–3 senior engineers on your team. For each, identify one way you could mentor or develop them (stretch project, sponsorship, teaching opportunity). Write a sentence on why it matters.
+
+**Question:** Why do we often neglect mentoring senior engineers? What's the cost?
+
+**Checkpoint:** Each senior has at least one development opportunity; you've articulated the value.