有些公司看起來有完整的組織圖，也有部門主管，但真正遇到事情時，大家還是會問同一句話：

「這件事老闆怎麼說？」

客訴怎麼處理，要問老闆；活動要不要辦，要問老闆；多花一筆預算，要問老闆；甚至連一封信怎麼回，也想先確認老闆的意思。

最後，所有決策都塞到老闆手上。老闆忙著回答各種問題，其他主管比較像中繼站，負責蒐集資訊、傳遞指令，再監督部屬執行。

看到這種情況，很容易得到一個結論：主管能力不夠，所以不敢做決定。

有時確實如此，但也可能完全不是。

如果把所有問題都歸咎於主管能力，老闆常見的做法就是再辦一堂課、再教一套工具，或者乾脆把決策收回來自己做。結果是老闆愈來愈累，主管愈來愈依賴，組織也愈來愈慢。

要解開這個結，不能只問「主管為什麼不決定」，而要依序判斷三件事：

1. 他會不會做決定？
2. 他願不願意做決定？
3. 組織允不允許他做決定？

這三個問題，可以對應到楊三角裡的能力、意願與治理環境。順序很重要：先確認他知不知道怎麼判斷，再理解他為什麼不願意承擔，最後回頭檢查制度是否真的給了他決策空間。

第一種情況：主管真的還不會做決定

做決定不是「有主見」就好，也不是憑經驗挑一個答案。

一個主管至少要能做到幾件事：看懂目標、整理資訊、辨識限制、比較選項、評估風險，最後說明自己為什麼這樣選。決定執行後，還要能根據結果修正判斷。

如果主管每次遇到問題，只能丟出一句「那現在怎麼辦」，卻說不出目標、選項與建議，可能真的缺乏決策能力。

但不要只看他最後有沒有選對。決策一定有不確定性，正確的判斷也可能得到不好的結果。更值得觀察的是：

• 他有沒有先確認要解決什麼問題？
• 他能不能提出不同選項與取捨？
• 他是否看見主要風險與可逆性？
• 結果不如預期時，他能不能回頭修正？

如果這些能力還沒建立，老闆要做的是示範、提問、陪他拆解，再用小範圍決策讓他練習。經過一段時間的回饋與練習，仍然無法形成基本判斷，這時才需要評估他是否適合主管職。

第二種情況：主管會做，但不願意做

另一種更常見的情況是：主管並非沒有能力，而是學會了「先不要決定」。

他可能過去自己做過決定，最後卻被老闆當場推翻；也可能長期只負責執行，從來沒被要求提出主張。還有些公司獎勵的是「不要出錯」，而不是「主動解決問題」，主管自然會發現，多做多錯，先請示最安全。

也有主管純粹不想承擔責任。他把所有難題往上丟，一旦出事就說「這是老闆決定的」。面對這種情況，不能只談心理安全感，也要把決策責任與主管角色說清楚。

所以，當主管不願意做決定時，要區分幾種可能：

• 害怕決定被推翻；
• 已經習慣等待指令；
• 組織的獎懲讓他覺得承擔不划算；
• 刻意逃避責任。

前三種需要調整互動方式、增加安全感與重新設計回饋；最後一種則需要明確的績效要求。理解原因，是為了選對介入方式。該談績效時，還是要談。

第三種情況：嘴上授權了，制度卻沒有允許

老闆最常說的一句話是：「我有叫他自己決定啊。」

但主管真正感受到的，可能完全不同。

如果目標不清楚、必要資訊拿不到、預算與人力不能調整、跨部門沒有人配合，出了問題卻要主管一個人負責，那麼這個主管得到的不是授權，而是一個沒有工具的責任。

有些老闆會說「你自己決定」，等主管真的選了不同做法，又立刻問：「你為什麼沒有先問我？」幾次之後，主管就會知道，真正的規則不是自主決策，而是猜中老闆心中的答案。

所以，授權不能只看老闆有沒有說出口，而要看治理系統是否同時提供：

• 清楚的目標與優先順序；
• 取得決策資訊的管道；
• 與責任相稱的權限與資源；
• 能容許合理試錯的績效與獎勵方式。

這也是楊三角中「允不允許」的重要性。當主管沒有決策空間時，再多培訓也很難改變行為。

下次看到主管什麼都問老闆，不妨先反過來問：這是他的問題，還是我們的管理方式讓他只能這樣做？

不要直接放手，先把決策變成可觀察的實驗

判斷主管是哪一種情況，最好的方法不是猜，而是給他一個真實但可控的決策。

例如，挑一個風險不高、結果可逆、兩週內可以看到回饋的問題，先和主管確認：

• 這次決策要達成什麼結果？
• 哪些條件不能碰？
• 可以使用哪些資源？
• 什麼指標代表有效？
• 什麼時候一起檢查？

接著要求主管帶著目標、選項、風險與自己的建議來討論。老闆先不要代替他回答，而是用問題檢查他的思考。

這樣做，可以看見他究竟是不會判斷、不願承擔，還是被制度卡住。也能讓主管在安全範圍內累積決策經驗。

一開始就丟一句「以後你自己決定」，通常不叫授權，只是把焦慮丟給主管。授權要有範圍、有資訊、有檢查點，也要允許主管在不偏離目標的前提下，選擇跟老闆不同的方法。

否則最後測到的，只是主管猜老闆心思的能力。

授權不是開關，而是一段逐步擴大的過程

很多人把授權想成兩種狀態：不是老闆決定，就是主管完全自主。

但更實際的做法，是把決策權分成不同程度：

1. 老闆決定，主管執行：適合高風險、資訊高度集中，或主管剛接觸的議題。
2. 主管整理選項並提出建議，老闆決定：開始訓練判斷，但最終責任仍在老闆。
3. 主管提出決定，老闆確認後執行：主管先形成主張，老闆只檢查重要假設與風險。
4. 主管決定，事前讓老闆知情，例外才介入：老闆不逐案批准，只在超出邊界時阻止。
5. 主管決定並執行，事後讓老闆知情：用結果與定期檢視維持透明。
6. 主管在約定範圍內自主決策：老闆只在固定節奏中檢查成果與調整邊界。

主管能穩定處理一個層級，才逐步往下一個層級移動；如果反覆越界、隱瞞資訊或不從結果學習，也可以暫時縮小授權範圍。

這不是不信任，而是讓權限和能力一起成長。主管的判斷品質、邊界意識和學習能力，比一次結果更能反映他能不能承擔更大的決策空間。

要讓主管決定，先把不同層次的目標對齊

主管之所以不敢決定，有時不是不知道怎麼做，而是不知道哪個方向才算對。

公司如果只有一句模糊的願景，各部門就會用自己的方式解讀。業務想衝營收、產品想顧體驗、技術想還債、營運想降成本；每個決定單獨看都合理，合在一起卻可能互相抵消。

Scrum 裡的三層目標，可以幫助組織建立一條由遠到近的決策脈絡：

• Product Vision
  說明我們想創造什麼長期改變，也就是「往哪裡去」。
• Product Goal
  說明下一個需要完成的重要成果，也就是「接下來先改變什麼」。
• Sprint Goal
  說明這一輪工作要驗證或完成什麼，也就是「現在為什麼做這些事」。

下一層不能自己定完就算了，而要先和上一層對焦。Sprint Goal 要支持
Product Goal，Product Goal 要朝 Product Vision
前進。對齊的是方向與成果，不是每一個執行步驟。

當上下層目標一致，主管就不必每件事都問老闆。他可以用目標作為判斷基準，在邊界內決定做法；只有目標衝突、關鍵假設失效或風險超出範圍時，再往上討論。

Scrum提供的，不只是會議，而是一套授權的運作方式

授權之所以容易失敗，常常不是理念不對，而是缺少固定的運作節奏。老闆一放手就看不到資訊，感到不安後又把權力收回；主管則不知道何時該報告，乾脆每件事都先問。

Scrum 可以提供一套可行的運作方式：

• 在 Planning 中確認 Sprint
  Goal，選擇要處理的工作，讓團隊知道這一輪要達成什麼。
• 透過 Product Backlog、Sprint Backlog
  與看板，把優先順序、進度、阻礙與資訊攤在共同的視野裡。
• 在 Daily Scrum
  中根據現況調整做法，不必等老闆逐項下指令。
• 在 Sprint Review
  中檢查真正做出的成果與利害關係人的回饋，而不是只聽進度報告。
• 在 Sprint Retrospective
  中回顧合作與決策方式，讓主管和團隊改善下一輪的工作系統。

老闆需要的不是掌握每一個動作，而是能定期看見目標、風險與成果。資訊透明後，他可以把注意力放在例外，而不是逐項核准。

這套運作方式不要求老闆突然完全放手。它讓主管在有目標、有邊界、有資訊，也有定期檢查的情況下，慢慢練習做決定。

主管一直逃避決策，老闆還是要適時介入

授權不等於不管理，自主也不代表主管可以無限延後、隱瞞或把責任往上推。

可以事先約定幾種需要老闆介入的例外：

• 決策超出原本約定的權限邊界；
• 出現可能造成重大損失、法規或聲譽影響的風險；
• 關鍵資訊被隱瞞，導致組織無法判斷真實狀況；
• 同樣的錯誤一再發生，而且看不到學習與改善；
• 主管持續逃避角色責任，不願提出主張或承擔結果。

遇到這些狀況，老闆要介入的不是每一個細節，而是重新確認責任、縮小決策範圍、增加檢查頻率，必要時進入績效管理。

但如果只是主管選擇了不同方法，或執行過程出現正常波動，老闆就急著收回決策權，主管永遠不會有機會成為決策者。

真正要改變的，不只是主管

當公司大小事都要老闆決定，主管能力不足可能是原因之一，但不一定是唯一原因。

有些主管還不會判斷，需要練習與回饋；有些主管有能力卻不願承擔，需要理解他是害怕、習慣，還是在逃避責任；還有些公司嘴上授權，實際的目標、資訊、權限和獎勵卻都沒有跟上。

真正有效的做法，不是要求老闆一次放手，也不是告訴主管「勇敢一點」。而是把決策變成可觀察的能力，對齊
Product Vision、Product Goal 與 Sprint
Goal，設定清楚的授權層級與例外，再用 Scrum
的透明、檢視和調整，建立穩定的管理節奏。

老闆不必從此什麼都不管。他要改變的是自己的介入方式：從回答每一題，變成確認方向、設計邊界、看見風險，並幫助主管對自己的決定負責。

這時，授權才不再是一句口號，而會成為組織真正的決策能力。

參考資料

書籍與管理框架

• 楊國安，《组织能力的杨三角：企业持续成功的秘诀 第3版》，機械工業出版社，ISBN9787111787372。本文的「能力、意願、允許」診斷順序參考此書的員工能力、員工思維模式與員工治理三個面向。
• Management 3.0，〈Delegation Poker & Delegation Board〉。本文「授權不是開關」的觀念參考其七級授權；文中的六個層級則是依本文管理情境重新整理，並非原框架的逐級翻譯。

直接參考的文章與影音

• Tricia Broderick，〈Are leaders needed for self-organizing teams?〉，2018 年 5 月 27 日。本文用來說明自組織不代表不需要領導者，而是領導者的工作會從指揮轉向教練、引導與支持。中文譯文另收錄於《2018 全球敏捷文章精選》，第 40–43 頁。
• Adam Weisbart，〈Anti-agile: Trick your partner into doing your laundry〉，2018 年 12 月 18 日。本文用來說明主管反覆代答、代做，可能讓團隊形成習得性無助。中文譯文另收錄於《2018 全球敏捷文章精選》，第 552–555 頁。
• Saskia Vermeer-Ooms，〈These are the 5 benefits of Scrum〉，2019 年 8 月 15 日。本文用來說明 Sprint Planning、Daily Scrum、Sprint Review 與 Sprint Retrospective如何建立專注、透明、回饋與改善節奏。中文譯文另收錄於《2019全球敏捷文章精選》，第 460–465 頁。
• KK、Vincent、老范，〈從「微觀管理」到「敏捷賦能」：如何運用 Scrum 思維打造自我管理的當責團隊〉，KVM 直播第 16 集。本文用來說明從微觀管理轉向目標對齊、逐步授權與定期檢視。
• Scrum Patterns Group，〈Vision〉（別名 Product Vision），來源：Scrum Book。本文用來說明願景如何提供共同方向，又不把執行方法規定得過細。
• Scrum Patterns Group，〈Sprint Goal〉，來源：Scrum Book。本文用來說明 Sprint Goal如何在工作可調整時，仍維持共同成果方向。

Scrum 正式定義

• Ken Schwaber、Jeff Sutherland，〈The 2020 Scrum Guide〉。本文對 Product Goal、Sprint Goal、Scrum
  事件，以及透明、檢視、調整的說明以此為正式定義。Product Vision 並不是2020 Scrum Guide 中的正式承諾，因此另採上列 Scrum Book的〈Vision〉作為來源。

作者簡介
范育銘是 Scrum Inc.認證培訓師及台灣敏捷協會常務理事，曾陪伴不同規模的企業推動數位與組織轉型。我協助主管對齊目標、釐清決策邊界，建立回饋與協作機制，讓主管能放心授權，團隊也能承擔決策與成果責任。
我也持續在 WeAgile分享組織變革與敏捷實務文章，並提供公開課、企業內訓及教練顧問服務，幫助企業把自組織與自管理，從理念轉化為真正能運作的管理能力。