Mở đầu — vì sao bài này quan trọng
Có một sự thật mà rất nhiều Tech Lead và Engineering Manager mới lên nhận ra quá muộn: bạn không thể tự mình mở rộng quy mô (scale) bằng cách code nhiều hơn. Một ngày chỉ có 24 giờ, và dù bạn giỏi đến đâu, năng lực cá nhân của bạn cũng là một trần cứng. Đòn bẩy thực sự của một người lãnh đạo kỹ thuật nằm ở việc nâng cấp năng lực của những người xung quanh — biến những kỹ sư junior và mid-level thành senior thực thụ.
Đây không phải chuyện "tốt bụng" hay "mềm mại". Đây là bài toán kinh doanh sống còn. Ở thị trường Việt Nam và Đông Nam Á, tuyển một senior engineer giỏi có thể mất 3–6 tháng, tốn hàng nghìn đô phí headhunter, và thường phải cạnh tranh lương với các công ty product lớn như Grab, Shopee, VNG, MoMo. Trong khi đó, nếu bạn có một quy trình "trồng người" tốt, bạn có thể tự nuôi senior từ chính đội ngũ của mình — vừa rẻ hơn, vừa giữ được context, vừa xây dựng lòng trung thành.
Bài học này tập trung vào các pattern (mô hình lặp lại) cụ thể để phát triển senior engineer. Chúng ta sẽ không nói chung chung về "hãy mentor nhiều hơn", mà đi vào từng cơ chế thực tế mà bạn — với tư cách Tech Lead — có thể áp dụng ngay tuần sau. Lưu ý: bài này không bàn về khung career ladder tổng thể (đó là Bài 22) hay quản lý hiệu suất (Bài 24) — chúng ta chỉ tập trung vào hành động phát triển con người để đưa họ lên cấp senior.
Khái niệm cốt lõi
Junior → Senior là về scope, không phải tuổi hay số năm
Sai lầm phổ biến nhất khi đánh giá "ai đã là senior" là đếm số năm kinh nghiệm. Ở Việt Nam, ta thường thấy tin tuyển dụng ghi "Senior: 5 năm kinh nghiệm". Nhưng số năm chỉ đo thời gian ngồi ghế, không đo scope của vấn đề mà người đó xử lý được.
Cách phân biệt chính xác hơn nằm ở phạm vi ảnh hưởng (scope of ownership):
- Junior giải được task được giao. Bạn đưa họ một ticket rõ ràng ("thêm nút này, gọi API kia"), họ hoàn thành. Họ cần người khác chia nhỏ vấn đề giúp mình.
- Mid-level giải được một feature hoàn chỉnh. Bạn đưa họ một yêu cầu ở mức feature, họ tự chia thành các task và làm xong, ít cần dẫn dắt.
- Senior identify vấn đề + solve + truyền đạt. Họ không chờ được giao. Họ nhìn thấy vấn đề mà chưa ai gọi tên (ví dụ: "cái flow thanh toán này sẽ vỡ khi traffic tăng gấp 5"), tự đề xuất giải pháp, thực thi, và quan trọng nhất — làm cho cả team giỏi lên nhờ cách họ giải.
5 pattern cốt lõi để phát triển senior engineer
Từ dàn ý gốc, đây là năm mô hình mà tôi thấy hiệu quả nhất qua thực tế:
1. Delegation theo bậc thang (Progressive delegation). Đừng giao việc theo kiểu "được ăn cả ngã về không". Hãy tăng scope từng nấc: từ task → feature → dự án nhỏ → mảng ownership. Mỗi lần bạn giao một thứ lớn hơn một chút so với vùng an toàn hiện tại của họ (stretch assignment).
2. Stretch assignment có lưới an toàn (Safe-to-fail challenges). Cho họ nhận việc khó hơn khả năng hiện tại một chút, nhưng ở nơi thất bại không gây thảm họa. Đây là cách kỹ năng thực sự lớn lên — không ai thành senior bằng cách chỉ làm những việc dễ.
3. Ownership thay vì task-based work. Chuyển họ từ "người làm ticket" sang "người sở hữu một mảng". Ví dụ: giao cho một mid-level việc chịu trách nhiệm toàn bộ hệ thống notification, chứ không phải từng ticket lẻ về notification.
4. Mentorship và pairing có chủ đích. Ghép cặp có mục tiêu rõ ràng, không phải "ngồi cạnh cho vui". Senior kèm mid, mid kèm junior — và bản thân việc đi kèm người khác chính là bài tập nâng cấp lên senior.
5. Feedback loop nhanh và cụ thể. Senior lớn lên nhờ được phản hồi kịp thời và có tính hành động. "Code này ổn" không giúp ai lớn lên. "Chỗ này em nên tách hàm ra vì lý do X, và cân nhắc edge case Y" mới tạo ra tăng trưởng.
Ba năng lực định nghĩa senior (và bạn cần bồi dưỡng)
Để mở rộng scope, một người cần ba nhóm năng lực mà bạn phải chủ động vun đắp:
- Technical judgment (phán đoán kỹ thuật): biết khi nào nên làm "đúng chuẩn" và khi nào "đủ tốt là được". Đây là thứ tách senior khỏi mid — không phải viết code phức tạp hơn, mà biết khi nào không cần phức tạp.
- Ownership & khả năng dẫn dắt sự mơ hồ (dealing with ambiguity): dám bước vào vùng chưa rõ ràng, tự đặt câu hỏi đúng, tự vẽ đường đi.
- Đòn bẩy qua người khác (force multiplier): viết tài liệu, review giúp người khác giỏi lên, chia sẻ kiến thức — biến cái mình biết thành cái cả team biết.
Tình huống thực tế
Tình huống 1: Tiki — biến một mid-level "an toàn" thành owner hệ thống thanh toán
Bối cảnh (giả định hợp lý dựa trên mô hình các công ty e-commerce Việt): Tại một team payment của một sàn TMĐT lớn ở TP.HCM, có bạn Minh — 3 năm kinh nghiệm, code sạch, làm task cực kỳ đáng tin cậy nhưng luôn chờ được giao. Tech Lead nhận ra Minh đã chạm trần mid-level suốt gần một năm.
Diễn giải: Thay vì tiếp tục giao ticket lẻ, Tech Lead trao cho Minh ownership toàn bộ luồng retry của cổng thanh toán — một mảng đang gây 4–5 sự cố nhỏ mỗi tháng. Đây là stretch assignment kinh điển: đủ khó để Minh phải học về idempotency, distributed transaction, monitoring; nhưng có lưới an toàn vì Tech Lead review architecture trước khi lên production, và có staging để thử. Tech Lead nói rõ: "Từ giờ anh không giao ticket về retry nữa. Em là người quyết. Anh chỉ review khi em cần." Trong 3 tháng, số sự cố retry giảm từ ~5 xuống còn dưới 1/tháng, và Minh bắt đầu tự viết runbook cho cả team.
Bài học rút ra: Chuyển từ task-based sang ownership là công tắc mạnh nhất để lên senior. Khoảnh khắc một người phải chịu trách nhiệm cho kết quả chứ không chỉ đầu ra, họ buộc phải suy nghĩ ở tầm senior. Và điều then chốt: Tech Lead phải thực sự buông tay — nếu vẫn giao ticket lẻ song song, ownership chỉ là danh nghĩa.
Tình huống 2: Một startup fintech ở Singapore — dùng "code review có giảng giải" làm bệ phóng
Bối cảnh: Một startup fintech Series A tại Singapore, team 12 engineer, có ba bạn junior mới ra trường. CTO nhận thấy các junior vá lỗi kiểu "chữa triệu chứng" và không tự tin đưa ra quyết định kỹ thuật.
Diễn giải: CTO áp dụng pattern mentorship qua review có chủ đích. Ông yêu cầu hai senior không chỉ approve/reject PR mà phải để lại ít nhất một comment mang tính "dạy" — giải thích tại sao, kèm ví dụ hoặc link. Đồng thời, mỗi junior được ghép với một senior làm mentor cố định, gặp 30 phút/tuần với một mục tiêu kỹ năng cụ thể (ví dụ tháng này: "học viết integration test"). Sau 2 quý, một junior tên Wei tiến bộ đủ để tự làm mentor cho intern mới — và chính hành động dẫn dắt người khác đã đẩy Wei sang ranh giới senior sớm hơn dự kiến.
Bài học rút ra: Feedback loop cụ thể + mentorship có mục tiêu tạo ra tăng trưởng nhanh gấp nhiều lần so với "để tự bơi rồi tự giỏi". Và một dấu hiệu vàng của việc sắp lên senior: người đó bắt đầu nâng người khác lên, không chỉ giỏi một mình.
Tình huống 3: Cái bẫy "senior bằng cách làm việc khó một mình" tại một team outsourcing Hà Nội
Bối cảnh: Một công ty outsourcing ở Hà Nội có bạn Tuấn — cực kỳ giỏi kỹ thuật, một mình cân cả module khó nhất. Sếp nghĩ đây là senior gương mẫu và giao cho Tuấn ngày càng nhiều việc khó.
Diễn giải: Vấn đề lộ ra khi Tuấn nghỉ 2 tuần: cả module đứng hình vì không ai hiểu code, không có tài liệu, không có ai được Tuấn kèm. Tuấn giỏi giải quyết, nhưng thiếu hoàn toàn năng lực đòn bẩy qua người khác. Anh ta là "senior IC theo kỹ năng" nhưng chưa phải senior theo scope ảnh hưởng. Tech Lead sửa bằng cách đổi KPI phát triển của Tuấn: quý tới, thành công không đo bằng "làm xong bao nhiêu việc khó" mà bằng "có bao nhiêu người khác giờ làm được việc mà trước đây chỉ Tuấn làm được". Tuấn buộc phải viết tài liệu, pair, và chia việc.
Bài học rút ra: Kỹ năng cá nhân xuất sắc là cần nhưng chưa đủ để thành senior thực thụ. Nếu bạn thưởng cho việc "ôm việc khó một mình", bạn vô tình nuôi ra những điểm nghẽn (bottleneck) và bus factor = 1. Senior thật sự nhân bản năng lực của mình ra team.
Hướng dẫn từng bước
Đây là quy trình để phát triển một engineer cụ thể lên senior:
Bước 1 — Định vị hiện tại. Với mỗi người trong team, tự trả lời: họ đang xử lý scope ở mức nào (task / feature / project / area)? Ba năng lực (judgment, ownership, force-multiplier) của họ mạnh yếu ra sao? Viết ra một câu: "Người này lên senior sẽ bị chặn bởi điều gì?"
Bước 2 — Chọn một stretch assignment. Tìm một việc lớn hơn vùng an toàn của họ một nấc — không phải mười nấc. Ưu tiên việc có giá trị thật cho team (để nỗ lực không lãng phí) nhưng thất bại không gây thảm họa (safe-to-fail). Nói rõ đây là cơ hội phát triển.
Bước 3 — Trao ownership, không phải task. Chuyển ngôn ngữ từ "làm ticket này" sang "em sở hữu mảng này". Định nghĩa rõ kết quả mong đợi, ranh giới quyết định (họ được tự quyết gì, cần hỏi gì), và cam kết bạn sẽ không nhảy vào giành lại vô cớ.
Bước 4 — Thiết lập lưới an toàn. Đặt các checkpoint (ví dụ review design trước khi code, demo giữa kỳ), chứ không phải micromanage từng bước. Cho họ biết thất bại ở mức nào là chấp nhận được và bạn đỡ lưng.
Bước 5 — Feedback loop hàng tuần. Gặp 1:1 ngắn, đưa phản hồi cụ thể và có tính hành động. Khen đúng hành vi senior khi thấy nó xuất hiện (đặt câu hỏi đúng, cân nhắc trade-off, giúp đồng đội).
Bước 6 — Buộc họ tạo đòn bẩy. Yêu cầu output không chỉ là code mà cả tài liệu, một buổi chia sẻ, hoặc kèm một người khác. Đây là bước biến "giỏi một mình" thành "nâng cả team".
Bước 7 — Đo bằng scope, ghi nhận công khai. Khi họ đã xử lý được scope của một senior một cách nhất quán qua vài chu kỳ, hãy ghi nhận rõ ràng — và đây là lúc kết nối sang các quy trình đánh giá/khung cấp bậc (thuộc phạm vi các bài khác).
Lỗi thường gặp & mẹo
Lỗi 1 — "Việc này để anh làm cho nhanh". Bẫy phổ biến nhất của Tech Lead. Khi bạn giành lại việc khó vì nóng ruột, bạn cướp mất cơ hội học của người khác. Mẹo: đặt câu hỏi "nếu mình không có ở đây, ai sẽ làm việc này?" — rồi giao cho chính người đó.
Lỗi 2 — Delegation kiểu ném bom. Giao việc quá lớn, quá đột ngột, không lưới an toàn, rồi ngạc nhiên khi họ thất bại và mất tự tin. Mẹo: tăng scope từng nấc, luôn có checkpoint.
Lỗi 3 — Thưởng cho anh hùng ôm việc. Như tình huống Tuấn — khen người ôm việc khó một mình sẽ nuôi ra bottleneck. Mẹo: đưa "giúp người khác giỏi lên" vào tiêu chí phát triển ngay từ đầu.
Lỗi 4 — Feedback mơ hồ hoặc để dồn. "Ổn đấy" không giúp ai lớn. Feedback dồn đến review 6 tháng thì đã quá muộn. Mẹo: phản hồi trong tuần, cụ thể, gắn với hành vi quan sát được.
Lỗi 5 — Nhầm chuyên môn giỏi với sẵn sàng làm senior. Người code giỏi chưa chắc dẫn dắt được sự mơ hồ hay nâng người khác. Mẹo: kiểm tra đủ cả ba năng lực trước khi kỳ vọng họ ở scope senior.
Mẹo bổ sung — nói thẳng về con đường. Nhiều engineer không lớn lên vì không ai nói cho họ biết "senior ở đây trông như thế nào". Hãy minh bạch: đây là scope em cần chạm tới, đây là những điều còn thiếu, và đây là kế hoạch của chúng ta.
Bài tập thực hành
- Bản đồ scope của team. Liệt kê từng thành viên và gán mức scope hiện tại (task / feature / project / area). Với mỗi mid-level, viết một câu về "rào cản lên senior" của họ.
- Thiết kế một stretch assignment. Chọn một người bạn muốn phát triển. Viết ra: (a) việc stretch cụ thể, (b) tại sao nó lớn hơn vùng an toàn của họ đúng một nấc, (c) lưới an toàn bạn đặt, (d) hai checkpoint.
- Chuyển task thành ownership. Chọn một mảng đang được làm theo kiểu ticket lẻ. Viết ra bạn sẽ trao ownership mảng đó cho ai, định nghĩa kết quả mong đợi và ranh giới quyết định của họ như thế nào.
- Viết lại 3 comment review. Lấy 3 comment review gần đây của bạn và viết lại theo hướng "dạy" — thêm tại sao và một gợi ý hành động, thay vì chỉ chỉ ra lỗi.
- Tự soi bản thân. Trong 2 tuần qua, có việc khó nào bạn đã tự làm mà đáng lẽ nên giao cho người khác để họ học không? Ghi lại và cam kết một hành động khác đi cho lần sau.
Tóm tắt
- Đòn bẩy lớn nhất của lãnh đạo kỹ thuật là nâng cấp con người, không phải tự code nhiều hơn — vì năng lực cá nhân luôn có trần.
- Junior → Senior là về scope, không phải tuổi hay số năm. Junior giải task được giao; senior identify vấn đề + solve + truyền đạt và nhân bản năng lực ra team.
- Năm pattern cốt lõi: progressive delegation, stretch assignment safe-to-fail, ownership thay vì task, mentorship/pairing có chủ đích, feedback loop nhanh và cụ thể.
- Senior cần ba năng lực bạn phải chủ động bồi dưỡng: technical judgment, ownership trong sự mơ hồ, và đòn bẩy qua người khác (force multiplier).
- Các bài học thực tế: chuyển từ task sang ownership là công tắc mạnh nhất (Tiki/Minh); mentorship + review có giảng giải tăng tốc mạnh (fintech Singapore); và đừng nhầm "giỏi một mình" với senior thực thụ (Tuấn/Hà Nội).
- Tránh các bẫy: giành lại việc khó, delegation ném bom, thưởng anh hùng ôm việc, feedback mơ hồ, và nhầm chuyên môn giỏi với sẵn sàng làm senior.