Day 58 · 2026.07.17

创意与研发团队领导:管聪明人,不能用管流水线的手

主题:Leading Creative & R&D Teams·4 个原则
"雇聪明人却告诉他们怎么做,是没道理的;我们雇聪明人,是为了让他们告诉我们该怎么做。" — Steve Jobs
本期的命题:你带的是一支 ML / research / 平台团队,全是比你更懂某个细分方向的人。用管交付团队那套(派任务、盯进度、按 ticket 计功)去管他们,会同时做到两件坏事:既压死创造力,又让最强的人先走。创意与研发团队的领导,本质是一门"给约束、不给指令"的手艺。本期四个原则——管理创意工作者(给上下文而非控制)、自主与方向(框架内的自由)、安全与创新(高安全 × 高标准)、失败容忍(区分好失败与坏失败)——帮你把一群难管的聪明人,变成一支持续产出非共识成果的团队。
PRINCIPLE 01

管理创意工作者:给上下文,别给控制 Managing Creatives — Lead With Context, Not Control

上下文自主动机
创意工作者的产出不是"手快",是"想得对"。你越用指令和审批去控制过程,越是拿走了他做对判断所需的上下文。管理动作要从"我告诉你做什么",转成"我确保你掌握足够的 why,好让你自己做出我也会做的那个决定"。
"Lead with context, not control. If you give your employees the information they need to make good decisions, you don't have to control them." "用上下文领导,而不是用控制。只要你给员工做好决策所需的信息,你就不必去控制他们。" — Reed Hastings,《No Rules Rules》(2020) Ch.9
情境:一位资深研究员想花三个月探索一个当前 roadmap 上没有、也没人要的技术路径,他很兴奋,你心里没底。
✗ 用控制回应

"现在先聚焦在 roadmap 上的东西,这个等有余力再说。" —— 你保住了这季度的确定性,但传递的信号是"你的判断不重要,按我的清单干活"。三个月后,最有想法的那个人开始更新简历。

✓ 用上下文回应

"我想听懂它。它如果成了,会解掉我们哪个真问题?"(给他表达 why 的空间)

"我的上下文是:这季度对 X 有硬承诺,我背着这个数。在不动摇 X 的前提下,能不能约定一个小切口——两周出一个能证伪的最小实验?成了我帮你要资源,不成也都学到了东西。"(给约束和路径,不给否决)

  • 我上次否掉一个想法,是给了"为什么不行"的上下文,还是只给了"不行"?
  • 团队卡住来问我时,我是直接给答案,还是补齐他缺的上下文让他自己定?
  • 我的审批环节里,有几个是真在控风险,有几个只是在满足我的掌控感?
  • 把"过程可见"当"过程可控"。要 daily 汇报每一步,聪明人会把精力花在让你安心,而不是把问题想对。
  • 用管资浅工程师的密度管资深研究员。方向感强的人被高频 check-in 会当成不信任;上下文更要前置,事后补的叫追责。
习作:这周挑一个你本来会"直接给答案"的求助,改成反问一句"你缺的是哪块背景?"——把上下文给足,让他自己做决定,然后忍住不修正。
思考题:我团队里如果有人做了一个和我不同、但基于同样上下文的合理决定,我的第一反应是"好,他能独立判断了",还是"他怎么没按我想的来"?
PRINCIPLE 02

自主与方向:框架内的自由,而不是放养 Autonomy & Direction — Freedom Within a Frame

赋能团队护栏北极星
自主不等于放养。创意团队跑偏,几乎总是因为你只给了自由、没给方向;而团队僵死,几乎总是因为你只给了方向、没给自由。答案是"框架内的自由":给团队一个要解决的问题和一组不可逾越的护栏,把"怎么解"完全留给他们。
"The key is to give teams problems to solve, rather than solutions to implement. Empowered teams are measured by outcomes, not output." "关键是给团队要解决的问题,而不是要实现的方案。被赋能的团队,用结果来衡量,而不是用产出量。" — Marty Cagan,《INSPIRED》(2nd ed., 2017)
护栏(我锁死,不可动) · 要解的问题 / 北极星指标 · 安全 / 合规 / 伦理红线 · 截止日与预算量级 自由区(团队全权决定) · 用什么技术方案 / 架构 · 怎么拆解、谁做哪块 · 试几条路、如何取舍 领导的活:护栏说清、说少 → 自由区越大越可信 护栏含糊或频繁改 → 团队缩回来等你拍板,自主就死了
情境:你给团队"降低推理延迟"这个问题,两周后发现他们在重写整个服务框架——技术上有意思,但离目标越来越远。
✓ 校准方向,不收回自由

"先确认北极星:这季度要把 P95 延迟砍到 200ms 以内,对吧?现在的方向是重写框架——帮我理解,这条路怎么最快指向那个数?"

"如果它是三个月的投资、这季度指标反而更悬,可能就选错了切口。方案我不替你们定,但护栏得守:先拿到那个延迟数。要不要一起把选项按'离目标的距离'排个序?"

  • 我给的是一个要解的问题,还是一份要造的功能清单?(后者是伪授权)
  • 我的护栏能不能一句话说清?说不清的护栏,团队没法在里面自由。
  • 我衡量他们用的是 outcome(问题解没解)还是 output(写了多少代码)?
  • 假授权。嘴上说"你们定",方案一不合心意就推翻——一次就够团队学会"等你拍板最省事"。
  • 护栏漂移。目标每两周变一次,团队永远在重启,自主变成无所适从。
  • 只给自由不给北极星。没有共享目标的自主,是一群人朝不同方向使劲。
习作:给团队一个当前任务,写下你的护栏(≤3 条)和自由区各一栏,发给团队问:"边界清楚吗?哪里你觉得被过度框住了?"
思考题:上次我推翻团队的技术方案,是它真会撞上护栏,还是仅仅因为"跟我想的不一样"?
PRINCIPLE 03

安全与创新:高心理安全 × 高标准,才有 learning zone Safety & Innovation — Where High Safety Meets High Standards

心理安全高标准learning zone
创新需要有人敢说出半成型、可能很蠢的想法——这要心理安全。但心理安全不是降低标准、一团和气。真正孕育创新的是"高安全 × 高标准"那个象限:既敢冒险直言,又对结果较真。只有安全没标准,是舒适区;只有标准没安全,是焦虑区。
"Psychological safety is not about being nice. It's about candor... It is not the absence of standards; combined with high standards, it creates the conditions for high performance." "心理安全感不是一味和气,而是敢于坦诚……它不是降低标准;只有与高标准结合,才创造出高绩效的条件。" — Amy Edmondson,《The Fearless Organization》(2019)
心理安全 → 对结果的标准 → 舒适区 Comfort 敢说,但没人较真 和气,不出成果 学习区 Learning 敢冒险 + 对结果较真 创新在这里发生 冷漠区 Apathy 不敢说也不在乎 焦虑区 Anxiety 要求高但不敢冒险 藏问题、报喜不报忧
情境:架构评审会,一位工程师抛出大胆但明显不成熟的方案,另一个资深立刻说"这根本行不通"。全场安静,提出者脸红了。
✗ 让它过去 / 或和稀泥

你要么装没看见(下次没人敢抛半熟想法 → 冷漠区),要么打圆场"大家都有道理"(没了标准 → 舒适区)。两条路都杀创新。

✓ 保护冒险的人,同时保住标准

"等一下——先谢谢你把这个还没想透的东西摆出来,这正是评审该有的样子。"(保护冒险行为)

"'行不通'拆开看:是哪个具体假设撑不住?如果是延迟,能不能只验证那一个假设,而不是否掉整个想法?"(对事较真,把"否定人"转成"证伪假设",标准不降)

  • 上一个被否的想法,我们否的是"这个人"还是"某条具体假设"?
  • 我自己在会上认过"我不确定 / 我错了"吗?领导先示范脆弱,安全才是真的。
  • 把心理安全误当"不能批评"。于是烂方案也不敢说破——那不是安全,是冷漠区。
  • 只保护安全,忘了标准。创新团队最怕"人人都好棒棒",最后什么都出不来。
Female Leader's Note 脑暴与评审里有个反复被验证的现象:女性和资浅成员的想法,更容易被忽略或被他人"重述后归属"(idea appropriation)。领导可当场做归因锚定——"这点最早是 A 提的,顺着 A 的思路往下"——一句话既护了原创者,也示范"在这里冒险提想法,功劳算你的"。
习作:下次评审会,当一个半熟想法被否时,把"这行不通"改写成一个问题:"它靠哪条假设?能不能只测那一条?"——把否定人转成证伪假设。
思考题:我的团队更像哪个象限?"舒适区"是我用"和气"换掉了标准;"焦虑区"是我要的高标准里带着惩罚——是哪种?
PRINCIPLE 04

失败容忍:区分"好失败"和"坏失败",只奖前者 Tolerating Failure — Reward the Right Kind of Wrong

失败光谱聪明的失败复盘
"容忍失败"最容易被做歪:要么变成"什么错都无所谓"(纵容疏忽),要么口头容忍、暗地记账(没人再敢冒险)。正解是把失败分级:可避免的疏忽型失败该问责,探索未知的聪明失败该奖励。创新的失败不是必要之恶,是做新东西的必然副产品
"Mistakes aren't a necessary evil. They aren't evil at all. They are an inevitable consequence of doing something new." "错误不是必要之恶,它根本不是恶。它是做新东西不可避免的结果。" — Ed Catmull,《Creativity, Inc.》(2014)
该问责 ← → 该奖励 可避免的失败 已知流程没照做 疏忽 / 走捷径 → 该纠正、该问责 复杂系统失败 多因素叠加 难完全预防 → 建早期预警 聪明的失败 探索未知的实验 假设明确、代价可控 → 该奖励、该传播
分级来自 Amy Edmondson「Strategies for Learning from Failure」(HBR 2011)。"聪明失败"的四个特征:(1) 探索新领域,答案本就未知;(2) 有明确假设,不是瞎试;(3) 代价刻意控制在小范围;(4) 事后能提炼出可复用的知识。四条全中,才配叫"聪明失败"。
情境:团队投六周做一个新模型架构,指标没跑赢 baseline,项目要停。工程师很沮丧,团队在看你怎么反应。
✗ 罚,或假装无所谓

"这六周基本白费了。"——一句话教全团队以后只提稳赢的项目。或反过来,不复盘、拍拍肩"没事下一个"——失败里的知识也一起蒸发了。

✓ 先归类,再提炼,公开传播

"先说清楚:这是一次聪明的失败,不是搞砸了。方向未知、假设明确、代价控制在六周,这正是我们该做的下注。"

"现在做最有价值的事:把它变成团队资产。写一页——赌的假设是什么、为什么没成、下一个碰这方向的人该避开什么。这页我在组会上讲,署你的名。"

  • 这次失败落在光谱哪一段?我是不是把"聪明失败"和"疏忽失败"一视同仁了?
  • 提"稳赢小项目"和提"高风险大赌注",在我这待遇一样吗?不一样,就没人会赌。
  • 口头容忍,绩效记账。嘴上"失败没关系",perf review 却只认成果——团队一眼看穿,从此只求稳。
  • 把所有失败都当"学习机会"。疏忽型失败也不问责,就是纵容,标准崩塌。
Female Leader's Note 研究(含 glass cliff 文献)显示,女性和少数群体的失败常被更严苛地归因、更长久地记住,同等失败在多数群体身上却被视为"值得的一搏"。领导公开、明确地把某次失败命名为"聪明的失败"并写进正式记录,不只是安慰当事人——更是在纠正这种不对称归因,让"该被奖励的冒险"对所有人一视同仁。
习作:翻出团队近三个月一次失败的尝试,用上面四个特征归类。若是"聪明失败",补一次迟到的公开肯定,并让当事人写一页 learnings 进 wiki。
思考题:我嘴上"鼓励冒险",但诚实回看我实际奖励和晋升的人,我是在奖励结果,还是奖励"敢在未知里下注并从中学习"?

深入思考

"给上下文不给控制"在成熟资深团队里很美,但如果我带的是一群资浅、方向感还没建立起来的人呢?
上下文 vs 控制不是开关,是一根随人成熟度滑动的滑块。对资浅的人,"上下文"里本就该包含更具体的方向、更密的 check-in、甚至一段示范——这不是控制,是在帮他建立做判断所需的上下文。危险的是把这套高密度指导原封不动用到资深研究员身上,或反过来对新人过早放手再怪他"没自己搞定"。给上下文的精神不变(永远解释 why),密度随人而变——这正是 Hersey-Blanchard 情境领导的内核。
"失败光谱"听着清楚,但现实里一次失败往往同时有疏忽和探索的成分,怎么分?会不会成了各打五十大板的和稀泥?
现实的失败确实是混合的,但正因如此才要拆开归因,而不是给整件事打一个模糊的总分。把一次失败拆成几条具体的决策,逐条判:探索未知的那部分归"聪明失败",该奖;已知流程没照做的那部分归"可避免失败",该纠正。同一次事件里,可以既表扬冒险、又指出疏忽——这不是和稀泥,恰恰是最精确的反馈。和稀泥是"整体还行下次注意";精确是"你赌这个方向对,我支持;但你跳过了压测那步,不能再有"。
大厂考核是季度 OKR、按交付量给分,我一个 tech lead manager 凭什么在这种系统里保护"聪明的失败"?
这是最真实的张力,别用理想主义糊弄。三层:(1) 向上翻译。把高风险探索用老板听得懂的语言包装成"对冲性投资"和"能力建设",让失败的实验在汇报里也有正当位置,而不是只报成的、藏没成的。(2) 用可控代价买探索空间。把探索切成小、快、代价明确的实验,季度里留出 10%~20% 带宽,失败也不伤主线 KPI,你才有底气护它。(3) 认清系统的边界。若组织真的只奖稳赢、任何失败都算减分,你能在缝隙里护一点,但改不了水温——这时诚实的问题是:这还是不是适合做创新团队 leader 的地方?