2023年Q2,谷歌某产品线的一个功能更新,在各部门已达成一致的情况下,硬是在"等待确认"的状态里躺了11周。不是技术卡壳,不是预算没批,是没人敢拍板。

这不是个案。产品团队内部调查显示,超过60%的中层管理者承认,自己曾把本可当场定夺的事项"往上推一层",只为规避个人责任。加速的反面,正在大公司里系统性上演。

「跨部门对齐」是怎么变成「集体甩锅」的

「跨部门对齐」是怎么变成「集体甩锅」的

理想的协作流程像接力赛:产品出方案,技术评估可行性,法务扫雷,运营准备上线。各棒交接顺畅,项目往前跑。

实际运行中,这套机制产生了意外的副产品。每个环节的人都完成了"内部对齐",但没有人对整体结果负责。产品说"技术没给明确排期",技术说"法务风险还没清",法务说"运营场景没确认全"。

决策的物理形态从"一个人签字"变成了"一群人点头",但点头的门槛被无限细分。

更隐蔽的问题在于:没有正式的升级(escalation,向上提请裁决),就没有明确的拖延责任。项目卡在"待确认"状态,像电脑进程占着内存却不运算——表面没死机,实际已僵死。

一位前谷歌中层向我描述过一个典型场景:会议室里八个人,议题是是否上线A/B测试的变体版本。讨论45分钟后,所有人认同"方向正确",但主持人最后说"我们再和亚太区同步一下"。

会后追问,亚太区负责人其实已在邮件里表过态。那个"再同步",是主持人给自己留的退路。

权威稀释:当组织架构比产品迭代还快

权威稀释:当组织架构比产品迭代还快

谷歌2022-2023年的架构调整频率,创下了近十年纪录。搜索、广告、云三大业务线各自重组,中层汇报线平均6个月变一次。

频繁变动的直接后果:决策者的权威没有足够时间沉淀。一个新上任的总监,面对需要跨组协调的事项,第一反应不是"我能定",而是"我需不需要再拉一个人一起担"。

这种现象在学术上有对应概念,叫"权威规模不经济"(authority diseconomies of scale)。组织越大,正式层级越多,非正式信任网络越稀薄,决策反而越慢。

亚马逊早年用"两个披萨团队"(two-pizza teams,人数控制在两张披萨能喂饱的规模)对抗的就是这个。但谷歌的产品复杂度——搜索涉及数百个信号模型,广告系统耦合全球竞价引擎——让"小团队自治"成了理论上的美好。

当系统复杂到没人能单独看懂全局,"集体决策"就成了风险均摊的避风港。

一位现任产品经理的观察很直白:"现在写文档的时间比写代码长。不是文档真有那么重要,是文档是免责的证据链。"

加速的幻觉:工具越先进,人越不敢动

加速的幻觉:工具越先进,人越不敢动

讽刺的是,这套僵局的背景是史上最强的协作工具栈。Notion文档实时同步,Figma设计一键评审,Slack把响应时间压到分钟级。

工具消除了信息延迟,却没消除决策焦虑。相反,信息的即时可得性制造了新的压力——"我再等等,说不定下午就有新数据"。

产品团队做过一个实验:把某功能的决策截止日从"下周"明确到"周五下午5点",逾期自动进入默认方案。结果那个项目的推进速度比之前快了三倍,争议反而更少。

「截止时间比共识更能驱动行动」,一位参与实验的工程师说,「没有DDL(deadline,截止日期),所有人都是完美主义者。」

这个发现指向一个反直觉的结论:加速需要的不是更多信息,而是更清晰的权力边界。知道谁最终拍板,比知道所有细节更能减少内耗。

小团队的反击:用"战时机制"绕过官僚层

小团队的反击:用"战时机制"绕过官僚层

不是所有团队都选择躺平。谷歌内部近年涌现了一批非正式的"加速小组",操作模式高度相似:从各职能部门抽调一人,物理上坐在一起(或强制全天视频),目标单一且时间盒定死。

一个广告系统的紧急修复项目,用这种模式在72小时内完成了原本需要两周的跨部门评审。秘诀很简单:那个小组被临时赋予了"无需二次确认"的权限,代价是如果出问题,全组共担责任。

风险共担替代了层层审批,成了新的信任货币。

这种模式能复制吗?很难。它需要高层明确的授权背书,需要参与者愿意放弃"留痕自保"的习惯,更需要一个具体的、有紧迫感的任务目标。日常迭代很难满足这些条件。

但它至少证明了一点:决策瘫痪不是技术问题,是激励机制设计的问题。当"不做不错"的收益高于"做了可能对",理性人都会选择等待。

那个延迟11周的功能,最终上线后的数据表现超出预期。复盘会上有人问:如果当初少开三次会,会不会更早拿到这个结果?

会议室沉默了几秒。没人接话。