Mở đầu — vì sao bài này quan trọng
Có một khoảnh khắc mà gần như mọi Tech Lead khi bước lên vai trò quản lý đều phải đối mặt: đầu quý, CFO hoặc VP Engineering gõ cửa và hỏi "Team em cần thêm bao nhiêu người cho quý sau, và tại sao?". Nếu bạn trả lời kiểu "Dạ team đang đuối lắm, cần thêm 3-4 người ạ" thì gần như chắc chắn bạn sẽ ra về tay trắng, hoặc tệ hơn, bị đánh giá là không hiểu chuyện kinh doanh.
Headcount planning — việc lập kế hoạch số lượng và cơ cấu nhân sự — là một trong những kỹ năng phân biệt rõ nhất giữa một người quản lý kỹ thuật giỏi và một người chỉ giỏi về code. Nó là điểm giao thoa giữa hai thế giới: thế giới của product roadmap (chúng ta muốn xây gì) và thế giới của tài chính (chúng ta có bao nhiêu tiền, và mỗi đồng tiền đầu tư vào con người phải sinh ra giá trị gì).
Với các công ty công nghệ Việt Nam và Đông Nam Á, nơi ngân sách thường eo hẹp hơn Silicon Valley và mỗi quyết định tuyển dụng đều được soi rất kỹ, kỹ năng này càng quan trọng. Một kế hoạch headcount tốt không chỉ giúp bạn "xin" được người, mà còn xây dựng uy tín với ban lãnh đạo: bạn được nhìn nhận như một người điều hành business, không phải một kỹ sư đòi thêm tay chân. Bài học này sẽ trang bị cho bạn tư duy và quy trình để làm điều đó một cách bài bản.
Khái niệm cốt lõi
Headcount planning là gì và không phải là gì
Headcount planning là quá trình xác định: (1) team cần bao nhiêu người, (2) ở những vai trò và cấp bậc (level) nào, (3) tuyển vào thời điểm nào, và (4) với lý do kinh doanh nào để biện minh cho từng vị trí. Nó không phải là việc "ước một con số cho sướng" rồi hy vọng được duyệt. Nó là một bài toán tối ưu có ràng buộc: tối đa hóa năng lực thực thi roadmap trong giới hạn ngân sách.
Điểm mấu chốt cần nhớ: headcount là chi phí lớn nhất và cứng nhắc nhất của một tổ chức engineering. Khác với việc mua thêm server (có thể tắt tháng sau), tuyển một người là cam kết dài hạn — lương, thưởng, thiết bị, và cả chi phí sa thải nếu sai. Vì vậy mỗi vị trí phải được biện minh như một khoản đầu tư.
Ba loại "gap" bạn cần phân biệt
Khi phân tích nhu cầu nhân sự, hãy tách bạch ba loại thiếu hụt khác nhau, vì cách biện minh cho mỗi loại là khác nhau:
- Growth headcount (tăng trưởng): người mới để làm những việc mới trong roadmap. Đây là loại dễ biện minh nhất nếu roadmap rõ ràng, vì bạn gắn được trực tiếp với sản phẩm/doanh thu.
- Backfill (thay thế): người thay cho vị trí trống do nghỉ việc. Loại này thường được duyệt gần như tự động vì nó không làm tăng tổng chi phí đã được phê duyệt (budget-neutral), nhưng bạn vẫn phải chủ động xin, đừng cho là mặc nhiên.
- Capability gap (thiếu năng lực): team đủ số lượng nhưng thiếu một loại kỹ năng cụ thể — ví dụ chưa ai biết về bảo mật, hay thiếu một Senior để dẫn dắt. Loại này biện minh bằng rủi ro và chất lượng, không phải bằng khối lượng công việc.
Capacity — đơn vị đo lường thực sự
Sai lầm phổ biến của người mới là đếm "đầu người". Người có kinh nghiệm đếm capacity — năng lực thực tế. Một team 6 người trên giấy tờ không có nghĩa là bạn có 6 đơn vị năng lực. Bạn phải trừ đi:
- Thời gian on-call, họp, phỏng vấn, hỗ trợ (thường 20-30%).
- Nghỉ phép, lễ Tết (ở Việt Nam nguyên tuần Tết gần như đóng băng).
- Ramp-up của người mới (một junior mới mất 2-3 tháng mới đạt năng suất đầy đủ; thậm chí làm chậm team trong tháng đầu vì cần mentor).
- Sự khác biệt về level: một Senior có thể tương đương 2-3 Junior về output cho các bài toán phức tạp.
Business case — trái tim của mỗi vị trí
Mỗi vị trí bạn xin phải có một business case ngắn gọn trả lời được: "Nếu công ty cấp người này, công ty được gì; nếu không, công ty mất gì?". Câu trả lời phải nối được tới ngôn ngữ của lãnh đạo — doanh thu, chi phí tiết kiệm, rủi ro giảm, hoặc tốc độ ra thị trường. "Team đang mệt" không phải business case. "Không có DevOps engineer, mỗi lần sự cố production chúng ta mất trung bình 4 giờ downtime, tương đương X triệu doanh thu mỗi lần" mới là business case.
Tình huống thực tế
Tình huống 1: Startup fintech Việt Nam và cuộc chiến giành 2 slot
Một startup fintech ở TP.HCM (gọi là PayFlow) có team engineering 12 người, đang chuẩn bị kế hoạch cho Q3. Roadmap có ba mảng lớn: ra mắt tính năng thanh toán QR liên ngân hàng, xây dựng hệ thống chống gian lận (fraud detection), và cải thiện hạ tầng để chịu tải mùa cao điểm cuối năm.
Tech Lead ban đầu định xin 4 người. Nhưng khi ngồi tính capacity, anh phát hiện: với roadmap này, mảng QR cần khoảng 3 engineer-tháng/tháng liên tục, fraud cần một người có kinh nghiệm về ML/data mà cả team chưa ai có, và hạ tầng cần một DevOps. Anh nhận ra không thể xin cả 4 cùng lúc — CFO sẽ không duyệt vì burn rate đang bị siết sau vòng gọi vốn khó khăn.
Anh đổi cách tiếp cận: xin 2 vị trí ưu tiên cao nhất với business case sắc bén. Vị trí một là Data/ML engineer cho fraud, biện minh bằng con số: "Tỷ lệ giao dịch gian lận hiện tại là 0.8%, mỗi tháng mất khoảng 180 triệu. Một hệ thống fraud detection cơ bản có thể giảm xuống 0.3%, tiết kiệm ~110 triệu/tháng — hoàn vốn lương người này trong 2 tháng." Vị trí hai là DevOps, biện minh bằng rủi ro downtime mùa cao điểm. Hai vị trí QR còn lại, anh đề xuất giải quyết bằng cách điều phối lại người nội bộ và lùi một phần scope sang Q4.
Bài học: Xin ít nhưng chắc, với business case gắn thẳng vào tiền, thắng xa việc xin nhiều bằng cảm tính. Việc chủ động cắt giảm và ưu tiên khiến CFO tin tưởng rằng anh hiểu ràng buộc tài chính.
Tình huống 2: Backfill bị coi nhẹ ở một công ty e-commerce
Một công ty thương mại điện tử tại Đông Nam Á có team platform 8 người. Trong quý, hai Senior engineer nghỉ việc (một sang công ty khác, một chuyển ngành). Manager cho rằng "backfill thì đương nhiên được duyệt" nên không đưa vào kế hoạch quý một cách chính thức, chỉ nhắc miệng.
Kết quả: khi mùa lập ngân sách đến, bộ phận tài chính "đóng băng" (freeze) một phần headcount để tiết kiệm chi phí, và hai vị trí trống đó — vì không nằm trong kế hoạch được phê duyệt bằng văn bản — bị tính là "tiết kiệm được". Team mất 5 tháng mới xin lại được quyền tuyển, trong thời gian đó 6 người phải gánh việc của 8, dẫn tới một người kiệt sức và nghỉ thêm.
Bài học: Không có gì là "đương nhiên". Ngay cả backfill cũng phải được đưa vào kế hoạch và phê duyệt chính thức bằng văn bản. Trong môi trường siết chi phí, mọi vị trí trống không được bảo vệ đều là mục tiêu để cắt.
Tình huống 3: Xin sai level ở một scale-up
Một scale-up SaaS xin được 3 headcount cho năm sau. Để "tiết kiệm ngân sách và tuyển được nhiều đầu người hơn", manager quyết định tuyển cả 3 đều là Junior/Fresher, vì lương thấp — cùng ngân sách có thể thành 4 người.
Sáu tháng sau, team rơi vào khủng hoảng. Ba junior cần mentor liên tục, nhưng team chỉ có một Senior duy nhất, và người này bị kéo hoàn toàn vào việc kèm cặp và review, không còn thời gian làm việc kỹ thuật quan trọng. Vận tốc team giảm thay vì tăng. Chất lượng code đi xuống, số bug tăng.
Manager sau đó phải xin đổi kế hoạch: thay vì 4 junior, chuyển thành cơ cấu cân bằng — 1 Senior để tăng "khả năng đỡ" (mentorship capacity) và 2 mid-level. Team ổn định trở lại.
Bài học: Headcount planning không chỉ là "bao nhiêu người" mà còn là "người ở level nào". Một team cần tỷ lệ hợp lý giữa senior và junior; nhồi quá nhiều người mới vào một team thiếu người dẫn dắt sẽ phản tác dụng.
Hướng dẫn từng bước
Đây là quy trình quarterly (theo quý) để lập kế hoạch headcount mà bạn có thể áp dụng ngay:
Bước 1 — Bắt đầu từ roadmap, chuyển thành nhu cầu capacity. Lấy roadmap đã được thống nhất với Product cho quý/năm tới. Với từng sáng kiến (initiative) lớn, ước lượng thô số engineer-tháng cần thiết. Đừng cầu toàn con số chính xác — mục tiêu là thứ tự độ lớn (order of magnitude). Cộng lại để ra tổng nhu cầu capacity.
Bước 2 — Tính capacity hiện có một cách trung thực. Lấy số người hiện tại, trừ đi các khoản "hao hụt": on-call, họp, phỏng vấn, nghỉ phép/lễ, và điều chỉnh theo level. Kết quả là capacity thực (effective capacity), thường chỉ khoảng 60-70% con số danh nghĩa.
Bước 3 — Tính gap và phân loại. Gap = nhu cầu (bước 1) − capacity hiện có (bước 2). Sau đó phân loại gap thành growth, backfill, capability như đã nói ở trên. Đừng quên cộng backfill dự kiến — nếu lịch sử team rớt 10-15% người mỗi năm (attrition), hãy tính trước.
Bước 4 — Chuyển gap thành danh sách vị trí cụ thể với level. Không chỉ nói "cần 3 người" mà nói rõ: "1 Senior Backend để dẫn mảng thanh toán, 1 Mid Frontend, 1 DevOps." Cân nhắc tỷ lệ senior/junior để team có đủ năng lực mentor.
Bước 5 — Viết business case cho từng vị trí. Mỗi vị trí một đoạn ngắn: vị trí này làm gì, gắn với initiative nào trong roadmap, giá trị kinh doanh nếu có (được gì / mất gì). Gắn với tiền, rủi ro, hoặc tốc độ bất cứ khi nào có thể.
Bước 6 — Ưu tiên và tạo phương án. Sắp xếp các vị trí theo mức độ quan trọng. Chuẩn bị sẵn kịch bản "nếu chỉ được cấp một nửa thì cắt gì". Việc thể hiện bạn đã tự ưu tiên cho thấy sự trưởng thành về tư duy business và tăng khả năng được duyệt.
Bước 7 — Trình bày và bảo vệ (submit lên Finance/lãnh đạo). Đóng gói thành một tài liệu gọn (thường 1-2 trang hoặc vài slide): tổng quan roadmap, gap phân tích, danh sách vị trí có ưu tiên và business case, tổng chi phí ước tính, và timeline tuyển. Sẵn sàng trả lời câu hỏi "tại sao không làm được với người hiện tại?".
Bước 8 — Theo dõi và điều chỉnh. Kế hoạch không phải là bản khắc đá. Mỗi tháng đối chiếu thực tế: tuyển đúng tiến độ không, roadmap có đổi không, có ai nghỉ không. Điều chỉnh và giao tiếp lại với lãnh đạo khi cần.
Lỗi thường gặp & mẹo
Lỗi 1 — Đếm đầu người thay vì capacity. Luôn trừ đi họp, on-call, nghỉ phép và thời gian ramp-up của người mới. Người mới không đóng góp 100% ngay, và trong tháng đầu còn làm chậm cả team.
Lỗi 2 — Business case bằng cảm xúc. "Team mệt lắm rồi" không thuyết phục ai. Dịch mọi thứ sang ngôn ngữ business: doanh thu, chi phí, rủi ro, tốc độ ra thị trường.
Lỗi 3 — Quên tính attrition. Nếu bạn chỉ lên kế hoạch cho growth mà quên rằng sẽ có người nghỉ, giữa năm bạn sẽ bị hụt. Hãy dự phòng backfill dựa trên tỷ lệ nghỉ việc lịch sử.
Lỗi 4 — Xin quá nhiều, mất uy tín. Xin 10 để hy vọng được 3 là chiến thuật tồi. Lãnh đạo sẽ mất niềm tin vào các con số của bạn. Xin đúng, có ưu tiên, có phương án cắt giảm.
Lỗi 5 — Bỏ quên level và cơ cấu. Đừng chỉ tối ưu "nhiều đầu người nhất với cùng tiền". Một team lệch toàn junior sẽ sụp vì thiếu người dẫn dắt.
Lỗi 6 — Coi backfill là đương nhiên. Đưa mọi vị trí, kể cả thay thế, vào kế hoạch chính thức bằng văn bản. Vị trí không được bảo vệ là vị trí dễ bị cắt.
Mẹo vàng: Xây quan hệ với bộ phận Finance/HR trước mùa lập kế hoạch, không phải lúc đang cần xin. Khi họ hiểu team bạn và tin con số của bạn, mọi cuộc thương lượng đều dễ hơn. Ngoài ra, luôn nắm rõ chi phí đầy đủ (fully-loaded cost) của một engineer — không chỉ lương mà cả thưởng, bảo hiểm, thiết bị, chỗ ngồi — để nói chuyện tài chính một cách chuyên nghiệp.
Bài tập thực hành
- Bài tập capacity: Lấy team hiện tại của bạn (hoặc một team giả định 8 người). Liệt kê mọi khoản "hao hụt" (họp, on-call, nghỉ phép, ramp-up) và tính ra effective capacity theo phần trăm. Bạn còn lại bao nhiêu đơn vị năng lực thực?
- Bài tập gap: Cho một roadmap giả định gồm 3 initiative, tự ước lượng engineer-tháng cho từng cái, cộng lại, rồi trừ đi capacity ở bài 1. Phân loại phần thiếu thành growth / backfill / capability.
- Bài tập business case: Chọn một vị trí bạn muốn xin (ví dụ DevOps). Viết business case dài 4-5 câu trả lời được "được gì / mất gì" bằng ngôn ngữ tiền, rủi ro, hoặc tốc độ. Không được dùng từ "mệt" hay "đuối".
- Bài tập ưu tiên: Giả sử bạn xin 3 vị trí nhưng Finance chỉ duyệt được 1.5 (một người và nửa ngân sách). Viết kịch bản: bạn cắt gì, giữ gì, và scope roadmap nào phải lùi lại.
Tóm tắt
Headcount planning là kỹ năng phân biệt giữa một quản lý kỹ thuật giỏi và một kỹ sư đòi thêm người. Cốt lõi của nó là một quy trình quarterly gồm bốn bước xương sống: (1) chuyển roadmap thành nhu cầu capacity, (2) so với capacity hiện có để tìm gap, (3) biện minh mỗi vị trí bằng một business case gắn với giá trị kinh doanh, và (4) trình bày lên Finance/lãnh đạo một cách có ưu tiên và có phương án dự phòng.
Ba nguyên tắc cần khắc cốt: đếm capacity chứ không đếm đầu người; mọi vị trí phải có business case bằng ngôn ngữ business chứ không phải cảm xúc; và luôn quan tâm tới level và cơ cấu team chứ không chỉ số lượng. Đừng coi backfill là đương nhiên, đừng quên attrition, và đừng xin nhiều để mặc cả. Làm tốt việc này, bạn không chỉ có được người mình cần mà còn xây dựng uy tín như một người điều hành thực thụ — điều sẽ mở đường cho các nấc thang sự nghiệp lãnh đạo tiếp theo.