# 27 敞开和服 培养有凝聚力的团队并不容易，没人可以保证做到，尤其是在最需要的时候，往往没人能迫使它发生。有时候，人员组成了一个小组，小组的人却不想凝聚成一个团队；他们就是独狼，喜欢一个人。 在《人和项目管理》一书中，Rob Thomsett 分析了阻碍团队形成的病因。读来饶有趣味。然而，这些病因基本上无药可治，唯一可行的疗法就是将那些阻碍团队凝聚的个人踢出团队。从学术上讲，这可能是合理的，但现实操作起来，你会发现这其实再愚蠢不过了。因为那个你想踢出去的人在其他方面可能是一把好手。很多事情都需要在没有凝聚力的团队中开展（并获得成功）。 尽管说了这么多，我们知道一个不可争辩的事实：一些管理者确实非常善于帮助团队形成凝聚力。他们成功的几率非常高。本章，我们会分析一下这种以团队为导向的管理者有些什么特点： ### 感觉好，请“病”假 你一定见过有人打电话请病假，或许你自己也这样干过几次：但是你可曾想过，有人会因为状态很好而打电话请假吗？ 情形可能是这样的：你给老板打电话说，“听着，我从在这儿工作起就开始生病；但我今天感觉挺好，所以我就不来上班了。” 当大家谈起一个组织，需要员工“病态”才能为其工作时，他们说的并不是生理上的病态，而是指在这种地方工作，需要扭曲一些精神上的生存法则，而这些法则本身是保护我们心理健康的。这些法则中最重要的就是关于自我认知。要是一项工作伤害了你的自我认知，本身就是“病态”。 只有在工作中感觉良好，才会增强自我认知。从事这样的工作，是对自身在相关领域竞争力的认可，并且能够给予员工足够的自主权，让他们能够同时履行对应职责。一经授权，这些优秀员工的管理者会小心翼翼地呵护这种自主权。他们知道，虽然员工的失败会让老板感到难堪，但这只不过是游戏中的一个小插曲罢了。他们对于偶然的倒退心有准备，也愿意接受其中一个人的失败带来的直接后果。一旦事情发生，他们也会心存怀疑，要是自己亲自操刀而不是去管理别人来执行，这种失败或许永远都不会发生。但这又有什么大不了的呢？你已经做到了唯才是举，人尽其才，那就要做到用人不疑。 敞开和服( Open Kiraono)酌态度恰好是防御式管理的反面。用人不疑，你将他放在这个岗位上，就要信任他，不需要做任何防御。你领导下的所有人都是值得信任的。一个不被你信任，工作没有自主权的人，对你来说简直一无是处。 我的第一个老板是 Jerry Wiener，他曾经在达特茅斯的通用电器管理过时间共享项目( time sharing project)的开发工作。后来，他自己成立了一家小型的高科技公司。当我加入时，他们正好在洽谈一个比公司已有任何项目都要大得多的合同。当公司律师把合同交给 Jerry 时，大家都聚在一起。律师让 Jerry 认真阅读合同，然后在最后一页签字。“我不读合同，”Jerry 说道，然后就开始签字。“天哪，等等，”律师说，“让我再检查一遍。” -TDM 这一经验并不是告诉你可以不检查合同就签字（当然，如果你请了专家来帮你把关，那也未尝不可）。如果你接受了错误的建议，你也是死路一条。对于能够熟练完成自己领域工作的管理者来说，评审合同应该超出他们的知识范畴了。检查合同可不是靠自负就能做到的。Jerry 费了九牛二虎之力才聘请到他能找到的最棒的律师，他定然已经了解过这个人过去的工作情况。现在，可没时间再来防御了；轮到老板向每个人展示信任、依靠大家的时候了。 老板将自己的声誉托付给下属，会诖大家感到那么一点小小的兴奋和刺激。这会使每个人竭尽全力。团队的形成就变得有意义了。大家不仅仅是在完成工作，更是在证明对他们的信任是值得的。正是这种敞开和服的管理方式让大家最有可能形成团队。 ### 走出去 老板防着自己人的最常见办法就是进行物理监控。他们在工作区域里到处巡逻，寻找着那些可能犯错或者能力不足的人。他们就是帕金森式的巡警，时刻不会掉以轻心。当然没人（不管是管理者还是员工）会这样想，因为这就是公司文化的一部分。对于很多管理者来说，想不这样做都是不可思议的。 我最近的一个咨询项目是为加利福尼亚的一家公司建立客户信息系统。需求说明已经写好，准备开始做系统内部设计了。这时，老板把我们所有人叫到一起，然后给我们每人一张地图，上面标出了一间远离长岛的办公室。他解释说，那里有间空着的会议室，可以使我们不受打扰，而他则会留守本部，帮我们过滤掉那些不重要的电话。最后嘱咐我们“做完了再回来”。两个多星期后，我们带回了一个很酷的设计。这期间，老板从来没有打过电话或者跑 来查岗。 -TRL 如果你的下属很有能力，要提升成功几率，可能没什么比偶尔让你自己远离他们更加有效了。任何一种容易隔离出来的任务都是一个好机会。这些任务不需要真正的管理存在。把大家送走，找一个偏远的办公室，要一间会议室，租一栋度假别墅，或者住到酒店。也可以趁着淡季去滑雪场所或者海滩。又或者召集他们一起去参加会议，然后多留几天安安静静地一块工作。（每种法子我们都至少听说过一次。） 因为这样的计划有些大胆，你的管理层和同事一定会心生疑问。他们会问：你怎么知道这些人此时此刻不是在神游？你怎么知道他们不会 11 点就去吃午餐，然后一下午都去喝酒聊天？答案很简单，从他们交付的产品就能知道。通过他们耕耘的成果，你就能了解他们。如果他们交付了一个精心设计得到的完整结果，就证明他们努力工作了；倘若没有，就说明他们人浮于事。对于开发工作者来说，那种看得见的监控就是开玩笑；监狱里的犯人才需要这种看得见的监控呢。 离开办公室在诸多方面皆有裨益。首先，排除了对你最有价值资源的各种干扰和打断。或许有一天，你可以建立一个高效的办公环境，人们能够在这样的环境下朝九晚五地完成工作。但这也可能遥遥无期。在短时间内，找命借口让你的团队走出去吧。除了可以让他们效率更高之外，这种完全自主的时间则有机会让他们形成一个士气高昂的团队。 ### 存在规则，但我们要打破规则 工程类职业有一种众所周知的开发模式，这种模式在其他地方是没有的，那就是臭鼬工程项目。臭鼬工程指的是项目可以在上层管理不知情的情况下悄悄展开。当底层的员工深信产品的正确性，因而不愿意接受管理层取消项目的决定时，这种项目就会诞生。电子设备公司（Digital Equipment Corporation）的 PDPII，是公司最成功的产品之一，它就是在如此背景下产生的。这样的项目可大有学问。有趣的是，臭鼬工程的另一面就是犯上作乱。管理层说不，项目却照常进行。 我的一位客户尝试着取消一个被认为没有市场的产品。勇于挑战的斗士取得胜利，最终产品被制造出来了。产品取得了巨大的成功。那个没能成功扼杀项目的经理（如今已是那家公司的总裁）给团队定制了一座奖杯，上面书写着“首届犯上作乱奖”。他做了发奖感言，说：以后谁要是犯上作乱，最好也这么成功。要是作乱失败了，别想给任何人带来奖杯： 各个级别的人士其实都知道在一些敏感领域犯上作乱到底能不能接受。大家都期望那种敞开和服式的管理者：他们希望让这些管理者脸上有光，尽管管理者们可能只是临时起意做出了决定：防御心重的管理者得木到人们的支持： ### 带嘴唇的鸡 20 世纪 70 年代中期，组织系统顾问 Larry Constantine 为特定的几家公司提供建立健康公司社会生态圈方面的帮助。在他给公司提出的建议中，有一点就是让最底层员工能够在团队选择过程中具有发言权。具体到实施，这个想法变成了公司把新项目粘贴到中央报亭。员工们自发组成参选团队来“竞标”项目。要是你们几个人向往一起工作，就可以把自己的简历一块提交，组成一个团队来竞标。评判标准为成员的胜任程度，成员之间的互补程度，以及把各个成员放在一起对其他项目的影响程度。公司由此挑选最适合的团队。 这样的设计给了员工两个维度上不同寻常的自由：他们能够选择自己工作的项目和自己的团队。令人惊讶的发现是第一个维度并不起什么作用。管理层一开始担心只有最耀眼的项目会有人竞标，事实却并非如此，即使最烦琐的项目也有人竞标。能够有机会与自己渴望共事的人一起工作，看起来更加重要。 在第 16 章中，我们提到的招聘试演的想法具有同样的作用。项目团队成员不仅仅是试演的观众，他们还具有话语权，可以决定是否雇用此人。除了技术方面的判断之外，他们还从团队的角度考察此人是否适合团队：“我想我们可以和他一起工作”，或者“他看起来合格，但他可能在团队中不会有大的发展空间”。 几年前，我们在～个融合得很好的团队中工作。该团队里的成员开始形成了很多共同的特质——尤其是一种近似的幽默感。我们甚至发明了一套关于幽默的理论。理论说：有些事物天生就有趣，比如鸡就有趣，但马却无趣；嘴唇很逗，手肘和膝盖让人发笑，但肩膀就仅仅是肩膀。有一天，我们一起面试一位新成员。当这位新人说完离开后，一名同事评论道：“我想他的学识让我们挑不出刺儿来：但是，你们觉得他会有一天觉得有嘴唇的鸡有趣吗？”这位新人最后没有得到这份工作。 ### 这里谁说了算？ 最好的老板都会冒些风险。他们勇于在他们的员工身上冒险。并不是说好的管理者就不管理，而是他们不会给出固定的方向或者独断专行。他们必须时刻做出决定和判断。这里给出的建议是他们应该充分利用那种与生俱来的权威。在匠艺级的大师与学徒之间横亘着这种与生俱来的权威——大师知道如何开展工作，学徒不会。服从这样的权利不会贬低任何一个人，不会消除激励，也不会让同事之间变得不融洽。这种服从的反面则是出于不安全感而要求的服从，它表明，“我们属于不同阶层的种族，我是一名高高在上的管理者。我属于思想阶层，隶属我麾下的员工必须执行我的决定。” 在最好的组织里，这种与生俱来的权威在各个方面发挥着效力。大家知道一个管理者的长处，可能是制定大方向、进行谈判或者招聘，而且大家对他做这些事情心悦诚服。每个员工皆有一技之长，而且在相虚的领域具有权威性，从而被大家所信任。在敞开和服的氛围下，团队有最大的融合可能。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://doc.shiker.tech/ren-jian/di-si-bu-fen-gao-xiao-tuan-dui-yang-cheng/27-chang-kai-he-fu.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.