Mở đầu — vì sao bài này quan trọng
Có một nghịch lý mà rất nhiều Project Manager (PM) người Việt gặp phải: càng giỏi chuyên môn, càng khó buông tay. Bạn từng là developer xuất sắc, business analyst sắc bén, hay kỹ sư giỏi nhất phòng — nên khi lên làm PM, bản năng đầu tiên là "để tôi tự quyết cho nhanh, tôi làm cái này quen rồi". Kết quả là bạn trở thành nút cổ chai (bottleneck): mọi quyết định lớn nhỏ đều dồn về bàn bạn, team ngồi chờ, còn bạn thì kiệt sức làm việc đến 11 giờ đêm mà dự án vẫn chậm.
PMP thế hệ mới — đặc biệt là PMBOK 7 với nguyên tắc "Leadership" và domain "Team" — nói rất rõ: vai trò của PM không phải là người ra mọi quyết định, mà là người tạo ra một môi trường nơi team có thể tự ra quyết định tốt. Đây chính là năng lực empowering team (trao quyền cho đội ngũ) và decision-making (phân bổ thẩm quyền ra quyết định).
Bài học này sẽ cho bạn một khung tư duy cực kỳ thực dụng — mô hình 7 cấp độ ủy quyền (7 Levels of Delegation) của Jurgen Appelo — để bạn biết chính xác: với quyết định nào thì bạn nên tự làm, quyết định nào nên hỏi ý kiến team, và quyết định nào nên trao trọn cho team. Nắm được điều này, bạn không chỉ thi PMP tốt hơn ở nhóm câu hỏi về "People" (chiếm tới 42% đề thi) mà còn thực sự lãnh đạo được một đội ngũ trưởng thành.
Khái niệm cốt lõi
Empowerment không phải là "buông xuôi"
Nhiều người hiểu sai: trao quyền nghĩa là PM rút lui, để team "tự bơi". Sai. Empowerment là trao quyền quyết định trong một khuôn khổ rõ ràng, kèm theo bối cảnh, mục tiêu và ranh giới đầy đủ để người được trao quyền thành công. Trao quyền mà không cho bối cảnh gọi là bỏ rơi (abdication); giữ hết quyền gọi là kiểm soát vi mô (micromanagement). Empowerment nằm ở khoảng giữa được thiết kế có chủ đích.
Khác biệt cốt lõi: ủy quyền không phải là chuyện "có hoặc không" (nhị phân), mà là một thang đo liên tục. Đây chính là đóng góp lớn nhất của Jurgen Appelo.
7 cấp độ ủy quyền của Jurgen Appelo
Jurgen Appelo — tác giả Management 3.0 — chia quyền ra quyết định thành 7 nấc, đi từ "PM kiểm soát hoàn toàn" đến "team kiểm soát hoàn toàn". Điểm mấu chốt: quyền lực dịch chuyển dần từ manager sang team, chứ không nhảy đột ngột.
- Tell (Nói) — PM tự ra quyết định và thông báo cho team. Team không có tiếng nói, chỉ được biết. Dùng khi tình huống khẩn cấp, rủi ro cao, hoặc quyết định thuần túy thuộc thẩm quyền quản lý (ví dụ: quyết định dừng dự án).
- Sell (Thuyết phục) — PM vẫn tự quyết, nhưng bỏ công giải thích lý do để thuyết phục team đồng thuận và mua vào (buy-in). Team hiểu "vì sao" chứ không chỉ "làm gì". Dùng khi quyết định đã chốt nhưng cần sự cam kết cảm xúc của team.
- Consult (Tham vấn) — PM hỏi ý kiến team, lắng nghe, cân nhắc, rồi tự ra quyết định cuối cùng. Team có ảnh hưởng nhưng không có quyền quyết. Đây là nấc rất hay dùng cho các quyết định kỹ thuật mà team hiểu rõ hơn PM.
- Agree (Thống nhất) — PM và team cùng thảo luận và cùng đi đến quyết định chung. Đây là điểm cân bằng — quyền lực chia đôi. Dùng khi cần cả góc nhìn quản lý lẫn góc nhìn chuyên môn, và cả hai bên đều phải cam kết thực hiện.
- Advise (Cố vấn) — Team ra quyết định, nhưng PM chia sẻ quan điểm, đưa lời khuyên trước để tác động. Quyền quyết nằm ở team; PM chỉ là một tiếng nói có trọng lượng.
- Inquire (Hỏi lại) — Team tự ra quyết định và thực hiện, sau đó thông báo lại cho PM để PM nắm tình hình. PM không tác động trước, chỉ theo dõi sau.
- Delegate (Ủy thác hoàn toàn) — Team toàn quyền quyết định và hành động, PM không cần được thông báo. PM hoàn toàn tin tưởng và giao trọn một vùng trách nhiệm.
Delegation Board và Delegation Poker
Appelo đề xuất hai công cụ thực hành. Delegation Board là một bảng liệt kê các vùng quyết định (ví dụ: chọn công cụ, phân công task, đặt deadline nội bộ, tuyển thành viên mới, chi tiêu ngân sách nhỏ...) và ghi rõ mỗi vùng đang ở cấp độ mấy trong 7 nấc. Bảng này làm cho ranh giới quyền lực trở nên minh bạch — không ai còn phải đoán "cái này mình được tự quyết hay phải hỏi sếp?".
Delegation Poker là trò chơi để cả nhóm cùng "bỏ phiếu" cấp độ ủy quyền cho từng vùng. Mỗi người chọn con số 1–7 mình nghĩ là phù hợp, lật bài cùng lúc, rồi thảo luận về những chỗ chênh lệch. Nó biến một chủ đề dễ gây căng thẳng (quyền lực) thành một cuộc đối thoại thẳng thắn và vui vẻ.
Liên hệ với PMP: từ "delegating" đến team tự tổ chức
Trong PMBOK 7, đội tự tổ chức (self-organizing team) và self-managed team là đích đến. Mô hình phát triển tình huống (Situational Leadership của Hersey-Blanchard) cũng ăn khớp: với team non (competence thấp) bạn dùng phong cách chỉ đạo — tương ứng Tell/Sell; với team đã chín (competence và commitment cao) bạn chuyển sang Delegating — tương ứng Delegate. Empowerment là hành trình, không phải công tắc bật/tắt.
Tình huống thực tế
Tình huống 1 — Tiki và cái bẫy "PM ra mọi quyết định"
Một PM tại một công ty thương mại điện tử lớn ở TP.HCM (bối cảnh giả định dựa trên môi trường kiểu Tiki) phụ trách team 8 người xây tính năng thanh toán mới. Anh này vốn là kỹ sư backend giỏi, nên mọi lựa chọn kỹ thuật — dùng thư viện nào, đặt tên API ra sao, sprint làm bao nhiêu story point — đều do anh chốt. Kết quả sau 2 tháng: velocity của team giảm 30%, hai senior developer nộp đơn nghỉ với lý do "không có không gian phát triển".
Retrospective phơi bày vấn đề: anh đang giữ mọi quyết định ở cấp độ 1 (Tell). Coach của công ty giúp anh dựng một Delegation Board. Kết quả tái phân bổ: quyết định về ngày go-live (rủi ro kinh doanh cao) giữ ở cấp 2 (Sell); quyết định kiến trúc kỹ thuật chuyển lên cấp 4 (Agree); còn quyết định code style, đặt tên biến, chia task trong sprint đẩy lên cấp 6 (Inquire). Sau một quý, velocity phục hồi và vượt 15% so với ban đầu, không còn ai nghỉ việc.
Bài học: Không phải mọi quyết định đều cùng một cấp. Sai lầm phổ biến nhất là để tất cả ở cấp 1. Phân loại quyết định và đặt cần gạt phù hợp cho từng loại mới là nghệ thuật.
Tình huống 2 — Startup fintech Singapore và Delegation Poker
Một startup fintech ở Singapore (khoảng 25 nhân sự) có một team engineering 6 người thường xuyên xung đột: developer bực vì "cái gì cũng phải xin phép", còn team lead thì lo "nếu buông thì họ làm sai, khách hàng khiếu nại thì ai chịu". Họ tổ chức một buổi Delegation Poker kéo dài 90 phút cho 10 vùng quyết định.
Điều thú vị lộ ra khi lật bài: với vùng "chọn thư viện mã nguồn mở", team lead bỏ phiếu 3 (Consult) còn các developer bỏ phiếu 6 (Inquire) — chênh lệch rất lớn. Cuộc thảo luận cho thấy team lead lo về rủi ro bảo mật của thư viện. Hai bên thống nhất: đặt ở cấp 5 (Advise) kèm một checklist bảo mật bắt buộc — team tự quyết nhưng phải chạy qua checklist. Với vùng "quyết định phản hồi sự cố production khẩn cấp", cả hai bên đều đồng thuận cấp 2 (Sell) vì cần tốc độ.
Sau đó tần suất xung đột về quyền hạn giảm rõ rệt, vì mọi người có một "bản đồ quyền lực" chung thay vì tự suy diễn. Số lần developer phải chờ phê duyệt trong tuần giảm từ khoảng 12 xuống còn 3.
Bài học: Xung đột về "ai được quyết cái gì" thường không phải do ác ý, mà do kỳ vọng ngầm không được nói ra. Delegation Poker làm cho kỳ vọng đó hiện lên bảng và được thương lượng công khai.
Tình huống 3 — FPT Software và ủy quyền theo độ trưởng thành
Một Delivery Manager tại một công ty gia công phần mềm lớn (bối cảnh kiểu FPT Software) quản lý hai team cùng lúc: một team fresher mới ra trường và một team senior đã làm chung 3 năm. Ban đầu chị áp cùng một mức ủy quyền cho cả hai. Team senior thấy ngột ngạt, team fresher thì hoang mang vì được giao quyết định vượt quá năng lực, dẫn đến vài lỗi estimate nghiêm trọng khiến một dự án trượt deadline 3 tuần.
Chị điều chỉnh theo tư duy Situational Leadership kết hợp 7 cấp độ: với team fresher, hầu hết quyết định giữ ở cấp 1–3 (Tell/Sell/Consult), kèm review sát và giải thích lý do; với team senior, đẩy lên cấp 5–7 (Advise/Inquire/Delegate). Quan trọng hơn, chị công bố một lộ trình: "mỗi quý sẽ họp lại và dịch cần gạt của các em fresher lên một nấc nếu đạt tiêu chí". Điều này biến ủy quyền thành một phần thưởng có thể nhìn thấy, tạo động lực trưởng thành.
Bài học: Cấp độ ủy quyền phải khớp với độ trưởng thành của team, và nên là một hành trình có lộ trình rõ ràng — không phải một con số cố định áp cho tất cả.
Hướng dẫn từng bước
Đây là quy trình triển khai empowerment mà bạn có thể áp dụng ngay tuần này:
- Liệt kê các vùng quyết định (decision areas). Ngồi xuống viết ra 8–12 loại quyết định thường xuyên xảy ra trong dự án: chọn công cụ, phân công task, đặt deadline nội bộ, xử lý sự cố, chi tiêu nhỏ, chọn giải pháp kỹ thuật, giao tiếp với khách hàng, tuyển người mới... Càng cụ thể càng tốt.
- Đặt cấp độ hiện tại cho mỗi vùng. Với mỗi vùng, tự hỏi: hôm nay thực tế nó đang ở nấc mấy trong 7 nấc? Hãy trung thực — nhiều PM giật mình nhận ra mình đang giữ 80% ở nấc 1–2.
- Chơi Delegation Poker với team. Tổ chức một buổi 60–90 phút. Mỗi người bỏ phiếu cấp độ mong muốn cho từng vùng, lật bài cùng lúc, thảo luận các chỗ chênh lệch lớn. Đừng ép đồng thuận tuyệt đối — mục tiêu là hiểu nhau và chốt một con số chấp nhận được.
- Dựng Delegation Board và công khai nó. Ghi kết quả lên một bảng (Miro, Notion, hay bảng trắng) mà cả team nhìn thấy được. Sự minh bạch là 50% giá trị của bài tập này.
- Cung cấp bối cảnh, không chỉ giao quyền. Với mỗi vùng bạn trao lên cấp cao, hãy nói rõ mục tiêu, ranh giới (guardrails) và ngân sách rủi ro. Trao quyền mà không cho bối cảnh là bỏ rơi.
- Thiết lập lộ trình dịch cần gạt. Hẹn lịch review định kỳ (mỗi quý chẳng hạn) để nâng cấp độ ủy quyền cho các vùng khi team chứng minh được năng lực. Empowerment là hành trình đi lên.
- Chấp nhận sai sót và biến nó thành học hỏi. Khi team ra một quyết định sai ở vùng đã được trao quyền, đừng vội giật cần gạt về nấc 1. Hãy cùng làm rõ nguyên nhân, điều chỉnh guardrails, và giữ niềm tin. Rút quyền vì một lỗi sẽ giết chết mọi động lực tự chủ.
Lỗi thường gặp & mẹo
Lỗi 1 — Giữ mọi thứ ở nấc 1 vì "cho nhanh". Đây là bẫy của PM giỏi chuyên môn. Nhanh trong ngắn hạn, nhưng tạo bottleneck và giết chết sự phát triển của team trong dài hạn. Mẹo: mỗi khi định tự quyết, hỏi "quyết định này có thực sự cần mình quyết không, hay mình chỉ đang quyết vì thói quen?".
Lỗi 2 — Nhầm empowerment với abdication (bỏ rơi). Nói "team cứ tự quyết đi" rồi biến mất, không cho mục tiêu, ranh giới hay bối cảnh. Khi team làm sai, PM lại trách. Mẹo: trao quyền luôn đi kèm ba thứ — mục tiêu rõ, guardrails rõ, và một kênh để hỏi khi cần.
Lỗi 3 — Áp cùng một cấp độ cho mọi vùng quyết định. Quyết định go-live và quyết định đặt tên biến không thể cùng một nấc. Mẹo: luôn tư duy theo từng vùng riêng biệt, không "một size cho tất cả".
Lỗi 4 — Áp cùng một cấp độ cho mọi thành viên/team. Fresher và senior cần mức trao quyền khác nhau. Mẹo: kết hợp 7 cấp độ với Situational Leadership — điều chỉnh theo độ trưởng thành.
Lỗi 5 — Rút quyền ngay khi có lỗi đầu tiên. Điều này dạy team rằng "chủ động là rủi ro", khiến họ co lại. Mẹo: phân biệt lỗi do liều lĩnh với lỗi do thiếu bối cảnh; phần lớn là loại thứ hai và giải pháp là bổ sung bối cảnh, không phải rút quyền.
Mẹo thi PMP: Khi gặp câu hỏi mà PM đang micromanage hoặc là bottleneck, đáp án đúng gần như luôn nghiêng về hướng trao quyền, tạo môi trường cho team tự quyết, hỏi ý kiến team (consult/collaborate) — chứ không phải PM tự áp đặt. Cảnh giác với đáp án kiểu "PM ra quyết định và bảo team làm theo" trừ khi tình huống thực sự khẩn cấp.
Bài tập thực hành
Bài tập 1 — Tự chấm Delegation Board của chính bạn. Liệt kê 8 vùng quyết định trong dự án hiện tại. Với mỗi vùng, ghi cấp độ (1–7) mà bạn thực tế đang áp dụng hôm nay. Đếm xem có bao nhiêu vùng đang ở nấc 1–2. Nếu quá nửa nằm ở nấc 1–2, đó là dấu hiệu bạn đang là bottleneck — chọn ra 2 vùng an toàn nhất để đẩy lên một nấc ngay tuần này.
Bài tập 2 — Tình huống ra quyết định. Team của bạn cần chọn framework testing cho dự án. Các developer hiểu rõ hơn bạn về mặt kỹ thuật, nhưng lựa chọn này ảnh hưởng đến chi phí bảo trì dài hạn mà bạn chịu trách nhiệm. Bạn sẽ đặt vùng này ở cấp độ mấy trong 7 nấc? Viết 3–4 câu giải thích, nêu rõ guardrails bạn sẽ đặt. (Gợi ý: cấp 4 Agree hoặc cấp 5 Advise thường hợp lý — cùng quyết hoặc để team quyết với lời khuyên của bạn.)
Bài tập 3 — Câu hỏi PMP mô phỏng. "Một PM nhận thấy các thành viên team liên tục chờ mình phê duyệt những quyết định kỹ thuật nhỏ, làm chậm tiến độ. PM nên làm gì?" — (A) Ra quyết định nhanh hơn để team khỏi chờ; (B) Thuê thêm người để giảm tải; (C) Trao quyền cho team tự quyết trong một khuôn khổ rõ ràng và cung cấp bối cảnh cần thiết; (D) Yêu cầu team ngừng hỏi và tự chịu trách nhiệm. Chọn đáp án và giải thích vì sao ba đáp án còn lại sai. (Đáp án: C.)
Tóm tắt
- Empowerment không phải nhị phân (trao hết hay giữ hết) mà là một thang đo liên tục. Đóng góp lớn nhất của Jurgen Appelo là biến ủy quyền thành 7 cấp độ: Tell, Sell, Consult, Agree, Advise, Inquire, Delegate — quyền lực dịch dần từ PM sang team.
- Đặt cần gạt theo từng vùng quyết định, không dùng một cấp độ cho tất cả; và điều chỉnh theo độ trưởng thành của team (khớp với Situational Leadership).
- Delegation Board làm cho ranh giới quyền lực minh bạch; Delegation Poker biến việc thương lượng quyền lực thành đối thoại công khai thay vì kỳ vọng ngầm.
- Trao quyền phải đi kèm bối cảnh, mục tiêu và guardrails — nếu không, đó là bỏ rơi (abdication) chứ không phải empowerment.
- Đừng rút quyền khi có lỗi đầu tiên; hãy bổ sung bối cảnh và giữ niềm tin. Empowerment là hành trình đi lên, có lộ trình.
- Trong đề PMP (nhóm People, ~42%), khi PM là bottleneck hoặc micromanage, đáp án đúng gần như luôn nghiêng về trao quyền, tạo môi trường cho team tự quyết.