“跨职能团队失败的原因，几乎从来不是人。”花了二十年搭建软件团队，我花了最长时间才彻底接受这个事实。
微软当年就狠狠地上过一课。被苹果和谷歌压着打了快十年，问题不出在缺人才、缺野心，而出在一套叫“堆叠排名”的绩效办法上。这套系统逼着员工互相打分、彼此竞争，把协作变成了一件违背生存本能的事。帮别的团队成功，开始像给自己挖坑。久而久之，楼里最能干的那批人，干脆不再合作了。不是因为彼此有敌意，而是这个制度把合作变成了一种自毁前程的选择。
今天多数公司早就不用堆叠排名了。但在几十个团队里，我反复看到了同一个剧本，只不过演法更隐蔽：产品经理拒绝优先处理一个不影响自家指标的需求，部门主管在要求“全员对齐”的规划会上死死护住预算。这些场面都谈不上人品问题，而是组织结构设计出来的必然结果。
大多数跨职能团队的诊断，从一开始就跑偏了。
不妨看看当产品、工程、销售三拨人被拉到一起推进一个新项目时会发生什么。产品团队的绩效看路线图交付，工程团队看系统稳定性，销售团队看管道数字。当取舍时刻出现——它迟早会出现——每个人下意识的判断，都不是冲着“共同目标怎么赢”，而是围着“自家结果怎么保”打转。这不是个性缺陷，更不是什么协作技巧的短板。这是一种激励结构上的扭曲，而任何再好的沟通培训也粘合不了。
绝大多数组织的本能反应，是治症状。安排工作坊，引入新的沟通框架，搞一次团建。但根本问题留在原处：每个人仍然在被不同的、甚至彼此冲突的标准考核着。只要人们是在孤立的指标里各扫门前雪，协作说到底只是一个可选项。
反过来，换一套围绕共同成功的单一绩效标准，它对行为的影响力，比任何宣导都强得多。 不过这种设计有一个硬前提：高管层必须首先实现真正的对齐。高层领导如果各自打着部门算盘，下属团队必定跟着上桌玩起同一款地盘博弈游戏。领导层对齐绝不是锦上添花的加分项，而是一项必备条件。
有一件事，应该在拉起任何一支跨职能团队之前就动手做完：彻底审计与这支团队相关的全部激励制度、汇报关系和成败衡量标准。磨结构，远比磨嘴皮子管用。
热门跟贴