AIHR
好团队不是挑出来的，是设计出来的。选人能决定天花板，但决定不了实际效能；真正决定效能的是这个团队被放置的条件：它要完成什么、边界划在哪里、信息怎么进来、反馈多久给一次。
一、选人解决不了的问题
把五个能力强的人放进一个团队，最常见的结局不是超常发挥，而是互相消耗。原因不在人，在于能力是个体属性，效能是系统属性。个体能力要经过协作结构才能转化为团队产出，而协作结构不是选人时顺便产生的，它需要被专门设计。
Hackman 在研究团队效能时给出的结论很直接：领导者无法直接制造团队协作，能做的是创造条件，然后让团队在这些条件下自行演化。这个判断把管理者的角色从「激励者」改成了「条件设计者」。前者作用于情绪，后者作用于结构。
这也解释了一个常见现象：同一个团队换一位管理者之后表现差异巨大，而成员一个没换。变的不是人，是条件。
二、效能来自五个条件，不来自成员构成
Hackman 提出的团队效能框架里，有五个条件被反复验证与效能相关。
第一是真正的团队，也就是边界清晰、成员相对稳定、彼此需要依赖才能完成工作。很多名义上的团队并不满足这一条：一群人各自做各自的事，只是共用一个主管，这不是团队，是编组。
第二是有分量的方向。目标必须足够清晰，让团队能自己判断什么该做；也必须足够有分量，让成员认为值得投入。方向含糊时，团队成员会各自按自己的理解行动，协作就退化成协调。
第三是合适的结构。包括任务设计本身是否值得协作、团队规模是否合理、成员构成是否覆盖了必要的能力、以及规范是否明确。规模这一项常被忽略，团队越大，协调成本上升的速度远快于人力增加的速度。
第四是支持性的组织环境。信息共享是否通畅、资源是否到位、评价体系是否承认团队贡献。这一条最容易被忽略，也最常成为效能的实际上限：一个只奖励个人贡献的评价体系，会持续地削弱协作动机。
第五是适时的外部辅导。团队在起步期和遇到瓶颈期最需要外部视角，但辅导必须由团队自己决定是否采纳，否则会变成干预。
这五条里，只有第三条与成员构成直接相关。其余四条都是条件问题，也就是设计问题。
三、心理安全不是氛围，是信息通道
Amy Edmondson 在 1999 年提出心理安全这个概念时，指的是一种共同信念：在这个团队里，承担人际风险是安全的。Google 在 2015 年的亚里士多德计划中研究了内部上百个团队，发现心理安全在区分高效团队与低效团队的各项因素里排在最前。
这项研究常被误读成「团队要和谐」。实际上心理安全讨论的是信息通道：成员是否愿意提出问题、承认错误、表达不同意见。心理安全低的团队不是冲突多，而是冲突不出现在台面上。问题被藏起来，直到变成事故。
从设计角度看，心理安全有三个可操作的抓手。一是领导者对错误的反应，是追问原因还是追查责任；二是异议是否有正式的出口，比如是否有固定的复盘机制；三是团队成员是否知道彼此的工作细节，不了解就会产生猜疑。
这三个抓手都是设计项，不是性格项。一个性格内向的团队也可以有高心理安全，只要它的复盘机制是稳定的、追责边界是清晰的。
四、三个最值得投入的设计项
条件很多，投入有限。三项设计通常回报最高。
第一项是任务边界。一个团队负责的事应该有清晰的起点和终点，也应该有可以自己控制的完整环节。任务被切得太碎的团队，成员看不见自己工作的完整结果，责任感会持续流失。这是最容易修的一项，通常只需要调整一下分工。
第二项是信息通道。团队需要知道自己做得怎么样，也需要知道外部环境发生了什么。前者是绩效反馈，后者是情境信息。两项缺失任何一项，团队都会做出方向错误的努力。多数团队的反馈周期过长，季度一次的评估对日常改进几乎无效。
第三项是依赖关系的显式化。让每个成员写下自己需要依赖谁、谁依赖自己，然后把这些依赖摆出来对齐。这一步会暴露大量从未被讨论过的隐性依赖，也是团队协作里最常出问题的地方。
这三项设计有一个共同点：都不需要额外预算，只需要调整现有安排。这也是优先做这三项的原因，它们的成本主要落在管理者的注意力上，而不在资源上。
五、设计的代价：效能与速度的取舍
追求高效能是有代价的。清晰的边界降低了灵活性，稳定的成员构成降低了调配速度，充分的协商延长了决策时间。这些代价在稳定环境中值得付，在剧变环境中可能不值得。
设计者需要明确一件事：这个团队被要求交付的是稳定的高质量产出，还是快速的响应。前者需要完整的五项条件，后者可以牺牲成员稳定性和协商充分性，换取速度。
把两种要求混在一个团队上，是最常见的设计错误：既要求它稳定输出，又要求它随时响应新需求。结果是两项都做不到，成员长期处于被打断的状态。
六、哪些团队不该按高效能来设计
至少两类团队不适合套用高效能框架。
一类是专家集合型团队。成员各自是高水平的独立贡献者，彼此之间依赖很弱，比如一组资深顾问或一组研究科学家。强行增加协作要求，只会把他们的专长时间切碎。对这类团队，提供支持与减少干扰比设计协作更有用。
另一类是危机响应型团队。它需要在极短时间内形成判断并行动，结构上更接近指挥链而非协作网络。这类团队效能的关键是信息的准确与指令的清晰，不是成员之间的相互依赖。
判断标准很简单：这个团队的产出，是需要成员之间互相调整才能完成的，还是各自完成再汇总就能得到的。前者才需要按团队来设计。
七、规模是被低估的设计变量
团队规模对效能的影响常被低估。成员从五人增加到十人，需要维护的协作关系不是翻一倍，而是增加数倍：每增加一名成员，新增的沟通链路与所有既有成员相关。
Hackman 的建议是规模应当控制在完成任务所必需的最小值。这条原则在实施中经常被违反，原因通常是政治性的而非任务性的：把某个职能放进团队，意味着该职能在组织中的地位被承认；把某个人放进团队，意味着他在这件事上的话语权被确认。规模因此成了组织政治的副产品，而不是任务需要的产物。
规模过大的后果是具体的。决策变慢，因为需要对齐的人更多；责任分散，因为没有人对整体的某一块有完整的所有权；个别成员的实际贡献变得难以观察，因为每个人的工作都被淹没在整体产出里。最后一项会反过来破坏评价体系：当贡献不可见时，评价只能依据可见度，而不是实际产出。
可行的修法有两种。一是拆成子团队，每个子团队有自己清晰的交付物与边界；二是把一部分人改为明确的协作方而不是团队成员，按需要接入，不参与日常决策。两种做法都比维持一个大团队有效，代价是需要有人专门维护子团队之间的接口。
结语：设计者的产出不是氛围，是条件
管理者在团队效能上能做的，不是让每个人更有干劲，而是把边界、方向、信息通道和评价体系摆到正确的位置上。这些条件到位之后，协作会自己发生；条件不到位，再多的团建也补不上。
这也是为什么团队效能问题反复出现时，应该先查设计而不是先查人。换人的成本最高，效果最不可控；改条件的成本通常低得多，而且可验证。
