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