反馈确认的调整动作里，有一类是把更多决定交给成员自己做。决定交出去的范围，以及管理者仍需承担的责任，需要在授权时事先明确。这里记录培训中的授权框架和我当时的理解。
先说我当时的处境。6 月底我盘点自己一周的时间（待确认：补充这次盘点的具体背景），发现相当大的部分花在替成员做决定上：技术方案选 A 还是选 B、需求变更接不接、和协作方怎么对齐口径，都汇总到我这里。成员来找我，有时是要一个判断，更多时候是要一个背书。这个状态两头受损：我成了所有事项的瓶颈，成员的负责范围停在执行层，判断力长不出来。
这个处境里有我自己的惯性。晋升前我长期带一个 3 到 4 人的小团队，成员自驱、背景整齐，授权在那样的团队里近乎天然全权：把事整块交出去就行，几年下来几乎没出过错。授权之前要先定边界、分程度、约定升级条件，这些意识我没有过，因为没有必要。接手这个 10 多人的团队之后，同一套整块放手的做法开始失效：成员的经验和背景参差，同样一句”这事你负责起来”，有人接得住，有人接不住。而看到接不住，本能反应是把权都收回来自己定，收回来的结果就是开头那次盘点里的样子。整块放手不行，事事收回也不行，培训的授权模块正好对着这个问题。
授权解决什么问题
授权的目标，培训里讲了三条，按我的理解记下来：
让决策靠近信息现场。方案细节、变更影响、协作口径，掌握第一手信息的是做这件事的人。决策汇总到管理者，信息要经过一层转述，转述会丢细节，判断跟着偏。
扩大成员的负责范围。只做执行的成员，经验积累停在执行层。让他对一块结果负责，他才会去关心上下游、约束和后果，这些在日常任务里学不到。
减少管理者成为瓶颈。这条最直接：所有决定都等一个人，团队的吞吐就是这个人的带宽。
三条里最容易被跳过的是第二条。只冲着省自己的时间做授权，挑出去的往往是杂事，决策权还在自己手里，成员的实际处境没有变化。我在小团队里没有这个问题，因为成员的负责范围本来就大，不需要通过授权去扩。新团队里不少成员此前只被当执行者用，这一条就成了授权的主要目的。
授权之前说清四件事
授权不等于”这事以后你看着办”。培训的要求是，授权之前管理者自己先想清楚四件事，并当面说清。
这四件事我在小团队里从来不说。目标靠共识，约束靠默契，什么情况该喊一声大家心里有数，说出口反而多余。新团队里这个前提不成立：成员和我的合作时间还短，彼此对边界的默认理解并不一致，不说就等于没有。
预期结果。要交付什么，验收标准是什么。说的是结果，不限定步骤。步骤定死了，授权就变成派活。
可自行决定的范围。哪些决定他自己能做主：方案选型、排期内的任务顺序、和协作方的日常对齐，这一类。
不可突破的约束。预算、上线时间窗、安全和合规要求、对外的承诺口径。约束是边界，碰到边界的事不在授权范围内。
何时需要同步或升级。什么情况要主动告诉我，什么情况停下来等我。比如影响范围超出本团队、约束可能要被突破、和协作方谈不拢。这条最容易漏，漏掉的后果是两个极端：成员自己扛住本该升级的事，或者事事上报，授权名存实亡。
（待确认：补充当时一次实际授权中明确过的四件事内容和复盘结果）
授权的程度是连续的
培训里有个提法我很受用：授权不存在完全信任和完全控制的二选一，程度是连续的，根据四个因素逐事调节。
这条对我的针对性最强。我过去实际上只有一个挡位，就是全权，因为小团队成员的能力和经验撑得起这个挡位，从不调节也从不出错。到了新团队，同一个挡位对不上所有人：给少了，能接住的成员被捆住手脚；给多了，接不住的成员带着风险往前跑。我只能逐事调。
成员经验。做过同类事情的，范围可以给大；第一次接触的，范围收窄，检查点加密。
任务复杂度。涉及的系统、依赖方、变量越多，管理者保留的协调和判断越多。
可逆性。这是我自己最看重的一条。决策错了能撤回的，放心给出去；不可逆或者撤回成本高的，比如对外承诺、删数据、改线上配置，保留在自己手里，或者要求事前确认。
影响范围。影响限在本任务内的，给出去；波及其他团队、客户或线上稳定性的，升级标准要定得更靠前。
同一个成员，在不同任务上的授权程度可以完全不同。对新人全权放手和对熟人事事审批，犯的是同一个错误：用一个固定姿态应对所有情况，省掉了逐事判断的功夫。我以前恰恰是靠这个固定姿态过来的，只不过那时候姿态恰好是对的。
授权之后，管理者还背着什么
这是这篇里我最想记下来的部分。授权转出去的是决策权，责任没有跟着转走。管理者保留的责任有五块。
目标校准。授权后成员对结果负责，但结果和团队目标是否仍然对齐，要管理者定期看。方向偏了首先是校准没做，不能先记到成员头上。
资源协调。人手、时间、跨团队的依赖，这些超出成员职权的事，仍然由管理者去办。成员因为缺资源做不到，账不能记在他头上。
风险兜底。授权范围内的失误，管理者对外承担责任。追责追到具体做决定的成员头上，授权机制在团队里就失效了：下次没人敢接。
关键节点检查。到点就看，但只看过事先约定的节点，不事事过问。检查的密度和授权程度对应，范围越大越松，越窄越密。
复盘。事情结束后一起回顾：结果怎样，过程中哪些判断好、哪些可以改进，边界定得合不合适。没有复盘，授权就只是一次任务分配，能力没有积累下来。
这五块在小团队里同样存在，只是当时做得毫不费力：目标天天在同步，风险随时有人喊，复盘就是饭桌上的几句闲聊。团队大了之后，它们成了要专门安排的动作，漏掉任何一块，授权都会出现对应形态的失效。
授权失败的四个典型原因
培训里列了授权失败的常见形态，对照我自己的观察，基本能对上号。
目标不清。只说”把这个事负责起来”，没说交付什么、验收什么。成员按自己的理解做完，和管理者预期对不上，双方都委屈。
上下文不全。决策需要的信息管理者有、成员没有，比如背景约束、之前的承诺、上游的打算。信息没给到，等于要求对方在信息不全的情况下做完整判断。上一篇写反馈时提过同一个问题：管理者要先认下自己该提供的部分。
检查点缺失。授权时热热闹闹，之后直到交付才看。问题积累到结尾才暴露，纠偏的余地已经没有了。
一出错就收回全部决策权。这条最伤。结果不符合预期，管理者的本能反应是把权收回来，以后都自己定。短期看保险，长期看是告诉团队：接授权有风险，做错了代价是退回原点。更稳的处理是先复盘整件事，看是边界没定对、上下文没给全，还是成员判断确实出了问题，再针对性调整授权的范围，不要一刀切收回。
小结
对我自己来说，这个框架最大的变化在意识层面：授权从一个不需要想的问题，变成了一件要逐事设计的事。小团队里那个唯一的挡位曾经是对的，只是它不再够用。
授权需要逐事设计：结果、边界、约束和升级条件都要提前说清，检查与复盘也不能省。管理者保留目标校准、资源协调和风险兜底等责任，才能让成员在范围内真正承担决策。
