Cấu trúc Đội ngũ Siêu việt: Hierarchy (Phân tầng) vs. Network/Squad (Mạng lưới)

Một trưởng phòng sản phẩm ở công ty fintech 80 người kể lại: mỗi tính năng mới muốn ra mắt phải qua bốn lớp phê duyệt — trưởng nhóm dev, giám đốc công nghệ, giám đốc sản phẩm, rồi CEO ký duyệt ngân sách đi kèm. Từ ý tưởng đến production: sáu tuần. Đối thủ cùng phân khúc, một startup 25 người, làm việc tương tự trong tám ngày. Không phải đội anh kém năng lực — cấu trúc của anh được thiết kế để kiểm soát rủi ro tài chính khi công ty đang gọi vốn Series A, còn đối thủ được thiết kế để tối đa tốc độ thích nghi.

Ở thái cực khác, có những đội "phẳng" tự hào không ai là sếp ai, mọi quyết định đều đồng thuận. Sáu tháng sau, ba nhóm nhỏ trong công ty đang xây ba phiên bản khác nhau của cùng một tính năng mà không ai biết. Khi khách hàng lớn khiếu nại, không có đầu mối chịu trách nhiệm rõ ràng. Tự chủ tuyệt đối, thiếu cơ chế phối hợp, biến thành hỗn loạn có tổ chức.

Hai câu chuyện là hai mặt của cùng một câu hỏi mọi Team Leader sớm muộn phải trả lời: cấu trúc theo tầng bậc (hierarchy) để tối ưu kiểm soát, hay theo mạng lưới (network/squad) để tối ưu tốc độ? Bài này không đưa ra câu trả lời đúng tuyệt đối — vì không có — mà cung cấp khung tư duy để chọn đúng cấu trúc cho đúng giai đoạn, quy mô, mức độ bất định mà đội ngũ đang đối mặt.

Bản chất: Cấu trúc là hạ tầng vô hình của tốc độ ra quyết định

Cấu trúc đội ngũ không đơn thuần là sơ đồ tổ chức trên slide — nó quy định ba thứ: ai có quyền quyết định gì, thông tin chảy theo đường nào, và ai phân xử khi có bất đồng. Nó là "hệ điều hành" vô hình chi phối tốc độ và chất lượng mọi quyết định, dù không ai nhắc đến nó trong họp hàng ngày.

Hierarchy tổ chức đội theo các lớp cấp bậc: nhân viên báo cáo quản lý trực tiếp, quản lý báo cáo giám đốc. Quyết định đi theo chiều dọc — đề xuất lên, phê duyệt xuống. Ưu điểm: rõ trách nhiệm giải trình (accountability), nhất quán thực thi, kiểm soát rủi ro tốt. Nhược điểm: mỗi lớp phê duyệt cộng thêm độ trễ, thông tin dễ méo khi qua nhiều tầng lọc.

Network/Squad (tiêu biểu là mô hình Spotify) tổ chức theo các nhóm nhỏ liên chức năng, tự chủ cao, kết nối bằng các cộng đồng chuyên môn ngang hàng thay vì chuỗi mệnh lệnh dọc. Quyết định phần lớn được ra ngay trong nhóm nhỏ. Ưu điểm: tốc độ, khả năng thích nghi, tinh thần làm chủ cao. Nhược điểm: dễ trùng lặp nỗ lực, khó nhất quán giữa các nhóm, dễ thành "ốc đảo" thông tin nếu thiếu cơ chế đồng bộ.

Đây không phải cuộc thi tìm mô hình "tiến bộ" hơn. Một nhà máy dược phẩm cần hierarchy chặt để tuân thủ an toàn — sai một quyết định có thể ảnh hưởng tính mạng người dùng. Một đội sản phẩm số cạnh tranh trong thị trường đổi hàng tuần cần network để không bị vượt mặt vì chờ phê duyệt. Team Leader giỏi không trung thành với một triết lý tổ chức — họ chọn cấu trúc phù hợp bản chất công việc và giai đoạn phát triển, sẵn sàng chuyển đổi khi bối cảnh thay đổi.

Khung so sánh: Hierarchy vs. Network

Quan sát thực chiến: phần lớn tổ chức Việt Nam vận hành mô hình lai. Khối vận hành/tài chính/pháp lý giữ hierarchy chặt vì cần tuân thủ; khối sản phẩm/công nghệ áp dụng network/squad để tăng tốc. Đây là thiết kế có chủ đích, miễn ranh giới giữa hai vùng được vẽ rõ.

Mô hình Squad — Tribe — Chapter — Guild (rút gọn từ Spotify Model)

Mô hình này được Spotify phổ biến (không phải phát minh gốc, và chính Spotify sau này cũng điều chỉnh) như cách tổ chức đội sản phẩm-công nghệ theo mạng lưới nhưng vẫn giữ nhất quán chuyên môn.

Squad — đơn vị nhỏ nhất, nhóm liên chức năng (5-9 người: PM, dev, design, QA) tự chủ hoàn toàn trên một mảng sản phẩm hoặc hành trình khách hàng (squad "Thanh toán", squad "Onboarding"). Giống một startup mini — có mục tiêu riêng, tự quyết cách làm, chịu trách nhiệm đầu ra.

Tribe — tập hợp các squad liên quan (Tribe "Trải nghiệm khách hàng" gồm squad Onboarding, Hỗ trợ, Thanh toán). Tribe Lead điều phối ưu tiên chung, giải quyết xung đột nguồn lực. Nguyên tắc gốc: một tribe không nên vượt khoảng 100-150 người (giới hạn Dunbar) — vượt ngưỡng này, sự phối hợp tự nhiên suy giảm.

Chapter — nhóm ngang các cá nhân cùng chuyên môn nhưng thuộc squad khác nhau (Chapter "Backend Engineers"). Chapter Lead phụ trách năng lực chuyên môn, chuẩn kỹ thuật, lộ trình sự nghiệp — không can thiệp việc hàng ngày của squad.

Guild — cộng đồng tự nguyện, xuyên tribe, quanh mối quan tâm chung (Guild "Data & Analytics"). Không có quyền lực chính thức, là kênh lan toả kiến thức và thực hành tốt.

Cơ chế cân bằng: Squad cho tốc độ và tự chủ (trục dọc theo sản phẩm); Chapter và Guild cho nhất quán chuyên môn (trục ngang xuyên sản phẩm). Đây là cách mô hình mạng lưới khắc phục nhược điểm lớn nhất của nó — nguy cơ phân mảnh — mà không quay lại hierarchy truyền thống.

Phân tích theo 5W3H1R: Thiết kế cấu trúc đội ngũ phù hợp bối cảnh

Why — Tại sao phải chủ động thiết kế. Phần lớn cấu trúc hình thành tình cờ — tuyển người, người mới báo cáo cho ai đó, dần thành sơ đồ không ai chủ ý vẽ. Hệ quả: quyết định tắc ở đúng điểm cần nhanh nhất, hoặc ngược lại rủi ro lớn được quyết quá nhanh không ai kiểm. Pain point: việc "rơi giữa hai ghế", họp phải có quá nhiều cấp mới ra quyết định, nhân sự giỏi rời đi vì bị trói bởi tầng phê duyệt. Thiết kế chủ động tạo giá trị: tốc độ đúng với mức rủi ro thực tế, trách nhiệm giải trình rõ, đội mở rộng được mà không sụp vì quá tải phối hợp.

What — Bản chất & phạm vi. Là quá trình xác định có chủ đích: (1) đơn vị làm việc cơ bản, (2) đường đi của quyết định — quyết định nào được quyết ở đâu, ai có quyền phủ quyết, (3) cơ chế phối hợp ngang khi hai nhóm cùng chạm một vấn đề, (4) cơ chế giữ chuẩn chuyên môn xuyên nhóm. Scope in: sơ đồ báo cáo, ma trận quyền quyết định (decision rights), cơ chế Chapter/Guild, tần suất đồng bộ, tiêu chí tách/gộp nhóm. Scope out: lương thưởng, đánh giá hiệu suất cá nhân, quy trình tuyển dụng. Thành phần cấu thành: sơ đồ đơn vị và ranh giới trách nhiệm; ma trận quyền quyết định theo loại vấn đề; cơ chế đồng bộ ngang; chỉ số giám sát sức khoẻ cấu trúc (thời gian ra quyết định trung bình, số lần leo thang không cần thiết, số lần trùng lặp công việc). Output: tài liệu "Operating Structure Charter" gồm sơ đồ, ma trận quyền quyết định, lịch đồng bộ — review định kỳ, không đóng băng một lần.

Who — RACI rút gọn:

Where. Trong Intelligence Hub (SellersStar), việc thiết kế và theo dõi thuộc module Quản trị nhóm — lưu sơ đồ tổ chức động, ma trận quyền quyết định theo loại quyết định, chỉ số vận hành (thời gian trung bình từ đề xuất đến phê duyệt, số lần leo thang quá hai cấp). Áp dụng từ cấp một squad (5-9 người) đến toàn công ty khi vượt ngưỡng cần phân tầng (thường trên 15-20 người/quản lý trực tiếp).

When. Dấu hiệu kích hoạt: thời gian ra quyết định thường xuyên tăng rõ; lặp lại tình trạng "không biết ai quyết"; hai nhóm phát hiện làm trùng việc; đội vượt ngưỡng một quản lý bao quát trực tiếp (8-12 người). Nhịp rà soát khuyến nghị: 6-12 tháng/lần hoặc sau cột mốc lớn (gọi vốn, mở thị trường, sáp nhập đội). Không nên đổi liên tục theo cảm tính — mỗi lần tái cấu trúc có chi phí gián đoạn.

How — Quy trình theo bước:

1. Đánh giá bối cảnh. Đầu vào: quy mô, ngành (mức tuân thủ), giai đoạn sản phẩm, độ biến động thị trường. Hoạt động: Team Leader và HRBP trả lời — đội đã vượt ngưỡng một quản lý bao quát chưa? rủi ro sai sót có nghiêm trọng về pháp lý/tài chính không? thị trường có biến động nhanh không? đội đủ năng lực tự chủ chưa? Đầu ra: bản đánh giá xác định thiên hướng hierarchy hay network.
2. Vẽ ranh giới đơn vị làm việc. Đầu vào: hành trình khách hàng hoặc dòng giá trị sản phẩm. Hoạt động: xác định mảng việc đủ endpoint đầu-cuối để một nhóm chịu trách nhiệm trọn vẹn, không lệ thuộc nhóm khác giữa chừng. Đầu ra: danh sách đơn vị làm việc đề xuất kèm phạm vi trách nhiệm.
3. Xây ma trận quyền quyết định. Đầu vào: danh sách loại quyết định thường gặp (ngân sách nhỏ, đổi tính năng, tuyển dụng, xử lý khủng hoảng). Hoạt động: với mỗi loại, xác định cấp được quyết không cần leo thang và ngưỡng buộc phải leo thang. Đầu ra: bảng ma trận, công khai toàn đội.
4. Thiết kế cơ chế đồng bộ ngang. Đầu vào: các mảng chuyên môn cần nhất quán xuyên nhóm. Hoạt động: lập Chapter/uỷ ban tương ứng, tần suất đồng bộ, quyền hạn Chapter Lead (tư vấn chuẩn, không can thiệp vận hành hàng ngày). Đầu ra: danh sách Chapter/Guild kèm người phụ trách và nhịp hoạt động.
5. Thí điểm và đo lường. Đầu vào: cấu trúc mới. Hoạt động: áp dụng ở phạm vi giới hạn (một tribe/phòng ban), theo dõi thời gian ra quyết định, số vụ leo thang không cần thiết, mức hài lòng về sự rõ ràng vai trò. Đầu ra: báo cáo thí điểm sau 4-8 tuần.
6. Điều chỉnh và nhân rộng. Đầu vào: kết quả thí điểm. Hoạt động: điều chỉnh ranh giới đơn vị hoặc ma trận theo vấn đề thực tế phát sinh, rồi nhân rộng. Đầu ra: Operating Structure Charter chính thức, truyền thông rõ tới toàn đội.

How Much. Thời gian: Team Leader cần dành mức đáng kể trong 4-6 tuần đầu cho đánh giá bối cảnh và vẽ ranh giới — công việc tư duy chiến lược khó giao khoán. Nhân lực: cần HRBP tham gia, cùng ít nhất một workshop có mặt Chapter Lead liên quan. Công cụ: sơ đồ tổ chức động, có thể bắt đầu bằng bảng tính/Miro, tiến tới module Quản trị nhóm khi đủ lớn. Ngân sách: nếu có offsite tập trung, ở mức "đủ tập trung được các trưởng nhóm liên quan trong 1-2 ngày" — giá trị nằm ở chất lượng thảo luận, không phải hình thức.

How Long. Tuần 1-2 sau khi công bố ma trận quyền quyết định, đã giảm rõ số lần hỏi "ai quyết cái này". Tuần 4-8, chỉ số thời gian ra quyết định trung bình bắt đầu dịch chuyển nếu cấu trúc phù hợp — lead time hợp lý để đánh giá thí điểm. Thay đổi văn hoá sâu hơn (nhân sự thực sự cảm thấy được trao quyền) thường cần 2-3 quý để ổn định, vì đòi hỏi quản lý cấp trung buông quyền kiểm soát vi mô.

Risk:

Tiêu chí chọn cấu trúc theo quy mô & độ bất định

Nguyên tắc rút gọn: quy mô càng lớn và bất định càng cao thì càng cần mô hình lai — hierarchy cho chức năng cần kiểm soát (tài chính, pháp lý, an toàn), network/squad cho chức năng cần tốc độ (sản phẩm, tăng trưởng, trải nghiệm khách hàng).

Case study Việt Nam (minh hoạ điển hình)

Case dựng để minh hoạ mô hình, không phải số liệu doanh nghiệp có thật. Một công ty thương mại điện tử ngành thời trang tại Việt Nam, quy mô khoảng 120 nhân sự, từng vận hành thuần hierarchy: mọi tính năng trên app qua ba lớp phê duyệt trước khi lập trình viên bắt tay code — Trưởng phòng sản phẩm, Giám đốc công nghệ, Tổng giám đốc ký duyệt nếu ảnh hưởng ngân sách marketing.

Vấn đề bộc lộ rõ vào mùa sale lớn: đối thủ tung tính năng "mua trước trả sau" chỉ trong ba tuần, trong khi công ty này mất hơn hai tháng cho quy trình phê duyệt nội bộ một tính năng tương tự — ra mắt thì đã lỡ mùa cao điểm.

Ban lãnh đạo tái cấu trúc một phần: giữ hierarchy cho khối Tài chính - Kế toán - Pháp lý (cần tuân thủ chặt, sai sót ảnh hưởng báo cáo cổ đông và thuế). Khối Sản phẩm - Công nghệ được tổ chức lại thành ba squad theo hành trình khách hàng: Squad Khám phá, Squad Giỏ hàng - Thanh toán, Squad Hậu mãi. Mỗi squad toàn quyền quyết định tính năng trong ngân sách kỹ thuật đã duyệt theo quý, không cần xin phê duyệt từng tính năng nhỏ. Đồng thời lập Chapter Kỹ thuật (chuẩn code, bảo mật đồng nhất) và Chapter Thiết kế (trải nghiệm nhất quán dù các squad làm độc lập).

Kết quả minh hoạ: tốc độ ra tính năng nhỏ rút ngắn đáng kể nhờ bỏ hai lớp phê duyệt trung gian; nhưng phát sinh vấn đề mới ở giai đoạn đầu — hai squad từng thiết kế hai cơ chế mã giảm giá khác nhau cho cùng nhóm khách hàng, gây nhầm lẫn. Giải quyết bằng cách bổ sung họp đồng bộ hai tuần một lần giữa các Trưởng squad, do Giám đốc sản phẩm chủ trì. Bài học: chuyển sang network/squad không tự động thành công — đòi hỏi đầu tư tương xứng vào cơ chế đồng bộ, nếu không tốc độ có được sẽ đánh đổi bằng hỗn loạn.

FRAMEWORK ÁP DỤNG ĐƯỢC: Bảng chẩn đoán cấu trúc đội ngũ

Tự chấm điểm 1-5 (1 = hoàn toàn không đúng, 5 = hoàn toàn đúng):

Cách đọc: tổng điểm 4 câu đầu cao (trên 16/20) và câu 5 cũng cao → đủ điều kiện dịch chuyển về phía network/squad. Nếu câu 5 thấp trong khi 4 câu đầu cao → cần xây Chapter/Guild trước khi tách squad, tránh lặp lại phân mảnh như case study trên.

GÓC NHÌN TEAM LEADER

• Nếu một quyết định thường ngày phải qua hơn hai cấp phê duyệt, đó là kiểm soát rủi ro thực sự cần thiết, hay chỉ là thói quen thừa hưởng từ quá khứ?
• Đội ngũ tôi đang trả giá bằng tốc độ để đổi lấy sự nhất quán — mức đánh đổi đó có còn đúng với giai đoạn hiện tại?
• Nếu trao thêm quyền tự chủ cho nhóm, tôi có sẵn sàng chấp nhận một số quyết định sẽ khác cách tôi từng làm không?
• Đội ngũ tôi có đang tồn tại những "ốc đảo" — nhóm tự chủ nhưng không đồng bộ chuẩn với nhóm khác — mà tôi chưa nhận ra?
• Khi đội ngũ mở rộng gấp đôi trong 12 tháng tới, cấu trúc hiện tại có còn vận hành được, hay sẽ gãy ở đâu trước tiên?

🔗 Liên kết với các bài khác (Alignment)

• Cấu trúc quyết định tốc độ, nhưng con người trong đó cần trải qua các giai đoạn phát triển nhóm — xem Mô hình Tuckman (Forming – Storming – Norming – Performing) để hiểu vì sao một squad mới lập luôn cần thời gian "storming" trước khi thực sự tự chủ hiệu quả.
• Trước khi tái cấu trúc, cần chẩn đoán xem đội có mắc các rối loạn nền tảng hay không — tham khảo Mô hình 5 Dysfunctions of a Team (Patrick Lencioni), vì tái cấu trúc không giải quyết được vấn đề thiếu tin tưởng hay né tránh trách nhiệm giải trình.
• Khi đã chọn xong cấu trúc squad/tribe, bước tiếp theo là gắn mục tiêu đo lường được cho từng đơn vị — xem OKRs cho Nhóm (Team OKRs).
• Ma trận quyền quyết định trong bài này có thể cụ thể hoá hơn bằng công cụ phân vai ở Framework RACI.

Cấu trúc đội ngũ không phải sơ đồ vẽ một lần rồi để yên trên tường — nó là quyết định thiết kế sống, cần xét lại mỗi khi bối cảnh thay đổi đủ lớn. Không có mô hình nào "tiên tiến" hơn mô hình nào; chỉ có mô hình phù hợp hơn với mức rủi ro, quy mô, tốc độ biến động mà đội ngũ bạn đang đối mặt. Nếu bạn đang lãnh đạo một đội ngũ, việc cần làm ngay không phải chọn phe Hierarchy hay Network — mà dùng bảng chẩn đoán ở trên để soi chiếu trung thực vào chính đội ngũ mình, xác định điểm nghẽn thực sự, và bắt đầu điều chỉnh từ đúng chỗ đó.

Bài trước: Mô hình 5 Dysfunctions of a Team (Patrick Lencioni) · Bài tiếp theo: OKRs cho Nhóm (Team OKRs)