Mở đầu — vì sao bài này quan trọng
Ở bài trước, chúng ta đã hiểu rằng tăng trưởng không phải lúc nào cũng tuyến tính: thêm người không đồng nghĩa với thêm năng suất. Nhưng câu hỏi tự nhiên tiếp theo là: vậy đâu là những "ngưỡng" cụ thể mà một tổ chức bắt đầu gãy vỡ? Vì sao một team 8 người vận hành trơn tru như một cỗ máy đồng bộ, nhưng khi lên 25 người thì đột nhiên mọi thứ trở nên rối loạn, họp hành liên miên, thông tin thất lạc, và không ai còn biết ai đang làm gì?
Câu trả lời phần lớn nằm ở một khái niệm đến từ nhân chủng học tiến hóa chứ không phải từ khoa học quản trị: Dunbar Number. Đây là một trong những "hằng số ẩn" chi phối cách con người hình thành nhóm, và nếu bạn là một leader đang scale team, việc hiểu các ngưỡng của Dunbar sẽ giúp bạn dự đoán trước khi nào cần thay đổi cấu trúc — thay vì chờ đến lúc mọi thứ đổ vỡ rồi mới chữa cháy.
Bài này không nói về cách thiết kế loại team nào (đó là các bài sau về Team Topologies), mà tập trung vào một câu hỏi nền tảng hơn: con người có giới hạn sinh học về số lượng quan hệ có thể duy trì, và giới hạn đó tác động trực tiếp đến quy mô nhóm mà bạn có thể vận hành hiệu quả. Hiểu đúng điều này, bạn sẽ ngừng chống lại tự nhiên và bắt đầu thiết kế tổ chức thuận theo nó.
Khái niệm cốt lõi
Dunbar Number là gì
Vào đầu thập niên 1990, nhà nhân chủng học người Anh Robin Dunbar nghiên cứu mối tương quan giữa kích thước não bộ (cụ thể là vỏ não mới — neocortex) của các loài linh trưởng và quy mô nhóm xã hội trung bình của chúng. Ông phát hiện một quy luật khá rõ: loài nào có neocortex càng lớn thì sống trong nhóm càng đông. Khi ngoại suy công thức này cho bộ não người, con số ước tính rơi vào khoảng 150.
Con số 150 này — thường gọi là Dunbar Number — được diễn giải là số lượng mối quan hệ ổn định (stable relationships) mà một người bình thường có thể duy trì cùng lúc. "Ổn định" ở đây có nghĩa: bạn biết người đó là ai, biết vai trò của họ, biết mối liên hệ giữa họ với những người khác trong nhóm, và bạn có thể tương tác với họ mà không cần "làm quen lại từ đầu".
Điểm mấu chốt cần hiểu: 150 không phải là số người bạn biết mặt, cũng không phải số danh bạ điện thoại hay số bạn bè Facebook. Nó là giới hạn của mạng lưới quan hệ mà bạn có thể theo dõi được bằng trực giác xã hội, không cần đến quy trình chính thức. Dunbar mô tả nó một cách rất đời thường: đó là số người mà bạn sẽ không thấy ngượng nếu bất ngờ ngồi chung bàn nhậu với họ mà không được mời trước.
Các Tier (tầng) của Dunbar
Sai lầm phổ biến là chỉ nhớ mỗi con số 150. Thực ra Dunbar mô tả một chuỗi các vòng tròn đồng tâm, mỗi vòng ứng với một mức độ thân thiết và "chi phí duy trì" khác nhau. Đây mới là phần thực sự hữu ích cho việc scale team:
- ~5 — Vòng thân cận (support clique): Đây là những người gần gũi nhất, bạn tin tưởng tuyệt đối và sẵn sàng tìm đến khi khủng hoảng. Trong công việc, đây là quy mô của một team làm việc trực tiếp hằng ngày mà mọi người hiểu nhau đến mức gần như không cần nói cũng biết ý.
- ~15 — Vòng thân thiết (sympathy group): Nhóm những người mà mất họ bạn sẽ thực sự đau lòng. Về mặt tổ chức, đây là quy mô mà một người quản lý có thể thực sự gần gũi và nắm bắt sâu từng cá nhân. Đây cũng là lý do nhiều người cho rằng một manager tốt không nên quản lý trực tiếp quá 15 người.
- ~50 — Vòng nhóm (band): Quy mô của một "bộ tộc nhỏ" trong thời săn bắt hái lượm. Ở mức này, mọi người vẫn còn cảm giác thuộc về một cộng đồng chung, biết tên và vai trò của nhau, ăn trưa cùng nhau. Đây là ngưỡng mà một tổ chức vẫn có thể vận hành khá tự nhiên mà không cần nhiều lớp quản lý.
- ~150 — Vòng bộ lạc (clan / Dunbar's Number): Giới hạn của một cộng đồng có thể vận hành dựa trên quan hệ cá nhân và lòng tin, thay vì dựa trên luật lệ, quy trình và cấu trúc phân cấp. Vượt qua 150, bạn buộc phải thay thế "sự tin tưởng lẫn nhau" bằng "hệ thống chính thức".
- ~500 và ~1500 — Vòng ngoài: Đây là những người bạn nhận ra mặt (500) và những người bạn chỉ nhận ra tên (1500). Trong tổ chức, đây là quy mô mà bạn hoàn toàn phải dựa vào cấu trúc, phòng ban, và định danh chính thức để phối hợp.
Vì sao ngưỡng 150 lại "gãy" trong tổ chức
Khi một tổ chức còn dưới 150 người, mọi người vẫn có thể phối hợp chủ yếu qua kết nối trực tiếp: bạn cần gì thì đi hỏi thẳng người biết việc đó, vì bạn biết họ là ai. Chi phí điều phối thấp vì "bản đồ tổ chức" nằm sẵn trong đầu mọi người.
Khi vượt 150, bản đồ đó không còn nằm gọn trong đầu ai được nữa. Bạn bắt đầu gặp người trong công ty mà không biết họ làm gì, họ báo cáo cho ai, dự án của họ liên quan gì đến bạn. Lúc này, để không hỗn loạn, tổ chức buộc phải "cấy" thêm các cơ chế nhân tạo: sơ đồ tổ chức chính thức, quy trình onboarding bài bản, hệ thống tài liệu, quy tắc ra quyết định rõ ràng. Nói cách khác, Dunbar Number chính là ranh giới nơi văn hóa "gia đình" phải chuyển hóa thành văn hóa "thể chế".
Tình huống thực tế
Ví dụ 1 — Gore-Tex và quy tắc "150 người thì tách nhà máy"
W. L. Gore & Associates — công ty đứng sau vật liệu Gore-Tex nổi tiếng — là ví dụ kinh điển được chính Robin Dunbar nhắc đến. Nhà sáng lập Bill Gore nhận thấy một điều qua thực tế vận hành: mỗi khi một nhà máy vượt quá khoảng 150 nhân viên, hiệu quả và tinh thần bắt đầu sa sút. Mọi người không còn biết nhau, các phe nhóm hình thành, và cái cảm giác "tất cả chúng ta cùng một đội" biến mất.
Giải pháp của Gore không phải là thêm tầng quản lý, mà là tách đôi: khi một cơ sở chạm ngưỡng ~150 người, họ xây một nhà máy mới bên cạnh và chia người ra. Nhờ vậy, mỗi đơn vị luôn giữ được quy mô mà mọi người còn biết mặt biết tên nhau, còn phối hợp được bằng quan hệ trực tiếp thay vì mệnh lệnh hành chính.
Bài học rút ra: Thay vì cố gắng "quản lý" một khối người khổng lồ, đôi khi giải pháp scale tốt nhất là chia nhỏ thành các đơn vị tự chủ nằm dưới ngưỡng Dunbar. Quy mô nhỏ không phải là điểm yếu — nó là công cụ giữ cho phối hợp diễn ra tự nhiên.
Ví dụ 2 — Một startup fintech Việt Nam vỡ trận ở mốc 40 người
Hãy hình dung một startup fintech ở TP.HCM — gọi là "PayViet" cho dễ theo dõi. Khi còn 12 người, họ vận hành như một gia đình: mọi quyết định ra ở bàn ăn trưa, ai cũng biết roadmap, ai cũng biết vì sao một feature được ưu tiên. Không có quy trình, và cũng không cần — vì mọi thứ nằm trong đầu mọi người.
Sau vòng gọi vốn, PayViet tuyển ồ ạt để lên 40 người trong 6 tháng. Vấn đề bắt đầu: engineer mới không biết hỏi ai khi vướng, vì không còn ai "biết hết mọi thứ". Hai team làm trùng một tính năng suốt ba tuần mà không ai phát hiện. CEO than phiền rằng mình phải ngồi trong 6 tiếng họp mỗi ngày chỉ để "kết nối các mảnh thông tin" — vì anh vô tình trở thành bộ định tuyến (router) duy nhất của cả công ty.
Điều PayViet gặp phải chính là hiện tượng vượt tier ~15 và tiến gần tier ~50: mạng lưới quan hệ trực tiếp đã quá tải, nhưng công ty chưa kịp xây dựng các cơ chế thay thế. Khi họ chia thành các squad 6–8 người có quyền tự quyết, mỗi squad có một tài liệu định hướng riêng, và thiết lập một kênh cập nhật định kỳ giữa các squad, sự hỗn loạn giảm hẳn trong vòng một quý.
Bài học rút ra: Khủng hoảng của PayViet không phải do tuyển sai người, mà do họ scale số lượng nhanh hơn tốc độ xây dựng cấu trúc. Ngưỡng Dunbar đến sớm hơn nhiều so với con số 150 huyền thoại — vì đối với việc phối hợp công việc hằng ngày, cái ngưỡng thực sự nằm ở tier 5–15–50, chứ không phải 150.
Ví dụ 3 — Amazon và "Two-Pizza Team"
Jeff Bezos đưa ra một nguyên tắc nổi tiếng ở Amazon: một team lý tưởng phải nhỏ đến mức hai chiếc pizza là đủ cho cả nhóm ăn — tức khoảng 6 đến 8 người. Lý do không phải để tiết kiệm pizza, mà vì Bezos nhận ra rằng chi phí giao tiếp trong nhóm tăng phi tuyến theo số người: nhóm càng đông, thời gian dành cho điều phối càng nuốt mất thời gian làm việc thật.
Con số 6–8 này rơi rất gần tier ~5 của Dunbar — vòng thân cận, nơi mọi người có thể phối hợp gần như bằng trực giác, không cần họp hành hình thức, không cần tài liệu dày cộp để hiểu nhau. Đây chính là lý do các "two-pizza team" của Amazon có thể ra quyết định nhanh và sở hữu trọn vẹn (own) sản phẩm của mình.
Bài học rút ra: Nếu bạn muốn tốc độ và quyền tự chủ, hãy giữ đơn vị làm việc cốt lõi ở quy mô tier-5 (5–8 người). Khi cần lớn hơn, đừng phình một team ra, hãy nhân bản thành nhiều team nhỏ.
Hướng dẫn từng bước
Dưới đây là cách áp dụng tư duy Dunbar khi bạn đang scale một tổ chức:
Bước 1 — Xác định tổ chức của bạn đang ở tier nào. Đếm số người thực tế và soi vào các ngưỡng: dưới 15, khoảng 15–50, khoảng 50–150, hay đã vượt 150. Mỗi vùng đòi hỏi một "chế độ vận hành" khác nhau.
Bước 2 — Đối chiếu quy mô với cơ chế điều phối hiện có. Hỏi thẳng: chúng ta đang phối hợp bằng quan hệ cá nhân hay bằng cấu trúc chính thức? Nếu bạn đã quá 50 người mà vẫn "mọi người tự đi hỏi nhau", bạn đang chạy quá tải và một cuộc khủng hoảng điều phối chỉ còn là vấn đề thời gian.
Bước 3 — Giữ đơn vị cốt lõi ở tier-5 đến tier-15. Thiết kế team làm việc trực tiếp ở quy mô 5–8 người (tier thân cận), và không để một manager quản lý trực tiếp quá ~15 người (tier thân thiết). Đây là hai ngưỡng bạn nên bảo vệ quyết liệt nhất.
Bước 4 — Nhóm các team thành "band" ~50. Khi có nhiều team nhỏ, hãy gom chúng thành các nhóm lớn hơn khoảng 50 người (một bộ phận, một product line). Ở quy mô này mọi người vẫn còn cảm giác thuộc về nhau, nên cần rất ít lớp quản lý trung gian.
Bước 5 — Chuẩn bị "hệ thống chính thức" TRƯỚC khi chạm 150. Đừng đợi đến khi đủ 150 người mới xây quy trình. Hãy bắt đầu đầu tư vào tài liệu, quy tắc ra quyết định, và cách định danh vai trò rõ ràng từ khi bạn ở khoảng 100–120 người, để quá trình chuyển hóa diễn ra mượt mà.
Bước 6 — Cân nhắc chiến lược "tách tế bào" (cell division). Giống Gore, khi một đơn vị chạm ngưỡng của tier tương ứng, hãy tính đến việc tách nó thành hai đơn vị tự chủ thay vì để nó phình to mãi.
Lỗi thường gặp & mẹo
Lỗi 1 — Coi 150 là một con số phép màu và áp dụng cứng nhắc. Dunbar Number là một khoảng ước lượng trung bình, không phải ngưỡng chính xác đến từng người. Đừng nói "chúng ta có 149 người nên vẫn ổn". Hãy nhìn vào triệu chứng (thông tin thất lạc, họp tăng vọt, người ta không biết ai làm gì) thay vì chờ chạm đúng con số.
Lỗi 2 — Chỉ nhớ mốc 150 mà quên các tier nhỏ hơn. Trong thực tế vận hành hằng ngày, các ngưỡng đau đớn nhất lại là 5, 15 và 50 — vì đó là nơi năng lực phối hợp trực tiếp bắt đầu quá tải. Nhiều công ty vỡ trận ở mốc 40–60 người chứ chưa cần đến 150.
Lỗi 3 — Tin rằng công cụ số hóa (Slack, danh bạ, Notion) nâng được giới hạn Dunbar. Công nghệ giúp bạn lưu trữ và tra cứu thông tin về nhiều người hơn, nhưng nó không thay được năng lực duy trì quan hệ tin cậy — vốn là bản chất của Dunbar. Đừng nhầm "có thể nhắn tin cho 500 người" với "có thể phối hợp tin cậy với 500 người".
Mẹo 1 — Dùng Dunbar như một "đèn báo sớm". Đặt các mốc 15, 50, 150 làm mốc rà soát cấu trúc tổ chức. Mỗi khi headcount sắp chạm một ngưỡng, hãy chủ động họp lại để thiết kế cơ chế điều phối cho tier tiếp theo.
Mẹo 2 — Bảo vệ "khoảng thân cận" của mỗi người. Đảm bảo mỗi nhân viên đều thuộc về một team tier-5 rõ ràng — nơi họ có 4–7 đồng nghiệp mà họ thực sự gắn bó. Đây là liều thuốc mạnh chống lại cảm giác lạc lõng khi tổ chức lớn lên.
Bài tập thực hành
- Chụp ảnh tổ chức của bạn theo Dunbar. Viết ra tổng số người trong đơn vị bạn đang làm việc, rồi phân loại: đơn vị làm việc trực tiếp của bạn có bao nhiêu người? Manager của bạn quản lý trực tiếp bao nhiêu người? Cả "bộ phận" của bạn có bao nhiêu người? Đối chiếu ba con số này với các tier 5–15–50 và ghi chú xem tier nào đang bị quá tải.
- Truy tìm "người router". Hãy xác định trong tổ chức bạn có ai đang vô tình đóng vai trò "bộ định tuyến thông tin" duy nhất (như CEO của PayViet) không — người mà nếu nghỉ một tuần thì cả nhóm tê liệt. Đề xuất một cơ chế cụ thể để phân tán vai trò đó.
- Kịch bản tách team. Giả sử team của bạn hiện có 9 người và sắp lên 16 người trong quý tới. Hãy phác thảo cách bạn sẽ tách nó thành hai đơn vị tier-5, gồm: ai vào team nào, mỗi team sở hữu mảng công việc gì, và hai team sẽ đồng bộ với nhau qua cơ chế nào.
- Suy ngẫm cá nhân. Liệt kê nhanh khoảng 5 người bạn tìm đến đầu tiên khi gặp khó khăn trong công việc. Đây chính là vòng tier-5 của bạn. Quan sát xem nó nói lên điều gì về cách bạn thực sự đang vận hành, so với sơ đồ tổ chức chính thức.
Tóm tắt
Dunbar Number — con số ~150 do nhà nhân chủng học Robin Dunbar đề xuất dựa trên kích thước neocortex — chỉ ra rằng con người có giới hạn sinh học về số lượng quan hệ ổn định mà mình duy trì được. Nhưng bài học quan trọng hơn nằm ở chuỗi các tier: ~5 (thân cận), ~15 (thân thiết), ~50 (nhóm), ~150 (bộ lạc). Mỗi tier đánh dấu một ngưỡng mà cơ chế phối hợp cũ bắt đầu quá tải và cần được thay bằng cơ chế mới.
Với người scale team, thông điệp cốt lõi là: đừng chống lại giới hạn sinh học này — hãy thiết kế tổ chức thuận theo nó. Giữ đơn vị làm việc cốt lõi ở quy mô "two-pizza" (tier-5), không để manager quản lý quá ~15 người, gom team thành band ~50, và chủ động xây dựng hệ thống chính thức trước khi chạm mốc 150. Như Gore-Tex đã chứng minh với chiến lược tách nhà máy, và như Amazon đã chứng minh với two-pizza team, quy mô nhỏ được thiết kế có chủ đích chính là bí quyết để một tổ chức lớn vẫn vận hành nhanh nhẹn như một tổ chức nhỏ.