Khoe khoang vụ scale team lên 50 mạng trong 6 tháng. Oai đấy. Nhưng bê cái P&L đặt lên bàn cho nhà đầu tư xem, thứ đập vào mắt họ chỉ là cái máy đốt tiền.
Kịch bản quen thuộc cực kỳ. Gọi vốn Series A xong, tiền về. Phản xạ đầu tiên của đa phần founder là xách giỏ đi lùa người. Bế nguyên cụm 15 dev sang. Đắp thêm 3 PO, 2 QA cho đủ mâm. Giăng cái bảng “go fast and break things” to đùng. Quyết đập đi xây lại hệ thống đang lết bết từ thời seed.
Nhìn ánh mắt rực sáng của bạn, mình chỉ muốn hỏi đúng một câu: “Tháng trước team 5 người của em ship 3 tính năng. Tháng này 20 người, em tính ship bao nhiêu?”
Dự đoán. Thực tế thì sau một tháng onboarding sấp mặt, team 20 người đó ship được đúng 1 tính năng. Cả tháng trôi vào họp sync requirement, vào việc QA dò lại đống lỗi cũ, vào chuyện dev cũ conflict code với dev mới. Đến tuần thứ ba thì Slack bắt đầu có mùi thuốc súng.
Cái bẫy này mình gặp đi gặp lại, ở startup lẫn ở công ty đã vài trăm người: Bệnh cuồng headcount.
Khi sự đông đúc là biểu tượng của quyền lực
Ở ta, thước đo ngầm cho một người quản lý vẫn là số lính dưới trướng. Quản 5 người thì là manager. Quản 50 người thì đã là Giám đốc. Có 200 lính thì thành V.I.P, đi đâu cũng có người xách cặp. Và cái tôi thì được vỗ về mỗi ngày: văn phòng đông nghịt, tiếng gõ phím lạch cạch, All-hands kín cả hội trường.
Xưa, mình cũng từng rơi vào cái bẫy cảm xúc này. Nhìn sơ đồ tổ chức phòng ban mình to lên mỗi quý, cảm giác quyền lực nó dễ gây nghiện lắm. Giờ chỉ muốn rất ít, càng ít report line càng thích.
Thời trước 2023, điều này có thể hiểu được. Headcount là rào cản gia nhập. Bạn muốn code nhanh hơn? Thuê thêm code. Bạn muốn test kỹ hơn? Thuê thêm QA. Sức mạnh của công ty công nghệ tỷ lệ thuận với số lượng kỹ sư họ có thể gom được vào một tòa nhà.
Nhưng 2026 rồi. AI đã nằm trong hầu hết các khâu làm sản phẩm, và bộ máy phình to bây giờ không nói lên sức mạnh. Nó nói lên là bạn chậm. Và nó ăn tiền của bạn đều đặn mỗi tháng, kể cả những tháng chẳng ship được gì.
The Theory: Lầm tưởng về AI như một chiếc bàn phím chỉ cần gõ là tốc độ tăng siêu tốc.
Khi nói về AI trong Product Development, đa số các C-level và Tech Lead ngoài kia đều hiểu sai bản chất. Họ coi Github Copilot, Cursor hay các hệ thống AI Orchestrator như một cái bàn phím gõ nhanh hơn. Tư duy của họ rất tuyến tính: Dev ngày xưa gõ 100 dòng code một giờ, giờ có AI gõ được 500 dòng.
Ngon ơ, nhiều Founder nghĩ. “Vậy thì giữ nguyên team 20 người, mua thêm cho mỗi ông một cái license AI 20 đô một tháng, năng suất sẽ tăng gấp 5 lần!”
Rồi ba tháng sau nhìn lại. Năng suất không tăng gấp 5. Có team còn tụt. Code merge vào thì rác, technical debt chất lên, mà anh em thì mệt hơn hẳn hồi chưa có AI.
Lý do đơn giản: bottleneck của làm phần mềm chưa bao giờ là tốc độ gõ. Nó là tốc độ hiểu nhau. Hiểu bài toán kinh doanh, rồi chốt được với nhau một phương án và không lật lại vào tuần sau. AI gõ hộ bạn thật, nhưng nó không làm 20 con người kia hiểu ý nhau nhanh hơn.
The Breaking Point: Chi phí chìm của Agile Theater
Hãy quay lại bài toán cơ bản của kỹ nghệ phần mềm: Định luật Brooks (trong cuốn The Mythical Man-Month năm 1975, vẫn đúng sau 50 năm). Cứ thêm một người vào một dự án đang chậm tiến độ, dự án đó càng chậm hơn. Mình không có số liệu ngành để dẫn ở đây, chỉ có số của chính mình: mấy squad quá 8 người mà mình từng quản, cycle time từ lúc commit đến lúc lên production luôn dài hơn hẳn squad 3-5 người, dù làm cùng một loại việc. Nhưng đó mới là phần nhìn thấy được. Soi vào P&L thì còn sợ hơn.
Khi bạn có 20 người trong team Product & Tech, bạn không chỉ trả lương cho 20 người. Bạn đang phải cõng một đống Operational Expenditure (OpEx) tàng hình:
Ma trận giao tiếp: 20 người đồng nghĩa với 190 đường dây giao tiếp chéo nhau công thức N*(N-1)/2. Nếu không quản trị khéo, 190 đường dây này sẽ biến thành 190 kênh cãi lộn mỗi ngày.
Thuế hội họp: Buổi planning, buổi grooming, mỗi buổi ba tiếng, phần lớn thời gian dành cho việc cãi xem nút kia màu xanh hay màu đỏ.
Thuế chờ đợi: Mười giờ đêm Slack vẫn sáng đèn: “Anh ơi API này bao giờ xong?”, “Em ơi spec chỗ này chưa rõ, confirm giúp em”. Dev chờ QA, QA chờ PO duyệt, PO chờ sếp trả lời tin nhắn. Chuỗi đó đứt ở mắt xích nào cũng được, và gần như ngày nào cũng đứt.
Layer quản lý trung gian: Scrum Master, Agile Coach, Delivery Manager... những người mà việc chính là đảm bảo 20 con người kia không giẫm chân lên nhau.
Nuôi nguyên một cái rạp hát Agile để phục vụ cho sự đông đúc đó, rồi tự nhủ là team mình làm việc có quy trình.
Trong lúc đó, đâu đó có một team 3 người với vài con AI đang lặng lẽ ăn dần thị trường của bạn.
Họ thắng vì gần như không có độ trễ giao tiếp. Hai Senior Engineer và một PM cứng nghề, ngồi chung phòng hoặc chung một kênh Discord. Cursor lo phần boilerplate, AI agent viết unit test và review pull request rồi đẩy thẳng lên CI/CD. Không có PRD 50 trang, vì người viết spec cũng là người code, và người đó hiểu business đến tận cùng. Nói vậy không có nghĩa là họ nhàn. Họ vẫn cày, chỉ là cày vào đúng việc chứ không cày vào việc giải thích cho nhau nghe.
Phản biện tý: Nhưng AI hay bị ngáo, sao làm được hệ thống lớn?
Đến đây, chắc chắn sẽ có những bác Tech Lead nhảy dựng lên: “Anh xạo! Em thử dùng mấy con AI rồi, toàn code rác, bịa đặt hallucination từ lưa. Đưa nó làm core banking hay hệ thống thanh toán có mà sập server à? Vẫn phải cần QA chạy tay, cần team 20 người review chéo nhau thôi!”
Mình từng nghĩ y hệt, khoảng hai năm trước. Cái sai không nằm ở chỗ đánh giá AI thấp, mà ở chỗ đang dùng nó như một thực tập sinh: giao việc xong rồi bỏ đó.
Đúng, AI sẽ sinh ra code rác nếu bạn quăng cho nó một cái prompt hời hợt kiểu “Làm cho tôi cái app giống Tinder”. Nhưng trong tay một Senior Engineer người hiểu rõ architecture, biết cách chia nhỏ bài toán decomposition, biết viết test-driven development (TDD) khắt khe AI trở thành một siêu vũ khí.
Chưa ai bảo AI tự dựng được một hệ thống lớn. Cái đang xảy ra là AI giúp một con người xuất chúng làm được khối lượng công việc của 10 người. Mười bạn junior ráp màn hình thì giờ không cần nữa. Cần một Senior chắc kiến trúc, ngồi đọc lại đống code AI vừa ráp trong ba phút và vặn ngược logic khi thấy sai.
Sự phức tạp của hệ thống lớn không nằm ở số dòng code, nó nằm ở cấu trúc. Và cấu trúc thì cần một cái đầu có sạn của con người, chứ không cần 20 đôi bàn tay gõ phím.
The Patch: Framework Cắt giảm OpEx
Vậy gỡ bằng cách nào. Dưới đây là mấy thứ mình đang làm và thấy có tác dụng. Không phải framework gì to tát, và cũng không chắc hợp với mọi công ty.
Hãy bấm theo dõi để đọc miễn phí nhé.
Want to see the rest of this awesome Post ?
Just hit that subscribe button for free to unlock the full post!
T.D,
T9.2026
P/s : 3 Người / 20 Người : là khái niệm 3 nhóm việc với chuyên môn cao, ko phải đại diện số lượng mà nhân sự thay thế 20 người. 20 Người ý việc 1 việc cần nhiều người làm dù có thể làm bởi 1 nhóm nhỏ hơn.
co vẻ như câu chuyện gọi vốn xong để scale team lên đang dần chuyển thành dùng vốn đó đầu tư vào AI sao cho hiệu quả mà vẫn chỉ cần duy trì những nhân sự cốt cán như ban đầu
Hi anh, bức tranh sau cùng thì quả là đẹp và là kỳ vọng của nhiều team startup, team em cũng hướng đến như vậy; team 20 người nhưng không kỳ vọng là cắt còn 3 người mà là hiệu suất của 20 người đó x5 x10. Tuy nhiên, là startup nên team chỉ có anh em developer từ junior đến mid, 2-3 Senior (mà là chập chững senior vì đi với công ty lâu dài từ khi còn junior); tư duy của mọi người vẫn còn khá là "thợ gia công" và việc áp dụng AI của mọi người cũng chỉ là khuếch đại năng lực hiện tại chứ chưa có tinh thần chuyển đổi sang năng lực mới.
Ngoài ra, AI quá mới và thay đổi quá nhanh; việc tìm kiếm người mới có được mindset và skillset sử dụng AI cũng rất rất hạn chế
Là một PM (Product) trong Core của công ty, em vẫn chưa biết cách tạo ra môi trường hoặc động lực cho anh em. Anh có ý kiến hay có thể chia sẻ thêm về phần này không ạ? Em cảm ơn