Mở đầu — vì sao bài này quan trọng
Trong gần 60 bài của khóa học này, chúng ta đã đi qua rất nhiều kỹ năng "nên làm" của một Tech Lead: cách delegate, cách review code, cách chạy incident, cách xây văn hóa. Nhưng có một sự thật mà ít ai nói thẳng: phần lớn Tech Lead giỏi không thất bại vì thiếu kỹ năng, mà vì mắc kẹt trong những anti-pattern — những khuôn mẫu hành vi trông có vẻ đúng, thậm chí đáng khen trong ngắn hạn, nhưng phá hoại đội ngũ và chính sự nghiệp của họ trong dài hạn.
Anti-pattern nguy hiểm ở chỗ nó thường xuất phát từ ý tốt. Bạn code nhiều hơn vì muốn giúp team giao hàng đúng hạn. Bạn tự quyết mọi thứ vì muốn tránh những cuộc họp dài dòng. Bạn ôm hết task khó vì bạn thực sự làm tốt nhất. Mỗi hành động đơn lẻ đều hợp lý — nhưng gộp lại chúng tạo ra một Tech Lead trở thành nút thắt cổ chai (bottleneck), một team không lớn lên được, và một cá nhân kiệt sức mà không hiểu tại sao mình càng cố gắng thì kết quả càng tệ.
Bài học này là tấm gương. Mục tiêu không phải để bạn cảm thấy tội lỗi, mà để bạn nhận diện sớm những khuôn mẫu này ở chính mình — vì hầu như ai cũng dính ít nhất một hoặc hai. Khi gọi được tên chúng, bạn đã đi được nửa đường tới việc sửa. Chúng ta sẽ đi qua các anti-pattern phổ biến nhất, mỗi cái kèm dấu hiệu nhận biết và cách "thoát bẫy" cụ thể.
Khái niệm cốt lõi
Anti-pattern lãnh đạo kỹ thuật là những phản ứng bản năng của một kỹ sư giỏi khi được đặt vào vai trò lead nhưng vẫn dùng bộ công cụ tư duy cũ. Vấn đề gốc là: cái đưa bạn lên vị trí Tech Lead (giỏi kỹ thuật, tự làm mọi thứ nhanh) không phải cái giúp bạn thành công ở vị trí đó (nhân bản năng lực qua người khác). Dưới đây là những anti-pattern hay gặp nhất.
1. The Hero — Người hùng ôm hết
Đây là anti-pattern kinh điển và cũng nguy hiểm nhất. Hero tự code những phần quan trọng nhất, từ chối delegate, và trở thành người duy nhất hiểu hệ thống. Kết quả là bus factor = 1 — nếu người này nghỉ (hoặc "bị xe buýt đâm", theo cách nói vui trong ngành), cả hệ thống đứng hình. Team thì luôn phải chờ Hero review, chờ Hero giải thích, chờ Hero fix. Hero thấy mình bận rộn và quan trọng, nhưng thực chất đang bóp nghẹt sự phát triển của cả đội.
Dấu hiệu: bạn là người commit nhiều nhất team; những task khó luôn "tự nhiên" rơi vào tay bạn; bạn hay nói "để tôi làm cho nhanh"; bạn không dám nghỉ phép dài.
2. The Bottleneck — Nút thắt quyết định
Gần giống Hero nhưng ở tầng quyết định. Mọi thứ phải qua bạn duyệt: từ tên biến, cách đặt tên branch, đến kiến trúc. Không ai dám quyết vì sợ làm sai ý bạn. Team mất tự chủ, tốc độ chậm lại, và bạn thì ngập trong hàng chục quyết định nhỏ mỗi ngày, không còn thời gian cho việc thực sự quan trọng.
3. The Absentee — Lead vắng mặt
Ngược lại với Bottleneck. Người này được thăng lên lead nhưng vẫn coi mình là IC (individual contributor) thuần túy, cắm đầu vào code của riêng mình, bỏ mặc team tự bơi. Không review, không định hướng, không unblock ai. Team cảm thấy bị bỏ rơi, tiêu chuẩn kỹ thuật trôi dạt, và những xung đột nhỏ tích tụ thành khủng hoảng.
4. The Perfectionist / Bikeshedder — Cầu toàn sai chỗ
Người này áp tiêu chuẩn hoàn hảo lên mọi thứ, kể cả những phần không quan trọng. Họ block một PR vì phong cách đặt tên trong khi kiến trúc tổng thể có lỗ hổng lớn không ai để ý. Đây là hiện tượng "bikeshedding" (định luật Parkinson về sự tầm thường): người ta tranh cãi màu sơn nhà để xe hàng giờ nhưng bỏ qua thiết kế lò phản ứng hạt nhân vì nó quá phức tạp để có ý kiến.
5. The Architect Astronaut — Kiến trúc sư trên mây
Say mê thiết kế những kiến trúc phức tạp, trừu tượng, "chuẩn tương lai" cho vấn đề mà hiện tại chưa hề tồn tại. Over-engineering vì lo xa. Team phải gánh chi phí bảo trì khổng lồ cho những abstraction chưa bao giờ cần đến. Đây là mặt trái của việc quá giỏi kỹ thuật.
6. The Yes-Man — Người gật đầu
Không dám nói "không" với sếp hay với PM. Nhận mọi deadline phi thực tế, cam kết thay cho team mà không hỏi ý kiến team. Kết quả là burnout tập thể, chất lượng tụt dốc, và mất niềm tin từ chính những người mình lead vì họ cảm thấy không được bảo vệ.
7. The Ostrich — Đà điểu vùi đầu
Né tránh những cuộc trò chuyện khó (difficult conversations — chủ đề của bài 58). Có một thành viên underperform suốt ba tháng nhưng lead không dám nói thẳng, chỉ âm thầm bù đắp bằng cách tự làm phần việc của họ. Vấn đề mưng mủ cho đến khi không thể cứu vãn.
Điểm chung của tất cả anti-pattern: chúng đều là tối ưu cục bộ, thua ở tổng thể. Bạn giải quyết được vấn đề trước mắt (task này xong nhanh, cuộc họp này êm đẹp) nhưng làm suy yếu hệ thống bền vững của team.
Tình huống thực tế
Ví dụ 1: "Anh Tuấn làm hết" tại một fintech ở TP.HCM
Tuấn là Tech Lead của một team 6 người tại một công ty fintech đang scale nhanh ở TP.HCM (giả định, nhưng kịch bản rất phổ biến). Anh là kỹ sư giỏi nhất, từng một mình viết lõi hệ thống thanh toán. Khi lên lead, anh vẫn giữ thói quen cũ: mọi module quan trọng — cổng thanh toán, đối soát, xử lý webhook — đều do anh tự viết. Junior trong team chỉ được giao mấy task CRUD đơn giản.
Kết quả sau 8 tháng: velocity của team tính trên đầu người thực ra giảm, vì 5 người còn lại không được giao việc thật để trưởng thành. Tuấn làm 60 giờ/tuần, review 20 PR mỗi ngày, và trở thành người phê duyệt duy nhất cho mọi release. Rồi Tuấn xin nghỉ 2 tuần về quê cưới vợ. Trong 2 tuần đó, một bug đối soát nghiêm trọng phát sinh, không ai trong team đủ hiểu code để fix. Công ty phải gọi điện làm phiền Tuấn giữa tuần trăng mật, và mất gần 40 triệu đồng do sai lệch đối soát không được xử lý kịp.
Bài học: Đây là anti-pattern Hero + Bottleneck kết hợp, dẫn tới bus factor = 1. Giá trị thật của một Tech Lead không đo bằng lượng code anh viết, mà bằng năng lực anh xây được trong đội. Một team mà thiếu lead thì sập là một team thất bại về mặt lãnh đạo, dù lead đó có giỏi đến đâu.
Ví dụ 2: Bikeshedding tại một startup SaaS
Tại một startup SaaS ở Singapore, Tech Lead tên Meera nổi tiếng review code cực kỹ. Nghe thì tốt. Nhưng dữ liệu từ công cụ đo cho thấy 70% comment của cô trong review là về những thứ như: dấu cách, thứ tự import, đặt tên biến userData hay userInfo. Trong khi đó, một PR triển khai cơ chế caching sai — có nguy cơ trả về dữ liệu của người dùng này cho người dùng khác — được cô approve trong 3 phút vì "code trông sạch".
Ba tuần sau, sự cố rò rỉ dữ liệu giữa các tài khoản xảy ra đúng ở chỗ caching đó. Điều tra ra, ai cũng ngạc nhiên vì "Meera review kỹ lắm mà". Sự thật là cô dồn hết năng lượng nhận thức vào những chi tiết dễ có ý kiến, và không còn sức để suy nghĩ về những rủi ro khó.
Bài học: Perfectionist + Bikeshedder. Sự kỹ tính đặt sai chỗ còn nguy hiểm hơn cả sự cẩu thả, vì nó tạo ảo giác an toàn. Tech Lead phải phân bổ sự chú ý theo mức độ rủi ro: những gì đúng/sai về mặt phong cách hãy giao cho linter và formatter tự động (bài 14), còn não người dành cho kiến trúc, bảo mật, và tính đúng đắn.
Ví dụ 3: Người gật đầu và cái giá của burnout
An là Tech Lead tại một công ty gia công phần mềm (outsourcing) ở Đà Nẵng, team 8 người làm dự án cho khách hàng châu Âu. Mỗi lần khách hàng ép deadline, An đều gật đầu: "Được, team em làm được." Anh không bao giờ đẩy lùi, không bao giờ giải thích trade-off, vì sợ mất lòng khách và sợ mang tiếng team yếu.
Trong 6 tháng, team làm việc trung bình 55–65 giờ/tuần. Chất lượng đi xuống, số bug tăng gấp đôi, và hai kỹ sư senior — những người khó tuyển nhất — lần lượt nộp đơn nghỉ vì kiệt sức. Chi phí thay thế hai người này (tuyển, onboard, mất tiến độ) ước tính hơn 600 triệu đồng, chưa kể uy tín team với khách hàng sụt giảm vì chất lượng tệ. Nghịch lý: chính việc An "luôn nói được" để làm hài lòng khách đã dẫn tới kết quả tệ nhất cho khách.
Bài học: Yes-Man + Ostrich. Vai trò của Tech Lead không phải là làm hài lòng cấp trên bằng mọi giá, mà là bảo vệ tính bền vững của việc giao hàng. Một cái "không, nhưng đây là phương án" đúng lúc có giá trị hơn mười cái "được" dẫn tới sụp đổ.
Hướng dẫn từng bước
Đây là quy trình thực tế để bạn chuyển từ anti-pattern sang pattern lành mạnh.
Bước 1 — Tự chẩn đoán bằng dữ liệu, không bằng cảm giác. Cảm giác luôn nói bạn đang làm tốt. Hãy nhìn số liệu: Bạn chiếm bao nhiêu % commit của team? Bao nhiêu quyết định trong tháng qua bắt buộc phải qua bạn? Nếu bạn biến mất 2 tuần, việc gì sẽ đứng? Danh sách "việc chỉ mình tôi làm được" chính là bản đồ các anti-pattern của bạn.
Bước 2 — Với The Hero: ép mình delegate theo công thức. Nguyên tắc là: "Việc gì người khác làm được 80% tốt như tôi thì tôi phải giao đi." Chọn một task quan trọng mà bình thường bạn sẽ tự làm, giao cho một thành viên, và cam kết bằng miệng: "Tôi sẽ không tự viết phần này. Tôi sẽ pair và review, nhưng tay bạn gõ." Chịu đựng cảm giác khó chịu khi họ làm chậm hơn — đó là chi phí đầu tư, không phải lãng phí.
Bước 3 — Với The Bottleneck: đẩy quyền quyết định xuống. Với mỗi loại quyết định, hỏi: "Cái này có cần mình quyết không, hay chỉ cần một hướng dẫn để người khác tự quyết?" Thiết lập các nguyên tắc rõ ràng (guardrails) để team tự chủ trong phạm vi an toàn, thay vì hỏi bạn từng lần.
Bước 4 — Với Perfectionist: tách tiêu chuẩn thành hai loại. Loại 1 là những thứ máy làm được — style, format, import order — hãy tự động hóa hoàn toàn bằng linter/formatter và đừng bao giờ comment tay về chúng nữa. Loại 2 là những thứ cần tư duy — kiến trúc, bảo mật, đúng đắn — dồn toàn bộ sự chú ý vào đó.
Bước 5 — Với Yes-Man/Ostrich: luyện câu nói bảo vệ team. Chuẩn bị sẵn mẫu câu: "Chúng ta có thể làm X vào deadline đó, nhưng phải hy sinh Y hoặc Z. Anh/chị muốn chọn cái nào?" Biến việc từ chối thành việc trình bày trade-off. Với người underperform, đặt lịch nói chuyện trong tuần này, đừng để sang tháng.
Bước 6 — Tạo vòng phản hồi định kỳ. Mỗi quý, hỏi thẳng team (ẩn danh nếu cần): "Có điều gì mình đang làm khiến các bạn khó tự chủ hoặc khó phát triển không?" Anti-pattern sống được là nhờ điểm mù; ánh sáng phản hồi làm chúng co lại.
Lỗi thường gặp & mẹo
- Lỗi: Nghĩ rằng "tôi giỏi kỹ thuật nên tôi không thể là anti-pattern". Ngược lại — càng giỏi kỹ thuật càng dễ thành Hero và Architect Astronaut, vì tự làm luôn hấp dẫn hơn dạy người khác. Mẹo: đo giá trị bằng sự trưởng thành của team, không bằng output cá nhân.
- Lỗi: Cố sửa tất cả anti-pattern cùng lúc. Bạn sẽ quá tải và bỏ cuộc. Mẹo: chọn một anti-pattern nổi cộm nhất, tập trung một quý, rồi mới sang cái tiếp theo.
- Lỗi: Nhầm delegate với "vứt việc rồi bỏ mặc" (dumping). Delegate mà không hỗ trợ sẽ biến bạn thành Absentee. Mẹo: delegate đi kèm bối cảnh, guardrails, và sẵn sàng unblock — nhưng không cầm tay chỉ việc.
- Lỗi: Delegate xong lại nhảy vào sửa vì "chưa đủ tốt". Đây là "false delegation", còn tệ hơn không giao, vì nó dạy team rằng nỗ lực của họ vô nghĩa. Mẹo: chấp nhận kết quả 80%, chỉ can thiệp khi thực sự có rủi ro nghiêm trọng.
- Mẹo tổng quát: Đặt cho mình câu hỏi kiểm tra hàng tuần: "Tuần này tôi đã làm gì để tuần sau team cần tôi ít hơn?" Một Tech Lead giỏi làm cho mình ngày càng ít thiết yếu ở tầng thực thi, để có thể vươn lên tầng ảnh hưởng lớn hơn.
Bài tập thực hành
- Bản đồ bus factor. Liệt kê ra 5 phần quan trọng nhất của hệ thống/quy trình mà team bạn phụ trách. Với mỗi phần, ghi tên những người thật sự hiểu và có thể tự xử lý khi có sự cố. Phần nào chỉ có mình bạn — đó là nợ rủi ro. Lập kế hoạch chuyển giao (pair, tài liệu, giao task) trong 90 ngày tới cho ít nhất một phần.
- Kiểm toán review của chính bạn. Xem lại 10 comment review gần nhất bạn để lại. Phân loại: bao nhiêu % về style/format (loại máy làm được), bao nhiêu % về kiến trúc/bảo mật/đúng đắn? Nếu loại thứ nhất chiếm trên 40%, hãy cấu hình linter/formatter để tự động hóa chúng và cam kết không comment tay nữa.
- Tập nói "không, nhưng...". Nhớ lại lần gần nhất bạn nhận một yêu cầu/deadline phi thực tế. Viết ra câu trả lời "Yes-Man" bạn đã dùng, rồi viết lại thành câu trình bày trade-off. Chuẩn bị sẵn để dùng cho lần tới.
- Tự soi anti-pattern. Đọc lại 7 anti-pattern ở phần khái niệm, tự chấm điểm mình từ 1–5 cho mỗi cái (5 = dính nặng). Chọn cái điểm cao nhất, viết một hành động cụ thể sẽ làm ngay trong tuần này để giảm nó.
Tóm tắt
Anti-pattern của Tech Lead không phải dấu hiệu của người kém — chúng là cái bẫy tự nhiên mà chính những người giỏi kỹ thuật hay rơi vào, vì họ dùng bản năng của một IC xuất sắc để giải bài toán lãnh đạo. Những khuôn mẫu phổ biến nhất gồm: The Hero (ôm hết, bus factor 1), The Bottleneck (mọi quyết định phải qua mình), The Absentee (bỏ mặc team), The Perfectionist/Bikeshedder (cầu toàn sai chỗ), The Architect Astronaut (over-engineer), The Yes-Man (không dám từ chối), và The Ostrich (né tránh chuyện khó).
Điểm chung là chúng đều tối ưu cục bộ nhưng thua ở tổng thể, và đều được nuôi dưỡng bởi điểm mù. Cách thoát ra là: tự chẩn đoán bằng dữ liệu chứ không bằng cảm giác, ép mình delegate thật, đẩy quyết định xuống, tự động hóa những tiêu chuẩn máy làm được, luyện nói trade-off thay vì gật đầu, và tạo vòng phản hồi định kỳ. Hãy nhớ thước đo cốt lõi: giá trị của bạn không nằm ở lượng code bạn viết hôm nay, mà ở việc mỗi tuần trôi qua, team của bạn lại vững vàng hơn và cần bạn ở tầng thực thi ít hơn một chút. Đó chính là dấu hiệu bạn đang lãnh đạo đúng.