Mở đầu — vì sao bài này quan trọng
Nếu bạn từng đọc tin tuyển dụng của các công ty công nghệ Việt Nam, chắc hẳn bạn đã gặp cảnh này: một vị trí ghi là "Tech Lead", nhưng đọc phần mô tả công việc thì thấy toàn nhiệm vụ của một Engineering Manager — quản lý nhân sự, phỏng vấn, đánh giá hiệu suất, làm việc với phòng nhân sự về lương thưởng. Ngược lại, có công ty đăng tuyển "Engineering Manager" nhưng thực chất chỉ cần một người code giỏi nhất nhóm để review pull request và đưa ra quyết định kiến trúc.
Sự nhập nhằng này không phải chuyện nhỏ. Khi hai vai trò bị trộn vào làm một, hậu quả rất cụ thể: người giữ vị trí bị quá tải vì phải gánh cả hai loại công việc vốn dĩ đòi hỏi hai bộ kỹ năng khác nhau; các kỹ sư trong nhóm không biết nên tìm ai khi cần hỗ trợ kỹ thuật, và nên tìm ai khi cần nói về lộ trình sự nghiệp; và bản thân công ty không có một khung rõ ràng để đánh giá, phát triển và trả lương cho từng loại nhân sự lãnh đạo.
Bài học này giúp bạn phân biệt rạch ròi hai vai trò: Tech Lead (TL) và Engineering Manager (EM). Đây là bài nền tảng cho toàn bộ hành trình lãnh đạo kỹ thuật của bạn. Bạn cần hiểu rõ ranh giới trước khi có thể quyết định mình muốn đi con đường nào, hay công ty nên thiết kế tổ chức ra sao. Chúng ta sẽ không bàn sâu về việc "IC có nên chuyển sang Manager không" (đó là chủ đề của bài sau), mà tập trung vào việc phân định: hai vai trò này khác nhau ở đâu, trách nhiệm ai lo phần nào, và làm sao để hai người ở hai vai trò cộng tác thay vì giẫm chân nhau.
Khái niệm cốt lõi
Hai trục trách nhiệm khác nhau
Cách đơn giản nhất để hình dung là tưởng tượng có hai trục trách nhiệm trong một nhóm kỹ thuật.
Trục thứ nhất là "cái gì cần được xây và xây như thế nào" — đây là trục kỹ thuật. Nó bao gồm: quyết định kiến trúc hệ thống, chọn công nghệ, chia nhỏ công việc thành các tác vụ khả thi, đảm bảo chất lượng code, giải quyết các vấn đề kỹ thuật khó, và giữ cho nợ kỹ thuật (tech debt) ở mức kiểm soát được. Đây là địa phận của Tech Lead.
Trục thứ hai là "ai làm và con người đó phát triển ra sao" — đây là trục con người và tổ chức. Nó bao gồm: tuyển dụng, đánh giá hiệu suất, phát triển sự nghiệp cho từng thành viên, xử lý xung đột giữa người với người, quyết định lương thưởng, và chịu trách nhiệm về sức khỏe tinh thần cũng như sự gắn kết của nhóm. Đây là địa phận của Engineering Manager.
Một câu nói kinh điển trong ngành tóm gọn khác biệt này: Tech Lead chịu trách nhiệm về "the work" (công việc), Engineering Manager chịu trách nhiệm về "the people" (con người).
Tech Lead là gì
Tech Lead thường vẫn là một Individual Contributor (IC) — nghĩa là họ vẫn viết code, vẫn đóng góp trực tiếp vào sản phẩm — nhưng đồng thời gánh thêm trách nhiệm dẫn dắt về mặt kỹ thuật cho một nhóm hoặc một dự án.
Trách nhiệm điển hình của TL:
- Định hướng kỹ thuật: quyết định kiến trúc, thiết kế hệ thống, chọn framework và công cụ.
- Chất lượng kỹ thuật: thiết lập chuẩn code, dẫn dắt code review, đảm bảo hệ thống không bị mục nát theo thời gian.
- Phân rã công việc: biến một yêu cầu sản phẩm mơ hồ thành các task kỹ thuật rõ ràng để cả nhóm thực thi.
- Gỡ rối kỹ thuật: là người mà cả nhóm tìm đến khi gặp bug khó hoặc bài toán thiết kế phức tạp.
- Đại diện kỹ thuật: làm cầu nối giữa nhóm và các bên khác (Product Manager, các nhóm kỹ thuật khác) về khía cạnh kỹ thuật.
Engineering Manager là gì
Engineering Manager là người quản lý trực tiếp (line manager) của các kỹ sư. Họ chịu trách nhiệm về con người và về việc nhóm vận hành trơn tru như một đơn vị tổ chức.
Trách nhiệm điển hình của EM:
- Quản lý con người: 1:1 định kỳ, coaching, phát triển sự nghiệp cho từng thành viên.
- Đánh giá hiệu suất: viết review, quyết định (hoặc đề xuất) tăng lương, thăng chức, và trong trường hợp xấu là PIP hoặc cho nghỉ việc.
- Tuyển dụng và giữ chân: xây pipeline tuyển dụng, quyết định offer, và tìm cách giữ chân người giỏi.
- Sức khỏe nhóm: theo dõi tinh thần, ngăn burnout, xử lý xung đột con người.
- Kết nối với tổ chức: làm việc với cấp trên, HR, các phòng ban để đảm bảo nhóm có nguồn lực và định hướng.
Vùng chồng lấn và điểm dễ nhầm
Sự nhầm lẫn xảy ra ở những vùng chồng lấn. Cả TL và EM đều quan tâm đến việc dự án về đích đúng hạn, đều tham gia lập kế hoạch, đều cần kỹ năng giao tiếp tốt. Nhưng góc nhìn khác nhau: khi một tính năng bị trễ, TL hỏi "vấn đề kỹ thuật ở đâu, thiết kế có sai không, ta có đang mắc nợ kỹ thuật nào không?", còn EM hỏi "ai đang bị quá tải, có ai cần thêm hỗ trợ, có xung đột gì trong nhóm đang cản trở không?".
Một điểm mấu chốt về thẩm quyền (authority): EM có thẩm quyền chính thức từ tổ chức, TL có thẩm quyền phi chính thức từ chuyên môn. Đây là lý do vì sao một TL giỏi phải học kỹ năng "influence without authority" (ảnh hưởng mà không cần quyền lực) — một chủ đề chúng ta sẽ đào sâu ở bài sau.
Tình huống thực tế
Tình huống 1: Công ty fintech "giáng chức trá hình" bằng cách gộp vai
Một công ty fintech tại TP.HCM có khoảng 40 kỹ sư, tăng trưởng nhanh sau vòng gọi vốn Series A. Họ có một kỹ sư tên Minh — backend rất mạnh, được cả nhóm nể phục. Ban lãnh đạo quyết định phong Minh làm "Tech Lead kiêm Team Lead" cho nhóm 8 người, với kỳ vọng anh vừa dẫn dắt kỹ thuật vừa quản lý nhân sự.
Sáu tháng sau, mọi thứ bắt đầu rạn nứt. Minh phải chạy 6 buổi 1:1 mỗi tuần, viết đánh giá hiệu suất, ngồi họp với HR về việc một thành viên xin nghỉ, đồng thời vẫn phải review toàn bộ pull request quan trọng và thiết kế kiến trúc cho dịch vụ thanh toán mới. Kết quả: thời gian dành cho kỹ thuật của anh giảm còn khoảng 30%, các quyết định kiến trúc bị trì hoãn, và bản thân anh kiệt sức. Tệ hơn, hai kỹ sư giỏi trong nhóm rời đi vì cảm thấy "không được coaching đàng hoàng" — Minh đơn giản là không còn thời gian.
Bài học rút ra: Gộp TL và EM vào một người ở nhóm 8 người không phải là tiết kiệm nhân sự — đó là đặt hai công việc toàn thời gian lên vai một người. Với nhóm nhỏ (3-4 người), một người kiêm cả hai có thể tạm ổn. Nhưng khi nhóm vượt quá 5-6 người, cả hai trục trách nhiệm đều phình to đến mức cần tách ra. Sau này công ty tách vai: Minh trở lại làm Tech Lead thuần túy, và họ tuyển một EM riêng lo phần con người. Năng suất và sự gắn kết của nhóm phục hồi trong vòng một quý.
Tình huống 2: Startup thương mại điện tử tách vai đúng cách
Một startup thương mại điện tử ở Singapore phục vụ thị trường Đông Nam Á, quy mô khoảng 25 kỹ sư, ngay từ đầu đã thiết kế mô hình rõ ràng. Mỗi "squad" (nhóm liên chức năng) có một Tech Lead lo kỹ thuật và chia sẻ một Engineering Manager quản lý 2-3 squad về mặt con người.
Ví dụ cụ thể: squad "Checkout" có anh Tuấn làm TL — anh quyết định họ sẽ tách dịch vụ thanh toán ra microservice, chọn ngôn ngữ Go, và thiết lập chuẩn testing. Trong khi đó, chị Lan là EM phụ trách cả squad Checkout, squad Search và squad Recommendation — chị lo 1:1, phát triển sự nghiệp, và làm việc với từng TL để hiểu ai đang tỏa sáng, ai đang gặp khó.
Điểm hay ở mô hình này: khi một kỹ sư trong squad Checkout muốn bàn về việc thăng chức, họ tìm chị Lan. Khi họ bí một bài toán kiến trúc, họ tìm anh Tuấn. Ranh giới rõ ràng khiến không ai bị quá tải, và mỗi vai trò được đánh giá theo đúng tiêu chí của nó.
Bài học rút ra: Một EM có thể quản lý con người cho nhiều squad, trong khi mỗi squad cần một TL riêng vì độ sâu kỹ thuật không thể chia sẻ theo chiều rộng như vậy. Tỷ lệ điển hình ở nhiều công ty là một EM quản 5-8 người (đôi khi trải trên nhiều squad), còn TL thì gắn chặt với một nhóm/dự án cụ thể.
Tình huống 3: Khi TL và EM bất đồng và cách họ giải quyết
Tại một công ty SaaS ở Hà Nội, TL tên Đức muốn dành trọn hai tuần sprint để refactor một module cũ đầy nợ kỹ thuật, vì anh cho rằng nếu không làm ngay, tốc độ phát triển sẽ chậm dần. Nhưng EM tên Hương lại thấy rằng thành viên trong nhóm đang căng thẳng vì áp lực từ đợt ra mắt sản phẩm sắp tới, và việc thêm hai tuần refactor "vô hình với khách hàng" có thể khiến tinh thần đi xuống.
Đây là ví dụ điển hình của việc hai trục trách nhiệm va nhau: Đức nhìn từ góc "công việc kỹ thuật", Hương nhìn từ góc "con người". Cách họ xử lý: thay vì tranh cãi ai đúng, họ ngồi lại và tách bạch quyết định. Về mặt kỹ thuật, refactor là cần thiết — đó là chuyên môn của Đức và Hương tôn trọng nó. Về mặt con người, thời điểm và cách thực hiện cần điều chỉnh — đó là chuyên môn của Hương. Cuối cùng họ chốt: chia refactor thành các phần nhỏ, làm xen kẽ trong ba sprint thay vì dồn một lần, để vừa giảm nợ kỹ thuật vừa không dồn áp lực.
Bài học rút ra: TL và EM không phải cấp trên của nhau — họ là hai đối tác (partners) với hai lĩnh vực chuyên môn riêng. Khi có bất đồng, giải pháp không phải là "ai to hơn thắng", mà là mỗi người ra quyết định trong phần chuyên môn của mình và cùng dung hòa ở vùng giao thoa. Mối quan hệ TL-EM khỏe mạnh là nền tảng của một nhóm kỹ thuật vận hành tốt.
Hướng dẫn từng bước
Dù bạn đang là người sắp nhận vai trò, hay là người thiết kế tổ chức, đây là các bước để phân định rạch ròi.
Bước 1 — Vẽ ra hai danh sách trách nhiệm. Lấy một tờ giấy, kẻ hai cột: "The Work" (kỹ thuật) và "The People" (con người). Liệt kê mọi trách nhiệm hiện có của nhóm vào một trong hai cột. Những mục nào rơi vào cột kỹ thuật thuộc về TL; cột con người thuộc về EM. Chỉ riêng bài tập này đã giúp lộ ra chỗ nào đang bị gộp nhầm.
Bước 2 — Xác định "quyền quyết định" cho từng loại việc. Với mỗi trách nhiệm, ghi rõ ai là người ra quyết định cuối cùng. Quyết định kiến trúc, chuẩn code, review: TL. Tăng lương, thăng chức, đánh giá, tuyển/sa thải: EM. Viết rõ ra tránh tình trạng đùn đẩy hoặc giẫm chân.
Bước 3 — Kiểm tra tải công việc theo quy mô nhóm. Nhóm dưới 4 người có thể tạm để một người kiêm hai vai. Từ 5-6 người trở lên, hãy nghiêm túc cân nhắc tách vai. Nếu chưa đủ nguồn lực để có hai người, ít nhất hãy giảm bớt kỳ vọng ở một trong hai trục.
Bước 4 — Thiết lập nhịp cộng tác giữa TL và EM. Nếu đã tách vai, hai người này nên có một buổi sync định kỳ (ví dụ 30 phút mỗi tuần) để đồng bộ về tình hình nhóm: TL chia sẻ về tiến độ và rủi ro kỹ thuật, EM chia sẻ về tình trạng con người. Mỗi bên nắm được góc nhìn của bên kia sẽ ra quyết định tốt hơn.
Bước 5 — Truyền thông rõ ràng cho cả nhóm. Nói thẳng với các thành viên: "Về vấn đề kỹ thuật, tìm anh A. Về vấn đề sự nghiệp, lương thưởng, cá nhân, tìm chị B." Sự rõ ràng này loại bỏ bối rối và giúp mọi người tìm đúng người khi cần.
Lỗi thường gặp & mẹo
Lỗi 1 — Nghĩ rằng "code giỏi nhất thì làm quản lý". Đây là lỗi phổ biến nhất ở các công ty Việt Nam. Kỹ năng kỹ thuật xuất sắc không tự động chuyển thành kỹ năng quản lý con người. Khi bạn cất người code giỏi nhất đi làm EM, bạn vừa mất một IC xuất sắc, vừa có thể có một EM tồi. Mẹo: hãy tách con đường TL (kỹ thuật) và EM (quản lý) thành hai lộ trình song song, để người giỏi kỹ thuật có thể thăng tiến mà không buộc phải quản lý người.
Lỗi 2 — Gộp hai vai vì "tiết kiệm headcount". Nghe thì hợp lý về ngân sách, nhưng thực tế bạn đang đốt cháy một người và làm hỏng cả hai trục. Mẹo: nếu bắt buộc phải gộp, hãy giảm quy mô nhóm hoặc giảm rõ ràng phạm vi một trong hai trục, đừng kỳ vọng 200%.
Lỗi 3 — Để TL "chơi trò quản lý ngầm". Một số TL, vì được nể phục, bắt đầu tự cho mình quyền đánh giá đồng nghiệp hoặc gây ảnh hưởng lên lương thưởng dù không có thẩm quyền. Điều này gây rối loạn. Mẹo: TL nên đưa ý kiến kỹ thuật về đồng nghiệp cho EM như một dữ liệu đầu vào, nhưng quyết định cuối cùng về con người thuộc về EM.
Lỗi 4 — EM buông hoàn toàn khía cạnh kỹ thuật. EM không cần code giỏi nhất, nhưng nếu mất hết cảm nhận kỹ thuật, họ sẽ không đánh giá được nhân sự và dễ bị "qua mặt". Mẹo: EM nên duy trì đủ hiểu biết kỹ thuật để hỏi câu hỏi sắc bén, dù không trực tiếp ra quyết định kiến trúc.
Mẹo tổng quát: Khi phân vân "việc này của ai", hãy tự hỏi: "Đây là câu hỏi về công việc, hay về con người?". Câu trả lời gần như luôn chỉ đúng người.
Bài tập thực hành
- Phân loại trách nhiệm: Lấy nhóm hiện tại của bạn (hoặc một nhóm bạn từng làm việc), liệt kê 15 trách nhiệm cụ thể đang tồn tại, và phân mỗi cái vào cột "The Work" (TL) hay "The People" (EM). Đánh dấu những cái đang bị một người gánh cả hai.
- Phỏng vấn tình huống: Viết ra 3 câu hỏi mà một kỹ sư trong nhóm có thể mang đến, và xác định họ nên tìm TL hay EM. Ví dụ: "Em không đồng ý với thiết kế database của anh X" (→ TL); "Em cảm thấy không được ghi nhận và đang muốn tìm việc khác" (→ EM); "Em muốn biết cần làm gì để lên Senior" (→ EM về lộ trình, TL về kỹ thuật cần đạt).
- Tự đánh giá xu hướng: Viết một đoạn ngắn (150-200 từ) trả lời: giữa "the work" và "the people", bạn thấy mình được tiếp thêm năng lượng khi làm loại nào hơn? Đây là bước chuẩn bị tư duy cho bài kế tiếp về việc chọn con đường IC hay Manager.
- Thiết kế nhịp cộng tác: Giả sử bạn là EM và có một TL đối tác. Hãy phác thảo agenda cho buổi sync 30 phút hằng tuần giữa hai người, gồm những mục gì và mỗi người mang thông tin gì đến.
Tóm tắt
Tech Lead và Engineering Manager là hai vai trò khác nhau, không phải hai tên gọi của cùng một công việc. TL chịu trách nhiệm về "the work" — kiến trúc, chất lượng kỹ thuật, phân rã và gỡ rối công việc — và ảnh hưởng bằng chuyên môn chứ không bằng quyền lực. EM chịu trách nhiệm về "the people" — tuyển dụng, đánh giá, phát triển sự nghiệp, sức khỏe nhóm — và có thẩm quyền chính thức từ tổ chức.
Với nhóm nhỏ, một người có thể tạm kiêm cả hai; nhưng khi nhóm vượt 5-6 người, việc tách vai gần như là bắt buộc để không đốt cháy con người và làm hỏng cả hai trục. Ba tình huống thực tế cho thấy: gộp vai bừa bãi dẫn đến kiệt sức và mất người; tách vai đúng cách giúp mỗi trục được lo trọn vẹn; và khi TL với EM bất đồng, giải pháp là tôn trọng chuyên môn của nhau chứ không phải tranh giành quyền lực.
Điều quan trọng nhất cần mang theo: khi phân vân "việc này của ai", hãy hỏi "đây là câu hỏi về công việc, hay về con người?". Nắm chắc ranh giới này là bước nền để bạn — và tổ chức của bạn — xây dựng một cơ cấu lãnh đạo kỹ thuật lành mạnh.