Mentorship & Dẫn dắt nhóm 🎓

Mentorship là kỹ năng phân biệt một Senior Engineer thông thường với một người thực sự tạo ra ảnh hưởng trong tổ chức. Code giỏi chỉ tạo ra ảnh hưởng theo độ rộng của 1 người. Mentor tốt có thể nhân vùng ảnh hưởng đó lên 5-10 lần thông qua từng người mình đào tạo.

1. Triết lý Mentorship — "Teach to fish, not give fish"

Mục tiêu cuối cùng của mentor không phải là giải quyết vấn đề cho mentee, mà là giúp họ có khả năng tự giải quyết vấn đề tương tự trong tương lai.

Điều này đồng nghĩa với việc đôi khi bạn phải chịu đựng sự khó chịu khi nhìn họ vật lộn với một vấn đề mà bạn đã biết câu trả lời từ 5 phút trước. Đó là điều tốt. Quá trình "vật lộn" là lúc learning xảy ra.

Spectrum of Mentorship

Không có một kiểu mentor duy nhất. Tùy bối cảnh, bạn cần chuyển đổi giữa các mode:

2. Onboarding thực chiến — 30/60/90 Day Plan

Tuần đầu — Orientation

Mục tiêu không phải là code, mà là cảm thấy chào đón và hiểu được bức tranh lớn.

Checklist ngày đầu tiên:

• Setup môi trường hoàn chỉnh (và update README nếu gặp vấn đề)
• Tour qua codebase từ 10,000 feet (kiến trúc, main services, data flow)
• Gặp gỡ các thành viên trong team (có thể là 1:1 ngắn 15 phút)
• Hiểu được "Definition of Done" và Git workflow của team
• Hiểu được sản phẩm từ góc độ user (dùng thử app)

30 ngày đầu — Building Foundation

• Merge được 2-3 PR nhỏ (Good First Issues), đã đi qua full cycle: code → review → staging → deploy.
• Có thể fix bug nhỏ mà không cần hỏi nhiều.
• Hiểu được domain của team, business logic chính.

30-60 ngày — Growing Autonomy

• Tự pick ticket có medium complexity.
• Bắt đầu tham gia thảo luận technical design.
• Có thể review code của người khác (ít nhất là phần mình quen).

60-90 ngày — Contribution

• Drive được một feature nhỏ end-to-end.
• Chủ động đề xuất cải tiến (không chỉ làm theo yêu cầu).
• Có thể là người Buddy cho một onboarding tiếp theo.

3. Pair Programming — Làm đúng mới có hiệu quả

Lỗi phổ biến nhất: Mentor cầm keyboard

Khi người mới bị stuck 5 phút, bản năng tự nhiên là "để tôi làm cho nhanh". Đây là sai lầm nghiêm trọng nhất trong mentorship.

Luật vàng: Mentee là Driver (tay trên keyboard), Mentor là Navigator (chỉ đường bằng lời).

Nếu cần demo kỹ thuật, hãy làm trên máy tính của mentor hoặc trong một file riêng, rồi để mentee tự implement lại.

Socratic Method trong Debugging

Thay vì:

"Lỗi ở chỗ này vì userID bị null ở đây, fix lại check null là xong."

Hãy hỏi:

"Lỗi nói gì? NullPointerException. Vậy cái gì đang null? userID. Nó đến từ đâu? Từ request. Vậy khi nào request không có userID?..."

Khi mentee tự tìm ra bug, họ sẽ nhớ nó mãi mãi. Khi bạn chỉ cho họ câu trả lời, họ sẽ quên sau 2 ngày.

Think Aloud Protocol

Khuyến khích mentee nói thành tiếng những gì họ đang suy nghĩ trong lúc debug hoặc code. "Em đang nghĩ là..." "Em thử xem ở đây trước vì..."

Lợi ích:

• Mentor có thể phát hiện misconception sớm hơn.
• Mentee học được cách suy nghĩ có hệ thống.
• Cả hai học được cách trình bày tư duy — kỹ năng cực quan trọng để thăng tiến.

4. Delegation — Giao việc hiệu quả

Delegation Matrix

Khi giao việc, hãy phân loại theo 2 chiều: Skill (Năng lực) và Will (Động lực):

          High Will
              │
   [Support]  │  [Delegate]
   Cần coach  │  Giao và tin
   để build   │  tưởng
   skill      │
──────────────┼──────────────  Skill
   [Direct]   │  [Coach]
   Cần hướng  │  Cần thách thức
   dẫn cụ thể │  và motivation
              │
          Low Will

• High Skill + High Will: Giao việc và trust hoàn toàn. Check-in 1 lần/tuần là đủ.
• High Skill + Low Will: Tìm hiểu tại sao mất motivation. Giao challenge mới, rotate task.
• Low Skill + High Will: Coach kỹ thuật, pair programming, code review chi tiết.
• Low Skill + Low Will: Giao task nhỏ có kết quả rõ ràng để build confidence, tìm hiểu root cause của disengagement.

Giao kết quả, không giao phương pháp

Kém: "Em vào file handlers/user.go, thêm function UpdateUserEmail, gọi service userService.UpdateEmail(), raise lỗi nếu email không hợp lệ."

Tốt: "Em handle task này nhé: User muốn đổi email. Email mới phải valid, unique trong hệ thống, và sau khi đổi gửi email xác nhận. Em đọc requirement, design trước rồi chạy qua anh review design xem approach ổn không, trước khi code."

Sự khác biệt: Phiên bản tốt để mentee tư duy về problem thay vì chỉ execute instructions.

Safety Net — Không phải lưới bắt, mà lưới đỡ

Mục tiêu khi delegate là tạo "safety net" — giúp mentee tự tin thử nghiệm vì biết rằng nếu có vấn đề, vẫn có người support.

Cụ thể:

• Không merge lên production những thứ đã deploy lên staging mà chưa review (kể cả khi tin tưởng mentee).
• Có rollback plan cho mọi deploy của người mới.
• Báo cáo lên manager về progress của mentee để có expectation alignment.

5. Giving Feedback — Kỹ năng quan trọng nhất

Framework SBI (Situation - Behavior - Impact)

Đây là cách đưa negative feedback mà không bị troll là "toxic":

S - Situation: Mô tả bối cảnh cụ thể, không chung chung.

❌ "Em hay đến trễ." ✅ "Trong sprint 2 tuần vừa rồi..."

B - Behavior: Mô tả hành vi quan sát được, không judgement.

❌ "Em thiếu tôn trọng team." ✅ "Em đến standup sau 15 phút 3 lần."

I - Impact: Nêu ảnh hưởng thực tế, không phóng đại.

❌ "Cả team rất bực." ✅ "Team mất 5-10 phút mỗi ngày để recap lại cho em, và chúng ta không nắm được blocker của em kịp thời."

Kết hợp:

"Trong sprint vừa rồi, em đến standup sau 15 phút 3 lần. Điều đó khiến team mất thêm thời gian recap và không nắm được blocker của em sớm. Em thấy sao về vấn đề này?"

Positive Feedback — Đừng bỏ qua

Positive feedback không chỉ là "Good job!" — nó cần cụ thể để có giá trị:

❌ "Em làm tốt lắm!" ✅ "Cách em handle race condition trong task caching tuần này rất thông minh. Em không chỉ fix bug mà còn thêm test cover edge case đó. Anh thấy approach này rất mature."

Khen công khai, góp ý riêng tư

• Khen ngợi: Trong standup, Slack channel chung, Sprint review — để cả team thấy.
• Góp ý/Criticism: Luôn trong 1:1 riêng tư. Không bao giờ chỉ trích ai trước mặt người khác.

Nhận feedback về... bản thân bạn với tư cách mentor

Định kỳ hỏi mentee: "Anh có thể support em tốt hơn theo cách nào?" Câu hỏi này khó hỏi nhưng rất quan trọng — nó cho thấy bạn không phải người "hoàn hảo" và tạo psychological safety để mentee thật thành thật.

6. 1:1 Meeting — Công cụ quan trọng nhất của Mentor

Cấu trúc 1:1 hiệu quả (30-45 phút mỗi tuần)

Không nên: Status update dự án (đã có standup cho việc này), nói chuyện về technical detail.

Nên:

• 10 phút: Mentee-led — họ muốn nói về vấn đề gì? Struggle ở đâu?
• 10 phút: Mentor-led — feedback, coaching về kỹ năng, career advice.
• 10 phút: Growth — goals của mentee là gì? Họ đang learn gì mới?

Câu hỏi powerful trong 1:1

• "Em đang học được gì mới trong dự án này?"
• "Điều gì đang làm em frustrated nhất hiện tại?"
• "Nếu em được thay đổi một điều trong team, em sẽ thay đổi gì?"
• "Trong 6 tháng tới em muốn giỏi hơn ở điểm nào?"
• "Anh có thể làm gì tốt hơn để support em không?"

Ghi chú 1:1

Luôn ghi chép lại (Google Doc shared giữa hai người). Điều này:

• Tạo accountability cho cả hai.
• Dễ track progress theo thời gian.
• Tránh "Tôi tưởng chúng ta nói thế này mà?"

7. Khi Mentorship trở nên khó khăn

Mentee không chịu apply feedback

Nếu bạn đã comment/feedback nhiều lần nhưng mentee vẫn repeat cùng mistake:

1. Đặt câu hỏi trước khi tự kết luận: "Em có thể giải thích tại sao em handle lỗi theo cách này không?"
2. Pair programming để observe: Có thể họ không hiểu feedback, không phải không muốn apply.
3. Be explicit và document: Ghi rõ ràng trong 1:1 note: "Chúng ta đã thống nhất điểm X, trong sprint tới anh sẽ expect em apply điều này vào task Y."

Mentee xuất sắc hơn bạn ở một số lĩnh vực

Đây là dấu hiệu tốt, không phải đáng lo ngại. Mentor tốt không cần phải giỏi hơn mentee mọi mặt — bạn có kinh nghiệm, context, và hệ thống tư duy mà họ chưa có. Hãy thẳng thắn: "Phần này em biết rõ hơn anh, anh muốn học từ em."

Khi bạn không có thời gian

Mentorship cần thời gian. Nếu bạn đang quá tải:

• Thương lượng với manager về workload.
• Giảm số lượng mentee xuống còn 1 người thay vì 3.
• Delegate một số phần mentorship sang senior khác trong team.

Mentorship kém hiệu quả vì thiếu thời gian còn tệ hơn là không mentorship.