Mở đầu — vì sao bài này quan trọng
Có một sự thật mà nhiều Technical PM phải mất vài năm mới ngấm: bạn không trực tiếp viết một dòng code nào, nhưng kết quả công việc của bạn phụ thuộc gần như hoàn toàn vào hai người mà bạn không có quyền ra lệnh — Tech Lead và Engineering Manager (EM). Bạn sở hữu kết quả sản phẩm, nhưng người quyết định "xây như thế nào, ai xây, xây trong bao lâu" lại là họ. Đây chính là mối quan hệ tam giác quyền lực mềm quan trọng nhất trong sự nghiệp Technical PM.
Khi mối quan hệ này tốt, mọi thứ trơn tru đến mức bạn thấy như mình có siêu năng lực: estimate sát, kỹ sư chủ động cảnh báo rủi ro kỹ thuật từ sớm, roadmap được bảo vệ trong các cuộc họp leadership. Khi mối quan hệ này hỏng, bạn rơi vào địa ngục: spec bị làm sai, deadline trượt liên tục mà không ai báo trước, và bạn trở thành "người chuyển ticket" thay vì người dẫn dắt sản phẩm.
Ở Việt Nam, vấn đề còn phức tạp hơn vì ranh giới vai trò thường mờ. Trong nhiều công ty, một người có thể vừa là Tech Lead vừa kiêm EM; có nơi PM bị xem như "thư ký dự án"; có nơi Tech Lead lại tự quyết luôn cả phần "build cái gì". Bài này sẽ giúp bạn phân định rạch ròi vai trò, hiểu động cơ của từng người, và xây dựng quan hệ làm việc khiến cả ba cùng thắng.
Khái niệm cốt lõi
Ba vai trò, ba câu hỏi khác nhau
Cách đơn giản nhất để ghi nhớ ranh giới là gắn mỗi vai trò với một câu hỏi chủ đạo:
- PM (Product Manager) trả lời câu hỏi WHAT và WHY: Chúng ta xây cái gì, cho ai, giải quyết vấn đề gì, vì sao việc này đáng làm bây giờ thay vì thứ khác. PM sở hữu outcome (kết quả kinh doanh/người dùng), sở hữu thứ tự ưu tiên (priority), và sở hữu định nghĩa "thành công trông như thế nào".
- Tech Lead (TL) trả lời câu hỏi HOW (về mặt kỹ thuật): Kiến trúc nào, công nghệ nào, chia module ra sao, đánh đổi kỹ thuật nào chấp nhận được. TL sở hữu chất lượng code và kiến trúc, sở hữu các quyết định kỹ thuật, và thường là người estimate độ phức tạp. TL là vai trò kỹ thuật — không nhất thiết quản lý con người.
- Engineering Manager (EM) trả lời câu hỏi WHO và HEALTH: Ai làm việc gì, đội có đủ người không, ai đang quá tải, ai cần phát triển kỹ năng, tốc độ giao hàng (delivery) của đội có bền vững không. EM sở hữu con người và quy trình, sở hữu sự nghiệp của kỹ sư, sở hữu năng lực giao hàng dài hạn của đội.
Vùng giao thoa — nơi xung đột sinh ra
Xung đột hầu như luôn nằm ở vùng chồng lấn giữa các vai trò:
- PM ↔ TL: PM muốn "ship nhanh để kịp test thị trường", TL muốn "làm cho chắc kẻo nợ kỹ thuật ngập đầu". Đây là căng thẳng giữa outcome ngắn hạn và sức khỏe kỹ thuật dài hạn. Cả hai đều đúng, vấn đề là tìm điểm cân bằng cho từng bối cảnh.
- PM ↔ EM: PM muốn dồn người cho tính năng A, EM nhìn thấy việc đó sẽ làm kiệt sức hai kỹ sư đang sắp burnout. PM nghĩ theo deliverable, EM nghĩ theo con người và tính bền vững.
- TL ↔ EM: ai quyết phân công ai làm gì? TL muốn người giỏi nhất làm phần khó nhất; EM muốn dùng cơ hội đó để một junior học hỏi và phát triển. Hai mục tiêu hợp lý nhưng kéo về hai hướng.
RACI ngầm cho các quyết định thường gặp
| Quyết định | PM | Tech Lead | EM |
|---|---|---|---|
| Xây tính năng gì, ưu tiên ra sao | Quyết | Tư vấn | Tư vấn |
| Kiến trúc & lựa chọn công nghệ | Tư vấn | Quyết | Tư vấn |
| Ai làm việc gì, phân bổ người | Báo nhu cầu | Tư vấn | Quyết |
| Đánh đổi scope vs deadline | Đồng quyết | Đồng quyết | Tư vấn |
| Trả nợ kỹ thuật bao nhiêu mỗi sprint | Tư vấn | Đồng quyết | Đồng quyết |
| Định nghĩa "Done" | Quyết | Tư vấn | Tư vấn |
Tình huống thực tế
Tình huống 1: Sàn TMĐT — PM lấn sân vào quyết định kỹ thuật
Tại một sàn thương mại điện tử quy mô trung ở TP.HCM (giả định gọi là ShopNhanh, ~40 kỹ sư), một PM tên Linh phụ trách tính năng "thanh toán trả góp". Linh từng học lập trình, nên trong spec cô viết hẳn: "Dùng Redis để cache hạn mức tín dụng, gọi API đối tác qua webhook đồng bộ". Tech Lead tên Đức đọc xong khó chịu ra mặt — webhook đồng bộ với đối tác có độ trễ 3-8 giây sẽ làm treo cả luồng checkout, và đội đã có sẵn một hàng đợi (message queue) phù hợp hơn.
Kết quả: hai tuần đầu, Đức âm thầm làm theo cách của mình nhưng không nói, còn Linh tưởng spec được tuân thủ. Đến demo, hai bên mới phát hiện hiểu nhau sai, mất thêm một sprint để đồng bộ lại.
Bài học: Linh đã vượt ranh giới WHAT sang HOW. Điều cô cần nói trong spec là yêu cầu: "Luồng checkout không được tăng quá 500ms; hạn mức tín dụng có thể trễ tối đa 5 phút so với thực tế đều chấp nhận được." Đó là ngôn ngữ ràng buộc (constraint) thuộc về PM. Cách implement để đạt ràng buộc đó là sân của Đức. Sau sự cố, họ thống nhất: PM viết constraint và acceptance criteria, TL viết kỹ thuật. Số vòng lặp sửa spec giảm rõ rệt.
Tình huống 2: Startup fintech — PM và EM lệch pha về sức khỏe đội
Tại một startup fintech ở Singapore mở văn phòng engineering tại Hà Nội, PM tên Hùng đẩy mạnh ba tính năng lớn liên tiếp trong một quý để chuẩn bị vòng gọi vốn. EM tên Mai liên tục báo: "Hai kỹ sư backend đang OT triền miên, velocity quý sau sẽ sụp." Hùng nghe nhưng vẫn ưu tiên deadline gọi vốn vì áp lực từ founder.
Đến giữa quý, một kỹ sư backend chủ chốt nghỉ việc. Velocity của đội rớt 35% và tính năng thứ ba trượt deadline — đúng cái deadline gọi vốn mà Hùng cố bảo vệ. Mất một người giỏi còn đắt hơn nhiều so với việc lùi một tính năng.
Bài học: EM không phải người "cản đường" PM — EM là hệ thống cảnh báo sớm về năng lực giao hàng dài hạn. Khi EM nói về burnout, đó không phải lời than, đó là dữ liệu rủi ro. Lẽ ra Hùng nên cùng Mai làm một bài toán đánh đổi minh bạch: "Nếu ship cả ba, xác suất mất người là bao nhiêu, và chi phí nếu mất người là gì?" Sau sự cố, công ty đặt nguyên tắc: mọi cam kết roadmap với founder phải có EM ký xác nhận về tính khả thi nhân sự. PM vẫn quyết priority, nhưng EM có quyền phủ quyết về tính bền vững.
Tình huống 3: Khi mối quan hệ vận hành đúng — phối hợp tam giác
Ngược lại, tại một công ty SaaS B2B (giả định là FlowCRM), bộ ba PM–TL–EM có một nghi thức nhỏ nhưng hiệu quả: mỗi đầu sprint, họ họp 30 phút "tam giác". PM trình bày vì sao mục tiêu sprint quan trọng và đo bằng metric gì. TL phản hồi về rủi ro kỹ thuật và đề xuất phương án đơn giản hơn nếu có. EM lên tiếng về dung lượng đội: "Tuần này Nam nghỉ phép, Trang dành 30% cho phỏng vấn tuyển dụng."
Trong một sprint, PM muốn ra tính năng export báo cáo. TL chỉ ra rằng làm bản "đẹp hoàn chỉnh" tốn 8 ngày, nhưng bản CSV thô chỉ tốn 2 ngày và đủ kiểm chứng nhu cầu. EM xác nhận đội chỉ còn 2 người-ngày trống. PM quyết: ship bản CSV thô trước, đo tỉ lệ dùng, rồi mới đầu tư bản đẹp. Kết quả: tính năng ra đúng hạn, dữ liệu cho thấy chỉ 12% người dùng thực sự cần export — và đội tránh được 6 ngày công lãng phí.
Bài học: Khi mỗi người phát biểu đúng "câu hỏi của mình" (PM nói WHY/metric, TL nói HOW/đánh đổi kỹ thuật, EM nói WHO/dung lượng), quyết định trở nên nhanh và chất lượng. Quan hệ tốt không phải là "không bao giờ bất đồng", mà là mỗi người tin tưởng và lắng nghe phần chuyên môn của người kia.
Hướng dẫn từng bước
Đây là quy trình thực dụng để xây và vận hành quan hệ với TL và EM:
- Vẽ bản đồ vai trò ngay tuần đầu. Khi join đội mới hoặc nhận TL/EM mới, hãy ngồi xuống 45 phút và cùng điền bảng RACI ở trên. Hỏi thẳng: "Khi mình bất đồng về scope và deadline, ai là người ra quyết định cuối?" Làm rõ trước khi xung đột xảy ra, không phải lúc đang nóng.
- Hiểu động cơ (incentive) của từng người. TL thường được đánh giá qua chất lượng hệ thống và việc không có sự cố production. EM được đánh giá qua sự ổn định và phát triển của đội, qua retention. Khi bạn trình bày một đề xuất, hãy đóng khung nó theo động cơ của họ: với TL, nhấn mạnh "phương án này giảm rủi ro vận hành"; với EM, nhấn mạnh "việc này tạo cơ hội cho junior phát triển".
- Mang vấn đề, đừng mang giải pháp kỹ thuật. Thay vì "hãy dùng Kafka", hãy nói "mình cần xử lý 10.000 sự kiện/phút mà không mất dữ liệu — đội nghĩ sao?". Để TL tự đề xuất công nghệ. Điều này vừa tôn trọng chuyên môn, vừa khiến họ sở hữu giải pháp (ownership).
- Đồng quyết các đánh đổi, công khai bằng dữ liệu. Với cặp scope–deadline–chất lượng, đừng quyết một mình. Đặt ba người vào một bảng: lựa chọn A/B/C, mỗi cái tốn bao nhiêu, được gì mất gì. PM cầm bút điều phối, nhưng quyết định là chung.
- Phân bổ "ngân sách nợ kỹ thuật". Thống nhất với TL và EM một tỉ lệ cố định mỗi sprint (ví dụ 15-20% công suất) dành cho refactor/trả nợ kỹ thuật. Khi đã có ngân sách này, bạn không phải tranh cãi từng lần — và TL không phải lén lút "giấu" công việc kỹ thuật vào ticket tính năng.
- Bảo vệ đội ra bên ngoài. Khi leadership ép deadline phi lý, vai trò PM là hấp thụ áp lực và đàm phán lại scope, chứ không phải chuyển nguyên áp lực xuống đội. EM sẽ nhớ mãi việc bạn đứng ra che chắn — đó là vốn quan hệ quý nhất bạn có thể tích lũy.
- Tạo nghi thức định kỳ. Một buổi "tam giác" 30 phút đầu sprint và một buổi 1:1 hai tuần/lần với TL và với EM. Quan hệ tin cậy được xây bằng những cuộc trò chuyện đều đặn lúc bình yên, không phải lúc khủng hoảng.
Lỗi thường gặp & mẹo
Lỗi 1 — Lấn sân HOW. PM có nền kỹ thuật rất dễ chỉ đạo cách implement. Điều này phá hỏng quyền sở hữu của TL và khiến họ làm việc miễn cưỡng. Mẹo: tự hỏi "câu này là constraint (của mình) hay là solution (của TL)?" trước khi viết vào spec.
Lỗi 2 — Xem EM là rào cản. Khi EM nói "không đủ người", PM hay nghĩ EM lười hoặc bảo thủ. Thực ra EM đang bảo vệ năng lực dài hạn. Mẹo: chuyển từ tranh cãi sang hợp tác — "Vậy để ship được cái này, mình cần đánh đổi gì?"
Lỗi 3 — Bỏ qua TL, đi thẳng xuống kỹ sư. Đi vòng qua TL để nhờ một kỹ sư làm nhanh một việc nhỏ. Việc này phá vỡ tính thống nhất kỹ thuật và làm xói mòn quyền của TL. Mẹo: mọi yêu cầu kỹ thuật đi qua TL, dù nhỏ.
Lỗi 4 — Nhầm EM với TL (hoặc ngược lại). Hỏi EM về quyết định kiến trúc, hoặc hỏi TL về kế hoạch sự nghiệp của kỹ sư. Mẹo: nhớ ba câu hỏi WHAT/HOW/WHO và gửi đúng câu hỏi cho đúng người.
Lỗi 5 — Không làm rõ ai quyết khi bất đồng. Để mơ hồ đến lúc nóng mới tranh quyền. Mẹo: thống nhất RACI từ ngày đầu.
Mẹo vàng: Khi TL và EM là hai người khác nhau, hãy để ý xem họ có đồng thuận với nhau không trước khi đẩy quyết định lên. Nếu TL muốn dùng người giỏi cho việc khó còn EM muốn để junior học, bạn đừng nhảy vào phân xử — hãy để hai người đó tự thống nhất, rồi bạn nhận kết quả. Đừng biến mình thành trọng tài cho mâu thuẫn không thuộc sân của bạn.
Bài tập thực hành
- Bản đồ vai trò. Vẽ bảng RACI cho đội hiện tại của bạn (hoặc một đội bạn quan sát) với ít nhất 6 loại quyết định. Đem đi xác nhận với TL và EM thật. Ghi lại những điểm họ không đồng ý với cách bạn điền — đó chính là vùng rủi ro xung đột.
- Viết lại spec theo ngôn ngữ constraint. Lấy một spec gần đây của bạn, gạch chân mọi câu mang tính "chỉ đạo kỹ thuật" (HOW). Viết lại mỗi câu đó thành một ràng buộc/tiêu chí chấp nhận (constraint) để trả phần HOW về cho TL.
- Đóng khung theo động cơ. Chọn một đề xuất bạn sắp trình. Viết hai phiên bản pitch một đoạn: một bản đóng khung cho TL (theo rủi ro/chất lượng kỹ thuật), một bản cho EM (theo con người/tính bền vững). So sánh xem cách diễn đạt thay đổi thế nào.
- Tình huống burnout. EM báo với bạn rằng đội sẽ kiệt sức nếu ship đủ scope quý này. Viết kịch bản một cuộc họp ba bên: bạn sẽ đặt những câu hỏi gì, đưa ra những lựa chọn đánh đổi nào, và bạn sẽ bảo vệ quyết định cuối cùng với leadership ra sao?
Tóm tắt
- Technical PM không có quyền ra lệnh với TL và EM, nhưng thành công của bạn phụ thuộc vào họ — đây là quan hệ ảnh hưởng (influence) chứ không phải quyền lực (authority).
- Ghi nhớ ba câu hỏi: PM = WHAT/WHY (sở hữu outcome và priority), TL = HOW (sở hữu chất lượng và kiến trúc), EM = WHO/HEALTH (sở hữu con người và năng lực giao hàng dài hạn).
- Xung đột sinh ra ở vùng giao thoa: PM↔TL (nhanh vs chắc), PM↔EM (deliverable vs con người), TL↔EM (ai làm phần nào). Dự đoán trước và thống nhất RACI từ sớm.
- Mang vấn đề và constraint, đừng mang giải pháp kỹ thuật. Đóng khung đề xuất theo động cơ của từng người. Đồng quyết các đánh đổi bằng dữ liệu, công khai.
- Lỗi chí mạng là lấn sân HOW, xem EM là rào cản, và đi vòng qua TL. Quan hệ tin cậy được xây bằng nghi thức định kỳ lúc bình yên, không phải lúc khủng hoảng.