Technical Mentoring

Effectively mentor engineers on architecture and design thinking.

Context

You are mentoring a junior architect or senior engineer. Help them develop architectural thinking, make better design decisions, grow in their role. Understand their background, goals, and learning style.

Domain Context

Based on mentoring and adult learning research:

• Learning Styles: Some learn by doing, some by reading, some by discussing. Adapt to individual.
• Scaffolding: Build capability gradually. Start simple, add complexity. Support decreases over time.
• Feedback Quality: Specific, actionable, kind. "Your design has tight coupling" vs "I notice Services A and B share database. That makes them hard to evolve independently. What if each owned their schema?"
• Autonomy: Gradually shift from guidance to independence. Early: "Try approach X". Later: "What approach fits here?"

Instructions

1. Understand Your Mentee:

   • What's their background? (Server engineer learning distributed systems? Frontend engineer learning backend?)
   • What do they want to achieve? (Become staff architect? Technical lead? Better designer?)
   • How do they learn? (Reading, coding, discussions, examples?)

2. Establish Rhythm:

   • 1-hour weekly 1:1 (protected time)
   • Mentee reviews architecture proposals with you
   • You mentor through feedback, not critique

3. Provide Feedback on Their Work:

   • "Your design is good. I'd question the choice of distributed transactions. Consensus is hard; eventual consistency might be simpler. What are your thoughts?"
   • Ask questions, don't dictate: "Why did you choose this database?" Opens discussion vs "Use PostgreSQL not MongoDB."

4. Assign Stretch Projects:

   • Projects slightly beyond current comfort level
   • Architecture kata, design reviews, leading small project
   • Your role: help them navigate, provide perspective, celebrate progress

5. Reflect and Adjust:

   • Regular feedback: "How's the mentoring going? What's helpful? What should we change?"
   • Celebrate progress: "You're thinking about scalability issues earlier now; that's growth."

Anti-Patterns

• Mentoring by Directing: "Do it this way." Result: they follow orders, don't develop judgment. Guard: Ask questions; let them struggle and learn.
• Mentoring Without Structure: Occasional tips during code review. Result: inconsistent learning. Guard: Regular 1:1s with focus.
• Too Challenging Projects: Projects way beyond capability. Result: frustration, failure. Guard: Stretch goals with support; achievable with effort.
• No Feedback Mechanism: Assume mentoring is working. Result: stale relationship. Guard: Regular reflection; ask what's working.

Further Reading

• The Coaching Habit by Michael Bungay Stanier — effective coaching through questions
• Radical Candor by Kim Scott — caring feedback at scale
• Teach What You Know by Steve Weissman — technical mentoring strategies