Câu chuyện mở đầu
Khoảng 3 năm trước, tôi gặp một anh bạn tôi - anh ta là tech lead tại một startup fintech khá lớn. Chúng tôi ngồi cà phê, anh kể rằng anh rất bối rối vì junior developers trong team của anh cứ "yếu cơm, yếu nước" - cứ hỏi tôi mọi thứ.
"Tôi đã cố dạy họ mọi thứ rồi," anh nói. "Nhưng mỗi lần có vấn đề mới, họ lại hỏi. Còn nữa, mỗi lần tôi dạy, tôi phải giải quyết rất nhanh vì deadline ép, nên tôi thường chỉ nói 'làm cái này, kết quả sẽ ra' - nhưng tôi thấy không ai hiểu tại sao phải làm thế."
Lúc đó tôi nhận ra: anh bạn tôi đang rơi vào cái bẫy của sự hiệu quả ngắn hạn. Anh đang dạy code, nhưng không dạy cách suy nghĩ. Kết quả là junior phụ thuộc vào anh, không bao giờ độc lập.
Quay lại chuyện mentoring
Mentoring không phải là transfer knowledge từ người anh lên xuống người em. Đó là giúp họ phát triển khả năng tự giải quyết vấn đề.
Tôi đã làm mentoring cách "sai" rất lâu. Tôi sẽ nói: "Đây là cách để fix bug này. Làm theo các bước..."
Rồi sao? Junior không hiểu sâu. Lần tới gặp vấn đề tương tự, họ vẫn lại hỏi. Vô hạn vòng lặp.
Sau đó, tôi học được cách khác. Thay vì nói "cách làm", tôi nên:
- Hỏi ngược họ: "Em thấy vấn đề gì ở đây?"
- Chỉ cho họ phương hướng: "Hãy thử xem logs này. Có thể sự cố nằm ở đâu?"
- Cùng giải quyết: "Em đi vào điểm nào? Tôi cùng em phân tích."
- Để họ ra quyết định: "Em nghĩ giải pháp nào là tốt nhất? Tại sao?"
Kết quả? Họ không chỉ fix bug, mà còn học cách suy nghĩ để fix bug trong tương lai.
Mentoring = Lắng nghe + Coaching
Có ba yếu tố quan trọng mà tôi học được:
1. Lắng nghe thực sự (Active Listening)
Hầu hết các tech lead tôi biết (có lúc tôi là một trong họ) - khi junior hỏi, chúng tôi lắc lắc đầu mà chẳng nghe. Chúng tôi đang suy nghĩ về câu trả lời, chứ không phải câu hỏi.
Lắng nghe đúng cách là:
- Đặt lại câu hỏi của họ bằng lời của tôi: "Nên em muốn hiểu tại sao query này slow, phải không?"
- Chờ họ xác nhận.
- Từ đó, chúng ta cùng khám phá.
2. Coaching thay vì Solution-Giving
Coaching là giúp họ tìm câu trả lời, không phải đưa câu trả lời.
Ví dụ với junior dev đang debug performance issue:
Sai (Solution-giving):
"Code này slow vì N+1 query. Dùng .Include() để eager load. Sẽ nhanh."
Đúng (Coaching):
"Em thấy database requests bao nhiêu khi load page này? Hãy check Profiler. Em thấy gì không? Có pattern nào bất thường không?"
Rồi họ tự phát hiện N+1. Khi họ tự phát hiện, bài học sẽ lâu dài hơn.
3. Tạo Safe Environment
Junior developer sợ:
- Hỏi mà bị chỉ trích
- Làm sai rồi bị trách
- Không hiểu mà phải giả bộ hiểu
Nếu mentoring relationship không safe, họ sẽ không dám hỏi. Và khi không dám hỏi, họ sẽ... không học.
Cách tôi tạo safe environment:
- "Không có câu hỏi ngu. Nếu em không hiểu, em hỏi."
- "Bug là bình thường. Cơ hội để học."
- "Tôi cũng đã làm sai. Lúc em cùng tuổi tôi, tôi còn tệ hơn."
Kinh nghiệm từ 20 năm trong nghề
Tôi từng dạy (mentoring) khoảng 30+ junior developers qua các công ty. Một số bây giờ là senior, một số là tech lead. Một số... bỏ cuộc.
Những người bỏ cuộc, không phải vì họ không thông minh. Mà vì:
- Không có clear roadmap: Họ không biết mình cần học gì tiếp theo. Mentoring mà không có goal, là lơ lửng.
- Mentoring relationship không ổn định: Mentor bận, ít gặp mentee. Hoặc mentor bỏ đi công ty.
- Expectations không match: Mentee muốn learn, nhưng mentor chỉ muốn "transfer tasks" thay vì transfer knowledge.
Những người thành công? Họ có:
- Clear goals: "Em muốn hiểu Clean Code. Tiếp theo muốn tìm hiểu Design Patterns."
- Regular check-ins: Mỗi tuần 30 phút 1-on-1. Có consistency.
- Growth mindset: Cả mentor lẫn mentee đều tin vào sự phát triển.
Một sai lầm lớn: "Mentoring = Có thời gian rảnh"
Tôi gặp nhiều senior developer chỉ muốn mentoring khi họ "rảnh". Nhưng reality là: bạn sẽ không bao giờ rảnh. Nếu mentoring không là priority, thì nó sẽ bị postpone mãi.
Tôi nên block calendar cho mentoring như block cho meeting. Mình làm tech lead chứ không phải "developer +title mentoring khi có thời gian".
Gửi các bạn trẻ - Nếu bạn là junior
Nếu bạn có mentor:
- Hỏi tận đáy: Không hiểu sao lại dùng solution này? Hỏi.
- Tìm kiếm mentor tự động: Đừng chỉ answer-seeking. Hãy tìm mentorship relationship - regular, có goal.
- Ghi chép bài học: Đừng chỉ làm theo hướng dẫn. Sau mỗi session, hãy note lại điều gì bạn học được.
Nếu bạn không có mentor chính thức:
- Tìm một senior developer. Hỏi họ có thời gian 30 phút/tuần không.
- Chuẩn bị câu hỏi rõ ràng trước lúc gặp.
- Theo dõi senior developers trên blog, podcast, GitHub - có thể họ sẽ share kiến thức.
Gửi các bạn senior - Nếu bạn là mentor
Nếu bạn muốn mentoring junior:
Hãy tự hỏi:
- "Tôi có thực sự muốn mentoring không, hay chỉ là duty?"
- "Tôi có block thời gian hàng tuần cho mentoring không?"
- "Tôi có hiểu mentoring là coaching (giúp suy nghĩ), không phải solution-giving (đưa đáp án) không?"
Nếu trả lời Có cho cả ba, hãy:
- Chọn 1-2 junior để mentor (không mentoring 10 người cùng lúc).
- Set clear expectations: frequency, goals, duration.
- Coaching framework: Hỏi → Hướng dẫn → Cùng khám phá → Feedback.
Triết lý: Một người junior hôm nay, là senior tương lai
Tôi đang mentoring một anh em junior bây giờ. Anh ta khiêm tốn, không sợ hỏi, và cứ 2 tuần anh ta mang tới một "aha moment" - những bài học mà anh ta tự phát hiện.
6 tháng nữa, anh ta sẽ là mid-level developer. 2 năm nữa, anh ta có thể là tech lead. Và khi anh ta là tech lead, anh ta sẽ mentoring người khác.
Mentoring không phải là một dịch vụ mà tôi cung cấp cho junior. Đó là đầu tư vào tương lai của team, công ty, và ngành.
Bạn đang mentoring junior nào không? Hay bạn là junior đang cần mentor?
Hãy comment dưới bài viết. Chia sẻ trải nghiệm của bạn - cái gì hoạt động, cái gì không. Mentoring là con đường 2 chiều. Tôi rất muốn biết câu chuyện của các bạn.
Hoặc nếu bạn là junior, bạn đã gặp mentor nào khiến bạn thay đổi? Hãy kể lại. Và nếu bạn chưa có mentor, đây là signal để bạn tìm một. Không ai là lửa bị sống một mình được. :)
/Son Do - believe in basic
#1percentbetter #mentoring #techleadership #engineeringculture #juniorengineer #developergrowth