del

极客时间专栏/geek/技术管理案例课/二线经理：开始带经理了/12 | 进阶心路：不要轻易跨过一线经理，给员工安排工作！.md

@@ -0,0 +1,199 @@
+<audio id="audio" title="12 | 进阶心路：不要轻易跨过一线经理，给员工安排工作！" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/37/58/3795a312e401b80b5d15ed675fa1yy58.mp3"></audio>
+
+你好，我是许健。从今天开始我们进入了一个全新的模块——二线经理。
+
+二线经理顾名思义就是管理一线经理的经理，也就是手下管的是经理而不是一线员工。今天我就和你聊一聊进阶二线经理的心路历程。
+
+那二线经理和一线经理到底有什么区别呢？这里有一个很大区别就是我们的能力要全面提高。在事务管理上二线经理需要有自己的**愿景**，并具备**在更大量的信息中抓住重点和深入分析**的能力；在人员管理方面，因为下属是一线经理，他们的成熟度和处理问题的能力相比一线员工要更好，所以留给二线经理处理的问题基本上都是**棘手难办**的问题了。
+
+我们公司是有健全的一线经理培训体系的，但是却没有相应的二线经理培训体系，基本上晋升到二线经理就是直接扔到战场上，通过实战慢慢积累经验。
+
+我自己在这条路上就出了问题，而且据我了解，这些问题都是我们进阶到二线经理后，高频发生的共性问题。解决一线经理不能搞定的问题，这样才能体现二线经理的价值。这句话听上去有点虚，所以接下来我分别从把事管好和把人理顺两个方面来跟你解释，二线经理相对于一线经理有什么不同。
+
+## 把事管好
+
+我们进阶二线经理，其实首先要转变的就是管事情的思路。把事管好，是二线经理的首要特质。
+
+刚刚做二线经理，很容易出现越级指挥，跟进项目时流于表面，以及布置任务急于“亲自作战”的问题。
+
+那我们应该怎样做才能把事情管好呢？**我们不仅要学会集权，更要学会授权；我们不仅要向上管理，更要下沉管理；我们不仅要处理任务，更要学会更好地布置任务。**
+
+### **处理好授权和集权的关系**
+
+作为一个二线经理，我们下面还有一线经理，这里要注意一个升为二线经理后的重大转变：你是通过管理一线经理来管理一线的员工，而不是直接管理一线员工。
+
+如果我们总是越过一线经理，直接给员工安排工作，这就是大忌，为什么这样说呢？下面我给你分析一下。为了方便你理解，这里我们假设王总是直接给一线员工安排工作的二线经理。
+
+**一线经理心里会怎么想？**
+
+王总经常跨过我，给我的部下安排任务，那他要我干什么呢？他是不是觉得我跟他思路不一致？他是不是信不过我？
+
+**一线员工心里会怎么想？**
+
+奇怪，王总老是越过我的上级直接给我安排任务，那我的上级是不是在王总那里出了什么问题，如果王总跟我的上级给我分配的工作有冲突，那我到底该听谁的呢？这不是让我难做人嘛。
+
+**上级领导心里会怎么想？**
+
+我付你二线经理的钱，你却去干一线经理的活？你当二线经理，应该把一线经理培养起来，这样才能更好地提升整体团队效率。总之，你要去解决你的一线经理干不了、或者干起来效率不高的工作，比如有些跨团队的协作问题。
+
+通过前面的分析，我们会发现作为二线经理的王总，越过一线经理直接安排一线员工的工作，会导致一线经理、一线员工和上级领导三个角色都心有不满。
+
+我们去发掘这个误区的本质，其实是没有认清二线经理的定位，这个定位就是二线经理是通过一线经理管理团队，而不是直接管理团队，**我们必须让手下的一线经理有存在感并且受到鼓舞**。一线经理是有决策权的，而且他面对的问题的难度往往需要他带领团队才能解决，作为二线经理要支持和鼓励。
+
+那我们认识到这个定位以后，还容易出现什么问题呢？没错，就是矫枉过正，一味去给一线经理授权，对一线团队的管理细节完全不关注。
+
+二线经理千万不能觉得授权一线经理以后就可以放手不管了。这么做的风险是割裂了自己和一线员工还有一线技术骨干的关系，脱离一线业务，慢慢地把自己变成了一个人事经理，自己把自己做空了。
+
+我刚升任二线经理时很迷茫，很不安，光是去参加下面几个一线团队的会议，就已经把时间消耗了大半。那时候被众多邮件“支配”的恐惧，我现在回忆起来还是历历在目。
+
+光是把自己加到所有一线团队的邮件列表之后，邮件数就已经在爆炸式增长了，就算去掉监控报警邮件，每天的新邮件从几十增长到了数百，根本看不过来。面对种种压力，我感觉自己根本找不到着力点。
+
+经历了不少起伏以后，后来我开始反思，得出的结论就是授权一线经理不等于不管不问，而是掌握二线经理的管理方法，原先一线经理的方法明显不适用了。
+
+我最后发现**真正的症结就是我踏上二线管理岗位后管理开始浮于表面，疏于关键细节**。
+
+### 通过下沉两个级别了解情况
+
+我之前在[向上管理](https://time.geekbang.org/column/article/280295?utm_source=pinpaizhuanqu&amp;utm_medium=geektime&amp;utm_campaign=guanwang&amp;utm_term=guanwang&amp;utm_content=0511)中谈到站在高你两级的领导角度去看问题。其实做了二线经理，也要下沉两个汇报级别了解情况，构建和基层的信任关系。
+
+前面我说自己刚做二线经理时，看似参加了很多会，查看数百份一线邮件，但这些都是浮于表面的典型做法，结果就是耗了很多时间还是不了解真实情况。
+
+那到底怎么了解到真实的情况呢？我们可以按照下面这四个方法来操作：
+
+**第一，梳理关键项目**。二线经理不可能对所有的项目都投入力量，所以就要梳理关键项目，只参加关键项目的关键会议。比如季度计划会议，审核会议，而不是每一天的例会。
+
+如果还是觉得会议太多，那就说明我们抓的还不够关键，应该继续精简。极端情况下，在同一个时间就只跟进一个我们认为最需要二线经理去重点关注的项目。
+
+那手头的重点项目到底怎么做一对一交流呢？具体来说就是和技术负责人做沟通，再把设计思考，技术细节，实施计划，潜在风险和应对策略全部一起过一遍，技术负责人的讲述必须让二线经理听懂。
+
+整个过程会花上一两个小时，为了保证重点项目做到位，我会从客户体验是否简单，技术决策是否跟客户价值交付强相关，技术方案实施投入产出比，后续运维成本，还有导致项目失败的风险点等多方面来做考察。
+
+**第二，找一线骨干沟通**。对于一线骨干，应该安排定期做技术上的单独交流，听一线骨干单独讲项目细节。这一点非常重要，我甚至觉得找一线骨干过技术和项目细节的效果，要比前面提到的关键会议更有作用。
+
+为什么这么说呢？因为往往在人多的会议上你只会听到好消息，或者听到不痛不痒的话，而单独针对技术细节的沟通，更能暴露一线的真实情况。作为二线经理，找多个一线骨干了解细节，再配合自己在关键会议上的观察，就更容易全面地了解情况，尽早发现问题以便我们介入解决。
+
+**第三，通过闲谈也能发现问题**。我们可以采用一些轻松的形式找各级骨干和一线经理聊天，比如一对一形式的散步，吃饭。这样做有两个好处，一是在这样的环境下，能够更好地增进你和各级部下的关系，另一个是没有目的性的闲聊很轻松，很多时候也能聊出有效信息来。
+
+我们可以问问部下对团队内一些事情的看法，一般部下都想表现出自己有真知灼见，他们的看法也能帮我们更好地了解情况。
+
+比如跟X聊天，说到合作，那我就会随口问问，你跟Y合作如何，你觉得Y怎么样呢？X回答我，Y很努力也有担当，但情商不够潜力有限。
+
+我也会问问X，你觉得小组里谁比较有潜力啊，X跟我说在日常工作中他觉得S很强，他自己很努力了，还不一定能跟上S的进度。我还会问问X，在能力上，部门里哪些人是你的学习榜样？X说完我还会问为什么？然后再提几个X没有提到的人，问问他为什么不是这些人呢。
+
+**第四，跟进客服情况和进行客户访谈。**二线经理想了解本团队产品，跟进客服情况是一个很重要的渠道。我们公司设有专门解答客户问题的渠道，比如每一个产品的Slack Channel，JIRA Project 。
+
+我觉得组织的一把手应该不定时地到一线答疑摸底。这不但能让我们直接了解一线的真实情况，对整条客服线也是很大的激励，能够推动他们提升服务质量。
+
+还有就是直接找重点客户做访谈，比如我们是基础架构部门，就会直接找到公司的支付和数据部门了解产品反馈。我想了解细节，所以我更喜欢跟一线的工程师坐在一起收集反馈，而不是单单等着看这些客户所在的部门让下属发来的反馈总结。
+
+把这些事完全交给客服团队去做，二线经理只是跟客服团队定期做个审查远远不够。总之，我坚信组织一把手才是那个关键人物，只有他真正参与了，才能最有效地把客户的需求反馈转换成组织执行力。
+
+### 布置任务的技巧
+
+前面我们了解到二线经理跨层级给一线员工布置任务是大忌，那么到底怎么布置任务更好呢？接下来，我给你举个具体案例说明这个问题。
+
+有一次，我手下的监控团队和云计算团队要协作才能完成一个任务，但是拖了很久还是没有进度。而更麻烦的是，我们是双向汇报制度，这个事情还牵涉到美国的监控和云计算团队，上海这边不能单独解决。
+
+于是我在上海召开了会议，在会议上做了提议，要求监控团队和云计算团队必须在三个月内按计划交付，会后我写了一份会议总结抄送给中美相关团队。
+
+当天晚上美国的监控主管就写了信，询问为什么没有跟他商量就做出决定，第二天又跟我说他的部下也质问他为什么这个事情没有在内部先充分讨论就定了。于是这件事逐步演变成消除我那封会议总结邮件产生的影响，而不是解决问题本身。
+
+事后我问自己，难道我应该先找监控的中美团队开会达成监控内部的共识，再找云计算的中美团队开会达成云计算团队共识，最后再召集所有人开会才能解决这个问题吗？那上海的监控和云计算团队还是我们同一个大部门管辖的吗？
+
+这时老江给了一个建议，他说“许健，你是二线经理，你为什么不尝试写一封邮件给上海的监控经理和云计算经理，列举你看到的问题，只列问题不列方案，然后要求上海的两个一线经理给一个方案呢？对于美国那边，你可以把邮件抄送给美国的监控和云计算经理。”
+
+后来我老板也跟我说，有些事欲速则不达。这件事我作为二线经理的初衷不错，强势介入解决。但是在人的问题没有理顺之前，这样强势直接解决问题的方式不一定更高效，事实也是如此。于是我总结了两条经验：
+
+- 要解决问题，前期在梳理人员这方面的准备工作不可忽视，开会定方案只是最后一击。
+- 作为二线经理，可以尝试先抛问题，把自己摆在裁判的位置，而不一定要自己直接上场。
+
+## 把人理顺
+
+二线经理除了把事情管好之外，还需要更多地着眼于把人理顺。请注意，我这里说的不是把人管好，而是把人理顺。
+
+那具体怎么把人理顺呢？二线经理和一线经理对人的着眼点到底有何不同？我会从人员诉求，招聘、裁人三个角度带你做个分析。
+
+### 人员诉求
+
+前面我强势解决监控和云计算协作的做法有什么问题呢？其实就是**只关注到解决问题本身，却忽视了人员诉求。**
+
+作为一名二线经理需要处理的更多是跨团队协作。我就拿前面监控和云计算协同的故事为例带你做个梳理，看看经理知道了人员诉求后，再去做协调会有什么不一样：
+
+我应该先想想监控的总部主管是什么样的人，他在乎什么？结合以往的相处经历，我想起这名主管曾多次明确提出他需要在决策圈内，如果不提前通知他，他总会质问是谁在他不知情时做了决定。
+
+再来想想云计算的总部领导是什么人，又在乎什么？云计算主管也有自己的优先级，回忆了和这位主管过去的交流互动，我意识到总部云计算主管很在乎解决方案有没有前瞻性，而不是一味解决眼前问题。
+
+还有一点也很重要，云计算部门的Quota实施已经做了一年，还没有一个成功案例来证明其价值，那这个诉求我有没有办法满足呢。
+
+梳理了这些诉求，再复盘前面的案例，我觉得除了之前说的跟上海的一线经理提出要求，我也可以帮忙在幕后铺一下路，比如：监控总部的领导那边，我应该提前打招呼告知困难，可以把事情的前因后果和他说清楚，再提出希望他给予帮助；云计算那边可以跟总部商量一下，是不是可以把监控当成一个成功案例来做。
+
+总之，**先了解清楚相关人的诉求，看能不能借助别人的思路把自己想办的事情办了。**有兴趣可以在网上搜一下“盖茨的女婿和世界银行副总裁”相关的故事仔细体会这一点。
+
+### 招聘
+
+我在讲[人才招聘](https://time.geekbang.org/column/article/282069?utm_source=pinpaizhuanqu&amp;utm_medium=geektime&amp;utm_campaign=guanwang&amp;utm_term=guanwang&amp;utm_content=0511)时就强调过招聘的重要性，但我们现在作为二线经理，实际是你的一线经理在招聘一线员工，那我们应该怎么做？每一个人的终面必须参加吗？还是说，我们直接把招聘的定夺权完全交给一线经理呢？
+
+作为二线经理，下面两种情况的面试我一定会参加：一种是高级别的候选人面试，另一种是团队转型时期招聘的新人面试（比如从传统运维向DevOps转型）。
+
+二线经理的介入程度要根据具体情况选择，如果我认为招聘经理的要求很高，我介入的就少，如果我认为招聘经理的要求不够高，我介入的就多，甚至要求必须让我参加面试，面试官的安排也必须要有我指定的人。
+
+这样做不是因为一线招聘经理招人的主观要求不高，而是他的能力和思维方式没有办法在短时期内就提升。如果这时候二线经理不参与，就很容易导致这个一线经理招来的人达不到我们的标准。
+
+如果不是大规模招聘实在忙不过来，我还是建议二线经理对每一个进入组织的人都要面试一下。
+
+面试一方面是考察候选人，另一方面也是我们和候选人的第一次接触。我一直觉得面试官和古时候科举考试的主考官一样，如果候选人在面试阶段就见过面，他们加入之后和我们的关系就自然会亲近一些。
+
+### 裁人
+
+除非是要裁掉一线经理，不然我们想裁掉一线经理下面的员工，就必须得到一线经理的配合。那么如果一线经理不愿意裁人，或者裁人的动力不大该怎么办呢？
+
+我们可以要求一线经理持续以高标准招聘，让他不要担心最后没有招聘预算。好的人才可遇不可求，如果这个一线经理经过自己的努力，终于面试到一个他很看好的人才，为了把这个他欣赏的人才纳入麾下，他就会有动力去主动裁掉团队内相对较差的员工。
+
+前面我说了裁人的简单情况，其实如果你一线经理给力，这些事并不需要我们亲自推动。更关键的裁人情况是，怎样完成关键位置的裁人，比如为了组织团队转型而裁人。
+
+有些重要项目想要做好，就要靠**关键位置上的人**。为什么这样说呢，我给你分析一下：
+
+作为二线经理，如果我们想落实一件事儿，但涉及这件事的关键核心人员跟你不是一条心，那事情就很难做成。比如我们想提升团队A的效率，但是团队A的经理觉得他的团队已经挺好了，那他即使没有当面顶撞你，提效这件事上他的贯彻执行力度也会大打折扣。
+
+所以有时候，你不得不下一个痛苦的决定，就是拿掉他。要知道这个人能走到关键岗位，一定有他的道理的，所以这个事情急不来，这里有两个思路供你参考：
+
+- **评估其人脉构成。**这个人手下的人员中对业务至关重要的关键骨干，我们要花时间构建信任关系。注意这里绝对不是说用利益去让他们背叛他们原来的上级，这样就走偏了。而是让他们了解我们是什么样的人，有怎样的价值观，了解我们希望这个组织变成什么样子。
+- **获取上级领导的支持。**特别是空降到一个部门做经理，想要拿掉一线经理，就要获得提拔过该经理的老板支持。这个对话不容易，我们要坚定，敢于承担责任。
+
+## 树立不断突破的意识
+
+当然，二线经理除了把事管好，把人理顺之外，还应该有更高的追求，那就是不断突破自己，走向卓越。
+
+对于一个二线经理来说，值得自豪的不是自己多苦多累，而是要带领好几个团队组成的一个大的部门达到新的高度。
+
+以我现在的情况来看，如果部门要取得突破性进展，已经没有简单的事情可以做了，关键的事情都是利益相关的，**如果我不站出来，只顾自己<strong><strong>安稳**</strong>得过且过，那是我失职；如果我把关系搞砸了，影响到我们团队的利益，也是我失职</strong>。这就跟历史上的变革一样，团队内部有以前的惯性，团队外部有利益冲突。
+
+所以，二线经理想要把自己负责的团队带到新的高度，特别需要有突破意识，如果每天工作所做的决定都很容易，每天处理的问题都不伤神、不痛苦，那就是在传达一个信号——我们自己的提升有限，我们带领的团队提升也十分有限。
+
+## 总结
+
+今天我们主要谈了进阶二线经理后，在**把事管好**和**把人理顺**两个方面需要做的提高，这个提高是区别于一线经理的。
+
+首先就是把事管好，二线经理要通过下面的一线经理去管理团队，所以要给一线经理授权，不要轻易跨过他们安排一线工作。
+
+同时也不能忘记，我们要下沉两个管理层级去了解一线的细节。具体有四个方法了解情况，**梳理关键项目、找一线骨干沟通、通过闲谈发现问题、跟进客服情况以及进行客户访谈。**
+
+在布置任务的时候，可以抛问题让一线经理协商给方案，然后你按需选择是直接启动方案里的实施步骤，还是根据情况做调整，这样二线经理就能更好地把握进退的空间。
+
+另一方面就是把人理顺，具体分为人员诉求、招人和裁人三个部分。人员诉求上，我们需要清楚相关人的诉求，借人成事。
+
+招聘和裁人上也需要得到一线经理的支持，不是所有情况都要亲力亲为。这里要注意团队招纳重要的候选人时还是要由我们二线经理参与、拍板。在团队转型这类特殊情况下，就算是一线经理，如果影响到了团队发展，也必须从关键位置上拿下来。
+
+二线经理做到把事管好，把人理顺以外，还要**具备突破意识**。除了维持团队正常运行外，二线经理还应该有更高的追求。我们可以想一想，自己有没有做过触及核心利益的艰难决定呢？这能帮我们审视自己，激励我们从合格的二线经理迈向更高的水平。
+
+<img src="https://static001.geekbang.org/resource/image/db/04/db36a22f0e7af50b2ca1ee6cf497c204.jpeg" alt="">
+
+## 思考题
+
+我不喜欢那种“捣糨糊”领导，就是那种碰到跨团队协作问题就跟部下说你们自己协商解决，还教育下级经理要主动扩大自己的影响力，但他作为领导却从不真正出力。
+
+1.二线经理在什么情况下要自己直接到一线解决问题，什么情况下需要让一线经理们自己协商解决呢？
+
+2.如果确定了一线经理自己去协商解决，二线经理又需要做哪些事情，才能避免成为我前面说的这种“捣糨糊不出力”的领导呢？
+
+欢迎在留言区晒出你的经历和疑问。如果有收获，也欢迎你把这篇文章分享给你的朋友。

极客时间专栏/geek/技术管理案例课/二线经理：开始带经理了/13 | 变革管理：如何从“拥抱变化”到“发起变化”？.md

@@ -0,0 +1,184 @@
+<audio id="audio" title="13 | 变革管理：如何从“拥抱变化”到“发起变化”？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/c8/0a/c8365d6d66a7469c5d47ea81fcf5bc0a.mp3"></audio>
+
+你好，我是许健。今天我们聊一聊变革管理这个话题。
+
+一般进入一家公司后，我们都会被告知要拥抱变化。比如我加入eBay先去了搜索后端部门，后来搜索部门都调回了美国总部，我和同事们被调配到云计算部门，经理再次强调了要拥抱变化，于是我们就从头开始学云计算。也有不愿意学的人，最后就离开公司了。
+
+后来我转岗做了经理，做着做着就发现遇到了瓶颈，想要做得更好却做不到，我慢慢地意识到我们需要变革，于是开始了从拥抱变化到发起变革的转变。
+
+接下来，我就跟你聊聊发起变革的那些事儿。
+
+## 拥抱变化：培养对变革的感觉
+
+回看我当经理的经历，我刚转岗做一线经理时就只能看到IaaS Provisioning系统这一块，整天想的也就是要如何提高这块系统的可靠性。
+
+那时我是一个执行者的角色，并不知道我们组织有什么问题，也没有想过要把这个产品做成什么样子，更别说对整个部门有什么长期规划了。
+
+我举个例子给你说说我当时的状态，前面[人才培养](https://time.geekbang.org/column/article/283313?utm_source=pinpaizhuanqu&amp;utm_medium=geektime&amp;utm_campaign=guanwang&amp;utm_term=guanwang&amp;utm_content=0511)那一讲我提到过，领导找人做我的Mentor，我的Mentor就是Wilson。有一次Wilson问我：“许健，公司里那些组织变动的announcement邮件你看吗？”我说自己不看的，毕竟看也看不懂，很多邮件的内容感觉跟我也很远，所以都是直接送垃圾邮箱的。
+
+Wilson却告诉我，他不但会看，而且还会试着理解这些组织变动背后的原因，有些变动甚至在发生之前Wilson就有预测，所以他会对比最后的announcement和自己预测的有什么不同，然后思考为什么不同。
+
+总结一下Wilson提出的对比法，其实就是**把实际发生的变革和自己推断的变革进行比较。**做这个对比有什么作用呢？作用就是可以锻炼经理对组织变革的判断能力。
+
+我意识到这个对比法后曾尝试练习，但因为没有足够的背景信息和当时积累不够，发生在身边的组织变革我也是后知后觉，这让我觉得自己对组织的变革敏感度还要提升。
+
+那么问题来了，**经理对变革的敏感度到底该怎么培养呢？**除了对比，我发现细致地做推演更重要，这个灵感也是多年之后，我成了二线经理才体会到的。
+
+在这里我给你总结一个**三步推演法**：
+
+首先，经理要能够看得到组织的问题。
+
+其次，要分析组织要怎么安排才能增加解决这个问题的成功率。
+
+最后一步，评估问题解决的收益和组织变动需要付出的代价，然后想一想这个代价可以接受吗？
+
+经常思考上面的问题，我们就能慢慢培养出对组织变革的敏感度了。用上这个推演思路后，再结合Wilson的对比法，我发现自己的判断也越来越准确了。
+
+记得我们公司新的首席产品官推出了一系列CPS（Customer Problem Statement），也就是一系列重要的客户不满意的问题，并且对整个产品部门提出了这样的要求，安排工作要围绕解决客户问题这个核心点进行。
+
+我当时就想，接下来也许会按这个要求做组织重组了。后来发生的一系列的组织变动果然就是按照CPS来进行的。
+
+要知道敏感度和判断力都来源于多观察，多思考。将来有一天如果轮到我们发起变革了，这些前期的积累会有很大帮助。
+
+## 发起变革
+
+在成为二线经理的初期，我们更多的是培养自己对变革的感觉，为自己更好地拥抱变革做积累。我们要主动关注领导是如何发起变革的，这样做自己也能逐渐发现组织的问题。
+
+思考了很多，没有实际操练还是火候不到，那什么情况下二线经理自己要主动做变革呢？
+
+如果有个问题严重到影响你的团队效率，但是又没有人站出来解决，这时我们就应该主动发起变革了。那么发起变革又有哪些关键事项呢，下面我就通过案例给你详细说一说。
+
+**案例背景**<br>
+时间回到2014年，当时我团队有16人，分成4个小组，每一个小组都跟美国一个团队对应。其中我直接负责的只有一个做云计算内部监控的小组，其余三个小组的所有工作都是美国的经理直接安排的，说白了我就是一个人事经理罢了。
+
+当时我们公司云计算平台C3主要是在OpenStack上，客户因为平台不稳定很不满意。于是我就动了组织变革的念头，想集中上海这16人的力量来提高C3稳定性。
+
+**推演思路如何落地**
+
+现在我们对照前面提到的组织变革三步推演法，实际分析一下这个案例。
+
+首先是**找到关键问题。**我找到的关键问题是：云计算这个组织的最主要产品是云计算平台C3，但是客户对C3的稳定性很不满意。
+
+为什么这样判断呢？我去参加总经理的Offsite，一堆同事群起而攻之，指着鼻子说云计算部门不解决客户问题。我相信总部那里的客服反馈也差不多，总部云计算平台的一把手也深知这一点，但是当前组织的大部分力量都在做什么？他们都在做新功能而不是修复现有系统的稳定性问题。
+
+所以，我觉得必须要把现在云计算平台的业务质量提高，而这里最大的痛点就是解决C3的稳定性问题。
+
+接下来是**推演解决方案。**找到关键问题以后，推演解决方案就很顺畅了。有个[故事](https://time.geekbang.org/column/article/89923?utm_source=pinpaizhuanqu&amp;utm_medium=geektime&amp;utm_campaign=guanwang&amp;utm_term=guanwang&amp;utm_content=0511)我推荐你看一看，就是马云曾经停掉支付宝的所有新功能，强制要求整个支付宝公司做变革，目标是把支付成功率从70%提升到90%。
+
+本质上我这里的变革思路跟支付宝提高成功率是一样的。解决方案很直接，就是把组织的骨干力量从新功能上撤出，转到解决客户当前关心的主要问题上。
+
+最后一步是**评估投入产出。**想要做成这件事要付出什么样的代价呢？就是一旦我们抽调一个骨干，那个骨干所在的新功能就会受影响，连带着负责那个新功能的经理就会受影响。
+
+那大面积影响美国团队和大面积影响中国团队，这两个方向总部领导会做何选择？我的判断是总部领导会选择让中国团队做组织变革，虽然这个变革要付出代价，但也是中国的云计算负责人希望的。
+
+总结一下，我愿意跳出来解决总部领导当前很头痛的问题，而且总部领导付出的代价可控，所以发起这个变革的可能性很高。如果能做好，上海的团队将不再是一盘散沙，我也不再是人事经理。所以，我决定主动发起这个变革。
+
+确定了要变革，具体怎么做呢？这里有两个关键事项，一个是向变革涉及到的关键人物讲清楚我的想法，另一个是说服上级领导支持变革。
+
+**正面冲突，把话当面讲清楚**
+
+我想集中力量搞稳定性，就要完全停掉经理T在上海的原有安排，所以我申请去美国出差找T沟通。在美国见到T后，T希望我不要改变他的原定计划，我当时拉不下脸直接拒绝，并没有把话当面讲清楚。我只记得当时说，好吧，我再考虑考虑。
+
+其他经理对变革的态度基本上是中立的，他们认同我要做的是正确的事情，同时又觉得原来计划的工作也很重要。在我飞回上海的路上，我觉得出这趟差什么也没有做成，白白费了公司几万元差旅费。
+
+没过几周，总部的负责人S来上海例行视察，这次我铆足了劲，态度坚决，有理有据，一定要达成变革目标。
+
+具体怎么说服S的我会在后面细讲，这里先说结果。S在上海待了一周，周五晚上飞回了美国，下周的周一就直接宣布了变革决定。
+
+因为我出差时没有和经理T明说，他的理解是这件事儿我们还在谈，结果T突然收到领导这样的通知，自然很不高兴。T经理非常生气，他觉得我不把话当面说清楚，背后使绊子。
+
+当时我的情绪管理做得也不够成熟，S宣布决定后我跟T打电话情绪也比较激动，还记得T在Skype上跟我说“Jian，watch your mouth！”过了一年多，我和T的关系才缓和。
+
+回顾看我跟T交互的过程，我总结了两点经验：
+
+- 在美国的时候，我其实完全可以当面跟T讲清楚我的想法，我就是为了集中力量把可靠性搞好。那为了做成这件事，我需要停掉你原来的工作安排。T也是讲道理的人，他后来对我这么生气，症结就是我没有在他面前把话说明白。
+- 我讲清楚我的想法以后，我期望得到T的支持这一点，其实可以和他明确表达出来。
+
+若干年后我已经负责带领更大的团队了，摩擦总会有的。我跟总部云计算高级总监有一次推心置腹的沟通，他也跟我提出来我们可以持不同意见，但是应该互相把想法讲清楚。大家都没有私心，没有什么不可以摆在台面上的，要么不说，要说就说得彻底。
+
+**如何说服上级领导支持变革**
+
+故事要回到S在上海的那一周，那时我做了什么呢？其实就是把变革的三个问题回答好。哪三个问题呢，我们一起看看：
+
+第一，**问题非解决不可吗？**也就是解决Cloud Reliability这个问题，是不是S眼中的重点问题？只有重点问题，领导才会为了解决它而支持你发起变革，哪怕要影响总部各个经理的原定计划。
+
+我们当时云计算部门自己的报表显示稳定性在99%，但是客户不买账，说给我们的服务发请求失败频率很高，发十次请求失败七八次，甚至有一个客户给副总写邮件列举了云计算七宗罪。我判断S面对客户也承受着很大压力，问题再不解决，S有可能位子不保。
+
+第二， **解决问题具体怎么做？**我给S做了详细分析，把做成Cloud Reliability这件事要解决掉的几大问题逐条列出来。
+
+我们要解决RabbitMQ消息中间件的稳定性问题，要提供能反映用户体验的指标，还要解决虚拟机启动时网络配置问题……每一条都我列得都很具体，这样领导才知道，我提起这个变革是经过深思熟虑的。
+
+第三， **为什么解决这个问题要交给我来做？**最后这一步很重要但却很容易忽视，就算是你提了方案，为什么领导要把这个方案交给你来执行呢？
+
+我们始终要记得领导最最关心的就是结果，所以必须向领导阐述解决第二步里的问题需要什么样的人才配置，说明我们就拥有这些人才配置，所以我们才是他手下最有可能办成这件事的人。
+
+因为解决了前面说的这三个问题，我才说服了领导支持变革提议。我觉得重要项目需要领导真正的支持，而不仅仅是口头支持。
+
+那么如此重要的事情，我们有哪些具体的事项需要领导帮忙呢，我和领导S提了下面3个要求：
+
+- 需要请S来宣布变革决定，也就是美国总部那里原定计划变更，上海将集中力量改进Cloud Reliability。
+- 我请S请上海的骨干一起吃饭，当面告诉他们这件事对组织的意义，激励这些骨干。我私下跟S说如果事情做成了，希望对这些骨干在年底绩效考评的时候有所体现。
+- 需要领导提供人员上的支持，我们毕竟远在上海，我需要总部安排一个项目经理来帮忙协调上海对总部的需求。我还希望美国总部技术实力最强的经理D参与进来，在必要时提供技术支持。
+
+上面说的支持需求，S全部答应了。我现在经常对我的部下说，如果我决定让你改变原计划去做一件我认为很重要的事情，你要是对我一点要求都不提，我会觉得不安，所以发起变革时，我们需要上级给什么支持，一定要提出来。
+
+## 发起变革后的前三个月
+
+变革启动后的前三个月是关键期，变革是打破原有的方式，前期拖得太长，容易出变故。所以我们需要在前三个月有产出，才能增强所有人对变革的信心。
+
+接下来我们就聊聊在Cloud Reliability Program（后面简称CRP）那次变革的前三个月，我是怎么做的。
+
+**第一，前三个月的执行必须亲自指挥。**
+
+作为二线经理，可以把执行交给一线经理，但是在这段时间，我们的主要精力必须专注在变革的执行上。我当时做了详细的分工：
+
+<img src="https://static001.geekbang.org/resource/image/ef/0e/eff2f36004e952fb53a907abee6d630e.jpeg" alt="">
+
+- 两个人做监控分析工作。B负责监控量化我们的稳定性指标，这样到底稳定性提高了多少大家一目了然。X负责对现有客户反馈的问题一个一个分析。
+- 四个人处理已知问题。J负责攻克最棘手的消息中间件不稳定的问题，G负责数据库的稳定性，H负责网络问题，Y 负责虚拟机镜像问题。
+- 我们每天都要自己过一下进度，因为X那边要分析的问题量比较大，我就和他一起做分析。
+
+**第二，早做推演，找到可能导致这三个月既定计划无法实现的风险点，及早做出部署。**
+
+换句话说，就是如果三个月后变革失败了，会是因为三个月前没做好哪些工作呢？不要以为艰难的决定在发起变革那一步就结束了，后续还有很多问题。
+
+一个典型的问题就是对别人的依赖，注意这个时候把事情做出来，要比把事情做完美要重要，三个月内的目标一旦确定就不要轻易扩大，打移动靶多半会失败。
+
+具体在CRP这件事上，当时我们最棘手的技术难题是消息中间件不稳定，所以一定是安排全组技术实力最强的人去解决。即使是这样，我们在前面近两个月都没有明显进展，压力很大。两个月过去后终于找到了问题，团队真的特别开心，信心也一下子起来了。
+
+接下来又碰到了OpenStack升级，稳定性又跌下来，后来我跟美国的另一个经理D协商又停掉了一个项目，把另一个骨干也拉进来一起解决这个问题。
+
+现在回顾OpenStack升级这件事，我发现这个风险点本该推演出来的，如果现在的我回到当年，就会坚持延后OpenStack升级，减少这个不确定因素。
+
+**第三，****保持执行的完全透明。**
+
+每周给上级领导发工作汇报，每个月做月度汇报，有困难不要藏着掖着。我当时就是每周都向总部做进展汇报，我们和总部毕竟隔着个太平洋，而这次变革也是力排众议进行的，如果沟通不及时、不到位，就会造成总部领导不满，甚至对我们的信心动摇。
+
+这种隐患在上海很难及时处理，所以我们请总部的一位华人来做项目经理，因为他跟我们信任度很高，所以找他负责跨洋沟通。这么安排是为了总部领导有任何问题都能得到及时解答。总部那边有什么情况，我们也可以通过这名项目经理及时了解，然后做出调整。
+
+在整个变革过程，肯定会有困难，但是我们一定要给部下和上级展示出我们的坚定信念。如果真的出现问题，那就算砍功能也不要轻易改动原定交付时间，因为确定的交付时间对外就是一个承诺，而对内是一口气，这口气不能泻。在约定的时间内能准时交付，团队就会更加有信心。
+
+## 总结
+
+变革不易，从被动地接受变化到有能力主动发起变革，这是二线经理的一个重大进步。
+
+我们要发起变革，首先要对于组织当前的重点问题有清晰的认识，平时就要培养对变革的敏感度，思考怎么通过组织变革进一步释放组织效率。
+
+真正要发起变革肯定会影响到一些关键人员的利益，这时不要回避，摆在台面上讲清楚，给予相关人员足够的尊重。
+
+说服领导的思路要围绕着“怎样做才能最大可能解决组织痛点”来构建。关键是和领导沟通好三个内容：**这个问题非解决不可吗？解决问题的具体方案？为什么这个变革要交给我来做？**
+
+发起变革一定要获取上级领导的支持，这个支持不只是口头的，有关具体事项的需求也要提出来。
+
+请你注意，发起一次变革只是起点，变革的关键期在启动后的前三个月，二线经理必须在这个期间亲自上阵指挥，专注于变革的执行，做详细分工，并根据推演到的风险点早做部署。
+
+对变革管理有兴趣的同学，我强烈推荐你学习一下中国历史上的变法，体会这些变法成败背后的原因。
+
+## 思考题
+
+后来我又做了开发部门和运维部门的整合，开发部门觉得运维部门不思进取，而运维部门觉得开发部门也有问题，问题有两个：因为启动的新项目并不真正解决线上的实际问题，做事老是缺少最后一公里，这个欠缺还是要运维部门去填。
+
+1. 如果你是我，准备怎么来做这两个部门的整合工作呢？
+1. 如果你是开发部门或者运维部门的一员，你又准备做些什么？
+
+欢迎在留言区晒出你的经历和疑问。如果有收获，也欢迎你把这篇文章分享给你的朋友。

极客时间专栏/geek/技术管理案例课/二线经理：开始带经理了/14 | 冲突管理1：如何进行高压对话？.md

@@ -0,0 +1,174 @@
+<audio id="audio" title="14 | 冲突管理1：如何进行高压对话？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/6a/90/6aaac6a372555391ca5d9e1273456290.mp3"></audio>
+
+你好，我是许健。今天我们来聊一聊如何进行高压对话。
+
+高压对话是冲突管理的重要部分，我放在冲突管理的第一节讲，是因为这是我们最经常碰到的冲突形式。
+
+那什么叫高压对话？高压对话就是我们预测双方观点会有重大分歧，过程压力很大的谈话。对话时双方的情绪都很容易激动，所以稍不注意就会点燃火药桶。我这么说你也许还没什么感觉，那我就举一个具体的例子，带你一起看看高压对话会爆发怎样的极端后果。
+
+年终考评会上，A和B分别是公司内两大产品的主管负责人，两人在候选人X的晋升问题上发生严重冲突：
+
+> 
+<p>A：我部门组员X能力很强，我们部门现在重点投资产品的管理系统都是X搞的，这个管理系统非常复杂，难度极大。<br>
+B：复杂是复杂，难度极大未必吧。X也没有你说的那么强，他如果来我负责的产品的核心我看很难。<br>
+A：按照你这么说，那我觉得你负责的产品其实也没有那么难啊，我觉得如果真的把X放在你们部门，做产品核心开发，他照样做得出来。<br>
+B: 胡扯，X 要是做得出来，就让他来做我的位置！最后，B 拍桌子直接离开了会场。</p>
+
+
+你说，有过这么一次谈话，接下来A和B这两个人还能好好合作吗？
+
+高压对话和重大利益紧密相关，对话的结果也是我们极其关注的，那我们该怎么做呢？接下来我就从高压对话的事前准备和如何进行高压对话两个部分做讲解。
+
+## 高压对话的事前准备
+
+首先你要做足准备，跟自己和自己下棋一样，把自己摆在对方的位置上，把所有你能想到的对话路线都列出来，然后一一做分析，考虑如何应对。
+
+这个其实谈不上什么技巧，关键在于充分摸底，花时间把准备工作做得足够好。事前准备可以从这三个角度进行，**基于对谈话对象的了解做演练，关注共同利益，拿数据和实例说话。**
+
+### 了解谈话对象，做好演练
+
+对话前的准备的起点是什么呢？就是我们先要了解谈话对象是什么样的人，然后根据对这个人的了解做好演练。
+
+我之前在做演练的时候，会推演对方会怎么想、怎么说，但我往往把自己的思维逻辑代入到对方身上，其实也就是用我的思维站在对方的立场上看问题而已。为了方便你理解，我举一个简单的例子说明：
+
+我和总部的首席架构师A沟通，我希望A同意让中国的一个经理Y发挥更大的作用。
+
+- 我的思维逻辑是**要承担责任就得给相应的权力。**如果用自己的思维代入我就会跟A说，我们要让Y发挥更大的作用，A你得放权啊，你要让Y感受到他也能做决定呀。
+- A的思维逻辑是**Y想要权力，就得先向我证明他的能力。**如果用A的思维代入，我就会跟A说，A你看Y最近做了ABC这三件事，你觉得Y哪里做得好，哪里需要提高。如果A有不满，我就继续让Y提高，如果A觉得Y不错，我再进一步建议A给Y更多的自主权。
+
+很明显，把自己代入对方的推演偏差就很大，模拟得不够准确。事实上我开始一直用自己的思维代入A，沟通时一点进展也没有，反而让A觉得我每次跟他谈，都只是要权。
+
+所以，我们要**先了解了对方是怎样的人，才能尽可能地模拟对方的思维，然后代入对方的立场理解问题，这样的<strong><strong>推演**</strong>才是更有效的。</strong>
+
+工作很久以后，我才慢慢意识到人和人其实是有很大的不同的。比如，有的人很在乎原则，有的人只看重结果，有的人外表冷漠内心温暖，有的人喜欢做事雷厉风行但不太注意人的感受，有的人做事喜欢走几个来回才安心……
+
+那我们怎样深度了解一个人呢？要深度了解一个人，我们平时就应该做个有心人，不仅要从工作中的接触下手，还要从他的周围的人、他的兴趣、爱好等方面做了解。
+
+比较厉害的人，还会注意到一个人的原生家庭和成长经历。我们也许不能一次性做到把谈话对象了解得很彻底，但可以有意识地锻炼自己这方面的能力。
+
+基于我们对谈话对象的了解，我们就可以更好地做演练了。只要我们想更好地准备，总会有提高的空间。优化路径我们可以从这三点考虑：
+
+- **增加演练次数**，在脑子里过一遍不如过两遍、三遍。
+- **总结成文字**，在脑子里过一遍，不如总结思路以后写下来。
+- **找高手模拟**，自己单独模拟，不如寻找信得过的高手，做真实模拟。
+
+### 关注共同利益
+
+凡事都要先问目标是不是正确，我们要进行高压对话，自己必须先要“师出有名”。
+
+我几乎每一篇文章开始都会强调“道”是不是正，因为这是根本，“道”正才可以驱动后续所有的“术”用在正确的方向上。
+
+**在高压对话中，我们的目标不是证明谁对谁错，而是去思考如何选择，才能让组织的利益更大。**其实在我们日常工作中，这是一个容易忽略的点，我们哪有那么多敌人，大部分做经理的平时接触的都是同一家公司的人，大厂里甚至都是同一个部门的人，双方都希望公司和部门更好，所以我们是有这个共同利益基础的。
+
+我们从共同利益切入，理顺沟通思路就很简单了，接下来我给你举个具体例子说明。
+
+因为去年公司整体业绩不是很乐观，需要减员。最后总部领导的方案是上海要承受全部门减员的大头。
+
+我的逻辑是上海人数只占全部门30%，却要承受整个部门大部分的减员指标。我完全不能理解总部这样安排的原因，但是给这个提议的领导是一位我很尊重的领导，在我做出任何进一步反应之前，我觉得我很有必要约这位领导当面聊一下，理解总部这么做的原因。你要注意，我在这里强调的是在你觉得对方不可理喻准备发飙之前，一定要控制住，先搞清楚对方的思路再说。
+
+而总部的逻辑是过去一年中，总部离职减员比例远大于上海的离职减员比例。在不少总部经理看来，总部已经承受了大部分的减员，这次上海多承受一些减员指标很正常。
+
+我虽然理解总部的想法，也明白他们过去一年的感受，但是我内心并不赞成这样的提议。在找总部领导沟通前，我专门去看了《谈判力》这本书，然后我就想到了从**共同利益**这一点切入。
+
+实际沟通的时候是有一些火药味的，当我阐述中国招聘优秀人才上的优势时，总部就有一位经理直接对我说，那按照许健你的逻辑，美国就应该继续减员嘛！美国经理负责的工作就应该继续减少嘛！当我对负责减员实施细则的领导说，我们做决定应该基于效率而不是基于平衡的时候，这位领导语气强硬，指出要综合地考虑问题，总部很多经理的感受也必须照顾。
+
+我想说的是，在这个案例中，关注点不在论证公不公平或者指责某一方。**让组织更好才是我们的共同利益**，而人才是组织发展的根本，所以我们就应该克服困难把优秀的人招聘进来。明确了这一点，我就理清了和总部如何沟通：
+
+**首先，同理心先行，从没有分歧的共同利益说起**。我的核心诉求是上海应该继续为eBay去吸引优秀人才，这一点上中国美国并没有分歧。那怎样在人手预算限制的前提下仍然把优秀的人招进来呢？我坚信方法永远比困难多，比如让想去美国发展的同事安排relocation，跟总部商量暂时让我招人，提出平衡人手的计划等。
+
+**然后，****基于实际情况，准备观点**。从组织效率更高的原则出发，我们想要吸引人才，在大方向上应该充分发挥eBay上海的优势而不是予以限制。美国离职率远高于上海，很大的原因是硅谷有很多高科技企业，其中不乏很好的创业公司。他们提供的机会和待遇对人才的吸引力高于eBay美国。而eBay中国对于想在上海生活、又希望有时间陪伴家人的人才是非常具有吸引力的。
+
+**最后，分析当前减员方案的影响**。本着对整个组织负责的态度，我们应该考虑到让上海承担大部分裁员指标产生的弊端，比如对组织效能的影响和对经理积极性的影响。
+
+为什么会影响组织效能呢？总部规定，对于每一个经理，他的实际人数不可以高于他的人员指标，也就是如果要招人就得先裁人。结果是经理很可能为了不裁人，就不去花精力吸引和招聘优秀的人才加入eBay.
+
+再说说积极性的影响，拿我自己来说，过去一年中我一直在积极地寻找优秀人才，同时劝退部门里不能在新形势下胜任工作的员工。这些事儿耗费了很多心力，而我愿意去花额外精力做这些，是因为认同这是组织要更加高效所必须经历的阵痛。所以这个方案一出，对我的积极性是一个严重打击。
+
+这个故事的结局没有那么尽如人意，总部领导还是没有改变减员比例的分配决定。但是通过关注共同利益，我还是取得了“阶段性”胜利的，具体体现在下面这两点。
+
+第一，我的这些观点总部领导真的听进去了，之所以这么判断，这是因为对于我上面陈述的这些点，总部领导都没有驳斥，而且最后对我说：“许健，你知道我其实一直都很支持上海研发中心的发展的。”
+
+第二，更为关键的是，在人才招聘上我争取到了一定的发挥空间。在我给了具体的人手配置方案后（碰到好的人先招进来，只要中美整体在预算内，我就不需要减人），我后续几个优秀候选人的招聘申请领导都同意了。
+
+我坚信一点，我跟领导说的那些话都是从整体组织共同利益出发的，这些话就像一颗颗种子一样种了下去，我有耐心这些种子会慢慢发芽。也许有一天，总部领导会加大对上海的投资。
+
+### 拿出具体数据和实例
+
+我们部门在关于网络技术栈的选择上分歧很大，两种观点针锋相对，意见相持不下。
+
+一方的观点是：技术栈的选择应以业务驱动为核心，不需要用超出业务需要的技术，否则实施这些技术就需要付出额外的投入；另一方的观点是：要用发展的眼光选择技术的方向，现在不投入，以后走回头路的损失就大了。
+
+在我看来，双方再继续争下去，也只是重复各自的原则和观点罢了。这时候事情要怎么推进呢？这时最好**用数据和实例说话**，不如让一线的工程师把两个方案的具体的实施细则拿出来，附上具体的实施成本，对于可扩展性和性能方面的担忧，就去做性能压测，把具体的数据拿出来。
+
+事实上这个事情的推进就是按照这个思路做的，负责人拿出了新方案的实验室压测结果。虽然有人对实验数据的可信度存疑，还有更多人担忧新方案无法按预期情况上线。但我觉得有了数据支撑以后，双方沟通起来会比之前空对空争论，却不下沉到细节好很多。
+
+除了刚才说的推动事情发展，数据和实例也是我们反驳的“工具”。
+
+在一次季度计划会议上，我们云计算的领导被同僚质问季度计划的制定原则是怎样的，到底是以业务为重还是以技术纯粹性为重。这位领导是这么回答的：请大家提问时不要光提原则，而是拿具体的数据和事例来说话。我刚才提出的计划里具体哪一个点没有以业务为重？！你说安全方面要上全链路TLS的事情用新技术栈不能满足安全部门交付时间是吗？好，那我告诉你，我跟安全部门核实了交付时间是2021年上半年，我认为基于那个时间我们可以用新的技术栈交付安全需求。
+
+## 高压对话如何进行
+
+我们做好了充足的事前准备，进行高压对话也就更有底气了。高压对话如何进行呢？下面我会从**递进提问**和**把握自己节奏**这两个部分给你做讲解。
+
+### 通过递进提问进行对话
+
+我之前在[人才招聘](https://time.geekbang.org/column/article/282069)那节课提到过递进问题的力量。其实在冲突对话中递进式提问同样很有威力。我给你分享几个真实场景，带你体会一下。
+
+年终晋升讨论会上，A 经理说他的人在自动化支持上有突出贡献。B 经理提问，具体是哪方面的自动化？请解释这个自动化的技术复杂性在哪里？能不能拿一个具体的例子进一步帮大家理解实施难度？
+
+技术方案讨论会上。A经理质问现有的系统不能满足业务需求。B 经理提问，你能不能讲一下具体哪个业务需求现有的系统不能满足？
+
+其实方法总结起来就一条，就是不停地问为什么。提问时我们要注意语气，秉承态度好，话到位的标准。
+
+什么叫态度好，就是你不会因为气氛紧张，就抬高讲话的声音，就情绪激动甚至人身攻击；什么叫话到位，我的经验是在关键点谈细节、谈数字、谈实例。
+
+我再给你举个例子，带你体会一下提问的“话到位”标准。招聘中，老板打电话过来，希望我考虑将我们的第一候选人让给另一个急需人才的部门E，建议我们考虑在候选名单里再找一个合适的，这里我们有两种回应方式：
+
+1. 为什么不让部门E从候选名单里再找一个合适的呢？
+1. 能跟我说一下部门E不考虑从候选名单里挑选人才的原因是什么吗？我们的第一候选人的名单已经提交总部审核，现在修改有丢失招聘预算的可能性的。
+
+很明显，第二种方式更有说服力。
+
+### 不要被别人带着走
+
+前面讲了我们要用提问的方法和别人进行高压对话。那如果在高压对话中，遇到对方用类似的提问来反问你，我们又该怎么办呢？我还是用一个真实案例，带你找找感觉。
+
+在一次公司组织的高级别员工项目评审对抗演练中，最后一个对抗环节是两个团队的对抗性辩论，当时我是A团队的教练。自由辩论开始后，B 团队的成员轮番向A团队的领队发问，A团队领队老M一一回答，结果老M答了一个问题，对方又会再问一个。
+
+当时我和田总坐在评审席上，B团队问到第三轮的时候，田总跟我说：“许健，你带的团队这样下去不行的，怎么老是在挨拳，从不出拳的呢！”
+
+其实田总已经把方法说出来了：**首先你得意识得到对方在使用递进式问题的方式主导对话，然后你不能一味回答对方问题，你得找到机会发问。你不能一直被别人的节奏带着走。**
+
+这个方法说起来简单，真正能够内化并熟练掌握没那么简单。因为人的思路默认是要回答对方的问题的，你必须集中精力，有意识地锻炼才行。具体锻炼的地方就是不要顺着别人的思路，这里我想和你分享一个很精彩的故事。
+
+阿里巴巴上市的时候，国外记者问马云：“阿里巴巴作为一家全球公司怎么处理和中国政府的关系？”换了你怎么回答呢，这个问题绵里藏针，总不能真的回答怎么跟中国政府搞吧？
+
+马云的回答是：“作为一家全球公司，处理跟**任何一个政府**的关系都不是很容易的事情。”然后再谈一些理念，但是这里已经不特指中国政府了。你看，马云这个回应就没有被记者带跑节奏。
+
+还有一种被别人带节奏的情况，就是有些人问你问题并不是寻求答案，他是自己已经准备了答案，就等你回答后用他再抛出他已经深思熟虑的答案。所以这种情况下你可以不直接回答他的问题，而是反过来问他：“你觉得呢？”
+
+这里要注意，同样在对方准备答案的情况下，如果是面对职位比你高的人，讲话更要有技巧。比如领导问你话，你说：你觉得呢？这显然不合适。但是你可以在回答领导提问之前，问领导具体的问题，比如领导你提问的背景是什么？最近出什么事情了吗？简而言之就是先拿到信息。
+
+## 总结
+
+今天我们讲的高压对话是冲突管理中高频发生的事情。我们要怎么应对呢？凡事都不能打无准备之仗，所以高压对话这件事儿，也是分为事前准备部分和高压对话进行时两个部分。
+
+首先，是事前如何做好准备。我们可以从这三个角度进行，**基于对谈话对象的了解做演练，关注共同利益，拿数据和实例说话。**
+
+知己知彼，方能百战不殆。了解谈话对象，我们才能推演出对方的思维，模拟出高压对话时对方会怎么想，怎么说。然后就是做演练，这件事永远没有“最好”，只有更好，优化路径有三个：**增加演练次数、把思路总结为文字，找高手模拟。**
+
+接下来我们讲了**关注共同利益和用数据、实例说话。**
+
+为什么要从共同利益切入呢？因为在高压对话中，我们的目标是选择让组织的利益更大的方案。沿着这个思路，对话准备可以按**同理心先行、分析现实情况和评估利弊**三步进行。如果谈原则谈不下去，那就谈细节，拿出数据和具体的例子为自己“代言”。
+
+做好了备战工作，就要真正进行高压对话了。我们要注意递进式的提问，是一种强有力的对话方式。不过这个方法呢，你可以用，对方当然也可以用，所以自己要能主动意识到这一点，别被别人带跑了节奏，巧的是，“最好的防守就是进攻”，多半的“防护措施”恰恰也是提问。
+
+总之，高压对话很有挑战性，我们要尽可能做足准备，对话时锻炼自己主导节奏，相信你一定会有所提高。
+
+## 思考题
+
+1.如果高压对话是发生在你和你的领导之间，领导不停地提出问题来质问你，你准备怎么做？
+
+2.我们提到原则谈不下去就要谈具体的数据和细节，如果你发现对方很有道理，你就是要被说服了，这时该怎么办？
+
+欢迎在留言区晒出你的经历和疑问。如果有收获，也欢迎你把这篇文章分享给你的朋友。

极客时间专栏/geek/技术管理案例课/二线经理：开始带经理了/15 | 冲突管理2：没有双赢的情况下，如何推进事情发展？.md

@@ -0,0 +1,145 @@
+<audio id="audio" title="15 | 冲突管理2：没有双赢的情况下，如何推进事情发展？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a3/e1/a3705c9bdbe0031b5bed9e8b0bd11de1.mp3"></audio>
+
+你好，我是许健。今天我要和你聊一聊，没法双赢的情况下，我们该怎么办。
+
+我们经常谈到冲突管理里的“双赢”思想，就是从各个方面寻求冲突双方的共同利益，最后找到一个点，对双方都有利。用一个简单的例子来解释“双赢”思想，就是我们有一块饼，你多吃了我就得少吃，那与其两个人争来争去还不如一起去把饼做大，这样我们都能多吃。
+
+可是我们在实际的工作中，很多时候就是没有办法双赢的。比如老板说了只有一个升职名额，你拿了我就没有；老板说必须裁掉一个人，你的团队不裁人，就是我的团队裁人。这时就必然会产生冲突。
+
+所以，今天我就以一个案例来谈一下在重大利益关切又没有办法双赢的情况下，我们该怎么处理冲突，推动工作进度。
+
+**案例背景**
+
+2017年的时候 ，我们的上海团队开始负责产品A，这是一款关于云计算用户体验的产品，它代表着整个云计算团队的门面，非常重要。不过呢，与我们同属一个大部门的一位美国方面的资深架构师在2019年也启动了一个团队，开始做云计算用户体验的另一个产品T。
+
+2019年9月的时候，我们的部门副总认为云计算用户体验产品只有一个就够了，于是让我和总部的资深架构师以及技术主管讨论如何安置部门内这两个团队。副总希望我们合并成“一个团队、一个产品”，让我们拿出合并的实施细则，但是真正落实执行的时候却是困难重重。
+
+为什么我会感叹“困难重重”呢？下面是我当时被问到的几个代表性问题：
+
+- 你为什么觉得A和T冲突，我觉得不冲突，他们就是两个不同细分场景下的产品，如果你觉得有冲突，那是因为你没有理解T产品的本质，你应该回去好好学一下。
+- 你为什么老是盯着产品T，你是不是担心T做起来了以后会威胁你负责的产品A的位置？
+- 你是不是在上海说过要关闭产品T的话，你知道这会对美国的T产品团队成员产生什么样的打击吗？副总只说要合并，并没有说要关闭任何一个产品。
+- 我们的问题在后端能力不足而不在前端，除了合并团队，我看不到合并产品有什么额外的业务价值，因为你的介入，美国的团队在半年内都没有取得什么实质的进展，因为他们怕你，你和他们有信任问题。什么？调T团队的人去帮助后端？那你为什么不调A团队的人去帮助后端。
+
+我们可以很明显地感受到这些问题中的火药味，为什么呢？因为这个案例就是没有办法取得双赢的情况，双方做产品的理念不一样，但最后只能有一方来主导。那我们就来谈谈做这个合并，选择不同的人主导会带来什么影响？
+
+如果是我来主导合并后的产品，就意味着T产品之后的发展方向改变，很可能无法按照总部资深架构师原先设想的路线进行，而他已经在这件事上倾注了大量精力。
+
+如果合并由总部架构师主导，我们在理念上又不完全一致，我可以预见到后续摩擦不断。而且，美国资深架构师和技术主管都很强势，他们在部门内很有影响力，除了云计算用户体验的产品，我们在其他方面还有很多合作，如果不能很好处理跟他们的关系，对我、对上海的云计算部门都很不利。
+
+如果从“技术实施”这个方面来看，虽然问题很明显，但却更难调和了，因为A和T各自开发了一套前端框架，这意味着无论选择哪一个框架，都有可能导致另一个团队的核心人员离职。
+
+好了，背景介绍就这么多，问题很突出，矛盾也很尖锐。你可能要问了，最后这件事是怎么解决的呢？接下来，我们就按照当时我解决问题的时间顺序做讲解。
+
+## 1.格局要高，一心为公
+
+我们看影视剧里有关打仗的剧情，就会发现将领们都很在乎**师出有名**，为什么这一点很重要呢？因为无论什么时候，你在做，其他人在看，得道多助，失道寡助，公道自在人心。千万不要觉得我说得太大了，不信我们来分析一下。
+
+- 如果我现在不是产品A团队的经理，而是T产品的经理，我的决定会有不一样吗？答案是不能有不一样！
+- 我站在我的位置，我站在副总的位置，我站在整个上级部门和公司的位置，我的决定会有不一样吗？答案是不能有不一样！
+- 我是不是在内心非常在乎美国T团队成员的感受，在乎他们的职业发展呢？答案是当然在乎！不但在乎，我还应该拿出具体的举措而不是只在嘴上说说。
+- 美国的两位主管的初衷也是为了我们的部门和公司更好，这一点我能不能怀疑呢？答案是不能怀疑！我要相信我们虽然看法不一致，但是我们都是有好的初衷。
+
+我上面说的这些点，我相信美国的主管心里也会思考的，因为如果他们不这么做，他们在道义上就矮了一截。我其实不是一个善于伪装的人，而且再聪明的人如果是伪装成表面大公无私，实则内心小九九，最终一定会露出马脚。一旦露出马脚，这个人就失去了德，失去了德被对方揪住，以后就很难挺直腰板讲话了。
+
+所以最好的处理办法就是我们的首先就站在很高的格局上，一心为公。我的立场就是，双方可以有不同的观点，但是我们必须给予互相足够的尊重，没有什么隐藏，君子坦荡荡。基于这样的立场，我是怎么做的呢？
+
+在产品合并期间，我给总部的架构师和技术主管分别打了视频电话，真诚地告诉他们我的行事原则是怎样的，让他们感受到我的真心，了解到我也会从总部角度看问题。为什么一定用视频电话呢？因为这样沟通双方可以看到面部表情和肢体语言，我要确保他们可以看到我的态度是诚恳的。
+
+同时我还给T团队的开发主力打了电话，获取他的信任。我和他沟通了我们现在面临的情况，也就是必须在A和T的框架中选择一个。我会选择A产品，不是因为我是A的经理，而是这样合并的成本最小。我理解他的心情，所以一定会尽我的全力给T团队的成员搭台子，让他们能在后续工作中负责有挑战并且能出成绩的模块，我最不想看到的就是有人离职。
+
+这次的沟通让我感觉赢得了他的信任，因为说完这些后我问他是否相信这些话，他回答说他是相信的。其实基于真诚互信、一心为公的立场，你的人就正了，对方会觉得你不是一个自私的人。有了这个信任基础，后面的沟通就能顺畅许多，因为双方会更多地关注事情本身，而不是互相猜忌。
+
+## 2.直面冲突，立场坚定
+
+刚刚说了一心为公能保证我们在道义上不输，但是这不意味着胜利。也就是说，硬仗还是要打的，没有双赢，但是为了事情有进展，你必须坚定自己的立场，勇于直面冲突。
+
+什么才叫“直面”呢？我的副总曾经说过一句很有道理的话：“不要让人猜，你让人猜，人家就会往坏里猜，而且是往最坏的地方猜。”所以无论有什么事情，就是要摆在桌面上讲的。
+
+我内心喜欢冲突吗？当然不喜欢，而且我相信大部分人都不喜欢冲突的，可是回避冲突并不能解决问题。我说出来的观点，对方就是不喜欢听的，这个心理准备要做好。但即使是这样我也必须讲，而且要很有逻辑地讲，底气要足，气场要强。
+
+具体怎么做呢？首先要在谈判前理好逻辑。而且自己必须深信这个逻辑，不然就别指望后续我们能抗得住强大的对手。没法双赢的局面就是很容易让人紧张，因此在实际沟通时，我们可以试着放慢语速，把观点讲出来。
+
+其实讲出来了也没有什么，情况无非是两种，如果对方情绪激动，他们就乱了；如果对方稳得住，也有可能用更强的逻辑来打击你，这也很好啊，这是多么好的锻炼机会啊，这么想想也就释然了。
+
+要知道，棘手的问题大多数情况不会轻轻松松地解决，谈判也要谈很多场，而现实很少是对错分明，在谈判的过程中也许又会有新的信息进来。这种情况我们又该怎么办呢？
+
+我的建议是，**在这个过程中一定要认真客观地评估对方的观点，带着一颗好奇心去挖掘更多的信息，努力还原事情的本来面目，但是我们自己的立场必须坚定，绝对不能动摇，要做到前后一致。**
+
+那怎么客观评估对方的意见呢？很多人谈话时容易急于把自己的观点灌输给别人，这样做并不合适，因为每个人都有自己的逻辑和诉求。而我们每一个人看到的，其实都是经过大脑加工过的一个侧面。所以我们要做的第一步就是认真地听对方讲，挖掘信息，设身处地地去用心了解对方。
+
+故事回到文章起初提到的质问，美国技术主管不觉得A和T有冲突，那我就需要理解他的逻辑而不是一上来就反驳他。
+
+他是这样说的，产品A负责的是业务应用的管理，而产品T负责的是基础架构应用的管理，他认为业务应用和基础架构应用是不一样的。而且他觉得这样细分就可以明确两个产品的定位是不同的，也就规避了产品合并所带来的人员离职风险。我通过挖掘这些信息，我就能更好地理解为什么他觉得是两个细分场景？
+
+请注意，理解并不代表我们就赞同对方了。经理对于自己的意见必须很坚定，不能动摇。因为一旦动摇，我们的上级，平级，下级都会动摇信心，要知道大战中军心不稳很容易跨的。
+
+我虽然可以理解美国的主管做两个细分市场划分的思路，但是我坚定地认为我们更应该集中资源来做好最主要的市场而不是分散力量。为什么要集中呢？因为只有用短期的合并痛苦换取合并后的一个团队一条心，最终才能更好更快地完成交付任务。
+
+事情发展到现在，我是基于前一步的一心为公去沟通的，直面冲突是我的态度，并且我的立场很坚定，这里其实没有绝对的输赢，我们想要的是进展。
+
+## 3.争取领导，寻找同盟
+
+如果我们做到直面冲突了，几次谈判下来却发现还是处在僵持阶段，又该怎么办呢？这时就需要开始找帮手了。
+
+如果能获取领导的支持，破局的机会就会大很多。在云计算用户体验产品这个问题上，领导其实是有偏向性的，但是领导在一开始相当长的时间内没有介入，这一定是有领导自己的考量，那么这些考量我知道吗？就算是合并，是一个团队一个产品，我理解的跟领导理解的一样吗？这些问题我都需要跟领导沟通清楚。
+
+那如果领导没有偏向性呢？那我就必须站在领导的角度来看这件事儿了。这个内容我们可以沿用[变革管理](https://time.geekbang.org/column/article/286834?utm_source=pinpaizhuanqu&amp;utm_medium=geektime&amp;utm_campaign=guanwang&amp;utm_term=guanwang&amp;utm_content=0511)那一节讲到的如何说服上级领导支持变革。我们要解决的依旧是三个问题，
+
+- 站在领导的角度，考虑到整体组织利益会做什么决定？
+- 如果要实现领导的预期，具体需要哪些成功条件？
+- 执行这件事儿，我是这个组织里最合适的人选吗？
+
+如果领导也在犹豫呢？你就要去争取领导周围的人的支持，争取同盟的时候我想专门提一点：**不要永远只说那些摆在哪里都正确的官话。**
+
+举个例子，老王，老许还有我是平级的同事，最近我和老许观点不一致，正在僵持阶段。有一天老王找到我，对我说不认同老许的做法。我回答说：“老许的做法有对的一面，他的战略思考很厉害，如果我们有人跟老许互补配合就好了。”
+
+我说这句话在很多时候是没有问题的，但是我们现在在谈的是有重大利益关切的冲突管理，要知道老王也是很厉害的人，他已经敞开心扉跟我说了一句“不安全”的真心话，而我回他一句永远正确的话，老王自然心里明白，我没有完全对他敞开心扉，那他也就不会再说什么了。总之，他吃不准我是什么想法和态度，就不会尽全力帮我。
+
+所以争取同盟的第一个要点，就是**不说官话，而是表明态度。**如果觉得问心无愧，我们的想法都是为了组织变得更好，而自己观念的落实就是需要老王的支持，所以要干脆地表明态度。也就是明明白白地对老王说，我从不怀疑老许的初衷，但是我认同你说的观点，我和你一样，也不认可老许的思路，我需要你的帮助。
+
+寻找同盟还有一个用意，就是我们可以借此来**评估别人是不是支持自己的观点。**如果别人只是说了一些不痛不痒的话，那就得给自己提个醒，很可能我们的支持度并不高。要知道，真正支持你的人要么会摆明立场，要么会付诸行动，要么会给出真知灼见。
+
+最后还要注意一点，当我们觉得领导的态度是反对的，就不要去争取同盟了，因为弄得不好容易被领导看成是搞山头来聚众反对领导。
+
+## 4.尊重事实，业绩为王
+
+后来，我获得了领导以及平级老王的支持，你觉得这样就能统一部门内的意见了吗？远远没有，总部资深架构师也是很有影响力的，他的逻辑也是强有力的，有一点我很佩服他，就是他是一个为了自己的原则坚持到底的人。不论我怎么说，部门内的人怎么说，我们还是没有办法证明客户最后会对哪种方案更买账。
+
+记得当时他对我说，他不认可我说的话，不过既然领导决定了，那就试3个月看看。但是如果最后我们的交付不能达到预期，他会非常生气，因为我浪费了组织3个月的时间来做合并。而且为了保证技术实施的正确性，他要求审核后续所有的设计方案。
+
+事情发展到这里，总部架构师这一关要怎么过呢？情况是我背着3个月就要交付的压力，时间这么紧张，架构师还要审核所有的设计方案，如果他不认可我们的方案呢？如果设计拖很久呢？这些风险点在总部架构师提出试行三个月的想法时，我就在想对策。最终我采取的做法就是拿客户需求说话，拿事实说话。
+
+接下来，我就根据前面这两点分析了对策具体我是怎样做的呢？
+
+- **找外援把关技术设计**。既然总部架构师要审核所有设计方案，为了得到他的认可，首先就得确保我们能跟得上他的思路。这一点我没有绝对把握，于是我让上海的一位资深架构师参与到项目中，帮助我做决策。
+- **执行中听取成员意见**。为了我们的设计方案在三个月内如期交付，推进执行就要尊重事实，听取执行团队人员的意见，针对大家提出的风险点逐个做突破。
+- **保证执行的公开透明**。虽然我们是最后做决定的人，但总部架构师和技术主管的意见也很重要，所以我在执行过程中，但凡涉及重要的决策，我都会把决策的依据和决策推理过程都书面化提前发给他们。有时我还会跟他们开视频会议当面沟通，每个礼拜都有进度报告，每个季度都有演示，实现了公开透明这一点。
+
+这件事从确定合并然后开始实施计划，到现在已经两个月了，虽然我做了努力，但是总部T团队还是有两人离职。副总和总部云计算的高管安慰我说，这是可以预见的代价，而我觉得即使他们心中对于这个结果产生一些波澜，也是可以理解的。
+
+我要做的，就是克服一切困难，把产品按原计划的时间和质量交付。而事实上，因为我们在执行上的透明度和较好的进度，目前总部架构师和云计算的主管都肯定了我们目前的进展。
+
+## 总结
+
+好了，今天的内容讲完了，我们来总结一下。
+
+前一阶段我在看《大明风华》，看到宣宗朱瞻基对汉王朱高煦说的一段话，我就不由自主地联系冲突管理这件事上了。朱瞻基的台词是这样的：“连我爷爷也没有想出赢你的办法，我爹却做到了，他一再忍让，是你不懂节制，各地藩王看你飞扬跋扈，不愿与你亲近，他又派我去南京，安定江南七省的局势，同时给你手下的将领写信，只用了八个月，他就将你的根基彻底瓦解。”
+
+下面我就用这段话做引子，总结一下在无法双赢的情况下，我们怎么做。
+
+这里朱瞻基说的我爹就是明仁宗，明仁宗在处理这个问题的时候，始终以最大的善意在思考问题，他为什么一再忍让呢？因为他**心系百姓，不想内讧**，把出兵作为最后选择。我们做经理的也一样，要一心为公，关心团队成员。
+
+明仁宗的态度很明确，汉王想做皇帝是不可能的，在这个前提下尽量**不要同室操戈。**我们在这个案例里的态度也很明确，就是要合并产品集中力量。这一点不能动摇。
+
+相持阶段，明仁宗作为皇帝尚且要争取各地藩王的支持，何况我们呢？**从明仁宗这里我还学到了不但要争取平级作为同盟，还要争取对方的下属的支持**。
+
+最终朱瞻基还是出兵了，光谈一下也还是达不到目的，等你获得大多数的支持后，还是**需要用实力去做最后一击。**在我们的现实工作中，这一击就是交付业务价值。
+
+## 思考题
+
+1.在A和T产品合并的决定基本确定后，产品T团队的主力开发给客户写邮件说T的开发要暂停。总部主管对这位主力成员的行为表示了强烈不满，他写了一封措辞强硬的邮件，要求T的主力开发收回邮件并解释动机。如果你是我，你看到这封邮件你怎么办？
+
+2.这场谈判上海这一边只有我一个人，总部一边有技术主管和总架构师两位高阶领导，如果你没有办法说服技术主管站到你的一边，你还有什么办法减少自己面对的阻力？
+
+欢迎在留言区晒出你的经历和疑问。如果有所收获，欢迎你把这篇文章分享给你的朋友。

极客时间专栏/geek/技术管理案例课/二线经理：开始带经理了/16 | 冲突管理3：冲突不可怕，可怕的是引发信任危机.md

@@ -0,0 +1,136 @@
+<audio id="audio" title="16 | 冲突管理3：冲突不可怕，可怕的是引发信任危机" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/69/f2/691c646d3fa29933ab7b58487cc254f2.mp3"></audio>
+
+你好，我是许健。今天我们聊一聊如何避免信任危机。
+
+前面我用了两节课的内容，带你学习了高压对话和没法双赢的冲突怎么应对，其实还有一种冲突管理的视角我们很容易忽视，那就是发生冲突本身不是最可怕的，可怕的是因为冲突引发信任危机。
+
+我为什么这么说呢？因为我们今天谈的很多冲突都是在工作中的冲突，大家都是同事，也就是说大家在大方向上的利益是一致的，都是为了所在的部门能够更好，公司能够更好。但是信任出现问题就不一样了，这会导致互相猜忌，而且是往不好的地方猜忌，冲突就会愈演愈烈。
+
+那么问题来了，我们具体要怎么做，才能稳住信任这块基石呢？接下来，我们就带着这个问题，开始后面的学习。
+
+## 提升工作透明度
+
+透明度很重要，因为它是建立信任的必要条件。工作中，常常会因为信息不透明引发信任危机。双方看到的信息不对等，就容易出现一些想当然的看法，还可能因此无端地升级矛盾，导致事情向不可预测的方向发展。
+
+为什么缺乏透明度，就容易被别人误解呢？接下来我就说个真实的故事，带你体会一下。
+
+很多公司都会有研发新功能和继续线上支持这两件事同时干的情况，去年我们上海的云计算部门也面临这个情况。有过类似经验的朋友就会知道，双线同时进行的压力有多大。
+
+那时我们的客户对线上系统的抱怨越来越大，我们这些上海的经理也觉得线上系统的问题很严重，却没得到总部领导足够的重视，因为新功能的开发一刻也没有停止。当时正好赶上了总部云计算总监A的休假时间，测试系统一切换到新系统，客户的不满直接捅到了CTO那里。
+
+为了解决问题，我们只好停掉所有的功能开发，全员做系统加固，三个月后，部门重组，副总给云计算安排了一位新的领导Y，今年年初，前面提到的那位总监A自己离开了公司。
+
+后来我才震惊地发现同样是这件事儿，总部有些同事的解读却远远超出我的预料。他们是往上海方面有预谋的方向想，如果不是我到美国出差，我觉得我完全不会想到这样的理解方向。
+
+这件事儿他们是怎样解读的呢？上海方面的经理因为无法说服总部领导加固现有系统，所以故意夸大了线上系统的可靠性问题。测试环境切到新系统的初期，上海方面在已经看到问题的情况下仍然加大了切换力度，这是有意把问题暴露到CTO级别。还有人认为上海是对那位休假总监有意见，想借此拿掉他。
+
+故事说到这里，我已经不想去纠结当时谁对谁错了，我更关心的是以后怎么处理类似问题。有什么系统性的方法来避免发生类似的误解，对症才能下药，其实发生误解最最重要的原因还是缺乏执行透明度。我复盘了一下，其实有这样两个关键事项，我们本该做好的：
+
+**第一，有问题早暴露。**系统可靠性问题，我们应该直接召开云计算经理会议，把数据摆在桌面上，并且直接提议要停掉新功能开发。如果更进一步，我们早就应该把线上系统出问题的趋势摆在桌面上，最好在A休假之前就应该这样做。
+
+**第二，扩大知情范围。**像测试系统切换这样的重大决策，应该把切换计划跟美国总部同步后再实施。不单单是跟总部的云计算部门沟通，还应该跟客户也过一下计划和切换条件。再来一次的话，我会建议系统切换前后每天同步状态更新报告。
+
+想清楚了这件事，我又往下推演了一步，想了想执行力度不透明造成的不信任，是不是在这次事件之前就埋下了呢？那么有什么更通用的方法，能够提升工作透明度呢，我这里给你梳理了两个要点：
+
+- 决策透明。把决策的过程和决策依赖的数据和材料发布出来。注意决策透明不代表放弃决策权，最后做决定的那个人还是你。
+- 执行透明。定期公布进度，特别是及时强调阻碍进展的事情，如果需要上级领导注意就直接说出来。千万不要等到影响最终交付的时候再说，那个时候再说就是甩锅了。
+
+## 重要问题当面谈
+
+重要的问题，特别是牵涉到人的问题，用邮件来回交流不如打电话沟通，而且最好是视频电话，当然，如果能和对方面对面坐在一起谈最好。
+
+为什么这么说呢？因为邮件沟通是没有办法得到及时反馈的，也体会不到沟通对象说话时的神态。因为得不到及时反馈，有些问题我们就没有办法及时澄清，这样就给猜忌留下了发酵的时间和土壤。
+
+我这么说是因为我在这个问题上踩过“坑”，下面我就分享一个这样的故事：
+
+我们公司在流量控制方面实行了两套方案，分别由A和B两个部门负责开发。短期来看因为这两个部门负责的模块不同，暂时不会发生直接冲突，但是考虑到长期发展，最后一定要面临两个方案二选一。刚好我去美国出差，A部门领导找我讨论这个问题，他建议我本着为组织利益考虑的原则，勇敢地表达自己的观点。
+
+于是我回上海之后写了一封表达自己观点的邮件，然后把邮件发给了A和B两个部门的领导和副总。邮件发出的第二天，总部另一位领导Y打电话给我，和我说B部门的领导看了邮件很生气，他给我电话不是为了说明孰是孰非，只是为了指出这里面的沟通有问题。Y建议我以后对于重大问题不要写邮件了，最好当面谈。
+
+很巧的是，当初建议我遇到重大问题最好当面谈的领导Y，后来成了云计算部门的一把手。上任后他对我说：“许健，以后我们合作，我很希望你有想法的话当面跟我说。”
+
+有了前面和领导Y的“重大事情当面谈”这个默契，后来有两件事，虽然我觉得他听了会不高兴，但是我还是当面把话说清楚了。
+
+一件是平台安全的事，我本着组织利益和员工个人发展的考虑，想要安排Y这条线上的一名高级别员工去支援别的部门，当面沟通后Y同意了。
+
+还有一件是Service Mesh的事情，我和Y说我越来越觉得我们没有汲取过去这么多年的教训：不把手上的现有系统做扎实，就去启动新系统，这会导致我们精力分散。我能感觉到Y听后有些不高兴，但是Y也没有反驳我。
+
+我自己做了一个复盘，发现其实这几年里在许多重大问题上，特别是与人有关的问题，我通过邮件交流而不是当面沟通的通常结果都是造成误解。这些问题不是一两件，它们最终消耗了我更多精力去处理。
+
+这里我多说两句，实际我们和别人当面沟通，特别是找领导沟通的时候，还是会紧张，担心领导不高兴。
+
+我的建议就是，把自己的态度摆明，比如说为了跟着领导好好干，我就是需要知道领导的期待；要是和领导的观点不一致，我会私下和领导做沟通，坦诚相告，如果领导没有认同，我会保留意见，对外还是会按照领导说的执行。
+
+信任都是依靠我们的实际行动来一点点建立的，那前面讲到的透明和当面谈的原则，该怎么具体落实呢？接下来我就从和部下沟通、和领导沟通这个角度给你详细讲一讲。
+
+## 对下：把话说透，不要让部下猜
+
+你要知道，没有部下会喜欢跟领导冲突，因为和领导相比，部下是弱势一方，所以跟领导冲突部下有什么好处呢？
+
+如果在实际工作中，我们作为二线经理，在已经能够感受到部下不满，甚至被部下当面顶撞的时候就要提高警觉了，因为很有可能部下实际的不满，要比他表现出来的严重得多。为了让你更好地理解这一点，我给你讲一个具体的故事。
+
+我部门有一名经理X，我一直很看好他的能力，觉得他完全可以独立负责一块项目，而且是在整个基础架构部门都有关注度的项目，所以我一直在找他沟通，希望他选定一个项目并确定业绩指标。
+
+后来X终于说出了自己的心里话，“许健，其实我不大喜欢你这样给我压业绩指标的，我更喜欢自己安排自己的目标”。
+
+在X给我这个反馈之前，我已经连续数次跟他谈了定指标的事儿，但是迟迟没有进展，我心里也能感受到他并不认同，不然按照他平时的做事效率早就应该贯彻执行了。
+
+我找到他，对他讲清楚了我的决策思路，也让他讲清楚他的意见，**在我看来我们俩有不同的意见事小，但是有意见分歧不当面谈清楚事大**。
+
+为什么这么说呢？因为这事儿弄得不好就会演变成：我作为经理说的话，部下不反对，也不按我预期的执行，那我会不会往部下不尊重我的方向想？而部下其实内心不认可领导的意见又被领导强压，部下会不会往他在领导心中是不是信得过的人这个方向上想？又会不会往领导根本不了解真实情况的方向想？
+
+回到我和经理X的沟通，我之后了解到X从小就在家里挑大梁，很反感别人帮他安排事情。基于这个了解，后来我跟他说了两点：第一是我不给他定指标，但是他需要自己给自己定一个目标。第二是我希望他对于我们之间的沟通，不要存在心理负担。也就是我希望他跟我说话时不需要准备，我找他说话我也不想准备。
+
+我们把话说透了以后，沟通就顺畅了不少，我能明显感觉到X在处理一线问题的时候，很好地掌握了度，很多事情他自己处理掉了。如果什么事，他觉得需要我知道，就会主动抄送我；如果需要我介入，他也会第一时间当面找我谈的。而最初我找他沟通的问题呢，他也明确跟我说了，他完全明白我的意思，但他也需要一些时间来想清楚他自己的目标。
+
+## 对上：不要去怀疑领导的初衷
+
+但凡是有些能力和想法的部下，就不大可能对领导所有的决策都认同。其实不认同不要紧，问题就出在不认同，然后又不跟领导做充分沟通，只是自己在那里瞎想。特别是把领导往坏里想，这就埋下了一个祸根，不要以为这个祸根能藏着住。
+
+接下来我们跟领导还有很多交互，还会有意见不合的时候，这个之前埋下的祸根会潜移默化地影响你对事情的解读。到了发生冲突的时候，再要修复你和领导的关系代价就大了。不要觉得我危言耸听，电视剧里那些上下级反目的故事，其实也在各个办公室中重现，只是激烈程度不同罢了。
+
+我的领导对于组织安排有她的想法，对人的潜力和发展也有她的看法，这些看法我有些也不赞同。问题是有时候我脑子里也飘过一些危险的想法，比如老板是不是要平衡下面的组织，老板是不是跟兄弟部门更亲一些而跟我们不是很亲……后来我很快把这些想法去除了。
+
+你一定会好奇，我是怎样去除那些危险想法的。其实是我和部下发生的一件事儿给我带来的灵感，也是因为这件事儿，我觉得自己更能体会我领导的初衷了，下面我就来给你说一说。
+
+故事是这样的，我基于保证线上系统的稳定性这个逻辑，将两个高级别员工从新系统调往线上系统，并拒绝任何现有系统维护人员投入到新系统开发中。负责新系统的经理就觉得自己的团队在新系统上做得很累，正是需要我支持的时候，于是跟我抱怨。
+
+有一次我和这位经理激烈对话中，他提出想自己去找老系统的维护骨干谈，我说了一句**不要动我老系统的骨干，那是我的根本**。该经理一下子就火了，对我说老系统的骨干是你的根本，那我就不是喽？我们做新系统的人就是后娘养的？！
+
+事后我回顾这件事，我不觉得自己的决定有什么问题，我承认“根本”这个词用得欠妥当，但是这位经理质疑我对他和新系统的人员的公正，把他们当后娘养的绝不是我的初衷。我很不喜欢他这样看问题的角度。
+
+那将心比心，我该怎么理解我的领导提出的组织调整建议，还有平时对我说的话呢？
+
+我的结论就是：**一定要积极正向地去理解问题。永远不要怀疑领导的初衷。哪个父母不希望自己的子女好，做子女的又为什么要去计较父母在一时一刻对某个子女好一点呢。**
+
+什么是积极正向的理解呢？我们的关注点应该是站在领导的角度去看问题，试图理解领导的想法。如果理解不了，就找领导好好地谈一下，问清楚领导的用意。每个公司的文化不同，至少在eBay，我就是这么做的。
+
+这里我假想一下，假设我不在eBay ，假设我的领导真的是对我有意见，那现实一点想，我把心思花在怀疑领导的初衷上有意义吗？
+
+我觉得没有意义，这样只是徒添烦恼。而且自己把握不好的话，还会让领导觉得我对他有意见，那我还不如把精力花在如何修复跟领导的信任上。其实说到底很简单，就两条路，要么我不认可就选择离开，要么我积极看待，然后着手提升和领导的信任。
+
+这里我再次提醒一下，要是想跟领导谈有冲突性的话题，我们一定是要单独去找领导谈，切忌纠集了几个认同了自己观点的人一起去找领导谈。因为这样做，弄不好就会被领导理解成“逼宫”。
+
+## 总结
+
+今天我们谈了解决冲突的基石，也就是信任。信任的保持首先需要决策和执行透明，不然就容易给猜忌留出滋生的土壤，在上面长出误会的杂草，如果不及时清理，甚至会升级成冲突。
+
+**如果你发现同一类冲突反复出现，你就要认真思考它的深层次原因，才能系统性地解决问题。**
+
+往往这些深层次的原因都跟信任有关，那在实际工作中，我们具体怎么做，才能稳住信任这块基石呢？
+
+首先我们要**提升工作透明度**，通过执行和决策两个维度的透明化，降低因为不知情引发的误会。其次，就是**重要问题当面谈**，把猜忌扼杀在摇篮之中。有了这两个原则，作为二线经理，我们还要和部下、领导培养好信任关系。
+
+对于部下，我们要把话讲透，不要让部下猜。我个人很不喜欢《大明王朝1566》里嘉靖皇帝老给部下打字谜的管理方式。这里我还想补充一下，我们对性格强硬的员工更应该直话直说，不要遮遮掩掩，因为有话直说，才会给人以一种君子坦荡荡的感觉，更能赢得他们的信任。
+
+对领导的安排有不理解的，不要去怀疑领导的初衷，如果实在想不通我的建议还是应该去找领导当面谈一下。在之前的文章[向上管理](https://time.geekbang.org/column/article/280295?utm_source=pinpaizhuanqu&amp;utm_medium=geektime&amp;utm_campaign=guanwang&amp;utm_term=guanwang&amp;utm_content=0511)中我也提到过，跟领导相处要有感恩之心，抱着支持的心去提反对意见，对外要维护领导权威。
+
+总之，信任的积累就像在一个玻璃鱼缸里垒小石子，需要很久才能垒满，但一个不小心就可能敲碎鱼缸，前功尽弃。希望这一讲的内容，能带给你一些启发，把冲突引发的信任危机提前化解掉。
+
+## 思考题
+
+1.作为下属，如果你对领导的决策有不同意见，你觉得自己不主动和领导谈清楚的深层次原因是什么？
+
+2.我们做个换位思考，作为领导，你觉得自己的部下在跟你意见相左时不和你充分交流的原因是什么？你会采取什么样的举措来改善呢？
+
+欢迎在留言区晒出你对于信任管理这个话题的经历和疑问。如果觉得有所收获，也欢迎你把这篇文章分享给你的朋友。

极客时间专栏/geek/技术管理案例课/二线经理：开始带经理了/17 | 招募高手：看人看本质，优秀的人才都是内驱的.md

@@ -0,0 +1,159 @@
+<audio id="audio" title="17 | 招募高手：看人看本质，优秀的人才都是内驱的" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/49/1e/49c74697fdce075856f5e1e78d13ed1e.mp3"></audio>
+
+你好，我是许健。今天我们来聊一聊招募高手这件事儿。
+
+管理者能不能招到“对的人”，几乎决定了我们想做的事儿能不能成。而我们能招募到一个高级别人才，是完全可以改变战局的。
+
+就拿我们公司开源的大数据分析产品麒麟来说吧，这事儿的技术难度很大，组织内部还有很强的反对声音，如果没有老蒋这样技术和性格都很强硬的技术骨干，我估计这个项目就做不起来了。
+
+后来，我们公司又花大力气替换TeraData，这个过程也不容易，如果没有老王这样的技术极客对Spark做深度调优，我看这事也就黄了。这些事呢，都印证了高级别人才对攻坚性的关键项目起到决定性作用。
+
+所以如果经理对招聘高级别人才的重视程度不够，那其他的就不要谈了。招募高手这件事不能把宝都压在人事部门，还是需要招聘经理平时多做积累，亲力亲为。
+
+## 1.高级别人才在乎什么？
+
+我们想要招募到高手，首先就需要推演一下，高级人才到底在乎什么？
+
+高级别人才最最在乎的是能够施展抱负的平台，或者说是展现才华的舞台，而不仅仅是薪金。要知道真正的人才，他所在的原单位也不会轻易放手的，市面上的机会也不少，所以这种人真是可遇不可求。
+
+在实际工作中，我遇到的问题主要有两个方面。一方面是“庙太小”，也就是我提供不了高级别人才需要的平台。因为我们是海外研发中心，需要遵从国外本部的决策，高级别人才会觉得得到的授权不够，决策效率不足；另一方面是我人脉不够，接触不到高级别专家。即使认识，我们之间的关系深度也不够。
+
+首先说说“庙小”这个问题，我觉得老是等着总部启动一个新的大项目，再去找相应的人才不是长久之计，而且别人启动项目的话，往往主动权不在我们。但在实际操作过程中，这就是个死锁问题（永远在互相等待的进程），也就是没有高级别技术专家就很难启动大项目，而没有大的项目又很难吸引高级别专家级人才。
+
+那么这个“死锁”要怎么解呢？我越来越觉得要有独立的思考，想想自己距离独立启动一个大项目还要做哪些准备。比如云计算的混合部署、公司测试效率提升，平台安全和针对业务数据做AIOps，这些都是很值得做的项目，而高级别技术专家是能够成功启动这种项目的基础。
+
+关于项目的技术决策问题我们后面的课程再展开讲，这里我想说的是，**作为部门领导我们自己必须心中先有目标，有了目标就不会再迷茫，有了目标再去找人。**
+
+再说说我人脉不广的问题，尤其是关乎我们部门发展的关键方向，我觉得自己和业界大牛联系还不够密切。可是人脉是需要长期积累的，这件事要从哪里下手呢？我总结了四个要点：
+
+第一点，从“经营自己的品牌”开始，主动构建人脉。比如我主动输出了自己的技术心得，写了[《三高产品设计那些坑-上》](https://mp.weixin.qq.com/s/bnhXGD7UhwTxL8fpddzAuw)和[《三高产品设计那些坑-下》](https://mp.weixin.qq.com/s/Xyvfx9mLKqquulnrhFi42Q)这两篇技术博客以后，就认识了不少对高可靠、高性能、高扩展问题有兴趣的技术同仁。
+
+第二点，主动走出去。想要做到这一点其实有很多方式，比如参加会议，认识会议演讲嘉宾；参加培训，认识培训老师，特别是实战类的培训；跟业界的优秀公司互相做分享，认识核心研发主力。
+
+第三点，提升自己的人才搜索技能。这一点可以跟HR学习，脸皮不妨厚一些，主动去联系想招募的候选人，比如给候选人写个邮件，就说希望认识一下。
+
+第四点，利用网络社区拓展圈子。相关领域的国内外论坛和微信公众号要访问，也许就会通过这些社区认识志趣相投的人。
+
+我刚刚总结的要点最终都是为了多认识人，要知道很多高级别人才不是通过猎头而是通过熟人换工作的，所以拓展人脉这件事我们一定要重视。
+
+## 2.高级别人才怎么招？
+
+前面我给你讲了高级别人才需要施展自己才华的舞台，接下来我们就来说说高级别人才到底要怎么招？
+
+**面试是双向选择**
+
+为什么我强调面试是双向选择呢？因为没有这个基本点，我们很容易进入误区。要知道，争夺高级别人才不代表我们只是一味希望他加入，却不设置严格的面试，相反，面试越严格才越能彰显我们对高级别人才的重视。面试的过程我们在选择候选人，候选人也在考察公司和招聘经理。
+
+我在前面[人才招聘](https://time.geekbang.org/column/article/282069?utm_source=pinpaizhuanqu&amp;utm_medium=geektime&amp;utm_term=guanwang&amp;utm_identify=geektime&amp;utm_content=0511&amp;utm_campaign=guanwang&amp;gk_cus_user_wechat=university)那一篇里专门强调过，面试是挖掘候选人的信息，而不是证明你比候选人强。但在面试高手时，这一条需要做出调整，在面试中我们至少有一两次表现，能带给候选人一个“招聘经理本人非常优秀”的印象，因为越是优秀的人就越希望跟同样的人一起工作。
+
+那问题来了，我们怎么给候选人留下好印象呢？我的经验是要带给候选人更加严格并且严谨的面试体验。在这个过程中，面试官自己的思路要非常清楚，要通过不断地问问题，在候选人自己做过的项目中找到一两个有漏洞的点。如果这一两个点所暴露的问题候选人认可，候选人心里其实也会对面试官加分的。
+
+面试高手，我们还有一个绕不开的问题，就是出现候选人的专业知识在面试官之上的情况，这个情况其实很常见，那这件事该怎么解决呢？这个时候可以找专业知识足够强的人帮你面试，不然还是只能自己上。
+
+如果自己亲自上的话，我觉得不管是技术细节还是管理细节，如果候选人不能用清晰的逻辑让我理解，我不会认为我水平差，而是会觉得候选人水平不够。因为我深信真正的高手是有能力用平实简洁的语言把问题讲明白的。
+
+招聘高级别人才不能急，就跟结婚一样，不能跳过谈朋友的过程。我会把公司和部门的实际情况，现实的困难和可能的机会尽可能详细地告诉候选人，而不是对现实的困难避而不谈。因为光谈机会不谈困难，候选人进来以后会有落差的。
+
+一般比较优秀的候选人，也会问面试官很多细节的问题来帮助他决策，从他问的问题里我们也能感受到候选人的认真程度。比如他可能会问这样的问题：
+
+- 老板对我加入后具体的期待是什么？
+- 请帮我理一下组织结构和人物关系。
+- 我进来以后主要困难在哪里，我能得到多大的支持？
+
+一般经过两三轮面谈，我们就可以问问候选人如果加入的话，接下来会准备怎么展开工作。有想法的候选人要么会继续问你细节，要么就会给出思路。
+
+**最重要的人才特质：内驱力**
+
+说完了双向选择的面试过程，还有一个关键问题很重要，就是顶级人才到底有什么共性？因为只有解决了这个问题，我们看人时才会更准。
+
+eBay中国研发中心的总经理做招聘经验分享时，最最强调的人才特质就是“内驱力”。你可以看一下自己公司内的那些顶级人才有什么共同的特点，我们公司其实无一例外都是内驱力很强的人。
+
+**内驱力是什么？内驱力就是这个人无论做什么，他都有一颗不断追求卓越的心，并且有这个毅力为此目标做长期奋斗，因为这个人的本质就是不甘于平庸。**
+
+我给你分享一个故事，给你说明一下什么样的人算是有“内驱力”。
+
+我的老板曾让我跟一位她看好的候选人吃饭，这位候选人是某个国内互联网公司的云计算高级总监。饭桌上这位候选人直接打开笔记本给我看了在他的主持下开发的PaaS系统，然后信心十足地说他现在整个OpenStack运维只需要三个人，最后他还现场展示了在17秒内创建一个独立测试环境的过程，用手机实时查询了各系统的健康指标。
+
+说到这里，你估计会想，这人是挺厉害的，但怎么就判断他有内驱力了呢？请听我细细道来，
+
+我记得在三年前，这名候选人曾经带着他的团队骨干来eBay学习，那时候他们什么也没有。当时我可以直观地感受到他对技术的热情，还有不断提高自己的渴望。
+
+更可贵的是，他不是那种只有热情却不能沉下去落地的人，因为通过现场展示这回事儿，就能看到他对自己负责产品细节非常熟悉，他会熟练操作自己负责的产品。怪不得老板说能得此人，他对上海云计算部门的信心就会倍增。
+
+这里我多说一句，试玉要烧三日满，辨材须待七年期。人才需要长期观察和考验才能判断这个“内驱力”。
+
+**高级别人才转型，你招吗？**
+
+伯乐为什么厉害，他在千里马还不是人人皆知的时候，就能看出来这是一匹千里马。我们想要招募高手，又要内驱力高，又要马上能用，符合这样要求的人其实很少很少，即使有这样的人才也是炙手可热的，不一定会看得上“小庙”。
+
+于是我就会放开一个条件，就是我不会强制要求候选人的技术背景一定可以跟我们部门完全匹配，只要这个候选人本身的素质高，我就会考虑，比如上面说的内驱力强，比如人聪明学习力强。很多时候这样的人才都是在寻求转型的阶段，比如下面这些情况：
+
+- 经过多年经理的职业生涯，候选人决定回到技术岗位上。我甚至见过候选人非常决绝，直接辞职准备回归技术岗位的。
+- 候选人因为工作原因两地分离，或者因为当前工作强度实在太大，想寻求家庭和工作的平衡所以换工作。
+- 候选人一直在传统行业工作并且是那个行业的精英，但是他基于对未来发展的判断希望转型到互联网行业。
+
+我们会发现这样的候选人有一个特点，就是他们已经在自己原来的领域比较资深了，只是在具体技能上跟我们现在的要求有差距，到底招不招呢？接下来我们还需要考虑这两个问题。
+
+首先，我们要考虑自己招聘的方向需要一个能独当一面的高级别人才吗？在这里我面临的情况是已经有了能够做执行的人，我就是缺一个有独立思考能力、能够扛起一个团队的技术骨干，所以答案是我就是需要这个人综合能力强。
+
+其次，我会去衡量这个候选人在具体技能上的差异，是否可以通过快速学习弥补。具体怎么看呢？就看候选人是不是提升动力很强，还要看候选人是不是足够自律，能不能静下心来主动快速学习。
+
+## 3.高级别人才怎么做后续跟进？
+
+我们通过之前的面试考察，如果对候选人已经有了比较好的印象，有意招聘他加入时还是要注意一下，越是高级别人才越要仔细谨慎一些。
+
+有时候我觉得这跟结婚差不多，约了两次会感觉很不错，并不代表能够在一起过日子，而且“离婚”成本非常高。所以领证前最好见见对方的父母至亲，如果能在一起住一段时间就更好了，最后就算因为种种原因没有成，但缘分还在，说不定那天缘分到了就在一起了。
+
+我建议不要把背景调查作为后续评估候选人的唯一标准，我更相信通过自己的熟人搭上线，得到更有价值的评估。
+
+**模拟真实项目**
+
+高级别人才招聘多两三个回合并不过分，这恰恰是对双方互相增进了解的必要步骤，这里我用自己的部门为例，给你讲讲怎么通过真实模拟做后续考察。
+
+招聘高级别人才往往有现实的需要，以我们部门来说，就有下面这两个需要。
+
+第一，公司介入支付业务，基础架构方面对安全的要求越来越高，我们需要一个在平台安全方面有经验的高级别人才来给整个部门设定方向，提升我们在平台安全上的整体水平。
+
+第二，公司的运维正在向智能运维转型，其中基于机器学习、时序分析的智能监控是基础。我们需要找到一个在智能监控上有实际经验的高手来加快部门整体转型速度，提升监控部门在智能监控方向的技术积累。
+
+那我们怎么把团队的需要转化成真实的模拟呢？我们可以给高级别人才模拟一个“大作业”，这个大作业需要我们把现实碰到的问题，我所知道的这个问题的背景，机会和挑战，问题本身和相关人员关系综合在一起告诉候选人，看候选人怎么解决。
+
+我觉得可以把这些背景材料整理成一个模拟项目，让候选人花一到两个礼拜提交项目解决方案，甚至是MVP的代码。
+
+刚才说的给候选人布置“大作业”，具体怎么落地呢？
+
+给了候选人模拟项目后，我一般会把微信留给候选人，看候选人会不会在这一两周内主动找我问问题。然后等候选人提交了“答案”，就约他再来公司针对这个项目一起做项目审核。
+
+这个作业其实考察的是候选人发现问题、分析问题到最终解决问题的能力，因为我们对高级别人才的综合能力有着更高的期待，高级别人才处理的问题很多都不是清晰定义的、可以马上做实施的，而是更为复杂和综合的。
+
+我实际操作下来，发现做具体项目并提交代码和项目方案这个方法效果很好，有一半人一听到要做“大作业”就直接放弃了，对这样的人我也不觉得可惜，因为他们加入我们部门的动力不强。剩下的人，真的能按时提交并且再来公司时能通过项目审核的，后来入职了表现都很不错。
+
+**如果这次招募没成功，我们怎么办？**
+
+我一直相信很多事情我们花了很多力气去做，看上去这次没有马上见效果，但是却播下了一颗种子，只要哪天外部条件成熟了，这颗种子就会发芽。
+
+我有两个非常得力的部下都是这样的情况，第一次没有来没有关系，我们保持联系，你能知道我很在乎你，很希望你来帮我，我能给什么样的平台你也都知道的；第二次不来也没有关系。我有耐心，等到外部条件发生变化，他们还是来了。
+
+我记得S入职的那天，Hr都知道前面我和S做了很多交互，HR领着他过来时，还对我说你的得力干将来报道了。R是我劝回来的，但R入职的时候因为我自己的部门没有招聘预算了，两年后他才通过内部转岗加入了我所在的部门。我还有几个长期联系的候选人，因为这样那样的原因现在不能在一起，但是不要紧，以后总会有机会的。
+
+**所以，就算这次招募没成功，我们也要坚信：这次不行，缘分还在。**
+
+## 总结
+
+要吸引高级别人才，不在一朝一夕，需要持续地积累资源，才能给这些人才搭建施展才华所需要的平台。
+
+我们想做好招募高手这件事儿，就需要想清楚这三个问题。
+
+第一，高级别人才在乎什么？答案是展现才华的平台。所以，我们要通过主导大项目吸引人才，通过扩大自己影响力、走出去交流学习等方法主动构建和积累人脉。
+
+第二，高级别人才怎么招？我们需要明确面试是个双向选择，别光说机会也要说明现实的困难；最最优秀的人才都是内驱的，能找到不甘于平庸的人是招聘经理的福分。看人看本质，放弃一个内驱力强做事认真，但是当前技能不够的高级别人才有可能是我们的损失，风险与机会并存！
+
+第三，前几轮双方印象都不错，招募高手的后续跟进怎么做呢？我实践下来，觉得做实际的MVP模拟大项目检验效果非常好，因为我们可以把问题从模糊理到清晰，从项目架构和源代码质量等多个方面评估候选人。
+
+希望你的人才库也经过日积月累，能够更加丰富，就算人没有来也不必着急，缘分还在，下次还有机会。
+
+## 思考题
+
+我在高级别人才转型的地方提到，要看候选人的内驱力够不够，是不是能沉得下来用很强的自我约束力学习。那你准备通过什么办法来判断这个候选人是不是这样的人呢？
+
+欢迎在留言区分享你在招募高手方面的经历与体会。如果有所收获，也欢迎你把今天的内容分享给你的朋友。

极客时间专栏/geek/技术管理案例课/二线经理：开始带经理了/18 | 组织管理：如何突破团队效率提升的三大关？.md

@@ -0,0 +1,164 @@
+<audio id="audio" title="18 | 组织管理：如何突破团队效率提升的三大关？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/28/60/28177cbf23dafb8bc73e96b5b4b31c60.mp3"></audio>
+
+你好，我是许健。今天我们来谈谈如何提高团队效率。
+
+关于提高团队效率，我先和你分享一个故事吧。这次新冠疫情期间，我回顾了自己这八年做云计算的经历，我觉得我们的团队做得非常累，我们团队的工作时长在eBay中国研发中心一定是排在前面的，但是我们的口碑却不一定最好。
+
+为什么这么说呢？因为同僚和领导承认我们很辛苦，却不觉得我们很优秀，从客户满意度、工程卓越性来说，我们取得的成效都和我们的付出不成正比。
+
+为了提高效率，我们也多次抓过可靠性、代码质量、搞CICD，连执行组织形式也尝试过多次变更，但是我觉得做这些事情都不是最最关键的。事实上，当我们去总经理那里汇报组织提效方案时，得到的反馈是“**没有触及灵魂**”。
+
+这个反馈对我的触动还是蛮大的，我开始认真地反思组织没效率，问题到底出现在哪里？
+
+我这个人很喜欢从历史里汲取教训，于是就把我们这三代云计算系统的经历排了一遍，分析哪些事情做得好，哪些事情做得差，然后对比它们之间的区别，最后总结了提高组织效能的三个关键问题。接下来我们就来详细聊一聊。
+
+## 1.选择正确的事情
+
+踏上管理岗位以后，你有没有意识到你的一个决定下去，会直接影响少则几个人、多则几十个人，少则几个月、多则半年甚至数年的投入呢？
+
+**很多时候，做正确的事情，远比正确地做事更重要。**做经理的，想要提升团队效率，首先就要看清楚我们身在何处，又想去向何方。
+
+那怎么定义什么才是正确的事呢？我给你分享一个思路，就是做决定时反问一下，如果这是你自己拥有的公司，员工的工资都是你自己掏的，你还会这么决定吗？
+
+我回顾云计算这些年在eBay的变迁，我们不是做得太少了，而是做得太多了。我们有的项目是技术驱动然后绑架客户来用，而不是真的客户需要，接下来我给你分享三个具体的故事来说明这一点。
+
+第一件事儿，就是我们把内部的云计算CICD从Jenkins改成了Prow，这件事儿投入了我们很大的精力。我认为影响云计算团队交付效率的关键在于测试环境不够稳定，边界测试和性能测试的测试框架不够健全。我们总可以列出Prow优于Jenkins的点，但这是解决团队交付效率问题的核心吗？
+
+第二件事，我们启动了Account Resource Quota，我承认公有云系统的资源都是属于Account 的，我们也列了很好的交付目标，比如可以让每一个业务部门自己管理自己的预算，从而帮助Capacity团队提高管理效率。
+
+但后来Capacity团队的负责人却告诉我，他们最大的痛点不是缺乏按账户管理，而是如何在保证资源利用率的前提下，加快业务部门获取资源的速度。也就是说如果财务模型不转换成每个部门单独结算的话，就算我们把系统做成按每个部门的账户结算，也不会提高资源利用效率。看来单单从Account角度变更Capacity的管理方式，并没有解决用户真正的痛点。
+
+第三件事，我们做了好几代网络管理系统了。在这个过程中，模型驱动是不停在强调的一个标准，模型驱动其实没有问题，但问题是花了这么大力气做系统变更以后，长期困扰我们的难点（比如安全流量迁移、网段分配冲突和泄漏）并没有得到解决。而且我们在搞出新系统的过程中，并没有干掉上一代系统，甚至更上一代的系统现在还在生产环境运行。
+
+从刚才讲的三件事儿中，你可以看得出来，我们只是在积极地做事儿，但并没有选择做正确的事情，这些事儿的共性就是**投资收益比不高**，却白白花费了团队很多精力。所以，在我们做决策以前，必须先理清做什么才是正确的事儿。
+
+那什么叫正确的事情呢？**我认为正确的事情就是在做决策的那个时刻，管理者所能选择的可以最大化交付业务价值的事情。并且这个业务价值不是管理者主观认定的业务价值，而应该是客户认可的业务价值。**
+
+其实我自己整理了一个文档帮助我理清思路，文档中的例子还不止上面这些，也不仅仅限于云计算部门。这里的关键点是第一出发点的选择问题，就是说技术经理要从客户认可的最终业务价值考虑，而不是把技术先进性当作第一出发点。只有从最终的业务价值出发，我们后面的努力才有意义，组织效率才能真正提高。
+
+凡是可以从根本上提高组织效率的事情都不简单，那么我们想干掉那些“不正确的事情”，难点在哪里呢？
+
+第一个难点在于凡是有能力在组织内提出新项目，甚至有能力组织一部分员工做雏形系统的人，一般都是组织内能力较强的人。如果技术经理经过评估后要关停这些人的项目，抽走支撑这些项目的资源，很大可能会让这些骨干很不爽，那我们有没有这个感情强度和能力落实呢？
+
+第二个难点是也不乏有些项目就是我们技术经理自己启动的。我们有这个气量来承认自己之前错了，然后纠正自己的错误，而不是不停去找理由证明自己是对的吗？
+
+难点列出来了，我们要怎么解决呢？虽然有些一言难尽，但这里的本质问题就是做好冲突管理。我们要在组织内部统一思想和认识，有魄力“下刀”。因为我们一旦确认了某些事情不是我们要选择的方向，那再做这些事情不仅毫无意义，而且还会浪费企业的资源，要知道在错误的路上走得快还不如在原地不动，所以我们必须删除这些项目。
+
+## 2.选择合适的技术方案
+
+前面说的留下高收益比的项目，是决定了我们到底做什么，那么选出合适的技术方案，就决定了我们怎么做。
+
+**不打移动靶**
+
+我先说说方案选择的关键原则，**技术方案的选择请务必直指核心问题的解决，不要打移动靶，不要去追求技术的纯粹性导致不断扩大战局****，最终造成****投入成本的快速增长**。
+
+为了让你理解这一点，我就拿C3（基于Openstack的云计算平台）到Tess（基于Kubernetes的云计算平台）的迁移为例做个说明。
+
+假设C3环境下我们要创建一个带有100个虚拟机的应用，那么就要先准备100个虚拟机，然后一个批量操作把负载均衡器配置好，后续部署代码的时候重用这100个虚拟机。也就是说，多次代码部署的时候不用重建虚拟机或更改IP。
+
+可是迁移到Tess以后，每一个POD创建完成都会触发一次负载均衡操作（加LB Member），Tess不是Fire-and-Forget（发后即忘）模式，而是不停地进行Reconcile。Kubernetes Native每次部署时都会重新创建所有POD，而在胖容器环境更换Image也是需要重建全部POD的。在这个过程中，其实API的调用次数是明显高于原来的C3环境的。
+
+现实情况是，并非整个生态都已经在Tess上，我们还有很多外围系统。所以我们耗费了大量时间试图解决性能问题。我给你说说当时我们的尝试过程：
+
+- 第一回合，首先我们把Tess调用LBMS（Load Balancer Management Service）的方式改成了Bulk Call，并且让LBMS去除了多余的输入有效性检验来换取性能，但还是不行，于是我们又联系数据中心添置额外的LB硬件设备来分摊调用量。
+- 第二回合，硬件扛住了，可是我们的配置管理系统CMS Sync在高压下还是会出现数据不一致问题，改了好几版这些才解决掉这个问题。
+- 第三回合，解决了数据不一致，我们又发现重建POD后的胖容器还需要重新部署代码，于是CMPAAS（eBay的代码部署工具）Schedule性能问题就因为不堪重负而暴露出来了.……
+
+我们本来只是上一个新系统，结果变成了要改造整个生态。在这个过程中我们的实施成本成倍增长，最后的交付时间一拖再拖。回过头来看，**我们是不是需要思考一下，当引入一个新的系统的时候，到底最看中的是什么？**
+
+我们看中Docker的“Build Once，Run Anywhere”（一次编译，随处运行），看中Kubernetes的Spec Driven（规范驱动），而在这个例子里，Rolling Upgrade是否需要坚持POD和对应的IP重建值得商榷。
+
+很巧合的是类似事件屡见不鲜，所以我们一定要提高警惕。最近我还在跟总部一位同事讨论，我们一个项目的核心只是为了给Squid的Proxy 加上ACL， 但是为什么谈着谈着，就变成了要把整个Squid集群换成Envoy集群呢？这么多年来这样的事情发生得太多了，其模式如下：
+
+一开始，我们要解决问题A，大家都认同A是值得解决的；接下来，解决问题时我们偏向新技术，觉得能搞定新技术，结果在过程中还想顺带解决别的问题，而且搞定新技术的时间超过预期。再然后业务突然有需求，新技术栈还没有好，只能让老技术栈来扛，这时人手已调往新技术；最后总是祸不单行，老技术栈扛不住业务突发需求，拖死。
+
+所以我给你简单总结一下，做技术经理的一定要时刻提醒自己，我一开始启动这个项目的初衷和想解决的问题是什么，我够不够专注，特别是在项目推进中碰到周围干扰时我有没有坚持足够专注？有没有把一开始想要解决的问题**踏踏实实地解决彻底。**
+
+**突破关键瓶颈**
+
+刚才我给你讲了方案选择的关键原则——不打移动靶，专注于一开始要解决的问题。但是除了这个原则，我们还需要解决关键瓶颈怎么突破的问题。要知道，决定整个战役成败的，往往就是那一两场关键战斗。
+
+我先和你分享一个故事吧，我们的监控组交付Metrics耗时了四年，记得对这件事做复盘的时候，副总觉得最最关键的问题是团队不够专注，所以他决定停掉监控组所有的项目，强迫监控组只专注Metrics这一件事上。
+
+但我跟副总说，对于监控的复盘我有不同的看法，关键瓶颈没有突破，就算停掉所有的工作专注Metrics还是不行的。我为什么提出这样的看法呢？我们先看看监控组在Metrics上的历程：
+
+第一版是基于Storm来实现的流式处理引擎。
+
+第二版我们发现眼下Flink才是趋势并且觉得Flink有很多优点，但是因为改造成本过大，于是选择了Storm On Flink的方式。
+
+第三版又有变化，因为第二版走到后来发现Storm On Flink有很多限制，于是决定走Native Flink模式。
+
+第四版，这时美国的一位资深架构师M指出公司内已经有很多部门在使用Prometheus ，我们也意识到我们基于Flink的实施方案有问题。因为这个方案需要自主开发处理各类时序数据的函数，但我们没有足够的投入可以去开发这么多各式各样的函数。于是开始转为解决Prometheus的高扩展下的性能问题。
+
+这四版的历程我刚才给你交代时只是简短的几句话，但实际过程都是我们团队以年为单位计数的成本投入，直到第四版的方向确立后，架构师M亲自实施了Prometheus的扩展原型，性能调优落实到Prometheus内部实现，最终论证了可行性。
+
+**这个关键技术瓶颈解决后，监控组半年就交付了可投入生产环境的成熟时序数据监控方案。**其实整个监控Metrics的交付，核心问题就是高可扩展性下的性能问题，整个团队前期耗时三年半却没有交付，但最后半年就交付了的根本原因是什么？在我看来就是一个高水平技术人员在关键点做了突破。
+
+后来又是这位架构师，确立了使用ClickHouse来构建我们的下一代Events监控方案，可扩展性和性能的问题也一并解决了。
+
+类似的事情还有很多，这些都让我深深意识到从事基础架构工作中要去找关键瓶颈。这类难题只靠堆更多的人是不行的，就是需要高手，要么外面引进，要么内部有合适的人能攻坚。
+
+我一直强调人和事的并行，我们找了高手，也总得搞清楚关键瓶颈在哪里吧，那关键瓶颈到底怎么找到呢？我一般会用这两个问题帮助自己整理定位关键瓶颈：
+
+- 我们的着眼点是不是足够聚焦？不停逼问自己哪一个点突破可以极大提升产品竞争力。注意就只挑一个点。
+- 问题真的是关键瓶颈么？关键瓶颈一定不能轻易解决。要么是技术难度极大，要么是关系很复杂，要么要耗时很久……
+
+这个思路怎么落地呢？我们还是用一个实际案例来说明，比如我们监控目前在做**异常检测平台**，需要解决的问题看起来有这3个：
+
+1.根据当前选定的一两个业务的实际生产环境，找到一个可以符合**性能和精度要求**的算法。
+
+2.算法精度所依赖的底层数据质量不过关，所以需要增强算法的**鲁棒性**。
+
+3.找到一种可以**快速自适应不同场景**，并能保证一定精度的算法。
+
+这3个问题第一眼看上去都很重要，但是如果我强制说一定要排一个优先级，并且推断出最高的优先级，就会迫使我们进一步分析筛选。
+
+我们的目标是构建一个平台，产品的竞争力到底在哪里呢？就是异常检测问题解决的投入产出比。也就是说，我们选择突破的点一定是能够让大批客户上线试用的，问题1能够让一两个用户上线但是无法实现大批客户上线，这不能让我们的异常检测成为平台去服务很多人，也就是解决方案的覆盖面不够广。
+
+问题2单独看着挺重要的，但如果和3对比一下，我们就能找到不足了。问题2其实是问题3的必要条件而不是充分条件，因为即使解决了2 还是不能达到大批用户可以上线试用的平台要求。所以最终我们确定了关键瓶颈是3，因为这是将eBay的大量对异常检测有需求的场景，进行平台化解决的关键。
+
+## **3.如何激励好组织内的员工**
+
+确定了团队做什么和怎么做，既然是经理，最终还是要回到人这个话题上来。刚才在突破关键瓶颈的问题上，我也强调了高级别人才的关键作用，那我们经理要怎么激励他们呢？接下来，我结合自己的感受给你说一说：
+
+在相当一段时间内，eBay中国研发中心都很忌讳讲Ownership这个词，我们只强调Responsibility。原因是美国有些领导觉得中国动不动就要跟他们谈Ownership，他们感觉这就是要抢活，没有One Team Mindset。
+
+我最近对这件事有了新的看法，我跟总部的副总和诸多领导都直说了，我觉得只谈责任不谈权力不谈担当是不符合人性的，而且我不认为Ownership 和One Team Mindset 有什么冲突。
+
+以我自己来说，副总最近让我全权负责云计算产品的入口体验，我对这个事情的投入程度和你让我辅助别的领导来做就是不一样的，我不是说我辅助别人就不卖力了，但是卖力程度可以不一样，我花100%的力气你也说不了我什么，问题上你怎么能让我花120% 甚至 200% 的力气呢？
+
+其实答案很简单，**信任和授权**。给高级别员工授权让他们去独立负责一个大项目，给他们自由让他们按照他们的方法去实现目标，用经理的信任去换他们的承诺。
+
+对于部门里我们看好的有潜力的员工，要敢于给机会，要高标准要求，出了问题我们也要兜着，因为对于经理来说，这些潜力股未来的成长更重要。
+
+最后，如果他们真的高质量达到了高标准，不要吝惜奖励，并且要以超出常规的方式去奖励他们。我对比我们部门和数据基础架构部门新人培养速度的差异，为什么他们不断地有明星员工浮现出来？我觉得关键的点就在这里：**我对我们部门有潜力的员工的要求不够高，并且在奖励上不够刺激。**
+
+最后就是淘汰部门内业绩差潜力差的员工。具体的操作方式我在[裁人](https://time.geekbang.org/column/article/284299?utm_source=pinpaizhuanqu&amp;utm_medium=geektime&amp;utm_campaign=guanwang&amp;utm_term=guanwang&amp;utm_content=0511)那一篇谈过了。心要慈，刀要快，有些事我们不喜欢做，但是为了这个组织能够有更好的发展，就是需要去做这些不开心的事情。而且级别越高的经理，最后留给我们去裁的人越难办。
+
+总之，能者上庸者下，为了团队效率的提高，员工激励这件事的原则就是**：赋能有潜力的人才和淘汰业绩差的员工。**
+
+## 总结
+
+组织管理上我们可以定一个基调，所有能从根本上提高组织效率的事情，都一定是高成本、高难度的。
+
+一招鲜吃遍天的绝技不存在，天上掉馅饼的好事更不会存在。“高光时刻”的背后，更多的是在整个过程中无数个平凡的日日夜夜的坚持，在我们成功之前，也要做好没有多少鼓励和关注的心理准备。
+
+在提高组织效率的路上，我们有三大关卡要突破：选择做正确的事情、确定合适的技术方案以及激励好员工。
+
+首先，**正确的事情就是在做决策的那个时刻，管理者所能选择的可以最大化交付业务价值的事情。**要注意，这个业务价值不是管理者主观认定的，而应该是客户认可的。想要干掉“不正确的事儿”，要么会动骨干的蛋糕，要么就是纠正自己的错误，本质上是我们做冲突管理，需要有足够的魄力去落刀。
+
+接下来，决定了做什么后，在具体实施过程中要不停提醒自己目标是什么，然后不停地质问自己，我们的技术方案是否始终聚焦在最开始的那个问题上。不要打移动靶，而是要聚焦。尽量减少依赖，不要轻易扩大问题范围，总之就是减少变量数目。
+
+关键技术点的突破对交付效率的影响是决定性的，我建议你把自己发现的问题写出来做比较分析，结合产品竞争力定位最关键的问题，然后通过外部引入或者内部资源寻找高手攻坚。
+
+在人的问题上我给你分享了三点心得，第一给高级别技术人员授权并且给决定权，第二给高潜质员工更高的标准和火线提拔的机会，第三要淘汰组织内业绩和潜力差的员工。
+
+最后我再强调一下，留给我们解决的问题大多是“硬骨头”，**没有轻轻松松可以提高组织效率的事情。这也正是需要你来做经理的原因。**
+
+## 思考题
+
+公司里说要提升效率，于是提出了测试代码覆盖率，CD覆盖率，手动重复劳动自动化率等指标并要求各部门执行，你怎么来看待这些提效的举措？
+
+我们说到给予高级别员工决定权，你怎么来平衡给予下属的决定权和你作为部门主管经理的控制力？如果他们做出的技术决定跟你想的不一样呢？
+
+欢迎在留言区晒出你在组织管理方面的经历和疑问。如果有收获，也欢迎你把这篇文章分享给你的朋友。

极客时间专栏/geek/技术管理案例课/二线经理：开始带经理了/19 | 危机管理：摆明态度，不要做名义上的领导.md

@@ -0,0 +1,146 @@
+<audio id="audio" title="19 | 危机管理：摆明态度，不要做名义上的领导" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/f2/06/f2271a2feea692300c66c863484b4606.mp3"></audio>
+
+你好，我是许健。今天我们聊一聊怎么做危机管理。
+
+《吕氏春秋·季春纪》里一篇叫[《论人》](https://www.jianshu.com/p/a24f53e34315)的文章，这篇文章提到了识人的“八观、六验、六戚、四隐”，我觉得讲得非常好，有兴趣你可以去看看。它强调我们要真正考察一个人，就得看他在面对重大利益关切，遭遇重大变故时的表现。同理，真正考验领导力的，也是在出现危机的时候。
+
+那我们怎么保持危机下的领导力呢？下面我就分享三个实例，都来自于我的亲身经历，说不定里面的应对方法和复盘思考能带给你一些启发。
+
+## 薪资预算大幅削减
+
+一年前，公司业绩持续走低，我们需要裁员4%；年底评级能够得优秀的比例控制在10%以内；年底调薪幅度还不到往年的一半。了解了这个情况以后，我初步判断这件事可能带来的风险是军心不稳，如果应对不当，很可能引发骨干离职等更大的危机。
+
+所以我准备找直接下属开一个会议，一方面我需要把这个消息告诉他们，让大家有一个预期，另一方面我也需要直接下属帮忙去稳定一线的队伍。当然，开会之前我必须先做充分的准备，理清楚自己除了传达消息之外，有什么办法能让下属理解我的心，然后把稳定一线队伍的事情真正落实下去。
+
+而我真正担心的是团队里那些核心骨干，他们都是在猎头那里挂了号的，会不会因为最近公司的业绩低迷而被人挖走呢？
+
+我其实并不觉得来自外部的压力太难应对，相比外患，我觉得一个组织最后垮掉，最根本的原因一定是内部，外部压力再大都是内部出了问题才能发挥作用。所以但凡有危机，我都会先注重管好内部，而且我相信真正难的事儿都来自内部。
+
+当时整个大部门都在这件事要怎么处理，美国总部的副总是这么做的：副总和他的直接下属（一般都是高级总监或者总监）全部零加薪，把自己的加薪预算拿出来补贴一线骨干。后来我有一个部下对我说，许健如果你也要求我们全部零加薪，我们也会支持的。但后来我没有采纳零加薪的方案，因为我觉得直属部下这一年也很辛苦。
+
+其实钱的问题只是一个触发点，核心问题不是钱，而是一把手的担当和承诺，这才是危机之下领导里的体现。那这种担当和承诺，我怎么传递给团队成员呢？
+
+我后来在会议上是这么跟团队说的：“首先，我许健在这里跟大家表个态，我绝对不会去外面看任何机会，不管这个机会有多好，因为我要带着大家把这个组织变成上海最优秀的部门。要是我违背这句话，我从此没有资格来要求你们。”
+
+表明自己态度以后，我给下属提出的要求是：“我们部门下面每一个组的经理和架构师，基本你们所在的组也是你们一手带过来的，你们也应该有跟我一样的承诺。”
+
+当然，提完要求我也想和他们交个底，留下意见反馈的“通道”，我当时说的是：“如果你们觉得待在我们部门有什么不开心或者有什么要求，我希望你们在出去找机会之前，至少应该给我一个机会来解决。如果我无力解决，那你再出去找机会我也不多说什么。但如果连解决问题的机会都不给我，这也说不大过去的。”
+
+为了保证沟通的闭环，说完前面这些话，我还向他们一个一个确认了是否认同我说的话。
+
+讲完了我在薪资预算削减这件事的应对方法，我还想进一步深挖，和你分享一下我的思路。在我的价值观里，一个真正有战斗力的团队，其中的核心成员就是应该有这样的承诺。这个承诺的本质就是做到“可托付”。
+
+为什么这样说呢？因为我们的职业发展到了一定程度时，要想让领导把关键岗位交到我们的手上，就必须成为可托付的人。也就是说，领导得知道我们不会因为困难退却，也不会因为诱惑离开，这样把队伍交给我们的时候他才放心。而有些人折腾了很多年，对自己的定位还是一个“可用之人”，虽然自己有点能力，但是如果碰到更好的机会，跑路也很正常。
+
+我一直信奉榜样的力量，危机面前，我们想要部下钉在自己的岗位上，不要在乎一时之得失，那自己首先要做到这一点。并且应该给部下明确表态，不给自己留退路。
+
+## 核心人员相继跳槽
+
+业绩不好削减了薪资预算，我们主要做的是稳定军心。那如果危机来自外部，比如出现了强大的竞争对手，甚至导致核心人员相继跳槽，这样的危机又该怎么办呢？我给你讲一个故事吧。
+
+在我转到经理岗位后，记忆中eBay中国研发中心最困难的阶段，就是大量人才向携程和唯品会流失的时候。当时eBay总部两位很有影响力的华人高级主管回国发展，分别加入携程和唯品会，吸引了一批中坚骨干离开。我记得有一次统计离职率竟然高达27%。
+
+其实我也差点去了携程。对我来说去携程工资没有涨，离家远很多，我都准备去淞沪路租房子了，工作时间也更长，但是我还会想去，这是什么原因呢？主要有这两点：
+
+第一点原因是eBay内部也有问题，我之前在[变革管理](https://time.geekbang.org/column/article/286834?utm_source=pinpaizhuanqu&amp;utm_medium=geektime&amp;utm_campaign=guanwang&amp;utm_term=guanwang&amp;utm_content=0511)那里也提过，那时候我虽然管了四五个小团队，但是工作都是美国安排的，自己其实没啥决策权，没有成就感。
+
+第二点原因是携程可以给到的平台很吸引人，至少在当时让我觉得可以干一番事业。那时候还流行“世界很大，我想去看看”，我还看了“一席”栏目里方励的[演讲](https://yixi.tv/speech/114#/speech/detail?id=114)，方励说他惜命的方式不是养生，而是折腾，我对他的观点很赞赏。
+
+我现在回忆一下，发现我的老板当时做了很多努力。一方面是帮我争取授权，老板其实知道根本问题在没有授权，那时正好碰到总部的领导S来上海出差，她就直接告诉S，许健想离开的一个最主要的原因就是授权不足，无法施展身手。因此我相信我的老板正在努力，在积极地解决这个问题。
+
+另一方面就是找我谈，还找跟我关系很近的人跟我谈，其中一个人就是老王。老王跟我在张江传奇广场的翠亭吃的饭，说他之前差点去了携程，结果他为什么没有去呢？是因为有一次儿子跟他说：“爸爸，我想你有多点时间陪我。”
+
+后来HR的经理Maggie跟我说：“许健，你花了这么多年终于在eBay 把手脚伸开，可以做些事情了，你现在走不就都白费了吗”。
+
+最后是老板在雨人会议室跟我谈的，我最后还是决定走，我记得她当时蛮憔悴的，这么多骨干离开，真的很难。后来经过一些波折，最终我并没有去携程，并且反而因为在这次危机中的种种经历，让我跟我老板走得近了很多。
+
+我说一下我对这事的反思：
+
+第一点，最关键的还是**平台和发展机会**。这个问题我们平时就要高度重视，等员工跨出找工作的那一步，就已经很被动了。最近由于我们公司在基础架构安全上有调整，打乱了我和老T原来商量好的发展计划。所以我必须尽早落实老T的发展平台，也要让美国总部领导高度重视这件事。
+
+第二点，平时就要和关键骨干**强调重承诺的原则**。怎么实现呢？留在公司首先得有个目标，而且这个目标是只有留在公司，才有可能得以实现的目标。我现在就在推进这一点，直接向我汇报工作的部下，每一个人都需要有这样一个目标，这也是一种承诺。我相信关键骨干都是负责守诺的人，在完成承诺前不会离开，因为守诺中很重要的一条就是说话算数，答应了就不会半途而废。
+
+第三点，**人才梯队建设**。我们要高度重视人才梯队建设，完善团队的人才培养机制，关键岗位继任者和后备人才计划要早早规划，早做培养。这里的人才其实比我之前在人才招聘里的要求要高，因为我们要找的其实是“可托付的人才”而不仅仅是“可用之才”。这样的人是要我们付出诚意请很多次才有可能得到的。而且这种人一旦加入了团队，往往是可以共患难的。
+
+关于上面的第二点我想额外说一句，你注意到了没有，当年的我一边在发起组织变革，一边却在考虑离开公司去携程发展。我现在回看当时的情况，觉得那时候的自己也不够成熟，没有担当。
+
+现在如果我要发起变革的话，我绝对不会在外面找机会，我会对部下表态，给出我的承诺，死死地钉在自己的岗位上表明我坚定的立场。
+
+你看到了吗？我其实也不是一开始就很成熟靠谱的，荒唐的事情当初也做了不少，运气好的是我的领导一次次地容忍了我，给了我自省和犯错后重新来过的机会。
+
+## 最严峻的危机：被部下架空
+
+这是我职业生涯中一次难受却又难忘，受挫严重却又促成我快速成长的经历。我现在仍对我手下这位经理Y说的话历历在目，这里我选择了四句最有代表性的话。
+
+> 
+<p>1.许健，你让C去做事情，他你的听吗？你让X去做事情，他听你的吗？我下面的人，都只听我的。<br>
+2.我下面的人干得这么累，我给他们多要一点涨薪和股票不过分，你如果不给，就把我的涨薪和股票拿走给他们好了。<br>
+3.许健，你说U是你的根本，所以我不可以劝他加入我的小组。那我就不是你的根本了喽，我和我的小组对你来说就是后娘养的，对吗！？<br>
+4.许健，你觉得你气量很大对吗？我告诉你其实你不是。</p>
+
+
+不知道如果你是领导，听到部下这样说，会有什么感受？这位一线经理其实是我多年的好友，还是我劝他加入eBay的，当时他已经在前公司做了多年经理。
+
+在一开始的两年，我和他都是尽力互相帮衬，最后怎么就变成这个样子呢？我今天不去谈我和这位经理Y的对错，其实也谈不清楚，我想讲的是我当时的处理方式和事情过去后自己的反思。
+
+**当时的处理方式**
+
+从刚才我提到的Y对我说的话，估计你也对情况有了初步判断，那就是情况已经有些失控了。我当时并没有把失控的事情瞒着领导，而是一五一十告诉了她。
+
+我跟领导讲的时候秉承了一个原则，就是我自己身上一定是有问题的，这一点要承认。我的感受我也没有几个人可以分享，总得有个出口。
+
+那时我干得也很不高兴，但当时的我已经有了担当意识，所以我给老板的建议就是：“既然我已经管不了这个组了，就让经理Y独立运作吧，你能不能给我一年时间呢？我会在这个期间完成我承诺给总部领导的工作，然后你看看能不能给我安排一个别的工作，我偏向于做回技术路线。如果找不到合适的位置，那我就去外面找找机会。”
+
+我和领导同步了情况还有自己的想法之后，接下来我就更加专注把C3（基于OpenStack 的云解决方案）的客户体验做好 ，并且由于我更加专注，我带的其他几个小组在半年内得到了几个重要客户的认可。
+
+在这期间又发生了一系列的事情，情况是这样的，Y负责的小组承担的是公司新的技术栈项目，也是公司将来技术发展的主方向。在这样的大背景下，为了这个项目成功，Y持续地和领导要求更多投入。加上上海这里对接总部新副总的领导迟迟不能到位，Y只能自己对接，因为Y跟总部领导也冲突不断，这让总部领导觉得这个团队已经不是他的团队了。
+
+因为这一系列的事儿，我并不认可Y的激进做法，觉得他没法把团队带往更好的未来。我慢慢也缓过神来，自己的看法也有了转变。
+
+我承认自己在过去这段时间存在问题，我会尽心尽力协助老板去外部找新的部门领导，但我越来越确定，如果要从内部选择团队主导人的话，我就是那个最合适的人选。
+
+**事后的反思**
+
+这个架空危机过去以后，我仔细做了反思。
+
+我作为一名二线经理，给一线经理授权不等同于放手不管，对于这么重要的Track，可以双手放开，但必须两眼盯紧。跨级的Deep Dive（深度谈话）要做，关键指标和Milestone（里程碑事件）要看，核心骨干的信任关系要培养。这些事没做到位是我最大的失误。
+
+另外，我在跟Y关系很好的时候，我把新技术栈的架构师以级别倒挂（架构师的级别在Y之上）的方式汇报给Y也是一个失误。我发现危机的产生都是平时的疏忽大意，看起来我和Y的信任关系很强，一直在给他授权，但一线团队的管理细节我却知道得更少了。
+
+那么Y为什么跟我的关系会从多年好友逐步恶化呢？我现在的解读是，Y觉得他面临很大的交付压力，但是他不觉得从我这里拿到了他需要的足够的帮助；而我觉得他只为自己的团队，却不考虑整体团队。Y觉得我作为领导决策失误，我觉得Y开始膨胀且越发不尊重自己。
+
+信任裂缝出现后，我们两个人在交付压力和观点不一致的双重作用下，冲突情绪迅速发酵。Y很强硬，而当时的我不够强硬，本质上来说自己不够强，不足以掌控部门内的其他强者。
+
+那么问题来了，当你感觉自己不够强，应该怎样调整自己呢？**“我可以承认自己距离强者有差距，但是我绝不会对自己失去信心。”** 这句话是经历这件事以后我的最大收获。
+
+出了问题并不可怕，可怕的是我们从此颓废，一蹶不振，这个问题我就算这次在eBay退却了、避开了，它以后还会在别的地方以其他形式重现，因为我一直没有解决它。还有，很多时候其实我们没得退，打个不恰当的比方，打了败仗还想划一个自留地，从此相安无事，这其实是做不到的。
+
+碰到问题，要正视矛盾。如果我们暂时没有那么强的领导力，就要专注我们能控制的事情，比如我在危机的时候就告诉自己应该对团队负责。所以我尽心尽力去帮助老板engage新的领导候选人，而且专注把C3的客户体验做好。
+
+危机也是我们历练的机会，也许我们可以把危机化为转机。静等转机的过程中，我们要把心态摆好，如果有转机那当然好，如果没有转机，我们也尽自己的努力做好能掌控的事情了，这也照样很好。
+
+总之，即使在危机状况下，我们也要始终专注于业务价值的交付和团队成员的成长。因为作为一名经理在最关键的事和人上持续投入，团队其他人特别是领导都会看在眼里，我们迎来转机的概率就会大很多。
+
+## 总结
+
+今天我们谈了危机下的领导力，面对企业内部的风波，比如业绩下滑，要做到能够共患难。作为领导必须以身作则，摆明你的态度，以坚定的意志和身体力行的作风稳定军心。我专门提了我们不但要做可用之人，更重要的是要做可信（可以托付重大职责）之人。
+
+光靠意志力约束其实无法长久，面对外部挑战，领导想要稳住团队里的骨干，还是要落到具体的计划和行动上。主要从三个方面考虑：
+
+第一是落实骨干的发展平台和工作机会，这件事我们要有紧迫感，不要等到人家去外面找机会了再急着解决。
+
+第二就是以身作则，树立重承诺的风气。高级别人才需要给予愿景，最好是他自己提的愿景。要知道这些人在内心对自己都是有要求的，他们大多觉得自己是一个说话算数的可靠的人，自己提的目标，当然不能轻易放弃，这意味着危机时刻他们也不会轻易放弃。
+
+第三是做好人才梯队建设，这里的人才其实是“可托付的人才”而不仅仅是“可用之才”。
+
+最后我谈了失去领导力的应对方式和我的反思，即使在危机状况下，我们也要始终专注于业务价值的交付和团队成员的成长，这会增加我们转危为安的几率。
+
+面对危机，最最重要的一点就是**我们可以承认差距，但是绝对不要失去信心。**这句话不单单对职业生涯有效，也是我们在人生中面对挫折时给自己的鼓舞。
+
+## 思考题
+
+1.我在文中谈了被部下架空的情况，那如果是被老板架空的情况呢？也就是老板在决策和执行的时候，基本上就越过你直接找你下面的人了。你觉得导致这种情况发生的原因可能有哪些？如何预防？如果事情已经发生了，你会怎么做？
+
+2.我做经理多年后，通过一次偶然的机会，我意识到可以积极看待公司裁员这一类的“坏事”。因为这些“扰动”，一些组织结构的调整才可能实施。建议看一下《反脆弱》这本书，然后结合自己的工作经历写一段心得分享出来（请务必做一下，一定有收获）。
+
+欢迎在留言区晒出你在危机管理上的经历和疑问。如果有收获，也欢迎把这篇文章分享给你的朋友。

极客时间专栏/geek/技术管理案例课/二线经理：开始带经理了/20 | 文化建设：哪些价值观能够提升团队凝聚力？.md

@@ -0,0 +1,182 @@
+<audio id="audio" title="20 | 文化建设：哪些价值观能够提升团队凝聚力？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d6/95/d6d8048e181a33972ca061072209a395.mp3"></audio>
+
+你好，我是许健。今天我想和你聊一聊文化建设这件事儿。
+
+有一本非常著名的书叫《人类简史》，不知道你看过没有？书里提到这样一个观点，就是用语言可以组织150个人，而在古代要组织更多的人就要靠宗教。
+
+这其实就是在说文化的力量，它可以快速聚集一批人，提升凝聚力。而在组织内，文化和核心价值观就是指导我们做事的一个现有依据。这种依据平常给人的感觉就是不显山不露水，但真到一些需要做决策、定目标或者换方向的场景中，就显得尤为重要了。
+
+这样的感觉在我近几年的工作中愈发强烈，你不妨通过我的故事找找共鸣，从而沉淀出提升团队凝聚力的具体方法。
+
+## 文化建设怎么做？
+
+我们先从文化建设讲起，可以分这样几点：树立品牌、暴露危机、统一思想和目标落地。
+
+### 树立组织品牌
+
+**一个组织就像一个人一样，它也有自己的标签**。这就好比我们经常会说某某某是一个什么样的人，认真的人、守信的人、自负的人等等，一个组织也一样。
+
+那我们云计算部门给人什么样的感觉呢？我老板说得最多的就是：“许健你们部门很苦，工作很努力”。但问题是很苦很努力不代表很强啊，我在一些偶然的机会，收集到了很多反馈，这里我给你列几个最有代表性的：
+
+有一个产品经理对我说，在你们部门错过承诺的交付时间，好像没有事一样的，但在我们部门如果说好哪个时间点完成，加班加点也要交付。
+
+在云计算的季度计划会议上，总部的高级总监说，App小组半年交付了什么？！UX 小组半年交付了什么？！而在副总的2020 H1总结会议上，副总直接问云计算部门完成了年初计划的多少，我回答说60%-70%，那一刻真是感觉一点也不硬气。
+
+框架部门的一位高级经理对我说：参加你们部门某个团队的Sprint Review，团队里有一位同学说既定任务没有做完，这时候团队经理一点质问也没有，就默认没有做完这个说法了。而他所在的部门，部门领导会直面这件事，如果没有令人信服的理由，当场就不会给面子。
+
+说完这些反馈估计你也明白了，我还有我们部门给别人的印象就是对承诺不够严肃认真，这已经影响到我们部门的声誉。所以我开始思考该怎么改变这种情况，我希望我和我的部门能有一个什么样的标签呢？这个标签就像是一个品牌，能引导团队文化聚焦到一个核心点上。
+
+我开始列了很多项，很细，但发现都很难落地。最后我想了一个方法，求极值，如果只能有一个标准的话，那我会希望它是什么。最后得出的结论就是：**说话算数**。
+
+你有没有注意到，**一个组织的品牌很大程度上是有这个组织的一把手决定的。**为什么呢？因为一把手会鼓励他喜欢的行为，压制他不喜欢的行为，时间一久，这个组织的特质就会带上组织一把手的印记。那反过来说，如果我们部门现在的文化不是“说话算数”，最大的责任人是谁呢？那只能是我。
+
+但凡事都是有过程的。我有仔细回想过，为什么我们部门的品牌是努力？因为我这么多年推崇的就是“努力”，我觉得这代表了不停追求更好的自己。你不达到这个努力的标准，我不会接受；你努力了，到时间事情没有做完，其实也没有关系。现在的团队我带了8年，新招的人，以及我们部门提拔到领导岗位的人都是努力型的。
+
+我没有那么天真，没有打算在短期内把一个花了八年形成的“努力”文化转变成“说话算数”文化，这个文化建设的过程，作为领导我们的态度要坚决，行动要谨慎。我看过《王安石变法》担心自己好心办坏事，而我的领导也担心我搞运动急于求成。
+
+我碰到的问题在组织内没有经验可以借鉴，很多落实的细节还有待进一步完善和验证，但摸着石头过河，边做边总结也算是树立品牌的必经之路吧。接下来，我就跟你分享一下我的这段经历（在我写专栏的时候，这个故事还在进行中）。
+
+### 暴露危机形成紧迫感
+
+首先要做的事儿就是明确我们为什么要改变文化？我是收到了反馈，但我们的团队成员也许并不清楚这些情况。
+
+所以我开始尝试给大家一些上级反馈，比如我在跟eBay中国研发中心的管理层、基础架构总部领导接触的过程中受到的批评和建议，都是促使我想改变的原因，我会让部门成员知道。组织内部先要达成共识，认识到文化的问题不解决，对我们整个部门的发展都不利。
+
+我先是在部门领导会议里分享了这些不按照承诺交付的负面反馈，提议在接下来的部门全员季度大会上直接让全员都知道，然后再引出“说话算数”这个组织文化。
+
+当时，部门的领导层里就有人不建议我这么做，理由是部门全员大会的目的是为了鼓舞士气，奖励本季度的优秀员工，如果我分享这些反馈，那就是在告诉团队，我觉得你们做得不好，团队积极性会受挫。我当时觉得有道理，就接受了这个建议。
+
+但是当天晚上我越想越不对，我算了一笔账，这个全员会议一百人，会议时间一个半小时，一共消耗150小时，相当于一个人干近20天。我愿意付这个成本，只为了开一个你好我好大家好的会议吗？当然不愿意，我还是觉得应该坚持原来的计划，于是当天晚上我在领导层微信群里说了我的想法。
+
+后来的季度全员会议上，我直接分享了那些负面反馈，也反复强调了今后要践行“说话算数”这个文化。我还做了一个共享表格，让团队成员把自己的目标都写下来，并提到接下来我会在奖惩上跟进。当然，我要以身作则啊，我是第一个填写目标的人。
+
+季度会议过去没多久，就出了一件事，这更让我觉得解决文化问题迫在眉睫。当时公司准备做组织重组，要把一个关键功能的小组合并入我所在的部门。
+
+想要完成组织重组，领导必须考虑这个小组关键核心骨干的稳定性，但是领导在征询意见时发现一些核心骨干对这样的组织变动持保留意见。为什么会这样呢？还是因为他们觉得我们部门不是一个说一不二，说到做到的部门，最终指向的就是部门的执行文化有欠缺。
+
+这件事让我很有感触，我相信我们部门的领导层也都是对自己要求很高的人，不能接受我们现在给人的印象：**这个部门很努力，手上的事情很多很杂，加班很多，但是交付时间并不准时，交付质量也不惊艳。**
+
+要知道这个时候，eBay中国研发中心正在发生快速的变化，支付和风控的崛起，广告和搜索的扩张，都需要我们在极短时间内做出成绩，还有数据分析的组织变革，数据基础部门OKR的推进，框架部门强大的人才梯队等等，都增强了我们的危机意识和紧迫感。
+
+所以哪怕文化建设这个事很难，为了团队更好，我们还是要迎难而上。
+
+### 领导核心必须统一思想
+
+文化建设这事儿很紧迫了，那我到底怎么往下推进呢？独木难支，下一步就是部门领导层必须意见高度统一。要实现文化转型，靠我一个人不行，必须靠我们的领导核心。而最难的也是领导核心达成方向和方式节奏的统一。
+
+那个季度会议过去的一个礼拜以后，我去看了那张收集团队成员目标的表格，除了我自己的目标在那里，其余都是空的。于是我开始反思自己，发现决定做这个共享表格并不代表我做了什么艰难决定，如果简单做个表格、走个流程就能把事情落实下去，还要经理做什么呢？
+
+为了不让决定流于形式，于是我召开了第二次部门领导会议，我提出：“不公开自己目标的人，将来不会列入接下来年度业绩评优的考虑范围，也不会在我们升职候选人的考虑范围内。”
+
+这样说完，会议气氛立马就严肃了很多，部门里有一名高级别技术骨干提出现在大家比较激动，是不是冷静一下，下次再开会。我也发现眼下开大会没多少效果，所以就同意了。
+
+在接下来的一周里，我**单独**找部门经理和技术骨干们去谈了这个事情，我上来就表明立场了：“关于说话算数这个文化我已经定了，没有商量的余地。但是关于怎么做，我想听到大家的真实想法。”
+
+他们其实都认可了这个大方向，但是对于如何做，还是有自己的保留意见。所以，我又召开了第三次部门领导会议，探讨之后我们有了一些方向：
+
+首先，领导层达成共识，只对部门内经理和高级别技术骨干实施新方案，第一阶段暂时不对全员实施新的业绩考核方案。因为新方案实施后，一线经理有这样的担心：经理无法根据实际需要灵活地调整员工的工作。
+
+其次，如果上级要求下级做出承诺，那是不是下级也可以要求上级做出承诺呢？如果我做到了，我的业绩是不是就是优，我是不是就可以升职？我们不想要这种上下级交易模式的氛围，我们希望团队氛围是每个人有自己的目标，而组织和经理是来帮助个人实现目标的。
+
+还有一点是，新的提案实施可能会让整个部门趋于保守，这点是我们共同的担心，因为员工可能只会设定自己有很大把握完成的目标，失去进取心，所以必须沉到落实细节上。
+
+我结合会上的探讨结果和领导层沟通的情况，越发觉得统一思想的问题是长期的事情，不可能一蹴而就，要有耐心。我的想法可以通过增加沟通频率，多次沟通，保持开放性，持续小步推进。尤其重要的一点是用实际行动去证明，要让团队里的人感受到实际的效果，比如中国区和总部领导的认可。
+
+你或许会问，为什么我要多次沟通呢？这是因为我心里认为我们部门的骨干都是为了部门整体好的，而且他们都是有能力、有主见的人。
+
+兼听则明，偏听则暗，做领导的一定要让部下把话说出来，而且还要观察部下的反应进行下一步的反馈。比如我在会议后设定了个人目标提交的时间，我能看得出来有人很积极，早早就填了而且写得很具体，有些人是最后一天才写的，有些人写得不具体。
+
+从这些细节中我是可以感受到大家的认可程度的，对于那些认可程度不高的同学，我就单独再找他们谈。注意我不是去兴师问罪的，而是想去了解他们的真实想法。谈话中所有的部下都明确表示对于“说话算数”这点没有任何异议，但是对于具体落实措施会有自己的想法，我收集到这样的反馈：
+
+> 
+<p>1.许健，你要是硬要我把目标写上去，我也可以写的，可以按你的要求把我现在要做的事一一罗列到纸上，但是又有多大意义呢？我现在手上有不少现实的问题，能不能先解决。<br>
+2.大家的目标都写了，你接下来准备怎么办？你年底业绩考评的时候准备怎么参考这个表格？那些目标写了完不成又如何？<br>
+3.许健，你有没有觉得你有点反应过度了，我觉得我们很优秀，我们没有那么差，基础架构部门的工作性质决定了我们不是那么光鲜，而是负重前行。<br>
+4.我希望自己有一些自由度，不想被逼着写目标。不写这些目标，我也在很努力地解决部门内的问题。我们手头这么多事情但是只有这点人，你告诉我，我能砍掉哪些事情。</p>
+
+
+这时你应该发现了，团队成员认可这个方向，但还是不认可这种形式，担心这是一种口号、纸面文章，有这个时间和精力还不如踏踏实实地解决一些一线经理眼前的现实困难。
+
+为了解决这个问题，我开始两条线并进，一条是继续在部门内强调文化转型，并在年底考评中突出那些对促进文化有贡献的员工；另一条就是对已经清晰的目标做好执行，让大家看到行动看到效果。而且我认为用实际的行动和效果这一点更为重要。我心里把宝压在了接下来的执行上。
+
+### 确保短期目标实现，增强信心
+
+统一了大方向，还是需要从现在出发，脚踏实地迈步。
+
+现在是九月份，我必须在年底前把我们部门已经清晰界定的目标按时高质量交付好，用实际行动来支撑我们的文化。所以我在整个2019年曾多次跟总部领导提出，要给上海的高级别技术骨干独立的舞台，这样才能提高交付效率、培养高级别人才。
+
+这个想法得到了总部副总和几位高级别领导的支持，这点非常值得高兴。我立刻就去圈定了年底前需要完成的目标，并且每一个目标都由上海的一名经理或者技术骨干全权负责：
+
+- eBay 网站的流量平衡达到100%自动化；
+- 基于ML对Checkout，Bidding和Listing三大业务监控的异常检测，在Precision和Recall上要全部达到80%以上；
+- 具备每个季度Patch整个容器环境的能力，并对一个生产环境AZ实施两次完整的Patching；
+- 彻底扭转大家对云原生应用上线体验差的印象；
+- ……
+
+其他目标我在这里就不一一列举了。我认为用实际行动按时按质交付这些承诺，才能让我们的部门越来越有信心，让领导对我们也越来越有信心，这是当前的重点。在这个过程中细节是关键，作为领导要盯紧执行，及时找到拖慢我们进度的因素，解决问题。
+
+那我接下来的计划就是：
+
+第一步，通过关注细节保证年底交付，并在年底考评中重点肯定按时按质完成的骨干，具体体现在加薪幅度，升职比例上；
+
+第二步，继续在各类场合强调我们的大方向；
+
+第三步，在不断地收集反馈和迭代中，扩大推行适用面，**并让制度保驾护航。**
+
+这就是我确定短期目标的过程了，有计划、有行动、有复盘、有肯定。
+
+## 如何用核心价值观指导工作？
+
+实现企业文化的一些手段我们介绍完了，接下来我们看看核心价值观。
+
+文化是重要的，但如果你让文化去指导日常工作，其实还是模糊的，这就好像我要你好好学习，却没告诉你怎么才算好好学习一样。这时候核心价值观就派上大用场了，也就是践行“说话算数”需要有一些具体标准。
+
+前些日子我碰到了不少事情，心情也不是很好，这些事情都让我很纠结，我在这里回顾一下几个最有代表性的三个问题：
+
+第一个问题是，许健，如果你问我目前来说什么事情是对客户体验帮助最大的，那我告诉你是那些集成工作。这些集成工作有多少技术深度吗？我觉得没有多少。那客户价值和技术深度你选啥？
+
+第二个问题是这样的，总部架构师提出的Kubernetes的UX体验是给每一个Kubernetes的Building Blocks做一个UX可视化和编辑插件，然后给你一个画布，你可以像搭乐高积木一样通过拖拽和编辑编排你的应用，这样的体验多灵活。
+
+而我们现在的方向是为有模式的应用搭建一个编排的向导，引导用户输入尽量少的信息来构建应用，用户不需要理解Kubernetes。那么哪种方法才是正确的道路呢？
+
+第三个问题，我们把原来构建应用测试环境的系统从OpenStack搬迁到Kubernetes并和周边系统集成，原系统构建一个环境需要一分钟，我们要不要坚持新系统必须比原系统好？要不要更进一步追求新系统面世的时候必须震撼到客户？但这么做的代价就是多投入一个月。
+
+请你注意，上面的每一个问题都不是一个简单的决定，甚至有一些会直接导致冲突。那我们会按照什么原则来指导自己呢？
+
+每次我纠结的时候，都倾向于回顾历史，我这么多年来做云计算到底学到了什么，这些经验教训怎么指导我接下来的工作？这时候我也开始总结核心价值观了，结果我觉得我的总结冥冥之中很熟悉。
+
+为什么说很熟悉呢？因为我在eBay的CIPS（Cloud Infrastructure and Platform Service，也就是云计算基础架构和平台服务部门）这个部门呆了很久，CIPS的负责人曾经提过CIPS的核心价值观，当时我记得不深。但是回过头看我的总结，竟然发现跟CIPS的核心价值观很像。
+
+我终于理解CIPS的负责人当年为什么要提出核心价值观了，因为直到现在我才内化了这些想法，我经历了从外物接受到内部总结的这个过程。可以说，核心价值观真的非常厉害，居然可以在我已经离开CIPS后还能发挥作用，并且将继续影响我所能影响的人。
+
+这里我也分享分享我的价值观，针对以上三个问题，希望能对你有所帮助。
+
+1.**客户第一。**我当然希望客户价值和技术深度兼顾，但是如果出现矛盾也不需要纠结，客户价值第一。作为一名经理，我们应该把自己管理的团队看成是自负盈亏的创业公司，如果是自己的公司，肯定是客户价值第一的。
+
+2.**极简体验。**我们都会说要构建很好的用户体验，那什么叫做好呢？如果只提一条，就要提这个极简体验了。为什么？作为基础架构部门，我们的客户就是业务开发团队，业务开发团队应该关注实现业务逻辑而不是关注基础架构。我们应该承受基础架构的复杂性，而让业务开发团队像使用水电煤一样简单地使用我们的服务。
+
+按照这个价值观，大部门的业务开发不需要强制理解Kubernetes细节，我们就应该总结实现客户需求的常用模式，并提供最佳实践指导原则，让用户在使用向导上通过最少的输入就能完成工作。
+
+3.**工程卓越。**这里面就不得不提工匠精神了。我们部门近些年来做得非常辛苦，其根本原因是战线铺得太开，要做的东西太多，多战线开工导致单条战线的投入不够，一碰到困难很容易错过承诺的时间点，因此导致兄弟部门觉得我们说话不算数。而且面铺得太开让我们无法专注对产品做持续打磨，发布远超现有体验的高质量产品。
+
+对于测试环境，这是开发人员高频使用的环境，我们新系统上线的标准必须是比原有系统时间短，如果不能实现这点，那做新产品的意义就不大，与其做新的产品还不如把原来的产品做到极致。
+
+你看，确定了核心价值就是确定了做事的准则，就像一盏明灯，可以在黑夜中指导我们前行。
+
+## 总结
+
+今天我们讲了文化和核心价值观，这是一种软实力，**看似虚，但其实是团队和组织的粘合剂**。
+
+我们想要促成文化的形成，首先就是要公开问题、暴露问题，从而让大家产生改变现状、形成团队文化的紧迫感。然后必须有一个坚定践行文化的核心团队，作为经理你一方面要坚定信心，一方面要收集反馈统一思想。
+
+光说不练假把式，除了说，我们还需要用实打实的业绩来给自己、给团队、给领导增加信心，让团队感受到持续的成功是当前的关键。最终要牢记，文化的形成是一个长期过程，需要不断调整并推进，如果没有奖惩制度保驾护航恐难长久。
+
+接着我给你介绍了更加具体的核心价值观，对于我们基础架构部门我最重要的价值观有三点：客户第一、极简体验和工程卓越。拥有核心价值观的组织才能在纠结、迷茫的时候明确前进方向。
+
+最后我想说，一个没有文化的团队，就像一个没有个性的人，很难在芸芸众生中脱颖而出，也很难成为一个有战斗力的集体。那进一步指导行动的核心价值观就是提升团队凝聚力的具体手段，它可以无时无刻地影响到团队的言行举止。
+
+## 思考题
+
+你所在的公司会强调哪些价值观呢？或者你在之前的公司有没有印象深刻的价值观，影响到你的行为和观念呢？
+
+期待你的留言，也非常欢迎你能和大家分享一些你在文化建设中使用的妙招！如果有所收获，也欢迎你把文章分享给你的朋友。

极客时间专栏/geek/技术管理案例课/二线经理：开始带经理了/21 | 内部考评：为什么说“一碗水端不平”才是公平？.md

@@ -0,0 +1,172 @@
+<audio id="audio" title="21 | 内部考评：为什么说“一碗水端不平”才是公平？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/80/52/8093c6bb88299691812ee3a45da5cd52.mp3"></audio>
+
+你好，我是许健。今天我们来聊一聊内部考评这个话题。
+
+做了经理以后，考评是我们绕不开的事儿。考评是为了什么？考评方式为什么有变化？为什么总有人说不要搞平均主义，但现实情况中平均主义的事还是那么多呢？
+
+这些问题也许有点抽象，那我们再把问题具体一些。比如，作为经理去参加年度考评审核，这个会议的目的是什么呢？到底是去公平公正地评价升职，还是强制裁掉低绩效员工，还是带动团队的活力？
+
+再说说考评方式，每一家公司都有自己的考评方式，我这些年在eBay ，就经历了考评上的不少调整：一定要按比例强制有业绩差评，后来取消强制业绩差评，最近又恢复业绩差评；一开始只看业绩贡献，后来又要同时看贡献和员工潜力；一开始只限制加薪经费，不限制业绩优秀的比例，到现在严格控制业绩优秀比例。
+
+那么在这些考评方式的变化背后，到底有什么用意呢？今天我就来跟你分享一下考评的那些难办的事。
+
+## 业绩考评的目的
+
+有关考评的疑问看着千头万绪，所以我们必须先搞清楚这件事的目的。我的看法很直接，**业绩考评的目的就是在资源有限的前提下，最大程度激励员工。**
+
+**公平公正评价员工业绩，这只是我们的方法，而方法是为了我们的目的服务。**作为技术经理是要主导方向的，我们有想要推进的事情，而经理鼓励什么样的行为，就应该奖励什么样的行为。虽然奖励有很多种方式，我们可以选择公开表扬，发一次性补助，但是我觉得最直接的方式还是年底考评。
+
+你注意到了么？我前面说“激励员工”的时候，并没有说明白具体怎么激励员工？要回答这个问题，我们就不能孤立地看考评，而应该跟组织目标结合起来看。
+
+为什么这么说呢？因为**无论你在组织内要促成什么样的变化，不绑定考评和奖惩的变化就是耍流氓。**这一点你看看中国历史就知道了，特别是商鞅变法，他制定的所有的奖惩都服务于农战。
+
+我们还需要留意，组织处在不同的阶段，我们的侧重点也是在变的。因为不同的阶段下，组织内需要鼓励的行为也是在变化的，这正是我们这节课一开始提到的**“考评方式的变化背后”的原因**，需要分情况讨论，比如下面几个阶段：
+
+- 组织发展的时间一长，人员很容易臃肿，那就可以强制末位淘汰。
+- 然后过了几年，差的人淘汰得差不多了，为了留下员工的心理安全，又可以取消末位淘汰。
+- 组织内的文化影响了“品牌”和声誉，我们想发起变革。比如我现在要推进员工“说话算数”，那我就要明确表态，年度考评需要配合组织文化的推进。
+- 技术任务上“旧账”结清，组织需要转守为攻：比如很可能过了两年，我们把以前的技术债还得差不多了，再制定目标的时候就可以从保守改成激进，相应的考评指标也会跟着变化。
+
+## 按业绩做考评怎么就这么难？
+
+不知道有多少经理有过和我类似的体验，我明明知道年底考评应该有区分度，但到了我实际填写涨薪幅度的时候，还是很困难，特别是这种时候——团队里没有明显的业绩很差的员工。
+
+为什么这件事这么难呢？因为我们评出的业绩不够好时，做当面沟通就会有压力。那为什么你觉得当面沟通人家的业绩问题很困难呢？如果这个事追根溯源，我们就会发现也许起初设立的目标就不够清晰。没有明确的标准，我们就没法有理有据地给员工传递坏消息。
+
+其实定义目标有很多书和资料可以参考，比如SMART原则等管理标准，我们去网上随便搜搜都找得到。但是我觉得问题不在这里，学习这些知识不难的，真正难的是下面这些问题：
+
+- 你真的可以按照SMART原则强制你的部下做出承诺吗？
+- 部下提了他的目标，你觉得目标不够高，你真的可以坚持让部下按照你期待的标准去做吗？
+- 就算你和部下明确沟通了目标，目标如果没有达到，你到了年底考评的时候真的敢给他低绩效吗？特别是这个员工是你的左右手或者是部门里不可或缺的骨干。
+
+只有这三个问题我们能给出肯定答案，按业绩做考评才不会那么难。作为部门主管，既然定了这个目标就是要坚持去落实，这个不要动摇，但是推进的节奏可以因地制宜。对于达成高目标的员工，我就要表扬和用业绩考评来强化。而没有达成的，我们需要自己先过一下，看看到底是什么原因。
+
+这里我重点说说员工的表现没达标，而且刚好他就是经理左右手的这种情况。因为我的沟通频率平时就很高，有问题在第一时间我自己就该介入了。如果这样他还没有达标，我真的要给低绩效的话，我会跟老板说自己也一定是低绩效的。
+
+如果我评估下来，发现真的就是这名部下的原因，而我平时也都及时做沟通了，他自己对于低绩效也不应该有意外，在这种情况下如果部下真的走我也认了。但是我一定不会去做故意牺牲自己的左右手或者骨干来立威这种自残的事情。
+
+总之，难的不是绩效考评的方法和手段，而是考评前的准备：也就是目标是不是清晰明确，对这样的目标经理和部下有没有达成共识，出现问题有没有在考评前就多次做过沟通。
+
+## 考评会议的经验教训
+
+刚才说的主要是考评前的一些准备，其实考评这个事儿最典型的场景还是考评会议，这也是每个技术经理都要经历的。
+
+在我们公司，参加年度业绩考评会议是技术经理的一项重要工作，部下辛辛苦苦了一年了，能不能拿到认可，这和业绩考评会议的关系很大。今天我们就从两个视角，来谈谈业绩考评会议有哪些注意点。
+
+### **下级经理参加会议**
+
+我们首先来看第一种视角，就是作为下级经理，去参加考评会议。这里的下级是一个相对的概念，比如我现在是二线甚至三线经理，我还是要去参加上级经理的会议的。
+
+参加上级经理主持的业绩考评会议的目的是什么呢？这里我先给你分享一个我的故事。有一次在苏州开业绩考评会议，我在介绍我部门的一个升职候选人的时候，除了介绍他的贡献，我还详细介绍了他的缺点。
+
+会议上这个候选人被否决了，当时我很不服气，开始指出其他部门的候选人其实也有这样那样的问题，结果搞得自己很被动，那个场面就是我已经站在了人民的对立面。
+
+这件事发生后，我的一个同僚私下好心建议说：“许健，业绩考评会议本质上就是一个Game，你要学会怎么Play。你看看人家N，目标很明确，就是要提拔他的人。”
+
+我虽然并不认可这就是一个经理人的游戏，因为游戏给我一种权谋的感觉，但是我不得不深思参加这个会议的目的。这个会议不是让我去证明自己作为经理是有多公正的，我内心是不是有个声音，希望在老板和同僚面前树立“我要求极高”的形象？
+
+我意识到自己把会议目的搞偏了，我的目标就是promote自己的候选人，而不是证明自己有多公正无私。因为我觉得我的候选人应该升职。
+
+再后来，我的一个部下推荐我看了一篇文章，里面讲了赵烈文给曾国藩进言的事，标题是《越正派越不得人心》。文中引用了赵烈文的话：“合众人之私，以成一人之公。大柔非柔，大俗非俗。”
+
+这篇文章我读了很多遍，我觉得文章有标题党的嫌疑，我不认可这个标题，因为它违反了我以正立身的价值观。但是里面提到的“借私为公”的想法对我很有启发。小时候，我一直接受的教育是大公无私，可实际上大公无私可以维持一时，并不能长久。
+
+那什么才能长久呢？必须把个人私欲和组织利益统一起来，这样才能长久。如果我们对部下要求很高但是又没有相应的激励，最后很有可能变成孤家寡人，又如何实现抱负呢？所以做经理的就是应该尽自己最大的努力给做出杰出贡献的人正向激励。
+
+所以，我最终明确了下级经理的与会目的是**获得同仁和领导的认可，然后同意给本部门的候选人升职。**考评会议不是经理展示自己的高标准严要求的“舞台”，让自己提名的候选人得到认可，通过审核才是重点。
+
+如果牢记这一点，我们就不容易走偏了。根据目的做推演，我们就可以把注意事项理清楚了，最后我整理了思路做了三点总结。
+
+**第一点，宁缺毋滥。**如果我自己确实认为候选人达不到升职的标准，就不会因为不想浪费名额而提名。不要觉得这样好像吃亏了，要知道我们自己认为不合格的人，领导和同仁也不会觉得好，最后很有可能候选人还是得不到认可。而更大的隐患是部门里的其他同事会觉得提拔的人是才不配位的，质疑考评不公，然后影响他们的积极性，甚至导致优秀员工离职这样劣币驱逐良币的事情。
+
+**第二点，准备功夫在平时。**关于这点我是从三个角度来切入的：
+
+- 反馈工作放在平时，员工需要改进的点，经理平时就应该给他反馈，而不是等到业绩考评。
+- 提早获取他人支持，候选人升职的反馈收集，约谈高级领导获取支持这些工作我们要早做，不要临时抱佛脚。尤其是高级别员工升职，很多时候一次还谈不下来，更应该提早进行。
+- 会议材料事先预备，有一次我到考评会议的时候，一名候选人的书面反馈还没有拿到，领导当着众人的面说这是最后一次，说这是我对自己的候选人不负责任。如果再有下次，就会直接取消我的候选人升职资格。
+
+**第三点，不要只在家里横。**按理说第二点准备工作做好了，考评会上不会有太大的问题。但是临场时什么情况都可能发生的。比如我们提了升职候选人后，被领导或者同仁质问的时候能够保持思路清晰，有理有据地坚持自己的观点么？会不会被领导一说就什么也不敢说了，或者被同仁抓到很明显的问题无力反驳呢？
+
+当然我们这里说的坚持自己观点，当然还是要把握好度，如果你确实觉得领导和同仁说得有理，那你得承认并且接受反馈，下次改善提高；但如果你不觉得是这样，即使是领导提出的意见，你都应该尽力坚持你的观点。要知道你一松口，就是失去了对一个候选人数年努力的最佳肯定，对公司也是损失。
+
+### **上级经理主持考评**
+
+成为二线经理后就需要我们自己来主持部门内的业绩考评事宜了。接下来，我就根据自己的经验把重要的环节给你讲一讲。
+
+**先设定准则**
+
+讨论不能凭空讨论，我第一次主持业绩考评会议时，第一件事就是召集我的一线经理，先把部门的业绩考评标准讨论出来。这个标准一定要一线经理自己提，然后大家一起选择其中最重要的几点，因为只有这样组织的核心人员才能达成组织考评原则的共识。
+
+比如我们部门就讨论出了下面的几条原则：
+
+- 积极进取，在挑战面前抱着学习的心，敢于做决定并推动事情往前发展。所以你不可以工作在被动模式，必须积极主动，找寻一切办法推动事情前进。
+- 贡献和影响力到达下一个层级才可以晋升。假设你现在是L25的级别，你想升到L26，你就必须在L25的时贡献和影响力和组织里L26的人相当。
+- 完整交付业务价值，也就是说员工必须把一件事做到业务价值实现才算完成。比如说我们做了一个新系统，但是不把旧系统上的用例迁移到新系统，业务价值就没有得以实现。
+
+说完了设定准则的事情，我还想聊聊按比例分配和投票选人的问题。
+
+**按比例分配有什么问题？**
+
+业绩考评时，候选人的升职名额分配是很重要的一环。接下来我就模拟一个小例子，带你一起进行思考。
+
+假设上级给你8个升职名额，你下面有4个小组，分别有A组10人，B组20人，C组20人，D组30人，那怎么在这四个小组内分配这8个名额呢？最简单的一种办法就是按比例分配，A组1个名额，B组2人，C组2人，D组3人。然后你作为二线经理就把把关，看看每个小组提上来的人怎么样。
+
+这个办法听着好像合情合理，做到了“一碗水端平”，但其实是存在问题的。接下来，我就从上级老板和部下两个角度出发，给你分析一下为什么按比例分配并不好。
+
+从上级老板的角度看，如果你就这样按比例分配，那他要你这个二线经理干什么呢？如果A组就是做得非常出色，而D小组做得很一般呢？老板这时候对你的期待是应该给A组更多的升职名额，并且还能让D组看到差距而不是觉得你不公。所以搞平均老板不会高兴。
+
+从部下的角度看，也不会觉得高兴。虽然是四个小组，但是毕竟在一个部门大家其实互相都有一些了解的。A组觉得自己是精英小组，人员素质就是比D组优秀很多，工作强度也大很多，这时候你按比例给A组1个人，A组经理就会很不爽 。
+
+实际情况要比上面复杂得多，我刚接手现在部门的时候，年底考评是个大问题。因为部门里的工程组和运维组看待问题的不同角度，工程组觉得自己在努力推动很多技术升级，工作强度更大，人员市场竞争力更高；而运维组觉得工程组不解决线上实际问题，最后一公里不能满足业务的工作都是运维组做的。
+
+所以，我年度如果按比例给工程组，工程组觉得我对他们不公；我如果多给工程组，运维组就会觉得我偏袒工程组。想解决这个问题，我现在唯一能想到长久方案就是团队融合。
+
+我这里想说的是，按比例分配“看上去很美”，但效果并不一定那么好，所以在实际操作中我的做法是参考比例，但是要让下级经理明确，我们二线经理有权按实际情况调整这个配额。
+
+**投票就真的好吗？**
+
+考评时推选升职候选人，还有一种解决方案就是投票。每个经理轮流来介绍他的升职候选人，然后参会的经理给出意见，候选人经理针对反馈意见答辩，之后进行投票。这其实也是我们公司常见的做法。
+
+接着刚才模拟的4个小组的例子，我们再做个分析，因为团队人数是不同的，要给ABCD这4个小组的选票加权重吗？若不加权重，人多的小组经理就会觉得你不公平。但要是加了权重，人少的经理就会觉得公平吗？我告诉你多半也不会。
+
+后来我意识到，无论采用哪种方式，都会有人不爽的。那这些方式的本质是什么呢？就是二线经理想通过这种固定流程的方式，把自己从冲突中心解放出来。你看，我们是投票投出来的，所以你就算不爽也不要对我不爽。
+
+这种想法其实是不对的，作为组织一把手就应该解决冲突。最后我们部门采取的方式就是：先让一线经理介绍他的升职候选人，然后进行答辩环节，接着投票排序。**但是部门一把手就是有权对排序结果做调整，不过还是会向部下解释这么做的原因。**
+
+投票其实代表了民意，保留一把手的变更权利，能够让一把手在投票结果上修正。而一把手修正必须告知部下，其实最终结果部下在升职名单出来的时候也是知道的，所以一把手也不能乱来。这种机制，能够比较全面地产生高质量的结果。
+
+**考评会议的异常情况处理**
+
+除了我们前面探讨的原则先行和名额分配方式，考评会议上还有一些高频的异常状况，需要注意。
+
+在答辩环节，一线经理之间是会起冲突的，那作为二线经理应该怎么引导并解决这些冲突呢？我认为解决方案不在考评会议上，而在平时的准备，要统一大家的选材标准。
+
+我整理了一些提拔人才的常见问题，而且在部门内部达成了共识，在会议上如果发现有提名候选人的经理出现下面的情形，就应该去质问：
+
+- 论资排辈而不是提拔上升劲头足、有才干的人，比如多年没有升职的人突然要升职，那提名经理一定要给出强有力的理由。再比如说优先提拔没有潜力的老黄牛，老黄牛有别的奖励办法，但不是升职。
+- 提名和实际情况有偏差，拉部门数年的年终考评评级数据，如果对照后发现一线经理升职候选人的排序和数据逻辑不符，比如连续两年业绩优秀的年轻人为什么排在后面，就要去追原因了。
+- 如果你是三线经理，发现你下面的二线经理搞平衡。
+
+这里我额外提醒一下，还有一件事我们要多留心对于团队里一些不善言辞和表现自己但是确实做了很多贡献的员工，因为其他组的经理不了解情况，所以考评会议上就没有办法给反馈。这种情况下，投票也就只能依靠这名员工经理的介绍和答辩水平了，这样也不公平。
+
+## 总结
+
+业绩考评是管理者绕不开的话题，我们要明确业绩考评的本质是在资源有限的情况下，最大幅度地激励员工。
+
+业绩考评很不容易，作为下级经理去参加考评会议，目的不是为了证明自己的要求多严格，而是为了给自己的优秀员工争取肯定和奖励。
+
+明确了会议目的，我给你列出了三点注意事项：
+
+1. 宁缺毋滥，达不到升职标准的候选人，提名了也不会通过，甚至影响团队其他成员积极性；
+1. 做好准备功夫，员工表现的反馈放在日常，无论是收集领导、同事对候选人的意见还是准备答辩材料都要提早预备；
+1. 临场不要退缩，我们思路要清晰，答辩环节要是碰到领导和同仁的质疑，我们要做到有理有据地回复。
+
+在上级经理主持考评这个部分，其实我把会议之前的设定标准，按比例分配晋升名额和投票选举的方式也一并给你做了讲解。这里要注意的是，作为二线经理组织主持考评会议，不要想着找个轻松的办法就能用流程生成结果，把自己从冲突中摘出来。
+
+按比例分配和完全尊重投票结果，都是为了规避冲突而实行的次优解。作为部门一把手就应该不畏冲突，强势把组织的年度奖励资源，给到你最希望鼓励的行为和人身上。
+
+## 思考题
+
+作为二线经理，我们在项目审核和技术分享会议中能发现很多优秀员工。然而，最终业绩考核时，我们更容易忽略对这样的人给予肯定，这类人就是在一线起到了关键作用却不善言辞的骨干，那我们该怎么避免这件事儿呢？
+
+欢迎在留言区分享你关于考评这件事的经历和疑问。如果读完文章有所收获，也欢迎转发给你的朋友。