Bài 48 — Manager vs Tech Lead vs Architect Roles

Mở đầu — vì sao bài này quan trọng

Khi một đội kỹ thuật còn nhỏ, mọi thứ đơn giản đến mức đáng ngạc nhiên: một người vừa viết code, vừa quyết định kiến trúc, vừa phỏng vấn ứng viên mới, vừa an ủi đồng nghiệp đang nản lòng. Nhưng khi đội tăng lên 20, 50 rồi 100 người, ba loại công việc rất khác nhau bắt đầu tách ra khỏi nhau — và nếu bạn không đặt tên đúng cho chúng, tổ chức sẽ rơi vào một trong hai cái bẫy kinh điển: hoặc một người ôm cả ba việc và kiệt sức, hoặc ba người cùng tranh nhau một việc và giẫm chân nhau.

Ba vai trò đó là Engineering Manager (EM), Tech Lead (TL) và Architect. Nghe qua thì giống nhau — họ đều là "người dẫn dắt kỹ thuật" — nhưng bản chất công việc, thước đo thành công, và loại quyền lực mà mỗi vai trò nắm giữ lại hoàn toàn khác biệt. Rất nhiều xung đột trong các công ty công nghệ Việt Nam mà tôi từng chứng kiến không đến từ việc ai kém năng lực, mà đến từ việc hai người tưởng mình đang làm cùng một việc trong khi thực ra họ nên chịu trách nhiệm hai việc khác nhau.

Bài học này giúp bạn phân biệt rạch ròi ba vai trò, hiểu khi nào nên tách chúng ra, khi nào nên gộp lại, và làm sao để ba người này phối hợp thay vì cạnh tranh. Đây là kiến thức nền tảng cho bất kỳ ai muốn xây dựng cơ cấu lãnh đạo kỹ thuật vững vàng khi tổ chức mở rộng.

Khái niệm cốt lõi

Cách dễ nhớ nhất là hình dung ba vai trò trả lời ba câu hỏi khác nhau:

• Engineering Manager trả lời câu hỏi "Ai?" — ai trong đội, họ có ổn không, họ phát triển ra sao, ai cần được tuyển thêm hay để đi.
• Tech Lead trả lời câu hỏi "Làm thế nào và khi nào?" — đội này build tính năng này bằng cách nào, chia việc ra sao, thứ tự thực thi thế nào để giao đúng hạn.
• Architect trả lời câu hỏi "Bằng cái gì và theo nguyên tắc nào?" — hệ thống nên được cấu trúc thế nào để bền vững qua nhiều năm và nhiều đội.

Engineering Manager — chủ yếu quản lý con người

EM là vai trò lấy con người làm trung tâm. Trách nhiệm chính của họ xoay quanh: các buổi 1-1 định kỳ, đánh giá hiệu suất (performance review), lộ trình phát triển sự nghiệp cho từng thành viên, tuyển dụng, onboarding, và cả những cuộc trò chuyện khó khăn khi ai đó không đạt yêu cầu.

Điểm mấu chốt: EM vẫn nên đóng góp kỹ thuật, nhưng ở mức nhẹ và có kiểm soát. Một EM tốt vẫn đọc code, vẫn review pull request, vẫn hiểu sâu về hệ thống — nhưng họ không nên nằm trên đường tới hạn (critical path) của bất kỳ tính năng nào. Lý do rất thực tế: khi một thành viên trong đội gặp khủng hoảng lúc 3 giờ chiều, EM phải bỏ mọi thứ để lắng nghe. Nếu lúc đó EM đang là người duy nhất viết một module quan trọng phải giao trong hôm nay, cả hai việc đều hỏng. Vì vậy nguyên tắc phổ biến là EM chỉ nên dành khoảng 10-20% thời gian cho code, và chọn những việc có thể gián đoạn được — sửa bug nhỏ, viết công cụ nội bộ, làm tài liệu — chứ không phải tính năng cốt lõi.

Thước đo thành công của EM là sức khỏe và sản lượng của cả đội, không phải sản lượng cá nhân của chính họ. Một EM giỏi được nhận ra qua việc đội của họ ổn định, ít nghỉ việc, thành viên thăng tiến đều, và giao hàng đáng tin cậy.

Tech Lead — người dẫn dắt kỹ thuật hàng ngày

Tech Lead là kỹ sư giỏi nhất về mặt thực thi trong một đội cụ thể, và họ vẫn viết code — thường chiếm 40-70% thời gian. Nhưng khác với một senior engineer thuần túy, TL còn chịu trách nhiệm về cách đội biến yêu cầu sản phẩm thành phần mềm chạy được.

Cụ thể, TL làm những việc như: chia nhỏ một dự án lớn thành các task, phân bổ ai làm gì cho hợp lý với năng lực, thiết lập chuẩn code review, quyết định các lựa chọn kỹ thuật ở tầm đội (dùng thư viện nào, cấu trúc thư mục ra sao, cách viết test), tháo gỡ các nút thắt kỹ thuật, và làm cầu nối giữa đội với Product Manager về khả thi và ước lượng thời gian.

Điểm quan trọng cần nhớ: TL thường không có quyền quản lý con người. Họ không quyết lương, không đánh giá hiệu suất chính thức, không sa thải ai. Quyền lực của TL đến từ chuyên môn và sự tin tưởng, chứ không từ chức danh trên sơ đồ tổ chức. Đây là điểm khiến vai trò TL vừa hấp dẫn vừa dễ gây khó chịu: bạn phải dẫn dắt bằng ảnh hưởng, không phải bằng mệnh lệnh.

Architect — người giữ tính toàn vẹn của hệ thống ở quy mô lớn

Architect nâng tầm nhìn kỹ thuật lên trên phạm vi một đội. Trong khi TL lo cho hệ thống của một đội, Architect lo cho cách nhiều hệ thống của nhiều đội ghép lại với nhau: chuẩn giao tiếp giữa các service, chiến lược dữ liệu chung, chính sách bảo mật, lựa chọn công nghệ nền tảng, và những quyết định "một chiều không thể đảo ngược" có ảnh hưởng nhiều năm.

Architect có nhiều biến thể. Có "hands-on architect" vẫn viết code mẫu (reference implementation) và làm proof-of-concept; có "ivory tower architect" chỉ vẽ sơ đồ và viết tài liệu — biến thể này thường bị ghét vì xa rời thực tế. Một Architect tốt trong môi trường hiện đại thường vẫn giữ tay nghề, tham gia vào các quyết định lớn thông qua quy trình như RFC, và dùng ảnh hưởng để định hướng nhiều đội cùng đi về một hướng thay vì áp đặt.

Ba trục phân biệt cần thuộc lòng

Tình huống thực tế

Tình huống 1 — Startup fintech ở TP.HCM: một người ôm cả ba mũ

Một công ty fintech tại Quận 1 có đội kỹ thuật 12 người. Anh Minh là co-founder kiêm CTO, và trên thực tế anh đang đảm nhiệm cả ba vai trò cùng lúc: anh 1-1 với từng người (EM), anh chia task và review toàn bộ PR quan trọng (TL), và anh quyết định toàn bộ kiến trúc microservice (Architect).

Khi đội còn 6 người, điều này ổn. Nhưng khi lên 12 người và bắt đầu có hai luồng sản phẩm song song, mọi thứ vỡ. Các PR nằm chờ review ba, bốn ngày vì Minh quá bận. Hai kỹ sư mới nghỉ việc vì "không ai để ý đến tôi cả" — các buổi 1-1 liên tục bị hủy. Và một quyết định kiến trúc sai về hàng đợi thanh toán không được ai thách thức vì Minh vừa là người ra quyết định vừa là người duy nhất đủ thẩm quyền phản biện.

Diễn giải: Khi đội vượt qua ngưỡng khoảng 8-10 người, ba vai trò bắt đầu xung đột về mặt thời gian và sự chú ý. Vấn đề không phải Minh kém — anh giỏi cả ba việc — mà là một con người chỉ có 8 tiếng một ngày.

Bài học: Việc đầu tiên cần tách ra thường là quản lý con người, vì đây là việc dễ bị hy sinh nhất khi bận và gây thiệt hại lâu dài nhất khi bị bỏ bê. Minh cuối cùng thuê một EM chuyên trách, giữ lại vai trò Architect cho mình, và đề bạt một senior thành TL cho từng luồng sản phẩm.

Tình huống 2 — Công ty gia công phần mềm ở Đà Nẵng: EM và TL giẫm chân nhau

Một công ty outsourcing khoảng 80 kỹ sư tách rõ EM và TL cho mỗi đội. Nhưng họ mắc một lỗi tinh vi: cả EM lẫn TL đều tham gia họp giao task hàng tuần, và cả hai đều "có ý kiến" về việc ai làm gì. Kết quả là các kỹ sư nhận chỉ đạo mâu thuẫn — EM muốn chị Lan làm module A để chị học công nghệ mới cho lộ trình sự nghiệp, còn TL muốn chị Lan làm module B vì đó là việc gấp và chị làm nhanh nhất.

Diễn giải: Đây là xung đột kinh điển giữa "phát triển con người" (mối quan tâm của EM) và "giao hàng đúng hạn" (mối quan tâm của TL). Cả hai đều đúng theo góc nhìn của mình. Vấn đề là ranh giới quyền quyết định (decision rights) không được vẽ rõ.

Bài học: Họ giải quyết bằng một thỏa thuận đơn giản: TL quyết ai làm task nào trong sprint (vì đó là quyết định thực thi), còn EM quyết hướng phát triển dài hạn của từng người và trao đổi mong muốn đó cho TL trước sprint, để TL cân bằng khi phân việc. Nói cách khác, EM đặt ràng buộc, TL tối ưu bên trong ràng buộc đó. Sau thay đổi này, các chỉ đạo mâu thuẫn biến mất gần như hoàn toàn.

Tình huống 3 — Sàn thương mại điện tử quy mô khu vực: Architect không có "răng"

Một nền tảng e-commerce lớn ở Đông Nam Á (giả định kiểu Tiki hay Sendo mở rộng) có một Architecture team gồm bốn người vẽ ra chuẩn kiến trúc rất đẹp: mọi service phải giao tiếp qua event bus, mọi API phải tuân chuẩn chung. Nhưng sáu tháng sau, không đội nào tuân theo. Các TL của từng đội vẫn làm theo cách riêng vì họ đang chịu áp lực giao hàng, và Architect thì không có quyền chặn.

Diễn giải: Architect dẫn dắt bằng ảnh hưởng, không bằng mệnh lệnh. Khi ảnh hưởng đó không được gắn vào quy trình thực tế, tài liệu kiến trúc chỉ là giấy tờ chết. "Ivory tower architect" là một thất bại tổ chức chứ không chỉ là lỗi cá nhân.

Bài học: Họ sửa bằng cách để Architect tham gia trực tiếp vào quy trình RFC — mọi thay đổi kiến trúc lớn phải qua một RFC mà Architect là người review bắt buộc — và quan trọng hơn, Architect cam kết viết reference implementation cho chuẩn mới để các đội có cái sao chép thay vì tự mò. Ảnh hưởng trở nên thực tế khi nó đi kèm sự giúp đỡ cụ thể, không chỉ là quy tắc.

Hướng dẫn từng bước

Nếu bạn đang xây dựng hoặc tái cấu trúc lãnh đạo kỹ thuật cho đội đang mở rộng, đây là lộ trình thực tế:

• Vẽ ma trận trách nhiệm hiện tại. Liệt kê tất cả trách nhiệm lãnh đạo kỹ thuật (1-1, review PR, quyết kiến trúc, tuyển dụng, ước lượng, phân task...) và ghi tên người đang thực sự làm mỗi việc. Bạn sẽ nhanh chóng thấy chỗ nào một người ôm quá nhiều và chỗ nào không ai chịu trách nhiệm.

• Xác định ngưỡng cần tách. Quy tắc kinh nghiệm: khi một người quản lý phải trực tiếp lo cho hơn 6-8 kỹ sư đồng thời với việc dẫn dắt kỹ thuật, đã đến lúc tách vai. Việc quản lý con người thường nên tách ra trước tiên.

• Tách EM trước. Tìm hoặc đào tạo một người thiên về con người để làm EM. Chấp nhận rằng người này sẽ code ít đi — đó là tính năng, không phải lỗi.

• Chỉ định TL cho từng đội. Chọn kỹ sư mạnh nhất về thực thi và có khả năng dẫn dắt bằng ảnh hưởng. Nói rõ với cả đội rằng TL không phải "sếp" mà là người điều phối kỹ thuật.

• Chỉ có Architect riêng khi thực sự cần. Với đội dưới 30 người, thường TL cấp cao hoặc CTO kiêm luôn kiến trúc là đủ. Chỉ tách vai Architect chuyên trách khi bạn có nhiều đội và cần sự nhất quán xuyên đội.

• Viết ra decision rights. Với mỗi loại quyết định (lương, phân task, chọn công nghệ, kiến trúc xuyên đội), ghi rõ ai quyết, ai tư vấn, ai chỉ được thông báo. Đây là bước ngăn ngừa xung đột lớn nhất.

• Thiết lập nhịp phối hợp. EM, TL và Architect nên có một buổi đồng bộ ngắn định kỳ để đảm bảo con người, thực thi và kiến trúc không lệch nhau.

Lỗi thường gặp & mẹo

Lỗi: Đề bạt kỹ sư giỏi nhất thành EM. Kỹ năng viết code xuất sắc không đảm bảo kỹ năng lắng nghe, đồng cảm và phát triển người khác. Nhiều công ty mất cả một senior giỏi lẫn một EM tồi trong một cú đề bạt sai. Mẹo: cho người đó thử vai TL trước — TL là bước đệm tự nhiên vì vẫn nặng kỹ thuật nhưng bắt đầu có yếu tố dẫn dắt.

Lỗi: EM vẫn ôm code trên đường tới hạn. EM viết một tính năng quan trọng rồi liên tục bị gián đoạn bởi việc con người, khiến tính năng trễ và đội mất niềm tin. Mẹo: EM chỉ nhận việc kỹ thuật có thể gián đoạn và không ai phụ thuộc gấp.

Lỗi: Coi TL là "phó của EM". TL và EM là hai trục khác nhau, không phải cấp trên cấp dưới. Gộp chúng lại theo kiểu thứ bậc làm TL mất quyền tự chủ kỹ thuật và EM bị kéo vào chi tiết thực thi. Mẹo: nghĩ về chúng như hai đường ray song song cùng đỡ một đoàn tàu.

Lỗi: Architect tách rời khỏi việc viết code. Càng xa code, quyết định kiến trúc càng phi thực tế và càng bị các đội phớt lờ. Mẹo: buộc Architect tham gia code thật ở mức tối thiểu, dù chỉ là reference implementation.

Mẹo tổng quát: Đừng tạo vai trò trước khi có nhu cầu. Cơ cấu ba vai trò tách bạch là giải pháp cho vấn đề của quy mô lớn; áp nó vào một đội 8 người chỉ tạo ra quan liêu và họp hành thừa.

Bài tập thực hành

• Lập ma trận vai trò cho đội của bạn. Lấy 8-10 trách nhiệm lãnh đạo kỹ thuật quan trọng nhất, kẻ bảng ba cột EM / TL / Architect, và đánh dấu ai đang chịu trách nhiệm mỗi việc trong đội hiện tại của bạn. Khoanh tròn những ô mà một người đang ôm quá nhiều, và gạch chân những việc không ai rõ ràng chịu trách nhiệm.

• Viết bảng decision rights. Chọn năm quyết định hay gây tranh cãi (ví dụ: ai làm task nào, có refactor lớn không, chọn thư viện gì, ai được thăng chức, dùng chuẩn API nào). Với mỗi quyết định, ghi rõ vai trò nào là người quyết cuối cùng và vai trò nào chỉ tư vấn.

• Tình huống giả định. Đội bạn vừa tăng từ 7 lên 15 người trong ba tháng, chuẩn bị chia thành hai đội. Bạn hiện là người duy nhất làm cả ba vai trò. Hãy viết một kế hoạch nửa trang: bạn tách vai trò nào trước, đề bạt/tuyển ai vào đâu, và bạn tự giữ vai trò nào — kèm lý do cho mỗi lựa chọn.

Tóm tắt

Engineering Manager, Tech Lead và Architect là ba vai trò dễ bị nhầm là một, nhưng thực chất trả lời ba câu hỏi khác nhau: Ai?, Làm thế nào? và Bằng nguyên tắc gì?. EM lấy con người làm trung tâm, code nhẹ và tránh đường tới hạn, quyền lực đến từ chức vụ. TL dẫn dắt thực thi hàng ngày của một đội, vẫn code nhiều, quyền lực đến từ chuyên môn và ảnh hưởng. Architect giữ tính toàn vẹn của hệ thống xuyên nhiều đội qua nhiều năm, cũng dẫn dắt bằng ảnh hưởng.

Khi đội còn nhỏ, một người có thể đội cả ba mũ. Khi vượt ngưỡng khoảng 8-10 người, xung đột về thời gian và quyền quyết định bắt đầu xuất hiện — và việc quản lý con người thường cần tách ra trước tiên. Chìa khóa để ba vai trò phối hợp thay vì cạnh tranh không phải là sơ đồ tổ chức đẹp, mà là decision rights được viết ra rõ ràng: ai đặt ràng buộc, ai tối ưu bên trong ràng buộc đó, và ai được thông báo. Vẽ đúng ranh giới này, bạn sẽ tránh được phần lớn những xung đột lãnh đạo kỹ thuật gây tổn hại nhất khi tổ chức mở rộng.