Mở đầu — vì sao bài này quan trọng
Có một khoảnh khắc trong sự nghiệp mà rất nhiều tech lead và engineering manager phải đối mặt lần đầu: sếp gửi cho bạn một file spreadsheet và nói "Đây là ngân sách engineering năm sau, em review giúp anh." Bạn mở ra, nhìn thấy hàng chục dòng với những con số hàng tỷ đồng, những cột như "OpEx", "CapEx", "burn rate", "fully-loaded cost"... và bạn nhận ra rằng suốt bao nhiêu năm viết code, chưa ai dạy bạn đọc thứ này.
Nhiều kỹ sư giỏi vấp ngã ngay tại đây. Họ nghĩ rằng ngân sách là việc của bộ phận tài chính hoặc của "sếp to hơn". Nhưng sự thật là: ngày bạn bắt đầu lãnh đạo kỹ thuật, bạn đã ngầm chịu trách nhiệm về tiền. Mỗi lần bạn tuyển thêm một người, mỗi lần bạn bật một cụm Kubernetes mới, mỗi lần bạn mua license Datadog — bạn đang tiêu tiền của công ty. Nếu bạn không hiểu ngân sách, bạn sẽ luôn ở thế bị động: bị cắt headcount mà không biết vì sao, bị từ chối đề xuất mua công cụ mà không biết cách bảo vệ, hoặc tệ hơn, làm công ty đốt tiền vô tội vạ mà không nhận ra.
Hiểu ngân sách engineering không biến bạn thành kế toán. Nó biến bạn thành một nhà lãnh đạo mà ban giám đốc tin tưởng — người nói chuyện được cả bằng ngôn ngữ kỹ thuật lẫn ngôn ngữ tiền. Đó chính là thứ phân biệt một tech lead "chỉ giỏi code" với một tech leader thực thụ. Bài này sẽ trang bị cho bạn nền tảng đó.
Khái niệm cốt lõi
Ngân sách engineering gồm những gì
Ngân sách engineering, dù ở startup 10 người hay tập đoàn nghìn kỹ sư, thường được chia thành ba nhóm chi phí lớn. Hiểu tỷ trọng của từng nhóm giúp bạn biết "nên nhìn vào đâu để tối ưu".
1. Headcount (nhân sự) — chiếm 70–85% tổng ngân sách. Đây là khoản chi lớn nhất, gần như luôn luôn. Nhưng lương gross (lương ghi trên hợp đồng) chỉ là một phần. Chi phí thực sự của một nhân viên gọi là fully-loaded cost — bao gồm: lương, bảo hiểm xã hội/y tế/thất nghiệp (ở Việt Nam khoảng 17,5% do công ty đóng), thưởng, cổ phần (equity/ESOP nếu có), chi phí thiết bị, phần mềm license cấp cho mỗi người, và chi phí văn phòng phân bổ. Quy tắc ngón tay cái: fully-loaded cost thường bằng 1,25–1,4 lần lương gross. Nghĩa là một kỹ sư lương 40 triệu/tháng thực chất "tốn" của công ty khoảng 50–56 triệu/tháng.
2. Infrastructure (hạ tầng) — thường 10–20%. Đây là tiền cloud (AWS, GCP, Azure), CDN, database managed, và các dịch vụ vận hành hệ thống. Với các công ty có sản phẩm lưu lượng lớn, đây có thể là khoản chi lớn thứ hai và tăng nhanh nhất theo tăng trưởng người dùng.
3. Tools & SaaS (công cụ) — thường 3–8%. Bao gồm IDE (JetBrains, Copilot), monitoring (Datadog, Sentry), CI/CD (CircleCI, GitHub Actions), quản lý dự án (Jira, Linear), giao tiếp (Slack), và hàng chục subscription nhỏ khác. Từng khoản nhỏ nhưng cộng lại đáng kể, và đây là nơi lãng phí "âm thầm" hay xảy ra nhất.
OpEx vs CapEx — cặp khái niệm bạn buộc phải biết
Bộ phận tài chính phân biệt hai loại chi tiêu. OpEx (Operating Expense) là chi phí vận hành hằng ngày — lương, tiền cloud hằng tháng, license phần mềm. Nó được tính hết vào chi phí trong kỳ. CapEx (Capital Expense) là đầu tư dài hạn — mua server vật lý, xây data center — được khấu hao dần qua nhiều năm. Với hầu hết công ty phần mềm hiện đại dùng cloud, gần như mọi thứ đều là OpEx. Nhưng bạn vẫn cần biết cặp khái niệm này, vì đôi khi CFO sẽ hỏi "chi phí này capitalize được không?" — và ở một số nước, lương kỹ sư xây dựng sản phẩm mới có thể được capitalize (vốn hóa), ảnh hưởng đến cách công ty báo cáo lợi nhuận.
Burn rate và runway
Burn rate là số tiền công ty đốt mỗi tháng. Runway là số tháng công ty còn "sống" được với lượng tiền hiện có, tính bằng: tiền mặt còn lại ÷ burn rate hằng tháng. Ở startup, đây là hai con số sống còn. Nếu công ty có 24 tỷ trong ngân hàng và đốt 2 tỷ/tháng, runway là 12 tháng. Là tech lead, bạn cần hiểu vì mọi quyết định tuyển người hay bật hạ tầng mới đều làm tăng burn rate và rút ngắn runway.
Top-down vs bottom-up budgeting
Có hai cách lập ngân sách. Top-down: ban lãnh đạo đưa ra con số tổng ("Engineering được 30 tỷ năm nay") và bạn phải phân bổ vừa vặn. Bottom-up: bạn liệt kê nhu cầu thực tế (cần tuyển 8 người, cần thêm cluster này...) rồi cộng lên. Thực tế, quy trình tốt là kết hợp cả hai: lãnh đạo cho một khung trần, đội ngũ đề xuất chi tiết bottom-up, rồi hai bên đàm phán ở giữa.
Tình huống thực tế
Ví dụ 1 — Startup fintech Việt Nam đốt tiền cloud không kiểm soát
Một startup fintech ở TP.HCM (gọi là PayFlow) gọi vốn Series A 5 triệu USD. Đội engineering 25 người, mỗi tháng đốt khoảng 1,8 tỷ đồng. Sau 8 tháng, CFO báo động: chi phí AWS đã tăng từ 120 triệu/tháng lên 380 triệu/tháng, trong khi số người dùng chỉ tăng gấp đôi. Runway rút xuống còn 9 tháng, đội bắt đầu hoảng.
Tech lead ngồi xuống phân tích hóa đơn AWS chi tiết (dùng Cost Explorer). Phát hiện: đội đã bật 12 môi trường staging luôn chạy 24/7, một cụm RDS instance loại lớn cho môi trường test hầu như không ai dùng, và data transfer giữa các region vì đặt service sai chỗ. Ba khoản này chiếm gần 45% hóa đơn nhưng không tạo ra giá trị nào cho khách hàng.
Họ hành động: tự động tắt staging ngoài giờ làm việc (tiết kiệm 65%), gộp môi trường test, dùng reserved instances cho phần tải ổn định, và sửa kiến trúc để giảm cross-region transfer. Kết quả: hóa đơn giảm từ 380 xuống 210 triệu/tháng — kéo dài runway thêm gần 2 tháng mà không cắt một người nào.
Bài học: Chi phí cloud không tăng tuyến tính theo giá trị. Nếu không có người theo dõi FinOps (financial operations cho cloud), nó phình ra âm thầm. Một tech lead hiểu ngân sách sẽ đặt cloud cost vào dashboard hằng tuần, không đợi đến khi CFO gõ cửa.
Ví dụ 2 — Cắt giảm SaaS trùng lặp tại một công ty e-commerce
Một công ty thương mại điện tử ở Singapore với 120 kỹ sư nhận yêu cầu cắt 15% chi phí tools trong bối cảnh thị trường 2023 khó khăn. Engineering manager cho audit toàn bộ subscription. Kết quả gây sốc: công ty đang trả tiền cho ba công cụ APM khác nhau (New Relic, Datadog, và Dynatrace) vì các team khác nhau tự mua theo thời điểm; có 40 license Postman Enterprise nhưng chỉ 12 người dùng thực sự trong 90 ngày qua; và một license Figma Organization trả cho 200 chỗ nhưng engineering chỉ dùng 30.
Sau khi hợp nhất về một APM duy nhất (Datadog), thu hồi license không dùng, và đàm phán lại hợp đồng theo số ghế thực tế, họ cắt được 22% chi phí tools — vượt mục tiêu — mà không kỹ sư nào cảm thấy bị lấy mất công cụ họ đang dùng.
Bài học: Lãng phí tools thường không nằm ở giá từng công cụ mà ở sự trùng lặp và license ma (mua rồi không dùng). Một quy trình đơn giản — mỗi công cụ có một "owner" chịu trách nhiệm và review lượng dùng mỗi quý — ngăn được phần lớn lãng phí này.
Ví dụ 3 — Bảo vệ đề xuất tăng headcount trước ban giám đốc
Một tech lead tại công ty SaaS B2B muốn tuyển thêm 3 kỹ sư backend. Lần đầu, anh trình bày: "Team đang quá tải, cần thêm người." Đề xuất bị bác ngay vì thiếu cơ sở. Lần sau, anh chuẩn bị khác: anh cho thấy velocity team đã giảm 30% do phải gánh on-call và bug fix; anh tính rằng ba tính năng doanh thu bị hoãn có giá trị hợp đồng ước tính 8 tỷ đồng/năm; và fully-loaded cost của 3 kỹ sư là khoảng 4,3 tỷ/năm. Anh trình bày dưới dạng ROI: "Đầu tư 4,3 tỷ để giải phóng 8 tỷ doanh thu bị kẹt, chưa kể giảm rủi ro burnout."
Lần này đề xuất được duyệt trong 15 phút.
Bài học: Ngân sách không phải cuộc chiến "xin thêm". Nó là cuộc trò chuyện về ROI. Khi bạn diễn đạt nhu cầu kỹ thuật bằng ngôn ngữ giá trị kinh doanh và con số cụ thể, bạn chuyển từ vị thế "người xin tiền" sang "người đầu tư có tính toán".
Hướng dẫn từng bước
Đây là quy trình để một tech lead xây dựng và quản lý ngân sách engineering, dù bạn đang làm ở quy mô nào.
Bước 1 — Lập bản đồ chi tiêu hiện tại. Trước khi lập kế hoạch tương lai, hãy hiểu hiện tại. Kéo dữ liệu 6–12 tháng gần nhất: bảng lương (từ HR/tài chính), hóa đơn cloud (từ Cost Explorer/Billing), và danh sách toàn bộ subscription (thường nằm rải rác trên thẻ tín dụng công ty). Phân loại theo ba nhóm headcount / infra / tools. Bạn sẽ ngạc nhiên về những gì phát hiện.
Bước 2 — Xác định cost drivers. Với mỗi nhóm, hỏi: điều gì khiến chi phí này tăng? Headcount tăng theo kế hoạch tuyển. Infra tăng theo lưu lượng người dùng — nên tính chi phí trên mỗi đơn vị (ví dụ: VND/1000 request, hoặc chi phí cloud trên mỗi khách hàng active). Đây là chỉ số vàng: nếu chi phí đơn vị giảm khi bạn tăng trưởng, bạn đang có economies of scale; nếu nó tăng, có vấn đề kiến trúc.
Bước 3 — Dự phóng theo kịch bản. Lập ngân sách năm sau theo ba kịch bản: bảo thủ, cơ sở, và tăng trưởng mạnh. Với mỗi kịch bản, tính headcount cần thiết và infra tương ứng. Điều này giúp bạn linh hoạt khi tình hình thay đổi giữa năm.
Bước 4 — Ưu tiên hóa và cắt phần thừa. Không phải mọi chi tiêu đều bình đẳng. Xếp hạng từng khoản theo mức độ ảnh hưởng đến khách hàng và doanh thu. Những thứ ở đáy danh sách (môi trường test dư thừa, tool trùng lặp, license ma) là nơi cắt trước khi phải chạm đến người.
Bước 5 — Trình bày bằng ngôn ngữ kinh doanh. Khi đưa ngân sách lên trên, luôn kèm phần "vì sao". Đừng nói "cần 12 tỷ cho cloud". Hãy nói "cloud chiếm 15% ngân sách, chi phí trên mỗi khách hàng đã giảm 8% năm nay nhờ tối ưu, và khoản này scale theo cam kết tăng trưởng 40% người dùng."
Bước 6 — Theo dõi và điều chỉnh liên tục. Ngân sách không phải tài liệu ký một lần rồi cất. Đặt review hằng tháng: chi tiêu thực tế so với kế hoạch (variance analysis). Nếu một hạng mục vượt 10%, tìm hiểu ngay vì sao trước khi nó thành 30%.
Lỗi thường gặp & mẹo
Lỗi 1 — Chỉ nhìn lương gross, quên fully-loaded cost. Khi lập kế hoạch tuyển, nhiều tech lead tính lương mà quên bảo hiểm, thiết bị, license. Kết quả là ngân sách thực tế vượt 30% so với dự tính. Luôn nhân lương gross với hệ số 1,3 để có con số gần thực tế.
Lỗi 2 — Bỏ qua "chi phí đơn vị" và chỉ nhìn tổng. Chi phí cloud tăng không xấu nếu nó tăng chậm hơn doanh thu. Đừng hoảng loạn cắt hạ tầng chỉ vì con số tổng tăng — hãy nhìn chi phí trên mỗi khách hàng. Nếu chỉ số đó ổn định hoặc giảm, bạn đang khỏe mạnh.
Lỗi 3 — Không có ai sở hữu chi phí. Khi "ngân sách là việc của tất cả" nghĩa là chẳng ai chịu trách nhiệm. Mỗi hạng mục lớn (cloud, mỗi nhóm tool) nên có một owner rõ ràng.
Lỗi 4 — Cắt sai chỗ khi khó khăn. Trong thời điểm siết chi phí, bản năng là cắt tools và training vì chúng "dễ cắt". Nhưng cắt công cụ khiến kỹ sư làm việc chậm hơn có thể tốn nhiều hơn khoản tiết kiệm được. Cắt lãng phí thật (trùng lặp, license ma) trước, đừng cắt thứ tạo năng suất.
Mẹo — Xây "văn hóa cost-aware" chứ không phải "cost-obsessed". Đừng biến mọi kỹ sư thành kế toán ám ảnh từng đồng. Thay vào đó, làm cho chi phí minh bạch: hiển thị hóa đơn cloud trên dashboard chung, chia sẻ chi phí mỗi feature. Khi kỹ sư nhìn thấy con số, họ tự đưa ra quyết định tốt hơn mà không cần bị ép.
Mẹo — Đàm phán hợp đồng SaaS cuối quý/cuối năm. Nhà cung cấp SaaS có chỉ tiêu doanh số theo quý. Đàm phán vào thời điểm họ cần chốt deal thường được giảm giá 15–30%, đặc biệt với hợp đồng nhiều năm.
Bài tập thực hành
- Audit thực tế: Lấy (hoặc giả định nếu chưa có quyền truy cập) chi tiêu engineering của team bạn trong 3 tháng gần nhất. Phân loại thành ba nhóm headcount / infra / tools và tính tỷ trọng phần trăm. Tỷ lệ có khớp với chuẩn 70–85 / 10–20 / 3–8 không? Nếu lệch, vì sao?
- Tính fully-loaded cost: Chọn một mức lương gross điển hình trong team bạn. Tính fully-loaded cost bằng cách cộng bảo hiểm (17,5%), thiết bị (~30 triệu/năm), license phần mềm (~15 triệu/năm), và thưởng ước tính. So sánh với con số bạn từng nghĩ.
- Săn lãng phí: Liệt kê toàn bộ SaaS/tool team đang trả tiền. Với mỗi cái, ghi: ai là owner, bao nhiêu người thực sự dùng, có công cụ nào trùng chức năng không. Tìm ít nhất một khoản có thể cắt hoặc hợp nhất.
- Viết đề xuất ROI: Viết một đề xuất nửa trang xin thêm 2 kỹ sư (hoặc một công cụ), diễn đạt hoàn toàn bằng ngôn ngữ giá trị kinh doanh: chi phí là bao nhiêu, mở khóa/tiết kiệm được gì, rủi ro nếu không làm. Đưa cho một đồng nghiệp phi kỹ thuật đọc — họ có thấy thuyết phục không?
Tóm tắt
Ngân sách engineering không phải việc của riêng bộ phận tài chính — nó là một phần trách nhiệm cốt lõi của bất kỳ ai lãnh đạo kỹ thuật. Ba nhóm chi phí cần nắm: headcount (70–85%, và luôn tính fully-loaded cost chứ không phải lương gross), infrastructure (10–20%, theo dõi bằng chi phí đơn vị chứ không chỉ tổng số), và tools (3–8%, nơi lãng phí âm thầm hay ẩn nấp qua trùng lặp và license ma).
Nắm các khái niệm nền: OpEx vs CapEx, burn rate và runway, top-down vs bottom-up budgeting. Xây quy trình sáu bước: lập bản đồ chi tiêu, xác định cost drivers, dự phóng theo kịch bản, ưu tiên và cắt phần thừa, trình bày bằng ngôn ngữ kinh doanh, và theo dõi liên tục.
Quan trọng nhất, ba tình huống thực tế cho thấy một bài học chung: người lãnh đạo hiểu ngân sách không phải người tiết kiệm nhất, mà là người biết đầu tư đúng chỗ và diễn đạt nhu cầu kỹ thuật bằng ngôn ngữ ROI. Khi bạn làm được điều đó, bạn không còn là "người xin tiền" mà trở thành đối tác được ban giám đốc tin cậy. Đó là bước trưởng thành từ một kỹ sư giỏi thành một nhà lãnh đạo kỹ thuật thực thụ.