Mở đầu — vì sao bài này quan trọng
Nếu bạn là một kỹ sư giỏi, viết code sạch, giải quyết bug nhanh, và một ngày sếp gọi bạn vào phòng họp nói: "Từ tuần sau, em làm Tech Lead cho team nhé" — thì đây là bài học dành cho bạn. Bởi vì phần lớn người mới nhận vai trò Tech Lead đều mắc chung một hiểu lầm chết người: họ nghĩ Tech Lead chỉ đơn giản là "kỹ sư giỏi nhất được thăng chức". Sự thật không phải vậy, và hiểu lầm này khiến rất nhiều người kiệt sức, làm việc gấp đôi mà team lại chạy chậm hơn trước.
Tech Lead là một vai trò hoàn toàn khác về bản chất so với vai trò Individual Contributor (IC — kỹ sư đóng góp cá nhân) mà bạn đã quen. Trước đây, giá trị của bạn được đo bằng lượng code bạn viết ra. Từ giờ, giá trị của bạn được đo bằng năng lực và kết quả của cả team — kể cả những phần bạn không trực tiếp chạm tay vào. Đây là một cú chuyển dịch tư duy (mindset shift) lớn, và nếu không nhận thức rõ, bạn sẽ vô tình bóp nghẹt team thay vì nâng nó lên.
Trong thị trường công nghệ Việt Nam đang phát triển nhanh, nhiều công ty startup và scale-up thăng cấp Tech Lead chỉ sau 3-4 năm kinh nghiệm, thường mà không có bất kỳ khóa đào tạo nào. Bài học này sẽ cho bạn bản đồ rõ ràng: Tech Lead thực sự làm gì, chịu trách nhiệm gì, khác gì với Engineering Manager, và làm sao để bắt đầu đúng hướng ngay từ những tuần đầu tiên.
Khái niệm cốt lõi
Tech Lead là ai?
Tech Lead (thường viết tắt TL) là người chịu trách nhiệm về chất lượng và hướng đi kỹ thuật của một team hoặc một sản phẩm. Họ vẫn là kỹ sư — vẫn viết code, vẫn review, vẫn thiết kế hệ thống — nhưng đồng thời gánh thêm trách nhiệm đảm bảo cả team đưa ra quyết định kỹ thuật đúng đắn, giao hàng đúng hạn, và không tự đâm vào những cái bẫy kỹ thuật đắt giá.
Điểm mấu chốt cần nhớ: Tech Lead lãnh đạo thông qua ảnh hưởng, không phải thông qua quyền lực chính thức. Trong hầu hết công ty, Tech Lead không phải là sếp trực tiếp của các thành viên team. Bạn không quyết định lương của họ, không đánh giá hiệu suất chính thức, không có quyền tuyển hay sa thải. Vậy làm sao để dẫn dắt? Bằng chuyên môn được tôn trọng, bằng khả năng giải thích "tại sao", và bằng việc tạo điều kiện để người khác làm tốt hơn.
Tech Lead vs Engineering Manager
Đây là điểm gây nhầm lẫn nhiều nhất, nên hãy làm rõ ngay. Bài học sau trong khóa (Bài 4) sẽ đi sâu hơn về so sánh hai vai trò này, nhưng ở đây bạn cần nắm khác biệt nền tảng:
| Khía cạnh | Tech Lead | Engineering Manager (EM) |
|---|---|---|
| Trọng tâm chính | Quyết định kỹ thuật, kiến trúc, chất lượng | Con người: tuyển dụng, phát triển, đánh giá |
| Đo lường thành công | Hệ thống chạy tốt, team giao hàng đúng | Nhân sự phát triển, giữ chân, team khỏe mạnh |
| Vẫn viết code? | Có, thường 30-60% thời gian | Ít hoặc gần như không |
| Quyền chính thức | Ít hoặc không có quyền quản lý nhân sự | Có quyền: lương, thăng tiến, sa thải |
| Câu hỏi hằng ngày | "Nên xây thế này hay thế kia?" | "Người này đang phát triển ổn không?" |
Bốn trách nhiệm cốt lõi của Tech Lead
1. Định hướng kỹ thuật (Technical Direction). TL đảm bảo team đang đi đúng hướng về mặt kiến trúc và công nghệ. Không phải tự mình quyết mọi thứ, mà là dẫn dắt quá trình ra quyết định, đảm bảo các lựa chọn được cân nhắc kỹ, được ghi lại, và phù hợp mục tiêu dài hạn.
2. Đảm bảo chất lượng và tiến độ giao hàng (Delivery). TL là người kết nối giữa "kỹ thuật" và "kinh doanh". Họ chia nhỏ công việc, ước lượng, phát hiện rủi ro sớm, và đảm bảo team không sa lầy. Khi có sự đánh đổi giữa tốc độ và chất lượng, TL là người đưa ra hoặc điều phối quyết định đó.
3. Nâng cấp năng lực đội ngũ (Growing the team). Một TL giỏi biến những kỹ sư trung bình thành giỏi. Qua code review có tính dạy học, qua pairing, qua việc giao đúng thử thách vừa sức. Đây là điểm khác biệt lớn giữa một "kỹ sư giỏi được thăng chức" và một "Tech Lead thực thụ".
4. Cầu nối giao tiếp (Communication bridge). TL dịch ngôn ngữ kỹ thuật sang ngôn ngữ kinh doanh cho Product Manager, và ngược lại. Họ bảo vệ team khỏi những gián đoạn không cần thiết, đồng thời đảm bảo team hiểu rõ "tại sao" mình đang xây thứ này.
Cú chuyển dịch tư duy: từ "tôi" sang "chúng ta"
Là IC, thành công của bạn = code bạn viết. Là TL, thành công của bạn = kết quả của team. Điều này nghe đơn giản nhưng cực khó thực hành. Vì bản năng của một kỹ sư giỏi là "để đó tôi làm cho nhanh". Nhưng nếu bạn luôn tự làm phần khó, các thành viên khác sẽ không bao giờ trưởng thành, và bạn trở thành nút thắt cổ chai (bottleneck) của cả team. Một TL trưởng thành học cách chấp nhận rằng team làm chậm hơn và "chưa hoàn hảo" ở hiện tại, để đổi lấy một team mạnh hơn trong tương lai.
Tình huống thực tế
Tình huống 1: Người bottleneck ở một startup fintech tại TP.HCM
Minh là kỹ sư backend xuất sắc tại một startup fintech gọi vốn Series A, team khoảng 12 người. Anh được thăng làm Tech Lead vì viết code nhanh nhất và hiểu hệ thống thanh toán sâu nhất. Ba tháng đầu, Minh vẫn giữ thói quen cũ: mọi task khó anh đều tự nhận, mọi Pull Request anh đều tự review và thường tự sửa luôn thay vì góp ý.
Kết quả sau ba tháng: velocity của team (số điểm story hoàn thành mỗi sprint) không tăng, thậm chí giảm 15%. Vì sao? Vì mọi thứ đều tắc ở Minh. PR chờ anh review trung bình 2 ngày. Các kỹ sư junior không dám đưa quyết định vì "để anh Minh quyết". Bản thân Minh làm việc 60 giờ/tuần và bắt đầu có dấu hiệu kiệt sức.
Diễn giải: Minh vẫn đang hành xử như một IC, chỉ khác là giờ có thêm chức danh. Anh tối ưu cho sản lượng cá nhân thay vì năng lực đội ngũ.
Bài học: Vai trò của TL là mở rộng năng lực team, không phải tập trung năng lực vào mình. Khi Minh học cách giao việc khó cho người khác (kèm hỗ trợ), review theo hướng đặt câu hỏi thay vì sửa hộ, chỉ trong hai sprint sau velocity tăng 25% và anh giảm giờ làm xuống còn 45 giờ/tuần.
Tình huống 2: Quyết định kiến trúc gây chia rẽ tại một scale-up thương mại điện tử
Tại một công ty thương mại điện tử ở Hà Nội (tạm gọi ShopFast), team đang tranh cãi gay gắt: nên tách hệ thống monolith hiện tại thành microservices ngay, hay giữ nguyên và tối ưu dần? Hai kỹ sư senior đứng ở hai phe, tranh luận suốt hai tuần trong các buổi họp mà không đi đến đâu. Deadline ra mắt tính năng mới đang đến gần.
Lan, Tech Lead của team, không đứng về phe nào ngay. Cô làm ba việc: (1) yêu cầu mỗi bên viết một tài liệu ngắn nêu rõ đánh đổi (trade-off), chi phí, và rủi ro; (2) đưa ra tiêu chí quyết định dựa trên mục tiêu kinh doanh — cụ thể là công ty cần ra mắt tính năng trong 6 tuần và dự kiến tăng gấp 3 lượng đơn trong mùa cao điểm; (3) chốt một quyết định "vừa đủ": tách riêng đúng một module (thanh toán) đang là điểm nghẽn, giữ nguyên phần còn lại.
Diễn giải: Lan không dùng quyền lực để áp đặt, cũng không né tránh để mặc team tranh cãi. Cô dẫn dắt quá trình ra quyết định, gắn nó với mục tiêu kinh doanh, và chịu trách nhiệm về kết quả cuối cùng.
Bài học: Trách nhiệm của TL không phải là luôn có câu trả lời đúng, mà là đảm bảo team đi đến một quyết định tốt và tiến lên. Một quyết định "khá tốt" được đưa ra kịp thời thường giá trị hơn một quyết định "hoàn hảo" đến quá muộn.
Tình huống 3: Google và mô hình Tech Lead tách biệt
Ở Google — một trong những nơi định hình rõ nhất khái niệm Tech Lead hiện đại — vai trò TL và Manager (gọi là EM) thường được tách riêng, và thậm chí có vai trò lai TLM (Tech Lead Manager) cho các team nhỏ. Điểm đáng học ở đây là Google định nghĩa rất rõ: Tech Lead chịu trách nhiệm về "cái gì cần xây và xây thế nào", còn Manager chịu trách nhiệm về "con người xây nó". Một Tech Lead ở Google có thể dẫn dắt định hướng kỹ thuật cho 5-8 kỹ sư mà không hề là sếp của họ.
Diễn giải: Sự phân tách này giúp mỗi vai trò tập trung và làm sâu. TL không bị phân tâm bởi việc quản lý nhân sự, EM không phải giả vờ giỏi kỹ thuật nhất phòng.
Bài học: Nếu công ty bạn đủ lớn, hãy cân nhắc tách hai vai trò. Nếu còn nhỏ và bạn phải kiêm cả hai, hãy ý thức rõ mình đang đội mũ nào trong từng thời điểm, và dành thời gian cho cả hai một cách có chủ đích.
Hướng dẫn từng bước
Nếu bạn vừa nhận vai trò Tech Lead, đây là lộ trình 30 ngày đầu để khởi động đúng:
Bước 1 — Làm rõ kỳ vọng với sếp (tuần 1). Ngồi xuống với Engineering Manager hoặc sếp trực tiếp và hỏi thẳng: "Với vai trò này, anh/chị kỳ vọng em chịu trách nhiệm những gì? Em có quyền quyết định gì và cái gì cần xin ý kiến?" Đừng giả định. Ranh giới trách nhiệm mập mờ là nguồn gốc của phần lớn xung đột về sau.
Bước 2 — Lập bản đồ hệ thống và con người (tuần 1-2). Vẽ sơ đồ kiến trúc hệ thống team đang phụ trách, xác định các điểm nợ kỹ thuật lớn và rủi ro. Song song, trò chuyện 1-1 với từng thành viên để hiểu điểm mạnh, mong muốn phát triển, và những khó khăn hiện tại của họ.
Bước 3 — Thiết lập nhịp làm việc kỹ thuật (tuần 2-3). Đảm bảo các quy trình nền tảng vận hành trơn tru: cách chia task, chuẩn review code, quy trình ra quyết định kiến trúc. Bạn không cần thay đổi tất cả — hãy quan sát trước, chỉ sửa cái đang gãy.
Bước 4 — Bắt đầu delegate (giao việc) có chủ đích (tuần 3-4). Chọn một task mà bình thường bạn sẽ tự làm, và giao cho một thành viên có tiềm năng — kèm hỗ trợ, không bỏ mặc. Đây là bài tập cơ bắp quan trọng nhất của một TL.
Bước 5 — Bảo vệ thời gian tập trung của chính mình. Với vai trò mới, lịch của bạn sẽ đầy họp và gián đoạn. Hãy chủ động chặn (block) 2-3 buổi mỗi tuần cho công việc kỹ thuật sâu, nếu không bạn sẽ mất luôn chuyên môn — thứ khiến bạn được tôn trọng ngay từ đầu.
Lỗi thường gặp & mẹo
Lỗi 1 — Trở thành bottleneck. Như tình huống của Minh, đây là cái bẫy phổ biến nhất. Mẹo: mỗi khi định "để đó tôi làm", hãy tự hỏi "ai trong team có thể làm việc này nếu tôi hỗ trợ họ?".
Lỗi 2 — Áp đặt quyết định kỹ thuật của mình. Dùng câu "tôi là Tech Lead nên nghe tôi" là cách nhanh nhất để mất sự tôn trọng. Mẹo: luôn giải thích "tại sao", mời phản biện, và chỉ dùng quyền quyết định khi tranh luận đã bế tắc.
Lỗi 3 — Bỏ bê việc phát triển con người vì nghĩ "đó là việc của Manager". Ngay cả khi bạn không phải sếp chính thức, việc nâng cấp kỹ năng đồng đội vẫn là trách nhiệm cốt lõi của TL. Mẹo: biến mỗi buổi code review thành một cơ hội dạy học.
Lỗi 4 — Bỏ code hoàn toàn. Một số TL mới lao vào họp hành đến mức mất kết nối với hệ thống thực tế. Khi đó bạn ra quyết định kiến trúc dựa trên hình dung cũ, dễ sai. Mẹo: giữ ít nhất 30% thời gian "chạm tay vào code", ưu tiên những phần rủi ro hoặc mang tính nền móng.
Lỗi 5 — Không giao tiếp đủ với Product/Business. TL im lặng khiến team nhận yêu cầu phi thực tế. Mẹo: chủ động cập nhật rủi ro và đánh đổi kỹ thuật cho PM bằng ngôn ngữ họ hiểu (thời gian, tiền, rủi ro), thay vì thuật ngữ kỹ thuật.
Bài tập thực hành
- Tự đánh giá trách nhiệm. Lấy bốn trách nhiệm cốt lõi (Định hướng kỹ thuật, Delivery, Nâng cấp đội ngũ, Cầu nối giao tiếp). Chấm điểm bản thân từ 1-5 ở mỗi mục dựa trên thực tế tuần vừa qua. Mục nào thấp nhất chính là điểm bạn cần đầu tư ngay.
- Phân tích một bottleneck. Nhìn lại 5 Pull Request gần nhất của team. Có bao nhiêu cái phải chờ bạn mới đi tiếp được? Viết ra một cách cụ thể để loại bỏ sự phụ thuộc đó (ví dụ: đào tạo thêm một reviewer, đặt chuẩn review rõ hơn).
- Viết "hợp đồng vai trò". Trong một trang giấy, viết ra: những quyết định bạn được tự quyết, những quyết định cần đồng thuận team, và những quyết định phải xin ý kiến sếp. Mang tài liệu này đi trao đổi với Manager để thống nhất.
- Bài tập giao việc. Chọn ngay một task tuần này mà bạn định tự làm. Giao nó cho một thành viên khác kèm 15 phút hướng dẫn. Ghi lại kết quả và cảm giác của bạn — đây là bước đầu để phá bỏ bản năng "tự làm cho nhanh".
Tóm tắt
Tech Lead không phải là "kỹ sư giỏi nhất được thăng chức", mà là một vai trò lãnh đạo kỹ thuật với bản chất khác biệt. Điểm cốt lõi cần khắc ghi:
- Tech Lead lãnh đạo bằng ảnh hưởng và chuyên môn, không phải bằng quyền lực chính thức — khác với Engineering Manager vốn tập trung vào con người và có quyền quản lý nhân sự.
- Bốn trách nhiệm cốt lõi: định hướng kỹ thuật, đảm bảo delivery, nâng cấp đội ngũ, và làm cầu nối giao tiếp.
- Cú chuyển dịch tư duy quan trọng nhất là từ "tối ưu sản lượng cá nhân" sang "tối ưu năng lực cả team" — đây là ranh giới phân biệt TL thực thụ với người chỉ có chức danh.
- Cái bẫy nguy hiểm nhất là trở thành bottleneck. Delegate có chủ đích và giữ cân bằng giữa code với lãnh đạo là kỹ năng phải luyện.