Ba role này thường bị nhầm lẫn nhưng phục vụ mục đích rất khác nhau. Một senior dev cần biết khi nào đóng vai nào.
Aspect
Mentor
Coach
Sponsor
Focus
Chia sẻ kinh nghiệm, guidance
Giúp tự tìm ra câu trả lời
Advocate cho người đó trong org
Approach
"Mình đã làm thế này..."
"Bạn nghĩ thế nào?"
"Tôi đề xuất bạn A cho project này"
Relationship
Dài hạn, informal
Có thể ngắn hạn, structured
Behind-the-scenes
Khi nào dùng
Người mới, chưa có kinh nghiệm domain
Người có năng lực, cần unlock
Người giỏi nhưng thiếu visibility
Ví dụ
"Khi design microservices, mình thường..."
"Bạn thấy trade-off là gì?"
Đề xuất tên trong meeting leadership
Nguyên tắc chuyển đổi
Junior dev → Cần MENTOR nhiều hơn (chưa biết gì, cần direction)
Mid dev → Cần MIX mentor + coach (biết rồi, cần guidance)
Senior dev → Cần COACH nhiều hơn (có năng lực, cần unlock)
All levels → Cần SPONSOR (visibility và opportunity)
Skill Development Plan Template
Template
markdown
## Skill Development Plan - [Tên] - Q[x] 2025### Current Assessment
| Skill Area | Current Level (1-5) | Target Level | Gap |
|------------|-------------------|--------------|-----|
| System Design | 3 | 4 | 1 |
| Cloud Architecture (Azure) | 2 | 4 | 2 |
| Technical Writing | 3 | 4 | 1 |
| Leadership/Mentoring | 2 | 3 | 1 |
### Action Plan
| Skill | Actions | Resources | Timeline | Check-in |
|-------|---------|-----------|----------|----------|
| Cloud Architecture | 1. Hoàn thành AZ-305 cert | MS Learn, Udemy | 8 tuần | Bi-weekly |
| | 2. Lead migration project module | Real project | 4 tuần | Weekly |
| | 3. Write ADR cho cloud decisions | Team wiki | Ongoing | Monthly |
### Success Criteria- [ ] Pass AZ-305 certification
- [ ] Successfully deploy 2 services lên Azure
- [ ] Present architecture decision tại team meeting
### Support Needed- Budget cho certification exam
- Pair session với Cloud architect 1h/tuần
- Dedicated learning time 4h/tuần
Level Assessment Guide
Level
Description
Indicator
1 - Awareness
Biết concept tồn tại
Đọc về nó
2 - Learning
Đang học, làm được với guidance
Cần help thường xuyên
3 - Practicing
Tự làm được, đôi khi cần review
Deliver với quality ok
4 - Proficient
Làm tốt, có thể teach người khác
Lead technical decisions
5 - Expert
Deep expertise, innovate
Recognized trong org/community
Pair Programming as Mentoring Tool
Các kiểu pair programming
Style
Mô tả
Khi nào dùng
Driver-Navigator
Mentee code, Mentor guide
Default cho mentoring
Ping-Pong
Luân phiên viết test ↔ implementation
Teach TDD
Strong-style
"Để idea đi qua tay người khác"
Khi mentee cần build confidence
Mob Programming
Cả team cùng 1 máy
Knowledge sharing rộng
Best Practices cho Mentoring Pairs
DO:
✓ Để mentee drive 70% thời gian
✓ Think aloud - giải thích reasoning
✓ Hỏi "Bạn nghĩ bước tiếp theo là gì?" trước khi suggest
✓ Celebrate small wins
✓ Giới hạn session 1-2 giờ (tránh burnout)
DON'T:
✗ Giành keyboard khi mentee đang stuck
✗ Nói "dễ mà" hoặc "hiển nhiên là..."
✗ Fix code mà không giải thích
✗ Pair cả ngày (diminishing returns)
Knowledge Transfer Sessions
Format Knowledge Transfer (KT)
1. Overview Session (60 phút)
- Architecture overview + big picture
- Key design decisions và lý do
- Known issues và tech debt
2. Deep-dive Sessions (45 phút × N)
- Mỗi session focus 1 module/service
- Live walkthrough code
- Hands-on exercise
3. Shadow Session (2-4 giờ)
- Mentee observe mentor handle real work
- On-call shadowing, production debugging
4. Reverse Teaching (30 phút)
- Mentee explain lại cho mentor
- Phát hiện gaps trong understanding
KT Checklist cho Service/Module
Architecture diagram updated
README với setup instructions
Key flows documented (happy path + error paths)
Runbook cho common operations
At least 1 pair session doing real task
Mentee có thể deploy independently
Mentee handle 1 production issue (với backup)
Setting Learning Goals
Framework: 70-20-10
Source
%
Ví dụ
On-the-job
70%
Stretch assignments, new projects, production issues
## Learning Goal - Q[x]**Goal:** [Specific skill hoặc knowledge area]
**Why:** [Tại sao quan trọng cho role/career]
**Measure:** [Làm sao biết đã đạt]
### 70% - On-the-job- Take ownership của [specific task/project]
- Apply [skill] trong daily work
### 20% - Social- Pair với [person] về [topic] - 2x/tháng
- Present [topic] tại team meeting
### 10% - Formal- Complete [course/book]
- Attend [meetup/conference]
Feedback Models
SBI Model (Recommended)
SBI (Situation-Behavior-Impact) là model feedback rõ ràng, objective, không mang tính phán xét.
Component
Mô tả
Ví dụ
Situation
Bối cảnh cụ thể
"Trong code review hôm thứ Ba..."
Behavior
Hành vi quan sát được
"...bạn đã review rất kỹ và suggest refactor service layer..."
Impact
Tác động
"...giúp giảm 30% duplicate code và team học được pattern mới"
So sánh Feedback Sandwich vs SBI
Aspect
Feedback Sandwich
SBI Model
Structure
Positive → Negative → Positive
Situation → Behavior → Impact
Vấn đề
Người nghe chỉ nhớ positive, miss feedback thật
Clear và actionable
Trust
Lâu dần người ta biết "khen trước = sắp chê"
Transparent, honest
Khi nào dùng
Tránh dùng
Default cho mọi feedback
Ví dụ SBI cho constructive feedback
Situation: "Trong sprint planning hôm qua..."
Behavior: "...khi Minh đưa ra estimation, bạn nói thẳng 'estimate này sai'
trước mặt cả team mà không giải thích lý do..."
Impact: "...Minh cảm thấy bị undermined và ít share ý kiến
trong discussion sau đó. Team cũng ngại estimate."
→ Follow up: "Bạn nghĩ lần sau có thể approach khác thế nào?"
Creating a Learning Culture
Các hoạt động xây dựng learning culture
Activity
Frequency
Effort
Impact
Tech Talk (team member present)
Bi-weekly
Medium
High
Book club / Article discussion
Monthly
Low
Medium
Hackathon / Innovation day
Quarterly
High
High
Post-mortem (blameless)
After incidents
Medium
High
Code review as teaching
Daily
Low
High
Conference budget per person
Annual
Low (money)
Medium
Checklist cho Engineering Manager
Mỗi team member có learning goal trong quarterly plan