Mở đầu — vì sao bài này quan trọng
Bạn đã từng nghe câu chuyện này chưa: một startup fintech ở TP.HCM tăng từ 30 lên 120 kỹ sư trong vòng 18 tháng. Về mặt con số, đây là một thành công vang dội. Nhưng bên trong, mọi thứ bắt đầu rệu rã. Có manager phải kèm 14 người, không còn thời gian làm 1-1 tử tế, review code hay coaching. Ngược lại, có "manager" khác chỉ quản đúng 1 kỹ sư — thực chất là một vị trí được vẽ ra để giữ chân một người senior không muốn mất. Quyết định từ CEO xuống đến kỹ sư phải đi qua bảy tầng, mất trung bình mười ngày để phê duyệt một thay đổi nhỏ.
Đây chính là bài toán của Org Design — thiết kế tổ chức. Ở các bài trước bạn đã học về Team Topologies (các loại team) và Conway Law (cấu trúc tổ chức định hình kiến trúc sản phẩm). Bài này đi sâu vào hai đòn bẩy kỹ thuật nhất, cũng dễ đo lường nhất, của org design: Span of Control (số người báo cáo trực tiếp cho mỗi manager) và Layers (số tầng quản lý từ trên xuống dưới).
Vì sao hai chỉ số này quan trọng đến vậy? Vì chúng quyết định trực tiếp ba thứ: tốc độ ra quyết định, chất lượng quản lý con người, và chi phí tổ chức. Một tổ chức có span quá hẹp và quá nhiều layer sẽ chậm chạp, quan liêu, đắt đỏ. Một tổ chức có span quá rộng sẽ bỏ rơi con người, manager kiệt sức, chất lượng công việc trôi tuột. Nắm được cách cân bằng hai chỉ số này là kỹ năng nền tảng của bất kỳ ai làm quản lý ở quy mô lớn — dù bạn là Team Lead, EM, hay Director.
Khái niệm cốt lõi
Span of Control là gì
Span of Control (tạm dịch: phạm vi kiểm soát) là số lượng direct report — người báo cáo trực tiếp — mà một manager quản lý. Nếu bạn là Engineering Manager và có 6 kỹ sư báo cáo trực tiếp cho bạn, span của bạn là 6.
Đây không phải con số tùy tiện. Mỗi direct report tiêu tốn một "ngân sách chú ý" của manager: 1-1 định kỳ, coaching, feedback, review công việc, gỡ vướng, phát triển sự nghiệp. Khi span vượt ngưỡng, manager không còn đủ băng thông để làm tốt những việc đó, và chất lượng quản lý con người sụt giảm — thường là âm thầm cho đến khi có người nghỉ việc.
Các mức span lý tưởng theo vai trò (đây là khoảng tham chiếu phổ biến trong ngành công nghệ, không phải luật bất biến):
| Vai trò | Span lý tưởng | Ghi chú |
|---|---|---|
| Engineering Manager (EM) | 5–8 | Người quản lý trực tiếp IC (individual contributors) |
| Senior EM / Manager of Managers | 4–6 | Quản lý các EM khác |
| Director | 4–7 | Quản lý các Senior EM/Manager |
| VP Engineering | 5–8 | Quản lý các Director |
Manager mỏng và manager dày (thin vs broad span)
- Span quá hẹp (< 4): Manager có quá ít người quản, dễ dẫn đến micromanagement (quản lý vi mô, soi từng chi tiết), và tổ chức phình layer không cần thiết. Một "manager của một người" gần như luôn là dấu hiệu cảnh báo.
- Span quá rộng (> 9–10): Manager không đủ thời gian cho từng người. 1-1 bị bỏ, feedback qua loa, coaching biến mất. Kỹ sư cảm thấy bị bỏ rơi và bắt đầu tự vận hành theo kiểu "ai lo phận nấy".
Layers là gì
Layers (tầng quản lý) là số cấp bậc quản lý từ đỉnh tổ chức xuống đến IC ở đáy. Ví dụ chuỗi: CEO → VP Eng → Director → EM → Kỹ sư. Đây là tổ chức 4 layer quản lý (không tính IC ở tầng cuối).
Số layer quyết định:
- Tốc độ ra quyết định: mỗi layer là một trạm dừng thông tin. Càng nhiều layer, quyết định càng chậm và càng bị "tam sao thất bản".
- Khoảng cách giữa lãnh đạo và thực địa: CEO ở layer 0 khó nắm được điều gì đang thực sự xảy ra ở đáy nếu phải qua 6 tầng trung gian.
- Chi phí: mỗi layer quản lý là chi phí lương không trực tiếp tạo ra sản phẩm.
Mối quan hệ toán học: span rộng → ít layer
Đây là điểm mấu chốt mà nhiều người bỏ qua. Span và Layers có quan hệ nghịch đảo về mặt toán học. Với cùng một số lượng nhân sự, span càng rộng thì càng cần ít layer, và ngược lại.
Hãy làm phép tính đơn giản với tổ chức 100 kỹ sư:
- Span = 5: Bạn cần 20 EM (100 / 5). Rồi 20 EM này cần khoảng 4 Director (20 / 5). Rồi 4 Director cần 1 VP. → Tổng cộng khoảng 4 layer.
- Span = 10: Bạn cần 10 EM (100 / 10). 10 EM cần 1 Director/VP. → Tổng cộng khoảng 2–3 layer.
"The Flat Organization" và giới hạn của nó
Nhiều startup tự hào "chúng tôi tổ chức phẳng, không có sếp". Điều này hoạt động tốt khi công ty dưới 30–50 người (nhớ lại Dunbar Number ở bài trước). Nhưng khi vượt ngưỡng đó, tổ chức "phẳng" thực chất chỉ là span cực rộng ẩn — một hoặc vài người phải quản lý hàng chục người, và họ luôn quá tải. "Phẳng" ở quy mô lớn thường là quan liêu ẩn: quyết định vẫn tắc, chỉ là không ai chính thức chịu trách nhiệm.
Tình huống thực tế
Ví dụ 1 — Startup fintech TP.HCM: bệnh "over-management"
Một công ty fintech tại TP.HCM (gọi là công ty A) tăng trưởng nóng, gọi được vòng Series B. Để "giữ chân nhân tài", họ liên tục thăng chức người giỏi lên làm manager. Kết quả sau 1 năm: 120 kỹ sư nhưng có tới 28 manager, trong đó 9 manager có span từ 1 đến 2 người.
Vấn đề lộ ra khi họ đo tốc độ giao hàng (delivery). Một feature trung bình mất 6 tuần, trong đó chỉ 2 tuần là code — phần còn lại là chờ phê duyệt qua các layer. Tổ chức có tới 6 layer quản lý. Một EM tâm sự: "Tôi quản 2 người, thực ra tôi vẫn code 70% thời gian, nhưng lại phải ngồi trong 4 cuộc họp management mỗi tuần."
Diễn giải: đây là hội chứng "thăng chức để giữ người" tạo ra span hẹp giả tạo và layer thừa. Mỗi manager thừa là một trạm dừng thông tin, một cuộc họp thêm, một chữ ký cần chờ.
Bài học: Đừng biến quản lý thành phần thưởng. Công ty A sau đó gộp lại còn 15 manager (span trung bình ~8), cắt xuống 4 layer, và đưa những người từng làm "manager 1 người" trở về track kỹ thuật với danh xưng Staff Engineer (nhớ lại: lattice không phải ladder — chúng ta sẽ học ở bài sau). Thời gian giao feature giảm còn 3.5 tuần.
Ví dụ 2 — Tiki và bài toán span khi mở rộng nhiều dòng sản phẩm
Giả định một tình huống điển hình tại một công ty e-commerce lớn kiểu Tiki/Shopee VN. Khi công ty mở rộng từ chỉ "sàn thương mại điện tử" sang thêm logistics, fintech (ví điện tử), và quảng cáo, họ đối mặt câu hỏi: mỗi Director nên quản bao nhiêu EM?
Ban đầu, một Director phụ trách toàn bộ Engineering của mảng logistics quản 9 EM. Span 9 đối với một Director là quá rộng — vì công việc của Director không chỉ là 1-1 với 9 EM, mà còn là điều phối chiến lược, làm việc với các mảng khác, xử lý dependency. Kết quả: Director này liên tục là bottleneck, các EM phàn nàn "không bao giờ đặt được lịch với sếp".
Diễn giải: span lý tưởng của Director thấp hơn EM (4–7) chính vì công việc của họ nặng tính điều phối và chiến lược, chứ không chỉ quản lý con người. Áp span của EM lên Director là sai lầm phổ biến.
Bài học: Công ty tách mảng logistics thành 2 nhóm (first-mile và last-mile), mỗi nhóm một Senior EM/Director với span 5 EM. Điều này thêm một chút cấu trúc nhưng giải phóng bottleneck. Span phải điều chỉnh theo bản chất công việc của từng layer, không dùng một con số cho tất cả.
Ví dụ 3 — Cú "de-layering" kinh điển của một tập đoàn công nghệ
Năm 2022–2023, nhiều Big Tech (điển hình là Meta với chiến dịch "Year of Efficiency") công khai tuyên bố mục tiêu giảm số layer quản lý và tăng span. Zuckerberg nói thẳng: "một manager quản lý ba người quản lý ba người thì không hiệu quả" — hàm ý những manager có span quá hẹp cần được yêu cầu quay lại làm công việc thực chất (IC) hoặc bị tinh giản.
Con số họ nhắm tới: đẩy span của nhiều manager lên khoảng 8–10, và cắt bỏ các layer "manager của manager của manager" mà mỗi tầng chỉ có 2–3 report.
Diễn giải: khi tăng trưởng chậm lại, chi phí của org design lỏng lẻo lộ rõ. Layer thừa và span hẹp là nơi "mỡ thừa" tích tụ nhiều nhất trong thời kỳ tăng trưởng nóng.
Bài học: Org design không phải làm một lần rồi thôi. Nó cần được rà soát định kỳ (thường mỗi 6–12 tháng). Trong giai đoạn tăng trưởng nóng, span có xu hướng tự thu hẹp và layer tự phình ra nếu không ai kiểm soát — vì thăng chức và tuyển manager dễ hơn là tổ chức lại.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng để đánh giá và thiết kế lại span/layers cho tổ chức của mình.
Bước 1 — Vẽ org chart thật và đếm. Không dùng org chart "trên giấy tờ" mà dùng thực tế: ai thực sự báo cáo cho ai. Với mỗi manager, ghi ra span (số direct report). Với toàn tổ chức, đếm số layer từ đỉnh xuống IC thấp nhất.
Bước 2 — Đánh dấu các điểm bất thường. Khoanh đỏ:
- Manager có span < 3 (quá hẹp, có thể là layer thừa).
- Manager có span > 9 (quá rộng, có thể bỏ rơi người).
- Bất kỳ chuỗi nào có layer chỉ toàn "manager của manager" với span 1–2.
Bước 4 — Tính lại số layer mục tiêu. Dùng công thức thô: số layer ≈ log(tổng số người) / log(span trung bình). Với 100 người và span 6, bạn cần khoảng 2.5 → làm tròn 3 layer quản lý. Đặt đây làm mục tiêu.
Bước 5 — Xử lý span hẹp trước. Với mỗi "manager 1–2 người", hỏi: (a) có thể gộp nhóm này với nhóm khác không? (b) người này có nên quay về làm IC (Staff/Principal track) không? Đây thường là nguồn cắt giảm layer lớn nhất và ít đau đớn nhất.
Bước 6 — Xử lý span rộng. Với manager quá tải (span > 9), tách nhóm và bổ nhiệm/tuyển thêm một manager. Lưu ý: đừng thăng chức vội một junior lên để giải quyết — chọn người thực sự có năng lực và ý chí quản lý.
Bước 7 — Truyền thông và theo dõi. Thay đổi org luôn nhạy cảm. Giải thích rõ vì sao (tốc độ, chất lượng quản lý), không để mọi người nghĩ đây là đợt "trảm tướng". Sau 3 tháng, đo lại: tốc độ giao hàng, kết quả engagement survey, tỷ lệ 1-1 được thực hiện.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi span là con số vàng cố định. "EM phải quản đúng 7 người" là tư duy sai. Span phụ thuộc độ trưởng thành đội ngũ, độ phức tạp công việc, và giai đoạn công ty. Dùng khoảng, không dùng con số cứng.
Lỗi 2 — Thăng chức để giữ người, tạo manager giả. Đây là nguyên nhân số một của span hẹp và layer thừa ở startup. Giải pháp: xây dual-track (kỹ thuật và quản lý song song) để người giỏi có đường thăng tiến mà không cần làm manager.
Lỗi 3 — Áp span của EM lên các layer cao hơn. Director và VP có công việc khác về bản chất (điều phối, chiến lược). Span của họ thường thấp hơn hoặc bằng EM, và mỗi report tốn nhiều "trọng lượng" hơn.
Lỗi 4 — Sùng bái "tổ chức phẳng". Phẳng chỉ đúng dưới ~50 người. Vượt ngưỡng đó, "phẳng" thường là span rộng ẩn không ai chịu trách nhiệm. Đừng dùng "phẳng" như một cái cớ để né việc thiết kế cấu trúc.
Lỗi 5 — Chỉ tối ưu một chiều. Cắt layer tối đa để "nhanh" nhưng đẩy span lên 15 khiến manager kiệt sức — cũng tệ như thái cực ngược lại. Luôn nhìn cả hai chỉ số cùng lúc.
Mẹo — "Quy tắc 7±2". Một heuristic dễ nhớ: hầu hết manager vận hành tốt với 5–9 direct report. Dưới 5 hãy tự hỏi "layer này có thừa không?"; trên 9 hãy tự hỏi "người của tôi có đang bị bỏ rơi không?".
Mẹo — Đo bằng dữ liệu, không bằng cảm giác. Hai chỉ số dễ theo dõi: tỷ lệ 1-1 thực hiện đúng lịch (nếu tụt, có thể span đang quá rộng) và số bước phê duyệt trung bình cho một quyết định (nếu cao, có thể quá nhiều layer).
Bài tập thực hành
- Tự chẩn đoán tổ chức của bạn. Vẽ org chart nhóm/công ty bạn đang làm. Với mỗi manager, ghi span. Đếm tổng số layer. Khoanh đỏ mọi span < 3 và > 9. Bạn thấy bao nhiêu điểm bất thường?
- Bài toán 80 kỹ sư. Bạn được giao thiết kế org cho một team engineering 80 người, gồm 60 kỹ sư trung cấp và 20 senior tự chủ cao. Hãy đề xuất: số EM, span trung bình, số Director, và tổng số layer. Giải thích lựa chọn span cho nhóm senior khác nhóm trung cấp thế nào.
- Đánh đổi span vs layer. Với 100 người: hãy tính số layer nếu span = 4, nếu span = 6, và nếu span = 10. Viết một đoạn ngắn (5 câu) lập luận: nếu công ty bạn ưu tiên tốc độ ra quyết định, bạn chọn cấu hình nào và chấp nhận đánh đổi gì?
- Xử lý manager 1 người. Trong tổ chức ví dụ, có một Staff Engineer giỏi đang "quản" đúng 1 kỹ sư junior. Đề xuất 2 phương án giải quyết span hẹp này mà không làm mất lòng người Staff Engineer đó.
Tóm tắt
- Span of Control là số direct report của một manager. Khoảng tham chiếu: EM 5–8, Director 4–7, VP 5–8. Điều chỉnh theo độ trưởng thành đội ngũ — team senior chịu được span rộng, team junior cần span hẹp.
- Layers là số tầng quản lý từ đỉnh xuống IC. Nhiều layer = quyết định chậm, xa thực địa, chi phí cao.
- Span và Layers nghịch đảo nhau về mặt toán học. Muốn tổ chức phẳng (ít layer) thì buộc phải span rộng, và ngược lại. Org design là nghệ thuật đánh đổi có ý thức giữa hai thái cực.
- Hai bệnh phổ biến: span hẹp giả (thăng chức để giữ người → manager 1–2 người → layer thừa) và span quá rộng (manager kiệt sức, bỏ rơi con người).
- "Tổ chức phẳng" chỉ đúng dưới ~50 người; vượt ngưỡng đó thường là span rộng ẩn.
- Rà soát org định kỳ (6–12 tháng). Xử lý span hẹp trước (gộp nhóm, đưa về track kỹ thuật), rồi mới xử lý span rộng (tách nhóm, thêm manager).
- Đo bằng dữ liệu: tỷ lệ 1-1 thực hiện, số bước phê duyệt trung bình — chứ đừng thiết kế org bằng cảm giác.