del

极客时间专栏/geek/技术管理案例课/一线经理：开始带员工了/04 | 避坑指南：从技术骨干到一线经理，你会遇到哪些坑？.md

@@ -0,0 +1,169 @@
+<audio id="audio" title="04 | 避坑指南：从技术骨干到一线经理，你会遇到哪些坑？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/33/a2/33ff25dc2bca5ec183242c5de3b190a2.mp3"></audio>
+
+你好，我是许健。今天我们来聊聊技术骨干转型经理那些坑。
+
+技术骨干在转型经理之前，一般都是部门里专业能力很强的那类人。但转型经理后，我们的思维就不能只关注于事，要同时开始关注事和人，而这里面更关键的其实是人。因为所有的事儿都需要人来完成，而经理更多的是通过培养人和激励人，从而提升团队做事儿的效果。那到底什么叫“关注事”，什么叫关注“人”呢？我下面给你举几个例子，你一看就能明白了。
+
+例子1：
+
+- 关注事：这件事我怎么干？
+- 关注人：这件事让谁干最合适？
+
+例子2：
+
+- 关注事：小王你这个方案A不够好，应该用方案B。
+- 关注人：小王能够主动提方案A很好，在承受范围内哪怕A有些瑕疵也让他尝试，我要培养他的积极性。
+
+例子3：
+
+<li>
+关注事：我们要交付业务价值。
+</li>
+<li>
+关注人：我们要提高团队成员的能力。
+</li>
+
+我把刚才说的例子，总结成了一张图给你放在下面了。
+
+<img src="https://static001.geekbang.org/resource/image/9f/f9/9fd125581322f92e1a39e26e3be69ff9.jpeg" alt="">
+
+从“关注事”到“关注人”，这两个真的是完全不一样的思考角度。因此，在这个转型经理的过程中，我们很容易出现一些问题。都有什么问题呢？我根据过往的经验，把这些问题按照难度递增，整理成了6大类，分别是管得太细、大包大揽、迷信流程、刷存在感、不能聚焦和不会说不。
+
+<img src="https://static001.geekbang.org/resource/image/7e/13/7e6a9ef2e5e65a156e189584fbdc0f13.jpeg" alt="">
+
+你可以想一想，你是不是也遇到过这些问题呢？接下来，我们来逐一讲解。
+
+## 坑1：管得太细
+
+管得太细，我估计很多人都见过这样的情况。典型的管得太细的做法一般是：要么给部下制定出特别详细的解决问题细则，而不是给部下提出问题让他自己拿方案，要么就是不停地去盯部下的进度和要求部下汇报工作，不等部下自己去思考和做事就先给一堆意见。
+
+这样做的坏处很明显，部下会觉得自己没有自由度，没有发挥空间。而且，这样做最大的问题是，有些部下会觉得，领导你不够信任我，觉得我没有能力自己解决问题。
+
+我这里拿给部下交待任务的故事给你举个例子，你可以体会一下下面两种沟通方式的区别。
+
+方式一：小王，你能把性能测试和失效性分析做一下吗？准备三个客户端给我加10倍流量，另外给我挨个给每一台机器断网，再给我做网络延迟模拟，我每天都要进度报告。
+
+方式二：老王，最近我们上线的模块性能发现问题，并且发现在网络不稳定的情况下行为异常，你觉得我们应该采取哪些举措来解决当前的问题，我还需要你帮助给一下意见，最好可以系统性地避免类似情况的发生。
+
+怎么样，你发现这两种沟通方式的区别了吗？
+
+人的本性是都要自由，要我的地盘我做主。因此，我们要注意他们对自己**话语权威性**的追求和对自己是一个靠得住的人的**自我认可**。说到底，这个核心就是要从只关注交付结果，转变成关注交付结果的同时也要满足人的需求，
+
+我就踩过一次这样的坑。一次我的一个部下V跟我说，他想做一套系统，自动排查搜索集群机器的健康情况，因为他觉得这样能大幅提高排查效率，提高可用机器的数量。
+
+当时，我是这么回复的：“你知道G在通用集群上也在做同样的事情吗？我觉得你可以先去看看G是怎么做的，然后给我看一下你的设计再开始执行。”
+
+我后来才知道，V在跟我谈后有点受打击，他觉得他自己有自己的做事方式，我让他去跟G学，好像是在表达“他不如G”。而且，我一定要看他的设计后，然后他才可以执行，就是信不过他的设计能力。
+
+你可以想一想，自己是否陷进了微观管理？
+
+如果是，你就要考虑自己为什么会微观管理？是因为你太关注部下的做事方式是不是符合你的要求？还是因为你享受那种指挥人干这干那的感觉？只有挖掘到你做微观管理的原因，才能从根本上解决问题。因为你不再是掌握了一些技巧，而是从更深的层面把自己分析透了。
+
+## 坑2：大包大揽
+
+大包大揽这一点很容易理解。
+
+“与其等他来做，我自己早就做完了”，这句话听起来是不是很熟悉。会说这种话的经理都有一个共同的特点，那就是个人能力很强。当你以外人的角度看他的团队时，只看得到他，看不到他的成员。一旦他休假，他的团队就不知道要干什么了。
+
+我给你举个现实中的例子。老徐是一位经理，他的下属小雄说自己对下一代流量管理项目感兴趣，所以想参与总部领导的该项目。但是流量管理是个高风险项目，弄不好就会影响业务可用性，而小雄说这件事2个礼拜就能做完。老徐一直很担心会出线上事故，于是去跟总部的项目主管打招呼，说小雄太乐观了。我建议老徐就让小雄自己去处理，他说2周就2周。老徐还是担心，你等着出上线事故吧。
+
+如果你遇到了类似的情况，我的建议就是：要么你不要把这件事交给下属做，要么你就跟他说清楚他的责任，然后让他全权负责。对于我们做经理的来说，下属不吃点亏是长不大的。我们要注意的是，这个“亏”必须是我们这个部门能承受的。
+
+我们公司在做一线经理培训的时候搞过一个模拟经理员工对话，目的是暴露一线经理日常工作中常犯的错误。
+
+我们从各个总监那里收集他们部门经历过的一些棘手的问题作为素材，把事情中的敏感信息改造后写成案例。给一线经理10分钟阅读案例，然后由总监扮演一个刺头员工，该经理扮演该刺头员工的经理，模拟他们俩单独谈工作，来解决这个案例里面的问题。刺头员工会找各种理由说这个案例里的事情很难、很棘手。
+
+不少经理在这个过程中都会犯“大包大揽”的错误，在模拟对话完成后自己领了一大堆任务。这是不对的，作为经理，你一定要提升自己的感情强度，把该员工需要完成的工作安排下去。不然你就是在剥夺该员工的成长锻炼机会。
+
+## 坑3：迷信流程
+
+很多老板对组织效率不满意的时候，会引入敏捷开发模式、OKR模式，或者阿米巴模式等各种模式。我一直认为，希望通过引入一个流程，就大幅提升组织效率的想法是不现实的。如果流程就能解决问题，那还需要经理干什么呢？
+
+要提高组织效率，不脱两层皮付出点代价是不可能的。我们真正的难点在于**怎么用人**，**怎么拿捏流程不能处理的意外情况**。
+
+如果你想把人用好，首先就要了解这个人。你知道你的每个部下擅长做什么，不擅长做什么吗？他在乎什么，反感什么？谁和谁搭配能够形成互补？这都是需要你去进行长期积累和挖掘。
+
+举个常见的例子吧，有些刺头技术水平很高，跟人相处很容易产生矛盾，你能靠流程解决这个问题吗？我们能做的，是去挖掘他容易跟人产生矛盾的原因。但即使你能挖出原因，这个刺头不经过“阵痛”就能够改正的机会不大。技术水平能够成长到很高的人，大多都30出头了，你能指望一两次对话就能彻底改变一个人前30年的行为模式吗？我不是说改不了，但是想做到这点，你要付出的成本很大。
+
+作为一个经理，你与其花大力气去把这个人拗成你希望的样子，还不如专注在怎么用好他的长处。他不是技术很好，但是跟人相处不行吗？那就安排那种技术难度很大，但是又不需要很多沟通交流的工作给他。
+
+## 坑4：刷存在感
+
+刷存在感和大包大揽里面提到的“让别的团队只看到经理”是不一样的。你能明显感受到大包大揽的经理对团队提供的额外价值，他对团队是有推动感的。
+
+但是刷存在感的经理不一样，你会发现他们在邮件和会议里频繁出现，但是却没有什么有价值的意见。他们的邮件往往是这样的：
+
+- 小王你做得不错，Great Job；
+- 我来做一个会议总结；
+- 上级领导安排了任务以后，他做任务在团队内的转发；
+- 很少发表对项目和人员安排的独立见解。
+
+这样的经理其实每天也挺忙的，他分配工作，也鼓励团队成员，但是他不能促进团队达到更高阶段，**你作为上级经理很少看到他有真知灼见，很少看到他做关键决策。**我认为这样的经理，每天的工作是在“刷存在感”，虽然他不是有意在刷存在感，但是事情的本质就是这样，其实随便找一个情商不低的人来做经理，也可以达到他的水平。
+
+当然，我不是说你刚从技术骨干转岗到经理就要马上有真知灼见，能做关键决策，这不现实。我建议，你可以在开始的时候先韬光养晦一段时间，但是你必须问自己，为什么团队需要你来做经理，你给团队提供什么额外的价值，你对于你所管理的团队有推动感吗？
+
+还有一种更高层次的“刷存在感”，这样的经理对日常工作中的事情是有独立见解的，也能做关键决策促进一些事情的解决，但是他们没有长期目标，更不要说制定为了达到长期目标的阶段性举措。
+
+举个例子，我就看到我们有团队每一个季度都要花很多时间制定季度目标，他们为什么每一个季度都要花很多时间来做目标呢？就是因为没有坚定的长期目标，每次都只往前看一个季度。这就会有一种看上去很忙，但是在天天刷存在感的感觉。
+
+如果你有长期目标，这样目标应该不会轻易改变的，需要每一个季度都花这么多时间做计划吗？大多数情况是根本就没有明确的长期目标，说得难听点，就是用战术上的勤奋掩盖战略上的懒惰。
+
+## 坑5：不能聚焦
+
+我自己在转岗经理一段时间之后，就犯过“不能聚焦”的错误。我管理了一个有3个项目（云计算的计算、存储和网络）的团队，而且我把时间平均分配在这三个项目上。结果就是，我在这三个项目上起的作用就是前面说的“刷存在感”。当时的我没有主见和能力启动项目，于是每一个项目做完以后就会去跟美国的主管谈，下一个项目是什么呢？
+
+现在想起来，我当时就跟一个包工头差不多，一旦我手下有空余的“工人”，就想着很快把这个“工人”派到新工地上去干活。直到我成长了一些，终于有了个人主见，要做云计算的可靠性，并且也想到了要自己主导来做这个项目，但却发现自己手上的人都已经“派到别的工地”去了。别看我管了十几号人，其实能分配到可靠性项目上的人手只有两个。
+
+这件事让我知道了**要做成一件事，你就必须聚焦**。
+
+那怎么判断你现在有没有真的做到聚焦呢？简单地说，就是你得**有一个且只有一个目标**，你可以想想，你有没有每天都在想怎么把这件事做好，是不是每天起床就在想怎么做，每天睡觉前也在想怎么做？
+
+人的精力是有限的，你同时搞几件事，基本上也就只能做到平常的水平，很难做出精品。而做一个精品的效果要远好于做一堆平庸的产品。
+
+我这里说有且只有一个目标，你很有可能会问：如果我负责的部门有好几个项目怎么办？那么我要告诉你的是：**如果<strong><strong>作为主管经理的你，在同一时间**</strong>有好几个项目，你的主要**<strong>精力**</strong>只能放在其中一个项目上，绝对不要平均分配时间</strong>**。**
+
+我是最终通过“云计算可靠性”这个契机把自己团队全部集中到可靠性这个方向上，若干年后的今天，我们已经正式成立了云计算的SRE团队。当时我是这么想的：
+
+我们Cloud SRE（Site Reliability Engineering）团队在第三季度的最重要的目标是什么？如果说是改进云计算监控效果，那我们Cloud SRE的绝大多数力量是投入在改善监控效果上吗？
+
+我觉得不是，当时我们最多只有40%的人力投入到这里。既然不是，我真的不觉得我们能做好。如果我们在第三季度的目标不是改善监控，那我们要定一个别的目标，但是我要求无论是什么目标，Cloud SRE的最主要的执行力必须在这个目标上。
+
+如果不能聚焦，就是有具体的困难，有困难就要提出来。现实中，有些困难是一线经理要去克服的，有些困难是更高一级经理要去处理的。如果你只会跟部下提要求，又不处理部下的要求，那你和前文说的那个“刷存在感”的经理又有什么区别呢？
+
+## 坑6：不会说不
+
+最典型的不会说不的经理就是只会家里横，碰到别的部门领导，或者碰到自己的直属领导都认怂。结果就是你的部下对你很失望，你在有能力的领导心目中的位置也不会高到哪里去。
+
+下面我用两个例子来给你讲讲我为什么这么说。这里，我给你设置一个情景，假设你有个兄弟部门的服务构建在你部门的服务之上。有一天，兄弟部门的服务出问题了，客户投诉到兄弟部门，但实际情况是，两个部门的服务都有一些问题。这时兄弟部门咬死了是你部门的问题，作为经理的你就要去跟兄弟部门交涉。你如果一味地说都是自己部门的责任，你的部下自然会对你非常失望。
+
+要解决这个情景还是比较简单的，你只要有理有据，采用“不夸大，不缩小”的策略就可以了。接下来，我再讲个难一点的情景。
+
+两个兄弟部门都来找你支持，他们都说他们的要求很急，对业务很重要，并且要求你给具体的交付时间，你给了时间以后，他们都不满意，质问你为什么要这么久。某部门甚至会要求你把打算分配给他们部门做支持的工程师直接交给他们管理，这样他就可以在他规定的时间完成业务。
+
+这时候你怎么做？如果你不会说不，就只能迫使自己的工程师加班来满足两个兄弟部门的要求。
+
+对于这种情况，我建议你做好基于数据的分析，拿着具体的数据去跟两个部门谈交付时间。对于把人交给其他部门的要求，我不认为这是有利于部门合作的做法。但是，你可以要求兄弟部门把他们准备“怎么在不降低交付质量的前提下，压缩交付时间”的细节给自己讲一下。如果两个兄弟部门因为争夺资源不可调和，那你就到更高一级老板那里，一起定一下到底哪个优先级更高。
+
+不仅是同事，对于老板的要求，你也不能像奴才一样什么都点头。如果你不是很赞同老板交待的任务，你不要马上说我去干，也不能直接说我不干，我的建议是你要问老板问题以获取更多信息。比如，你可以问老板：我们为什么要做这件事？你的具体期待是什么样的？我现在碰到的具体困难是这样的，如果你一定要做A，在不增加人手的情况下，我现在手头的B项目会受影响。
+
+你要让老板感受到你是有独立思考的人，不是一个奴才部下，同时还要表明你正在积极寻找解决问题的方法。
+
+## 总结
+
+微观管理和大包大揽是技术骨干转经理后最常见的问题，其本质都是太关注于事情的交付而忽略人的发展，你要记住的是**经理是通过提高部下的能力，来更好地完成任务**。
+
+很多人做了经理以后，一般都希望很快发现组织问题，并且采取措施来解决这些问题，而采取的措施往往是引入一些流程。但你千万不要迷信这些流程，哪有这么简单的事情？还是要关注人本身，**所有的问题最终都是人的问题**，多琢磨琢磨你的团队成员本身，**不要拗姿势，而应该因材施教**。
+
+接下来，你就要审视自己，看看自己有没有对自己的团队有推动感，自己有没有用战术上的勤奋掩盖战略上的懒惰？就算你想清楚了自己团队的价值和目标，你真的聚焦了吗？**伤其十指不如断其一指**的道理你懂吗？
+
+最后，“兵熊熊一个，将熊熊一窝”，不单单对于兄弟部门，对于老板你也不能唯唯诺诺地做奴才部下。话要说得客气，但是你的原则不能动摇，逻辑必须清晰。
+
+## 思考题
+
+我们公司领导说高度重视开发效率，有一个专门的部门负责开发效率，他们制定了完善的开发流程，甚至把流程中的关键点比如Unit test Coverage、测试Approval流程、CICD等都做进了开发流程，还制作了耻辱墙发布每一个组织的BUG数量。
+
+但是我们公司的业务开发部门仍然不停抱怨开发效率不高，你怎么看部门的这些流程？如果是你来负责开发效率这个事情，你准备怎么处理？
+
+请你思考这一节课中说的6类问题，联系自己日常的工作，就每一个主题自己找一个例子，并且描述一下出现这个问题的根本原因是什么。
+
+欢迎在留言区晒出你在管理路上遇到的各种“坑”。如果你的朋友也遇到了类似文章中提到的这些问题，也欢迎你把这篇文章分享给他，也许就能帮他解决这样的问题了。

极客时间专栏/geek/技术管理案例课/一线经理：开始带员工了/05｜事急则乱：上任第一个礼拜的教训.md

@@ -0,0 +1,137 @@
+<audio id="audio" title="05｜事急则乱：上任第一个礼拜的教训" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b2/c6/b2c0c9f239a7319d108df127c665b0c6.mp3"></audio>
+
+你好，我是许健。今天我要跟你聊的是我上任第一个礼拜时获得的教训。
+
+这件事情我至今记忆犹新，专门拿出来讲，是因为这个案例可以生动地说明“新官上任”急于求成的风险，给你一个活生生的例子，来看看急于求成办坏事后，该怎么弥补，该如何反思自己、反思别人的过程。
+
+在你踏上经理岗位后，跟“人”相关的事情会比单纯做技术的时候多很多，希望你不单单从我的例子里吸取教训，更重要的是养成反思的习惯。
+
+上任第一周时，我跟很多新手经理一样，干劲满满，踌躇满志，很希望自己能很快地解决问题，做出成绩来。
+
+我当时负责云计算中IAAS部分的工作，其中给系统重装更高版本的镜像（Reimage) 是重要的基础能力之一。因此，我找到了部下小李，向他了解Reimage API的问题，并做出指示让他改进。
+
+一周后，我跟美国一起开项目审核例会（Sprint Review），美国的K经理（也是我的虚线汇报经理）在得知小李花了一周做我指示的工作后，直接就在会议上当着所有人的面质问我：“健，你为什么要浪费小李一个礼拜的时间做这个工作！而且这个工作并不在计划里面！”
+
+我当时一下子就“毛”了，脑子一热就直接跟K杠上了，说：“你凭什么说我浪费小李一个礼拜！”当时总部的产品经理A看到我直接跟K杠上，出来打了个圆场，但是产品经理也指出了问题，认为这个安排确实不在原先的计划里面。
+
+## 冲动会坏事
+
+事后冷静下来，我发现自己冲动了，我不能上任第一周就跟自己的虚线汇报经理搞僵，而且我要客观看待K的质问。所以，我找到小李再次询问细节，询问他关于reimage API的改进指示是否真的有用。小李的回答是有用是有用的，但是并不是最关键的。
+
+那时候我才知道，K经理的话是有道理的。我跟小李说：“以后你觉得我的话有问题，一定不要因为我是你的经理而有负担不敢说真话，一定要跟我直接说。你不跟我说清楚，我容易犯错误，而且还耽误你自己的时间花在不是最重要的事情上。”
+
+然后，我理了理思路，给K经理打了一个电话，服了个软，承认自己对小李的指示确实有问题，自己在会议上也太冲动了，希望K给予原谅。K说没有事，他也是希望大家能把工作做好。
+
+那个时候我刚转岗经理，我的领导给我安排了导师Wilson。我跟Wilson分享了这段经历，Wilson给我的建议是：很多事情看上去有很多表现，其实根子里都是**信任问题**，你要开始构建跟K的信任。
+
+于是我接受了这个建议，我知道K当时一边做经理一边在用自己的时间写一个方便他管理Cloud的工具，所以，我就开始用自己的时间主动给他贡献代码、修复Bug来逐步与他建立起了信任关系。
+
+这事情已经过去很多年了，今天我再把这件事拿出来，除了对当年自己在处理这件事有一些反思外，如今的我比当年的我的理解也加深了不少，现在的我觉得K的做法也是有提高空间的。今天就一起做一个总结：无论碰到什么事情，切忌冲动，一冲动你就输了，而且会坏事。
+
+## 为什么新上任的经理容易冲动？
+
+冲动是魔鬼，不管碰到什么事情，都不要冲动，一定要控制好自己的情绪。现在分析一下，当年我有冲动行为的原因有很多方面。
+
+### 想要维护个人面子
+
+但如果让我选择一个最重要的原因，那就是K当着我部下的面说我浪费员工时间，让我觉得自己非常没有面子。我相信K不会有意操纵我的情绪，但是本质上我的情绪被操纵了，而这是大忌。我认识的一个兄弟部门的开发经理，就因为跟美国的经理在会议上吵了一架，突然离职了。
+
+那我们该怎么避免自己因为面子问题而冲动？
+
+如果你去查相关的资料，大概率会查到“杏仁核”的概念，意思是人的动物性本能的传导速度会比理性分析的传导速度快。所以，很多文章会建议你察觉到自己快要情绪失控前，要做一些动作，比如把手表拿下来再戴上，为理性重新占领自己的大脑争取时间。
+
+你也可以去实际操作一下，但我发现，很多时候这样做的效果并不明显。如果你能意识到自己要去把表拿下来，就已经说明你已经意识到自己的情绪了。但很多时候你意识到后却还是会发作，为什么呢？很可能是你的潜意识就是想发泄。所以，我才不觉得这是传导速度的问题，这本质上是情绪自控力的问题。
+
+我们要先保证自己的情绪不失控，再**有理有据地反驳**。做反驳也是有诀窍的，你的**态度要好**，但**话要重**。
+
+如果现在我回到当年，再被K质问同样的问题，我会尽量控制自己的情绪，然后放慢语速，很客气地问他：“K，我相信你这么说一定有你的理由，你能详细说一下你得出这个结论的逻辑吗？”或者如果我觉得没有马上解决这个问题的必要，我会说：“我相信你一定有你这么说的理由，如果你觉得可以在会议开完以后再说，那我在会议之后单独打电话给你，可以吗？”
+
+等我在会后跟小李了解完情况，确认K对于这件事的判断是正确以后，我再跟K打电话，跟他说两点：第一，我承认我对于小李的工作安排是有失误的地方，非常感谢你指出来；第二，我也希望你可以不要当着众人的面用这样强烈的语气跟我说话。
+
+多年后，我跟总部一位负责人谈一个产品定位的时候，他直接说我不懂，让我好好去学一些细节。我就直接用上了这样的解决方法：“请你给出具体的细节，为什么你说我不懂？我现在对这件事的理解跟你不一样，你是我尊敬的人，你说的话我会在跟你打电话之后仔细核对。还有，我不觉得你直接下结论说我不懂是合适的说法，如果以后你我意见不一致的时候，我也直接下结论说‘你不懂’，你会怎么想？”
+
+除了有理有据地反驳之外，还有一类技巧是你可以**抓对方的逻辑漏洞**。
+
+想做到这点，你可以注意分析对方的话是不是在技术上没有问题，但是在待人处事上有问题？比如：你要判定，对方是说你的技术决定有问题，还是在怀疑你的动机有问题。同时你还要看对方的话是不是扩大了打击范围？
+
+举个简单的例子，你可以说我许健有问题，但是你不可以说上海的经理有问题，你不可以说中国的团队有问题。
+
+最后，就算吵了架也不应该因为这个而辞职，你辞职了你团队的成员怎么办？作为一个负责任的经理，你既要敢于说真话，敢于为团队争取资源，又不能把事情搞砸，我们不能做悲剧英雄。
+
+### 急于干出成绩
+
+刚才说了，我冲动的根本原因是我觉得自己在部下面前丢了面子，那还有别的原因吗？有的！就是我新官上任三把火，想马上出成绩，才在并不了解真实情况之下给下属下达了错误指令。急于出成绩的时候，你可能会在“事情”和“人”这两方面栽跟头。
+
+在办“事”的时候，你一定要给自己提个醒，你的下属不是傻瓜，你的领导也不是傻瓜。一个团队，一个项目，如果有一个投入产出比很高的机会，你的部下和上级视而不见等着你上任来解决问题的概率很低，这个问题之所以存在至今一定有它的原因。如果你真想做，就要去挖掘它背后的原因。
+
+除了事情本身，你还要考虑“人”的感受。给你举个真实的例子，我们公司搞云计算时发现云计算可靠性是个很大的挑战，而当时开发团队的人手有限，再加上正好想给部分运维团队转型，就以原来运维团队为骨干，成立了Cloud Reliability Engineering（简称CRE）。
+
+CRE的骨干一上来就说Cloud有各种问题。Cloud开发团队里的一些同学就不高兴了：这些问题难道我不知道吗，需要你来一个一个指出来，你不要光指出来，你去修啊，你了解情况吗？如果这个问题真的很严重，我早就修掉了……
+
+最后的结果就是“人的问题”不解决，两个团队放在一起，非但没有对实际工作有什么推进，反而徒添烦恼。
+
+你要记住，如果你急着想要出成绩的时候，千万给自己提个醒，看看自己是不是只看到了表面问题，事情看清楚了吗？人理顺了吗？
+
+刚接手的时候多看多问，多方核实，少下结论。最好找一两个了解一线情况又跟你关系很好的人，帮你理一理。不要急着出成绩，你可以很积极，但是做事一定要细致。
+
+### 没拿到部下的真实反馈
+
+我们再分析一下，我还有什么问题？我在跟小李交代任务的时候除了指挥错误之外，还有别的深层次的问题吗？有的！
+
+如果我很诚恳地征求小李的意见，小李就有可能在一开始告诉我很多的情况，避免我决策失误。我现在已经记不清我当时跟小李交代任务的时候是什么态度了，也有可能我刚上任，小李也不想一开始就给我浇一头凉水吧。
+
+要避免这个问题，你就要给愿意说真话的部下加分。
+
+现在的我即使在了解情况下也会跟部下说，如果我说的不对的**一定一定**跟我说，不然我的一个错误决定会让大家的投入没有收获，那整个组织都受损失了。如果你能用清晰的逻辑驳倒我的想法，我心里给你加分。我现在会反复地说这一点，单独1:1的时候说，开周例会的时候说，在All Hands上也会说，我要形成这样的一个文化。
+
+但即使我这样反复说了，这么多年下来能够主动给我提意见的部下还是凤毛麟角，你不能寄希望于部下主动找你。大部分有价值的反馈都是我单独跟部下1:1的时候主动询问出来的。
+
+> 
+我：“小刘，我准备要用技术方案X来做我们接下来的这个项目，这个项目很重要，我需要你的意见，但说无妨。”
+
+
+> 
+小刘：“许健，方案X如果你自己亲自试用一下的话，你会发现其实用起来不是很方便。如果我们的目标用户不是很了解技术细节，我觉得我们的后续客户扩展会很困难。还有，你安排小吴去做迁移，其实他心里不是很愿意的，他想做有技术深度的工作，我建议让小吴做方案X的简化工作。”
+
+
+> 
+我当面感谢了小刘的反馈，然后给小吴打电话，跟小吴强调，如果他自己有什么诉求一定不要犹豫，第一时间告诉我。
+
+
+我们一定要给部下灌输一个思想，那就是你不说，我就可能不知道，如果我不知道，我就不会安排，这样你自己不就损失了吗？
+
+### 表扬与批评的场合不对
+
+前面我提到了一句，现在的我看K当年的做法，也觉得他还是有改进空间的。因为我认为“批评”要在私下进行。
+
+如果换成现在的我在当年K的位置上，我在会议上不会说什么，然后在会后我会单独找许健，把我的反馈直接告诉他，这样我保留住了他在部下面前的面子，他也能感受到我真诚地希望他得到成长。
+
+我会像这篇文章前面提到的那样，从不要冲动，不要急着出成绩，怎么拿部下的真实反馈等方面帮许健做分析，我觉得如果我这么做，许健会很有收获。而且，信任是双方的，我花了这么大的力气培养他，可以加强他对我的信任，以后替我管理团队会更加尽职尽责。
+
+批评要在私下里，而做得好的地方就需要公开表扬了。
+
+我们公司对业绩表现优异的同学有一次性现金奖励，还有一张奖状。不要因为奖励跟钱相关就单独发，一定要当着整个团队的面发，我们就是要鼓励这样的优异表现。
+
+而且，表扬不单单对部下，对平级也应该有，但这不是要你笼络人心，而是单纯地有感而发。就比如今年这次新冠疫情，导致出差全部取消，给我的平级老张带来了许多麻烦。他手上一个非常重要棘手的项目，需要跟总部有紧密合作才可能做成。
+
+本来他是准备出差去办的，现在不能出差，老张每天很早就来公司，采取人盯人的战术，每天找到总部对应的人开会、核实进度，硬是把这个项目办下来了，我很佩服他。这个话总部开会审核项目的时候老张自己不好意思讲，但我一定要把我看到的说给副总听。
+
+## 总结
+
+今天，我用我自己转岗经理一个礼拜后冲动的例子回顾了我的收获，**而且一定要深挖，挖到根本原因**。
+
+首先，你遇事一定不能冲动，如果事情已经发生了，那就挖深一点，看看自己当初为什么会冲动？又该怎么避免自己冲动？如果你做到不冲动了，那你的态度好吗？话重吗？说到位了吗？
+
+其次，遇事你要先提醒自己，不要因为急于出成绩，在不了解情况就急吼吼地下结论，要把事情和人的背景关系都搞清楚。再问自己，如果有人给我提意见，指出我的问题决策就好了。
+
+再次，你还要剖析你的下属是怎么做的？你接下来要怎么样，才能让大家都这么做？
+
+除了鼓励以外，我得主动询问。然后我如果是K我现在会这么做？我要公开表扬，私下批评。
+
+## 思考题
+
+你作为一名经理，如果你发现你做决策很顺，几乎所有的部下都很认同你的决定，并且连续很长时间都是这样，你会作何感想呢？
+
+在用重话回复的部分，我提了两个技巧，分别是不要怀疑我的初衷和不要扩大打击面，你还能总结哪些在对方对你说让你很不爽的话的时候，你有理有据反驳的技巧模式吗？
+
+学完这节课，你可以在留言区分享你对“新官上任”这个话题的体会。也欢迎把这篇文章分享给你的朋友、同事，帮助他们更好地闯过新手经理的“情绪关”。

极客时间专栏/geek/技术管理案例课/一线经理：开始带员工了/06 | 员工沟通：怎么赢得之前平级的技术骨干的尊重？.md

@@ -0,0 +1,144 @@
+<audio id="audio" title="06 | 员工沟通：怎么赢得之前平级的技术骨干的尊重？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/4f/fd/4f69ecc475abf225d34af96fb9ee81fd.mp3"></audio>
+
+你好，我是许健。今天我要我要和你聊一聊，你成为经理后，怎么和之前跟你平级的技术骨干相处。
+
+如果在成为经理之前，你就是所在组能力最强的技术骨干，其他组员的战斗指数、综合实力都在你之下，那对于这个问题我估计你体会不深。但如果在你当经理之前，组内有跟你级别一样的、能力差不多甚至专业能力在你之上的组员，**你必然要经历一个困难的适应过程。**
+
+我就经过了这样一个过程，你可以看看我当上经理之后，我们部门的资深员工跟我都说过什么样的话，感受一下我面临的问题：
+
+1. 许健，这事儿我们事先商量得好好的，怎么一到副总那边你就软了？
+1. 许健，你在这个会上说了这么久，我还是不知道你的主旨是什么啊。
+1. 许健，你说要我们先做容易做成的，我不，我就是要挑最难的！
+1. 许健，我不想和你1:1沟通，我们好像也没有什么可讨论的。
+
+类似的情况还有很多，有不服从的、有正面刚的、有不说话的、有不执行的。不知道你听到这些话什么感觉，反正我心里挺不好受的。但是，作为经理，再不好受，这事儿咱还得做。
+
+那遇上这些问题怎么办呢？我们下面就来聊一聊。
+
+## 经理的目标
+
+首先，让我们深吸一口气，暂时放开刚才那些棘手的问题，先来思考一下，作为经理，我们的目标到底是什么？
+
+我们首先确立一个认知，那就是经理在技术实现能力上并不一定比团队的技术骨干强。经理比部下技术能力强又如何呢？经理技术更强就能服人吗？如果你沉浸在“让自己最强”的表象中，就会导致一个问题——你的水平会成为整个团队的瓶颈，这可不是公司希望看到的。
+
+级别越高的经理，越应该明确一点，**经理的目标是让团队的成员更强，凝聚力更高，从而可以一起去攻克更艰难的目标，而不是证明你比你的部下或者平级更强**。如果你被部下说两句就不爽，那你以后还怎么带人？岂不是永远只能带比你差的人么？
+
+所以，遇到前面所说的“平级刁难”问题时，你应该先克制情绪，回顾自己的目标，去分辨他们反馈的内容里，哪些是真的诉求，哪些是情绪垃圾。
+
+也就是说，这时候，你不要把焦点放在自己的权威是否被冲撞了，而是要看他说这个话的前提是不是为了组织好。只要前提有道理，那就把你的自尊咽到肚子里面去吧。作为一个经理，这点气量你要有，不然团队里那些会说“逆耳忠言”的人就会离开，最后就再也没有人跟你说真话了。
+
+该承认自己有错的时候要承认，该坚持自己的权威的时候也要坚持。对于前提正确的有效诉求，你当然应该接受，但你还要正面地拒绝部下的情绪垃圾。
+
+不过，单有气量是没有办法赢得这些干将的心的，如果你作为团队领导在平级和部下面前一味地像只羊一样温顺，那你其实也就没有什么威信可言了。如果你的部下中有“狼”的话，要么他会取你而代之，要么他会因为不愿意留在你这只“羊”下面而离开。将熊熊一窝，这样一来，这个团队也就不会有多少战斗力了。
+
+## 如何赢得尊重？
+
+那么，你怎么才能赢得团队里这些干将的心呢？我自己经历了“给干将搭台子”，“克服自己的心理障碍” 和 “提升自身能力” 三个阶段。其难度也是递增的。
+
+### 给干将搭台子
+
+给高级别员工搭台子是我的上级领导教我的，我转成经理以后觉得自己对于跟团队里面原来的平级特别是比较资深的高级别员工怎么相处这事儿有点力不从心，于是我主动去找了上级领导，领导建议我从给他们搭台子开始入手。
+
+**第一，给充分的资源支持。**
+
+给资源支持这件事，分对内、对外两个方面。
+
+对外，平时你要多找一些需求点，然后把你的员工推出去，让他们去负责解决这个强需求点，并且要持续地推出去。
+
+对内，为了团队的核心骨干能有更好的发展，你需要给他们提供充足的支持，努力去跟相关的高级总监、副总去谈，去找需求、要资源、要认可，让他们获得真正的成长。
+
+这种向外、向上的沟通一开始可能并不容易。在搭台子的过程中，我们需要高级别领导的支持。
+
+事前，你需要说服他们把有挑战、可以出成绩的项目交给你的团队成员，如果一个人做不下来，还需要给你预算去招人；事后，如果做出了成绩，需要你去申请给员工加薪升职，寻求领导支持。这些都需要你主动去提。
+
+我在一开始的时候很不好意思去找上级领导去要资源，总觉得自己好像是去求这些位高权重者。
+
+后来，我想通了，如果某个项目真的是公司一直没能解决的痛点，公司就是需要投入资源的。只要你不抱有私心，就要很有底气地去跟这些领导交涉。
+
+团队里的员工看到你为了他的事情鞍前马后、费心费力，他是能感受到你的诚心的。你不能只让他们干活，而不给他们争取权益。
+
+当然，争取得到争取不到另说，但是你必须去给他们争取，这代表了你这个经理的态度。很多员工能够接受你尽力了但是没有能把他们的升职办下来，但是不能接受你不尽力。
+
+**第二，让员工有被需要的感觉，让他感觉自己在这个团队里“独一无二”。**
+
+在面对入门级别、低级别的员工时，你可以跟他们讲这个事情对公司有多重要，有什么意义。但是，给高级别员工安排工作时，可就不一样了。他们要么是自身能力已经很强，要么在公司已经待了很久，资历很深。说直白点，谈价值和意义，大多数情况下对他们都没什么用。我们只能从人性的角度另辟蹊径。
+
+你可以这么说，“**这件事很有意义，但是也很难**，就我们组织目前的人员配置，只有你最有可能搞定这件事，我没有别的选择，只能靠你。”
+
+如果是你，你听了这话，会不会觉得有被需要的感觉呢？注意，说这个话的时候绝不是耍语言技巧，而是在陈述事实。你的每一句话都是很真诚的，大家都是聪明人，心里什么都明白，人家很容易能判断出你是在耍技巧，还是诚以待人。
+
+好了，我觉得做到这两点，应该就差不多了。但是这里，我还想强调一个非常重要的注意点，那就是，不要觉得给人家做了一点点事，就马上希望看到回报，马上就想见到效果。我们要慢慢来，一次、两次的这样做，人心自然就会越来越近，何况你们每天在一起的时间比跟老婆在一起的时间还多。
+
+刚开始，你为了实现自己的管理目标用些技巧，是可以被理解的。但是从长远来看，我希望你最好是从心底里认同这件事，这样才能真正走得长远。
+
+### 克服心理屏障
+
+你有没有遇到过这样的情况，你明明觉得你的平级或者你团队的高级别员工有些事情做得让你不满意，但是因为他们级别高，或者你觉得他是个硬茬，而你没有足够的感情强度去把他们的问题指出来？
+
+我就是有这样的感觉的，而且在一开始很多时候我都忍了，但是后来我觉得这样不行，我开始尝试做出改变去指出问题，这句话说起来容易，做起来可不容易。
+
+你看过《谁动了我的奶酪》这本书吗？故事里的小老鼠，她的关键问题其实就是要走出去。
+
+我相信很多人也跟我一样，新上任的时候觉得自己气场不足，碰到战斗力值比较高的员工说话有顾虑，怕他不开心，同时也怕自己说得不妥帖，怕人家不接受。
+
+但是，你说出来总比什么都不做要好，因为你说出来了，你就可以看到对方的反馈，你可以再学习、再调整。
+
+当你没有了解具体的细节，或者对事情的认识不够深刻时，就去给员工提意见，那效果一定会很差。所以，你给员工提意见和建议的时候不要空谈，要不绕弯子地谈具体的细节。了解得越详细，你提意见的时候也就越有底气。
+
+对普通员工你要这样做，对能力强的员工更要这样做。因为平时很少有人给他们特别好的建议，如果你能够给出，并且让他们认可的话，他们会对你加分。
+
+“给员工提出有效意见”，特别是给个性比较强的高级别员工提有效意见，这是经理心理上的一个坎，越过这个坎，才说明你自己的感情强度到达一个更高的层级，也说明你和该员工的信任关系到达了一个更高的阶段。
+
+一开始我会找这样的员工一起吃饭，先把感情距离拉近了。接着在1:1 的场合开始委婉地提出问题，比如：“X，你的执行力很强，这一点很好，但是我还是一直希望你有一个单独负责的项目，能够按照你的设想，制定一个比较高的目标并为之奋斗。”
+
+但是我实际操作下来我并不觉得这样委婉的效果很好，而且我也没有突破自己的心理壁垒。我后来开始改变方式，我现在变得越来越直接：
+
+“J，你作为这个方向的技术负责人，你必须更加有主见，不能被别人牵着走，如果你都被人牵着走，那跟着你干的那些资历较浅的员工就整个都是工作在资源模式下了。找个硬茬去练练吧！”
+
+“X，你如果不能准时参加会议，那必须跟我事先打招呼，如果你自己安排一个会，我当作没有发生，你怎么想！”
+
+“Y，你为什么留在eBay 工作，你总有一个你在这里工作的愿景吧？你回去想一下，把你想在这里工作完成的愿景告诉我，然后你要有实际的行动为之奋斗。你如果不去为了你的愿景争取资源，那别人就会争取你的资源，你想要实现你的愿景我觉得就遥遥无期了。”
+
+不要为了给意见而给意见，但是当你注意到他们的问题，你必须克服心理障碍直指他们的问题，我前面说了，目的不是压得住压不住，而是为了这个团队更好，为了这个员工好。
+
+### 提升自己的能力
+
+仅靠有气量和诚以待人地搭台子，就算你能指出这些同事的有待改进的问题，你觉得就能赢得前平级同事的心了吗？不是的！做到这两点，他们会说你是一个“好人”。就跟你追女孩子，很可能你追了很久后得到一句话：“你是一个好人。”
+
+我先问你个问题，你觉得自己的能力能在一两个礼拜或者一两个月内有质的飞跃吗？
+
+如果不能，那你也就不要奢望自己可以在短时间内去“收服”团队内的员工。既然这是个长时间的事儿，我们大可以把线放得长一点。不要把精力花在收服上，而是要把精力花在提高自身上。
+
+因为能力强的人都希望自己的领导是个有能力的人。那我们前面也说了，经理的目标不是证明自己比部下强，很多时候，员工某些方面的专业能力可能比Leader强的，那这时候作为经理，应该怎么看待这事儿呢？
+
+我觉得，如果你团队里有能力强的员工，这是对你自己提高自己能力的一个鞭策，你可以把团队中能力强的员工当成使自己更快提高的磨刀石！
+
+我成为经理后，有俩同事虽然在我组里，但是他们直接向我的领导汇报工作，我们实际上还是平级。其中一个男生人特别聪明，说话直接、有性格，攻坚能力也很强。面对这样的人，我一直觉得自己气场不足，即使在我领导离职后，这个男生开始向我汇报工作，这个情况也没有改变。
+
+为此，我曾经找过我的大老板，为了组织整体利益考虑，提议让更有能力的人来做经理。大老板却表示，我应该为团队里有能力更强的人而感到幸运，认为我更加应该鞭策自己，这样我才有能力帮助团队成员们变得更强，公司才会更好。
+
+事实也确实如此，这个员工的很多意见都在工作中给了我新的启发。比如他说我不管团队，在团队里待着的时间少；我跟美国的技术人员1:1的时间，都比培养上海员工的时间多；团队中能力可以达到攻坚水平的人太少，等等。
+
+那怎么提升自己的能力呢？我的结论是没有捷径，最有效的方法就是去经历挫折，主动去走出舒适区，把每一次办砸的事情都看成“天将降大任于是人也，必先苦其心志，饿其体肤，增益其所不能”。犯错比不犯错好，人从失败中汲取营养的效果远好于从成功中汲取营养的效果。
+
+我从成为我们部门一位高级别员工的经理，到我觉得自己真的在能力上成为他的经理前后5年时间，我觉得我能实现这个转变的最重要的原因是这5年我经历了很多事情，我犯了错，老板没有把我开掉，还给了我更大的平台去锻炼去历练。于是在这个过程中我能够有机会从失败中总结反思，然后在反思后矫正后重新应用到工作实践中去。
+
+所以，以后你再有碰到困难，感到困难的时候，不如对自己说：“我作为一名经理提高能力的机会来了”。
+
+## 总结
+
+在成为经理之后，你必然要经历一个与“前平级同事相处模式改变”的适应过程。
+
+为了解决这个问题，我们要先知道，自己作为一个经理到底应该做些什么。我们的目标是让团队的成员更强，凝聚力更高，一起去攻克更艰难的项目，而不是证明你比你的部下或者平级更强。
+
+你的目标摆正了只是基础，真的要做到能够赢得前平级同事们的心，你需要用心给他们搭台子，去解决他们现实的问题，而不是一味地对他们提要求。如果人家尽了力做出了切实的贡献，你就应该给他们争取他们该得的名誉和物质认可。
+
+你还要努力提高自身能力，没有捷径，去多吃点苦。最后你的能力上去以后，你才能看到员工身上深层次的问题，这时候你需要有足够的感情强度和逻辑去直接给反馈。
+
+## 思考题
+
+曾经有一位经理跟我说过，说他的部下可以私下顶撞他，但是不可以在团队会议上顶撞他，如果在那样的场合他必须坚持，维护自己的权威。你们怎么看这位经理的做法？
+
+你能举出一个你部下说了很冲的话，但是你觉得他说的有道理，这种情况你会如何处理呢？
+
+欢迎在留言区晒出你的经历和疑问。如果你有所收获，也欢迎你把这篇文章分享给你的朋友，说不定就能给他一些启发。

极客时间专栏/geek/技术管理案例课/一线经理：开始带员工了/07 | 向上管理：你知不知道你领导真正的烦恼是啥？.md

@@ -0,0 +1,183 @@
+<audio id="audio" title="07 | 向上管理：你知不知道你领导真正的烦恼是啥？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/83/23/835a4b99d18a022f3387a0033aeb3623.mp3"></audio>
+
+你好，我是许健。今天我想跟你谈谈“向上管理”这件事儿。
+
+上一节中，我给你讲了怎么赢得平级骨干的尊重。那我们作为下属，又该如何赢得领导的信任呢？所以今天，我想以一些实例来讲解一下我和领导的相处之道。
+
+在讲具体的方法和注意点之前，我要先问你一个问题，这个问题是：什么叫“你的团队”？因为只有定义好这个问题，你才能想清楚如何去与自己的领导相处。
+
+我猜测，几乎所有的经理给出的回答都是：“我的团队就是我所管理的团队”。没有人把自己的上级放入自己的团队里，也更不会把上级团队看成自己的团队。
+
+那我们为什么会进入这样的误区呢？原因就是没有做好向上管理，不考虑向上管理，就很容易导致你做决策的时候，只为自己的小团队做局部优化，而不顾及大团队利益。
+
+## 对内：把上级纳入你的团队
+
+那么我们到底怎么修炼，才能把上级纳入自己的“管理”中呢？
+
+首先，你要站在领导角度思考，具体方法是拔高层级来看问题；接下来，你如果光想不做，还是空谈，所以你还要行动起来，主动帮领导排忧解难；最后，你还要明确领导到底需要什么样的部下？他需要有能力、有主见而且和自己一条心的部下。
+
+<img src="https://static001.geekbang.org/resource/image/0b/04/0ba368c4bdd45008aaa1fac9b52d3b04.jpeg" alt="">
+
+### 拔高层级看问题
+
+首先，你要意识到，领导看问题的高度跟你是不一样的。你要有站在领导的角度去看问题的意识，甚至你还要进一步，站在高你两级的领导的角度去看问题。
+
+下面我给你分享一个我的经历，正是这次经历让我开始反思：为什么领导的判断和我的判断不一样？我又该怎么做，才能拔高层级，读懂领导的思路和烦恼呢？
+
+我所在的部门是云计算部门，有一次，我去总部出差拜访云计算的内部客户。其中一个客户就是公司的机器学习基础架构平台，该平台的领导其实也是我的老同事了。
+
+拜访他一周后，他让我帮忙在上海招聘一个编制外员工，需要这名员工来做机器学习平台的运维和客户支持工作。我欣然同意，很热心地帮忙招聘。
+
+我为什么乐于做这件事呢？因为我觉得，机器学习平台那时在上海没有团队。那在上海有这样一个人，我就能更及时地了解到机器学习平台对云计算平台的使用反馈，而且机器学习平台是一个很好的方向。
+
+其实这件事情，我在答应帮这位老同事招人时就说过，我当然蛮希望他在上海部署研发团队。我建议他先看看在上海部署的运维和客服的实际效果。如果他真的要部署研发团队，一定要跟我老板谈，因为我老板会从整体来看，如何安排人员，才能达到效率最高。
+
+又过了几个月，这位老同事准备在上海建立一个团队负责机器学习平台的研发。我的老板说，虽然一开始运维和客户支持的工作是从我这里开始的，但是她觉得正式建立的研发团队，还是放在大数据部门那里更加合适。
+
+如果你只是站在自己的角度，你肯定也和我当时的想法差不多：如果机器学习平台能放在我这里多好啊。这是一个蓬勃发展的方向，对于我们部门做大做强有很大的促进作用。而且一开始招人做机器学习平台的运维和客户支持工作，还是从我们这里起的头。
+
+但是这个时候，就需要我站在更高层级来看问题，才能更好地理解整个上海研发中心的战略布局。我想到了拔高层级整体去理解这件事儿，然后就发现在上海我们从大数据基础架构，到大数据分析，这一整条链路有比较健全的大数据系统，而机器学习离开了大数据是没有办法发挥作用的。
+
+我这样一分析，才理解了从领导的角度、从更高级别组织的效率来看，把机器学习平台跟大数据放在一起，而不是跟云计算放在一起，是更有道理的。我想通了这一点，就更觉得不管这个机器学习的团队是不是汇报给我，我都应该尽力去做。因为这是对上级团队有帮助的事情。最后老板确实把这个团队给了别人，我也认为这是正确的决定。
+
+### 帮领导排忧解难
+
+主动换位思考，去体会领导面临的问题，体会领导的烦恼，然后是你想不想帮的态度问题，也就是你有没有想到要去做些什么，来帮助领导。将心比心，这其实是一个很容易想到的问题。
+
+那更难的问题是什么呢？那就是你究竟知不知道领导真正的烦恼。更进一步是你能不能帮上忙呢？就算你知道了领导真正的烦恼，你真的愿意花额外的精力，甚至牺牲你小团体的利益，去帮助领导解决烦恼吗？
+
+我用一个案例给你说明一下，即使你无法一次性解决问题，还是可以做一些事儿帮领导解忧。
+
+我们部门在流量管理上有两套方案，分别由两个部门负责，副总一直希望能够明确一个比较好的方向，这样就能够把这两套方案有机地整合起来。而且我们公司现在的财务状况是不适合搞内部竞争的，所以最好大家往一个方向使劲。
+
+但是，说起来容易做起来难啊，这个事情一直拖着。最近公司因为支付业务的安全要求需要给全链路配置TLS（一种网络加密协议），于是流量管理多套方案的问题又摆出来了。
+
+有一天，我们在副总的会议上激烈讨论了一轮，却没有结论。会后我就想，这个问题悬而未决很久了，问题如果不解决，就会继续在一个部门内消耗两个组的资源去运行。那我能做什么能帮助副总和我们的大部门解决这个拖了很久的技术决策难题呢？
+
+于是当天下午，我召集上海的相关技术骨干，一起梳理了一遍所有我们能想到的方案，对于每一种方案，都给出我们的优劣分析，并估算出粗略的实施成本。第二天，我们在副总的会议上讲了我们所有分析的方案，虽然还是没有能彻底解决这个问题，但是也是比之前朝最终方案进了一步了。
+
+在我看来，至少副总能看到，他虽然没有要求我们去做这个分析，而我们却主动去做了。**这里的关键是你要想到，你可以主动帮领导排忧解难**。你要知道，人脉和信任的积累，都是通过平时点滴细节中持续投入达成的。
+
+在帮助领导解忧上，你到底怎样能验证自己有没有做到位呢？下面我给你讲一个反例，说明这个问题。
+
+我觉得自己做得不大到位的一件事儿，就是没能帮助上海的领导排忧解难。最近我们总经理亲自负责了一个eBay的战略性业务项目的前期验证，项目很急。总经理虽然手上有预算，但是临时去招人肯定赶不上进度了，于是就希望从各个部门紧急抽调人手帮忙。
+
+我遇上了紧急抽调，却自己发现没法调动人手出力。我给你分析一下当时我部门的状况：我所在部门人手已经排满，而因为我的影响力不足，还有跟总部关系还是不够紧密的原因，我没有办法调动本部门上海的人手去帮助总经理的项目。
+
+而我的平级中就有人有这个能力可以调动，这至少说明两点我的同僚比我强：一是人家手上有应对临时需求的相应人才；二是人家对于本部门工作的主导能力在我之上，所以可以调动这些人才。
+
+如果你也遇到类似上面的情况，你该怎么办呢？现阶段，你还是要先有这样的一个问题意识，哪怕你一时解决不了。我想提醒你，“冰冻三尺非一日之寒”，没有短期就能提高的方法。你只有持续扩大自己的影响力，提升自身团队实力才可以做得更好。
+
+### 不做奴才部下
+
+这是我对我自己的一个要求，也是我对我部下的一个要求。不能在领导面前唯唯诺诺，领导说一就是一，领导说二就是二。我应该是一个有独立思考，能够跟领导进行高质量沟通的部下。
+
+我认为，**一个好的部下不单单<strong><strong>只**</strong>是领导的部下，而应该同时是领导的智囊</strong>。最差的情况是老板教训你根本没有心理负担，注意我这里说的教训而不是说教育。稍微好一点，但是仍旧不理想的情况是什么样呢？对于老板给你下达的工作任务，你从来都是执行，却没有跟老板交流。你哪怕有一些自己的想法，也不敢对领导说。
+
+我做经理，如果一两个月我安排的工作从来都听不到一个“不”字，我就会自己反思：什么时候我们部门成了一言堂了？我觉得跟老板相处，**要带着“一颗支持的心去提反对的问题”**。因为你希望你的老板成功，这样你才有可能成功，所以你要主动去想可能的风险点。
+
+就拿领导安排工作这个事情来说，如果你还没有被完全说服，建议不要直接说“不”，下面是一些技巧，你可以按照这些思路和领导进行高质量的沟通：<br>
+<img src="https://static001.geekbang.org/resource/image/67/c5/6789287ddb415d3b70274f7d683b6ec5.jpeg" alt="">
+
+### 不做无能部下
+
+“你要知道，我不是无能的部下”。我专门写了这样一句话，是因为我经历了一个思想转变：从极度认可这句话，转换到觉得这句话其实有问题。
+
+如果有一个部下，你觉得他能力很不错，然后你看到一件事情他却办得不怎么样。那么这时候，你可以对照一下，你的反应会更符合下述两个情况之中的哪一个：
+
+- 他怎么把这件事办成这个样子？
+- 他能力很不错的，事情应该没有这么简单，是不是有别的原因？
+
+我当然会选第二个，但是必须注意一个问题，如果你作为部下，你的领导来问你说你这件事情的结果为什么不是领导心中的样子？你怎么说，你应该跟领导说下面的话吗：“领导，你觉得我是这么没有能力的吗？”
+
+现实中有很多不同的表达，但是其核心意思是你作为部下，你希望领导找你谈话之前过一下脑子。你虽然是领导的部下，但是因为你能力出众，所以领导跟你讲话也要做一些准备。这背后存在的问题就是 “信任”不够，如果领导跟你谈话需要事先过脑子，那你跟领导的关系其实不是很近的。
+
+**最好的<strong><strong>状态**</strong>是：领导可以在一个很放松的状态下跟你谈话，他指出你的问题不需要经过取证，准备的过程，他可以说，你可以解释。也就是说他也没有负担，你也没有负担。</strong>
+
+我个人比较喜欢刘备和张飞、关云长之间的上下级关系；或者《少帅》里面张学良和褚时新的关系。这个关系的本质，概括下来就是，**你是你老板的左膀右臂，并且信任程度很高**。如果失去你，对于你老板来说是非常心痛的，失去一条胳膊和失去一辆车的感觉是完全不一样的。
+
+## 对外：学会感恩，维护领导
+
+前面说完了对内的修炼。那对外你要怎么做呢？这里的对外，是指你和你的领导之外，在所有涉及你领导的事儿上，你要做一个忠心的部下，学会感恩，对外维护领导权威。
+
+### 维护领导权威
+
+对于领导的做法，你不一定在所有的时候都是认可的。特别是当你慢慢成长起来以后，你也有你自己的独立思考。而且我在这一节课的一开始，就鼓励大家拔高自己来看问题。
+
+但是拔高层级看问题后，你还会遇到更进一步的问题。都会遇到哪些问题呢？我来给你分析一下。
+
+- 如果你站在领导的位置来看问题，却发现你的看法跟领导的看法不一致，这种时候要怎么办呢？
+- 如果你越发觉得你自己才是对的，领导是错的你会怎么办？
+- 如果在你的想法和领导的想法不一致的时候，领导还按照他的想法实施了，搞得你不爽你怎么办？
+
+**我的原则是这<strong><strong>些问题都**</strong>是你和领导之间的事情，**<strong>因此你**</strong>绝对不应该在自己的部下面前，或者在旁人面前对自己的直属领导说三道四。</strong>
+
+无论是在部下或者其他人面前，我都会绝对维护自己的领导的权威，我如果对我的领导的做法不满意，我应该单独跟他说。我们做个换位思考，你就明白为什么要这样做了。
+
+先来说说我把这种意见不一致传递给部下，这时候部下会怎么想：“哦，我的领导对他的领导不满意了。”如果你碰到搬弄是非的部下，后果就难说了。
+
+我去跟旁人说就更不应该了。我在其他人面前对自己的直属领导评头论足，那是我自己内心的膨胀在作怪，我其实在告诉别人，我的领导不行，我比他行。
+
+己所不欲，勿施于人。你可以想一想，如果你听到你的部下私下说你不行的时候，你是什么感觉？你的感觉也一定不会好到哪里去。通过这样的换位思考，你应该也发现了，这不是解决问题正确的方法。
+
+你作为一名经理，当你从其他渠道知道这种负面反馈后，应该做到客观去看待这个反馈，有则改之。但是，如果你作为一名下属，我还是强烈建议不要在背后去评论自己的老板。
+
+还有一种维护领导权威的方法就是**分清主次**。有一次我们公司安排全体经理去外地开会，领导致开幕词，为了生动，领导现场找两个人谈一下感受，于是我举手发表意见，并且洋洋洒洒讲了很多。
+
+结果，我讲完以后领导说，要不下次开幕词你来讲吧。听到领导这样说之后，我感受到了他的“画外音”，所以发现自己喧宾夺主了。
+
+这件事给我的反思就是在各类场合要分清主次，不要因为自己内心的虚荣而忽视这一点。
+
+### 别让领导做坏人
+
+什么叫做“让领导做坏人”？就是指，你对外的时候总是把“责任”推给你的领导。“让领导做坏人”，相对应的是，你自己要“做好人”。我来给你举两个具体的例子。
+
+为了方便理解，我们假设你是一线经理，许总是你的上级。公司到了年底绩效评定的时候，你想提拔团队里的老王，然后在上级领导那里却没有过关。于是你就跟老王说：“老王，不是我不想提拔你啊，我已经尽力了，是许总他不同意啊。”
+
+还有一种情况，你想给小张年底评定为优，但是公司有比例限制，许总觉得这个优的评定应该给别人，你跟许总再三分析利弊。最后，许总还是同意把这个“优”给小张，然后你跟小张是怎么沟通的呢？你说：“小张，你这个‘优’我可是花了大力气的，你知道吗？许总他一开始是不同意的，是我再三跟许总争取的，最后才说服了他。”
+
+上面这两种情况，就是让领导做坏人，自己做好人。发生这样的情况，其根本原因是什么呢？没错，是你不想让你的下属对你不满意，就试图把这些责任推给你的领导。或者是你想在你的部下心里加分，却以领导在部下心里减分为代价。
+
+你想想看，这里都有哪些风险？第一，你的部下会有想法。成熟点的员工会觉得管理层意见不一致，而不成熟的员工甚至会埋怨领导的领导；第二，天下没有不漏风的墙，你无法阻止你的领导通过其他渠道了解情况。一旦他知道你让他当坏人，那你的领导又会怎么看你呢？
+
+所以，我们回到刚才的场景，你的思路应该是：许健不同意一定有许健的原因，你给员工反馈的时候，就应该用你的立场把反馈给到员工，而不是把自己撇开，说A领导觉得你这个地方需要提高，B 领导觉得你那个地方要改进。
+
+你正确的做法应该是：结合自己的观察，给这名员工分析他需要改进，具体哪里需要改进，因为他做的工作还不够好，所以这次还不能拿优。
+
+### 懂得感恩
+
+做人要懂得感恩，要用历史的眼光看问题。以我自己来说，我能走到今天，离不开团队、部下的支持，更离不开领导的多次提拔。因此，对上你要时刻提醒自己，要有一颗感恩的心。
+
+老板给你好处的时候，你欣然接受，但是要拿走一点点，就很不爽甚至跟老板闹，这样很不好。
+
+而懂得感恩，就可以帮助你摆正心态，客观地看待问题。这个心态会指导你的待人处事，让你从积极正向的角度，而不是从怨恨猜忌的角度来处理问题。
+
+三年前，领导力排众议把一个重要部门交给我。慢慢我也成长了，逐渐能适应和管理一个上百人的团队了。接着，因为大大小小的组织重组，好几个团队分了出去。有一次，领导跟我谈跟总部的组织Alignment问题，我一开始是抗拒的，脑子里还开始猜测各种可能性。
+
+突然有一天，我在看一本关于人生的书——《Ego is the Enemy》的时候，看到里面说，人要活得开心就要懂得感恩。我一下子就联想起组织Alignment 的事情，我终于能够更客观地分析这样的安排了。具体我是怎样想的：
+
+- 我首先审视了我自己，自己这几年是不是膨胀了？要知道，觉得自己挺行的时候就是自己停止进步的时候，就是听不见正确意见的时候。我的结论是自己有点膨胀了。
+- 我再告诉自己，没有领导的信任和提拔，我能有今天吗？领导给了我四五个团队，现在要拿回去一个团队我就不爽了？我发现是自己的心态有问题，缺乏感恩之心。
+- 最后，我应该客观去分析领导这么建议的原因，放下预设立场后去看问题。
+
+这件事情在数个月后，我越来越觉得应该重新做Alignment。其根本原因是，一开始领导就看到了要接管这个团队的新领导的潜力，以及他与总部良好的协作关系。而我在数月之后因为跟那个新领导有了更多的接触，才渐渐体会到这一点。
+
+## 总结
+
+向上管理是一个循序渐进的过程，我们先要对“你的团队”重新定义，意识到把上级纳入你团队的重要性。如果不考虑向上管理，会限制你看问题的视野。
+
+思维上，你只有去拔高层级看问题，才能更好理解领导的思路和烦恼。领导也是人，你站在他的角度考虑问题，他自然感觉得到。你要先把态度和意愿做到位，再慢慢找机会，跟领导一起探讨在领导这个层面的问题。随着这种讨论的机会变多，你看问题的高度自然会慢慢提升。
+
+行动上，你光想不做当然不行，还要主动帮领导排忧解难。即使你短期内在有些问题上，没有能力马上帮到领导，也要先树立这种意识。另外，领导需要有主见、有能力，和领导一条心的部下。
+
+有“主见”意味着你不是“奴才部下”，我们和领导相处要做到不卑不亢，因为你如果只是一个唯唯诺诺的人，领导也是不敢让你担当重任的。
+
+而随着你经验的积累，你渐渐成为“有能力”的部下，这时候不能恃才傲物，你有能力更应该和领导彼此高度信任，不要让领导指出你问题还有什么心理负担。
+
+对外，你的能力要长，脾气和心气不要长，对领导也要抱着感恩之心。有意见单独跟领导提，对外时要坚决维护领导权威，绝对不要去做自己做好人让领导做坏人的事情。
+
+## 思考题
+
+你的老板任命你去部门A任职，但是在任命你之前，他把部门A原先的主管裁了。你觉得老板为什么要这么做？那部门A的主管走之前，你会约那位主管一起吃个饭吗？
+
+欢迎在留言区晒出你的经历和疑问。如果你的朋友也在向上管理方面有困惑，欢迎你把这篇文章分享给他。

极客时间专栏/geek/技术管理案例课/一线经理：开始带员工了/08 | 人才招聘：招人过程中容易犯的5种错误.md

@@ -0,0 +1,180 @@
+<audio id="audio" title="08 | 人才招聘：招人过程中容易犯的5种错误" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/79/ec/79960085c1705a55a7483442b83abaec.mp3"></audio>
+
+你好，我是许健。今天我想跟你谈谈“招人的那些事儿”。
+
+五年前，上海研发中心想设置Kubernetes团队，就是因为我的团队里有一个在Linux内核方面很有影响力的高级别技术专家，最后我才能说服总部在上海部署Kubernetes团队。同样地，也是因为我们有一个在OpenStack社区存储方面很有影响力的人，才能在上海成立云计算存储团队。
+
+对于一个管理者来说，能不能招到“对的人”，几乎决定了你想做的事儿能不能成。软件和互联网行业尤其如此，一个厉害的员工能影响一个团队，成就一个产品。可如果经理招到一个不合适的人，非但不能提升团队实力，还有可能因为团队不和，导致原来有能力的员工离职。所以，作为招聘经理，我们就得自己承担后果，甚至需要自己把那个不合适的人裁掉。
+
+你看，“招人”对经理和团队的成功来说至关重要，如果要我说，我觉得招人这件事值得我们花费工作50%的精力。那问题来了，我们的时间这么宝贵，这50%的时间到底应该怎么用才能不浪费呢？
+
+这里需要我们先了解招人时容易犯哪些错误，下面我会用递进的方式，分析常见的问题，带你从简单的注意事项开始，学会如何在招聘时“避坑”。
+
+## 1.向候选人炫技
+
+第一个容易犯的错误就是“炫技”，我自己在早期也犯过这样的错误。我先列举几个面试片段，带你感受一下。
+
+片段一：
+
+> 
+<p>我：“你能给我讲讲什么叫做CAP吗？”<br>
+候选人（卡壳）：“……”<br>
+我：“那我来给你讲一下吧……（超级细致）”</p>
+
+
+片段二：刚才的问题还有一个升级版本，那就是候选人主动要求面试官给他讲一下。
+
+> 
+<p>我：“你能给我讲讲什么叫做CAP吗？”<br>
+候选人：“好像是分布式系统设计有关的，具体细节说不好，您看上去挺资深的，能给我讲一下吗？”<br>
+我：开始飘飘然地讲起来………</p>
+
+
+你可以想想，如果一场面试中，大部分时间都是面试官自己在说，那是我们面试别人还是别人面试我们呢？其次，当面试官在炫技的时候，其实很难判断候选人是不是“对的人”，因为我们只是在考虑自己。这不但偏离了招人目标，而且还白白耗费了时间和精力。
+
+那么正确做法是什么呢？很简单，做任何事情我们都要明确目的。公司安排面试，是希望经理去尽量客观地了解应聘人员的情况，所以我们应该把精力花在**挖掘候选人的信息**上。
+
+面试官才是把握时间和控制局面的那个人。面试不是去证明自己比应聘的人厉害。如果候选人总是“带节奏”反问的话，我们完全可以直接跟他说，现在不方便解答。
+
+如果已经判定这个候选人不行，那就换个简单的问题交流一下，让候选人感觉好一点，然后送他离开；或者让他问两个问题，借机宣传一下我们所在的公司，再送他离开。切记不要说什么“你怎么这么简单的问题都不懂”这一类的话。
+
+## 2.不要总问是非问题
+
+刚才我们明确了招人时不能自己盲目炫技，而是要更多地收集候选人的信息。这个收集信息的过程，其实就是通过向候选人提问，并根据他们的回答来做判断的过程。那问出好的问题就很重要了。但是很多人在面试时都会犯一些基础的错误，比如总问是非题，而不是开放式问题。
+
+我前面举的那个“让候选人介绍什么叫做CAP”的问题，本质上其实就是“是非问题”，也就是说，问题答案不是“Yes”就是“No”。我们通过这样的问题得到的信息量非常少，那怎样提问才能获取更多的信息量呢？
+
+这就是我们接下来要讲的——追问细节。通过这个方法，我们可以考察候选人的逻辑能力。具体怎么操作呢？
+
+举个例子，当我们查看候选人简历时，发现里面提到候选人有分布式系统的经验。这时候，我们就可以让候选人给我们讲一下，这个分布式系统设计实施过程中碰到的实际问题，问候选人是如何考虑系统一致性问题，又是如何看待系统可用性问题的。比如我经常会提出的问题有这些：
+
+- 如果我现在还希望有分区容错呢？怎么实现？
+- 硬件失效系统行为如何，网络延迟增加系统行为如何？
+- 你怎么做监控呢？
+
+我们可以这样一步步地去深挖，追问上线后候选人可能会碰到了哪些具体的问题，并要求他给出细节，看他是怎么解决的。
+
+整个过程需要我们精神高度集中，因为这是在考察候选人的思维逻辑是否清晰，也就是看他是否能够把一件很复杂的事情理得很清楚。
+
+要注意，只要抓住细节，我们就不容易跳坑了。如果这个项目是候选人亲自做的，他一般都能说出具体的实例，比如他踩过的坑、吃过的亏，有些人甚至能说出准确的系统吞吐量、可用性指标等具体数字。
+
+有些候选人表面上看起来逻辑清晰，他会说：“这个问题分三个方面，第一，第二，第三……”
+
+我们可不要被这样的形式所迷惑，而是应该关注回答的内容，是不是真的符合逻辑。说不定他只是用了这个“第一、第二、第三”这样的叙事框架，但内容上却答非所问。
+
+## 3.忽略了耐受性问题
+
+在面试中，如果候选人在面临高压时不能保持思路清晰，不能顶着压力坚持不轻易放弃任何一个题目，那多半他在实际的工作中抗压能力也好不到哪里去。
+
+面试时，我们可以用一些递进式的提问方法，从各个角度去考察候选人的思路，给他压力（比如限制时间、增加需求条件等等），看看他的反应和思路。
+
+那我们怎么给面试者营造高压氛围呢？我给你举一个具体例子。
+
+比如我们要考察候选人的系统设计水平，就可以要求他设计一个分布式的作业系统。不需要候选人用什么Kafka、Zookeeper、Kubernetes 这些时髦名词，我们就让候选人用最基础的、从无到有的方法讲他会怎么设计这个系统，然后再根据他的回答往下问一堆问题：
+
+- **算法优化**：你现在的实施算法需要遍历两个循环，有没有办法做到一个循环出结果？
+- **边界测试**：现在你给我写一下测试用例，怎么把你的系统搞死？
+- **监控运维**：系统上线了，你有你的客户，还有你的依赖，如果客户现在到你老板那里投诉你，说系统不稳定，你怎么办？你觉得需要在这个系统里做哪些监控？
+- **服务降级**：如果你的依赖挂了，你会怎么办？你的依赖没有死彻底，但是性能下降了，你怎么办？
+
+有些候选人在时间到了以后还坚持说：“再给我五分钟”。我们能感受到他的坚持，感受到他正在全力整理思路。
+
+如果是我，虽然会拒绝给他加时机会，但却会给他留个微信联系方式。如果对方能够在面试结束以后，主动把面试里没有回答得很好的题目重新答好发给我，我一般会再给他一次机会。
+
+这个机会可能是直接给一个项目，限期一个礼拜把代码提交到GitHub上，然后请他来公司跟我们做Code Review。你也可以这样试试，说不定能获得一个意愿和能力都很合适的员工。
+
+如果候选人真的很在乎这个岗位，他一定会接这个题目，我曾经有一次花两个多小时跟候选人做Code Review，做完以后我对他的能力基本就清楚了。而且通过这个交互过程，他对这个岗位也会有一个更了解得更清楚。当然，这样做也有缺点，就是投入很大，我们的机会只会给那些我们觉得很有潜力的候选人。
+
+总结一下，其实我们怎么走出总问非问题和忽略耐受性这两个误区呢？
+
+**其实有相通的解决方法，使用递进的提问方法全面考察候选人，期间观察他的逻辑是否清晰，有没有细节和具体实例。同时，还要关注对方是不是能在压力下够坚持，不轻易放弃。**
+
+## 4.不要泛泛而问
+
+前面是具体问问题的误区，其实还有对候选人履历没做深挖的误区。问十个项目，但是每一个项目只是浅尝辄止，还不如盯着一个项目，把祖宗十八代都刨根问底效果好。围绕一个项目，你可以这样问：
+
+- 挑一个你最最满意的项目来跟我讲一下吧？
+- 你们为什么要做这个项目？
+- 你在这个项目中具体起了什么作用？碰到哪些具体的困难？
+- 如果再让你做一遍，你会有哪些不一样？
+- 你从这个项目里学习到的东西，有在后续的项目中实践过的例子可以分享一下吗？
+
+真正自己做过的事情，候选人的回答一定会有细节，而不只是说一些笼统的原则。
+
+> 
+<p>我：“你为什么想离开原来的公司？”<br>
+候选人：“我不大认可现在公司做的事情的意义，我还觉得我的领导做的是更上级领导希望看到的工作，而不是真正对公司有意义的工作”。</p>
+
+
+**这个时候<strong><strong>我们**</strong>千万不要停下来，随意换下一个方向去问，而要盯住这个点深挖</strong>：“可以分享一个具体的例子吗？”“你觉得你的老板是一个什么样的人，他为什么会做出这样的决定？”
+
+面试官精神一定要高度集中，因为只有精神高度集中，我们才能抓到这些要深挖的契机，并提醒自己从那里切入。**对于敏感问题不要不好意思问，不要回避，深入进去。**
+
+那我们要怎么沿着候选人的回答，追问更深入的问题呢？你可以从下面几个角度入手。
+
+- **量化结果**：候选人说提高很多，到底多多少；做得很好，到底什么叫好；受到肯定，具体有哪些肯定；产生效益，到底产生了多大的效益。
+- **询问例证**：候选人说一个观点，面试官不要直接就默认了，可以请他举自己身上的例子说明。想进一步了解的话，让他再举一个例子。还可以让他把自己对这个例子的总结、反思过程讲出来。
+- **追问原因**：多问为什么。对于候选人的决定，无论是技术决定还是非技术决定，都要深挖原因。
+- **考察提升意愿**：同样一件事，候选人回头复盘时，会不会考虑自己能不能做得更好？具体怎么做更好呢？
+
+我们通过这些角度切入，就能有效地深入了解候选人的情况，更全面地评估他是否符合公司、团队的期待。
+
+## 5.不要只关注技术能力
+
+很多技术出身的经理，面试时可能更多关注候选人的技术能力。原因是技术容易判定，但人性、协作能力这些软实力是很难挖掘的，也正因为难以挖掘，很多人都忽略了这个问题。
+
+那软实力要怎么挖掘呢？我们可以从背景调查和候选人面试时表现出来的逻辑冲突点分析。
+
+我曾经面试过一个人，觉得这个候选人很好，技术扎实、很有主见、超级自信，而且当时所有在场的面试官都给他评了“优”。
+
+但后来做面试总结时却发现了一个问题：这个候选人很强，但是在回答他在原公司的职业发展细节时，却闪烁其辞。这是为什么呢？
+
+后来，我们通过背调才发现这个人的团队协作能力很差，在原公司跟很多人发生过冲突。而这些在面试时都是看不出来的，因为这类问题往往要在激烈冲突时才能暴露出来，而面试中候选人都比较理性克制。
+
+除了背调，我们还有什么判断方法呢？就是找逻辑冲突点，下面的例子就用了这个思路。
+
+有个候选人的教育背景、动手能力都不错，可当他回答为什么选择离开原公司时，完全归因到了原公司待人不公，并给出一些细节做证明，却对自己是否有问题绝口不提。
+
+作为面试的一方，我们并不清楚对方的原公司是否真的有问题，所以面试时我们就根据这样一个逻辑冲突点去引导他进行责任分析。最终发现他在分析责任的时候，会习惯性地把责任归因到别人身上，却缺少对自身的反省。
+
+这种情况很常见，我们要给自己提个醒，候选人口中说的一切（对于原公司和原公司老板的描述）只是候选人的理解，并不代表事实。
+
+不知道你注意到了没有，抓到冲突的关键是我们要对细节高度敏感，发现问题的逻辑矛盾点。比如一个人这么优秀，那他为什么没有在原公司得到重用呢？
+
+这里我想提醒一下，要不要录用协作能力有问题、或者看问题不客观的候选人呢？我们虽然要抱有一定的开放性，但一定要谨慎，绝不能过于乐观。
+
+比如刚刚这个案例中的候选人，他把责任完全推给原公司领导“有眼无珠，待人不公”，我们作为面试官，可不要自我感觉良好，觉得自己就一定比候选人原公司的领导厉害，别人驾驭不住的人我可以驾驭，别人拗姿势拗不过来的人我就能拗过来。
+
+我的建议是一定要谨慎，你可以再问问他对他上上家公司领导的评价，如果他觉得两任领导都不行，那哪怕这个候选人的技术很不错，我也偏向于不招。
+
+**责任归因是常用的软实力考察方法。很多事情都不是那么黑白分明，一般双方都有责任，哪怕自己真的一点责任也没有，优秀的人也会主动反思，会内省。一个人一旦停止从自身发掘问题，他自我提高的过程也就停止了。**
+
+从另一个角度看，如果他说一件事做得非常好，那他会把成功全部归为自己，还是能想到别人的支持呢？其实有错从自己身上先找原因，有成绩也能想到别人的思想，不单适用于候选人，对面试官自己的日常工作也同样适用。
+
+具体操作时，我们可以让候选人列举一些项目失败的例子，或者是候选人经历过的一些逆境，让候选人分析反思。这是为了判断候选人的态度是积极正向的，还是悲观负面的；他是把责任都归咎于外因，还是会主动向内找寻自身的问题。如果老是归责给别人，我们就要小心了。
+
+在面试的全过程，作为面试官我们的精神要高度集中，去观察候选人回答问题时的表情、神态等细节，比如说是自信真诚还是闪烁犹豫。这样就能更好地判断候选人的回答是否为真，有没有夸张。
+
+万事都有因缘，多一个心，至少可以和对方核实一下。**如果核实不了，宁愿不招，也不要因为当前的项目压力就去招聘一个我们存有疑问的候选人。**
+
+## 总结
+
+好了，今天的内容讲完了，我们来总结一下。
+
+招人是组建团队第一步，极其重要，一定要花大力气去做。而经理人在招人容易犯错，本质上都是对候选人的情报没有做全面、细致的收集。要想避免在招人时犯错，就得从简单的方法开始做起，具体怎么做呢？
+
+首先，不要向候选人炫技，要始终牢记面试是尽力挖掘候选人的信息，以便做出客观评价，而不是去满足面试官的虚荣心。
+
+接下来，不要总问是非问题，而是要通过递进的提问来获取细节和具体案例。我们还可以用限时和增加条件的方法，验证候选人的抗压能力。
+
+而且，面试过程中我们需要精神高度集中，才能找准深挖的切入点。我们要“刨根问底”，围绕一个点做系统了解，远比浅尝辄止的效率高。
+
+另外，虽然人性、协作能力这类软实力很难挖掘，但也不能忽略，我们从技术和待人处事多方面切入，才能降低误判概率。在软实力挖掘上，一是可以通过背景调查做挖掘；二是从候选人面试时表现出的逻辑冲突点入手。
+
+总之，想招对人是这样一个思路：以了解候选人情况为目标，通过递进提问、压力测试和深挖项目这三个方向做全面考察，关注技术能力之外也要留心候选人的软实力。做好这些，我们基本上就能招到水平还不错的人了。
+
+## 思考题
+
+在招聘任务比较急、时间比较紧的情况下，如果你在面试过程中犹豫了，哪怕只是直觉上觉得吃不准，你会怎么办？如果候选人是应聘关键岗位的高级别人才，你又会怎么办？
+
+欢迎在留言区晒出你的经历和疑问。如果有收获，也欢迎你把这篇文章分享给你的朋友。

极客时间专栏/geek/技术管理案例课/一线经理：开始带员工了/09 | 人才培养：御人也是育人，人才培养的5个维度.md

@@ -0,0 +1,159 @@
+<audio id="audio" title="09 | 人才培养：御人也是育人，人才培养的5个维度" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a1/68/a17dde939699f9c165c65acf75911e68.mp3"></audio>
+
+你好，我是许健。今天我们来谈谈“如何培养人”。
+
+我的老板说：“管理的本质跟教育是一样的。”这句话放在四五年前我还没有理解，现在却越发觉得有道理。我在女儿出生后，也看了不少育儿的书，发现教育的思路和培养员工的思路是相通的。
+
+我们带领着一个团队，不仅仅是为了把事情做成、交付业务价值，更重要的是要帮助团队成员提高能力，让他们过得更好。即使他们有一天离开这一家公司，我们不再是他们的领导，他们也会因为我们的存在而成为更好的自己。从这个角度看，我们作为经理，就是要给员工赋能。
+
+那我们该如何给员工赋能呢？我们可以参考自己的成长经验，提取思路，也可以借鉴其他人的方法。接下来我们就从五个维度，一起来梳理怎么做好人才培养这件事儿。
+
+## 1.积极主动，态度先行
+
+刚工作的时候，我一直觉得自己技术不错，但是却不受领导重用。直到工作两年以后，偶然看到一本《动物职场进化手册》，才让我开始思考应该做一名什么样的员工。
+
+曾经有高级别员工指导我，让我要“拔高层级”看问题，才能更好地和领导对齐思路。我开始意识到，考虑问题的时候应该从领导的角度、从组织的角度来看，而不是单单从自己的角度来看。当我转换了思考问题的角度后，我明显感觉到领导对我的态度有了改变。
+
+多年后我成为了一名经理，我对自己更加需要什么样的人才有了更清楚的认识：“优秀的员工不是坐等领导安排工作，而是会主动去发现问题，去理清问题，他会跟领导说这个问题我考虑过很多种解决方案，优劣的分析结果在这里，我觉得应该选方案X， 原因是ABC。”
+
+如果问题的解决已经超越这名员工的权限范围，他会清楚地告诉我需要帮忙解决哪些问题。我们想想看，这样的员工，他具备的本质特性是什么呢？如果用一个关键词来概括，就是积极主动性。
+
+那怎么衡量员工的积极主动性呢？我们可以借用《别让猴子跳到我背上》的书里提到的“安肯自由度量表”做判断，这是一个用来衡量员工自由度的工具。
+
+<img src="https://static001.geekbang.org/resource/image/d5/4a/d551e2ac962f503841ea1ddacd4fac4a.jpeg" alt="">
+
+你会发现第一层、第二层的员工占用经理的时间更多，而越高层级的员工其实会得到主管更多授权，同时占用经理的时间更少。
+
+落到具体的工作里，经理可以这样考量部下的积极主动性：
+
+- 小S负责跟总部做新的流量管理系统集成，他是等着总部催进度还是会主动汇报进度？虽然在内部技术评估会议上，我们已经明确了新的流量管理需要保证10个典型客户场景不会出问题，但他是否需要等我去催，才会给我一个时间点，拿出针对这10个场景的具体书面分析报告呢？
+- 小沈在做一个模版系统，总架构说总部也出了一个方案，于是我让小沈找总部的工程师聊一下。那小沈谈完会主动找我做分析吗？还是他在等我去找他？
+- 老王在做一个高风险的自动化项目，我不去找他的话，他会不会主动找我分析项目风险并讨论对策？要知道这事情我心里一直在惦记着。
+
+员工的积极主动性很重要，作为经理人，学会怎样激发大家的积极主动性更重要。具体可以分三步走。
+
+**第一步，明确标准，告知期待。**经理应该明确地告诉员工，自己对他们积极主动性的期待，包括内容和程度两个维度的期待。
+
+**第二步，赏罚分明，落地要求。**提供对员工积极主动性的激励（如态度上的认可、口头表扬、和绩效挂钩等等）或惩罚措施。积极主动不是一蹴而就的，而是习惯的养成。员工距离我们的标准接近了一些，就可以给出适当的反馈，鼓励他们向这个方向前进。
+
+**第三步，循序渐进，带头提升。**经理作为团队的带头人，自己做事儿就要注意积极主动性，这样才能促进团队形成积极主动的氛围。比如，经理也要主动约自己的上级做工作汇报，甚至可以主动询问领导有什么烦心事儿。拿我自己来说，像两个组同时做流量管理的问题，还有未来平台安全的里程碑定义和组织配套……这些问题都来源于我向领导主动询问，才慢慢明晰。
+
+## 2.实战积累为主
+
+不知道你看没看过《亮剑》这部电视剧。我觉得李云龙这样在实战中摸爬滚打积累的经验是非常关键的。李云龙是先打仗，后上的军事院校，而不是反过来。
+
+工作中也一样，前面我们聊过了如何提高员工积极主动性，解决了工作意愿的问题。态度问题解决了，技能不达标就是白搭。所以怎么解决技能（工作能力）的问题呢？
+
+我们很容易想到的就是先解决技术原理问题，我之前的学习方法一直就是先彻底搞清楚理论，再动手。我学C++，先买一本《 C++ Primer》来啃；学Linux，就去上一个RHCE 培训班。
+
+那这种方法有什么问题呢？我发现当时花了很多时间，但只是纸上谈兵，没产生什么实际效果。
+
+后来在交付时间的压力下，我才意识到，不结合实际需求去真实的战场上锻炼，提高就很慢。所以必须先动手，一边干一边学。学React ，自己去拿一个项目练练手，先学会怎么用再去查资料搞清楚原理。遇到问题别有畏难情绪，因为遇到问题是提升能力的起点。最好在学的过程中多碰到点问题，在排查的过程中自己的动手能力就上去了。
+
+我们部门曾讨论过新员工如何培养这个问题，还做了投票表决。结果在众多选项中，得票率最高的就是“放到一线去锻炼”：
+
+- 去一线做产品的客户服务，这样能让新员工更了解产品，还能积累基础问题的解决能力。
+- 让新员工完成难度适中的Bug Fixing任务，或者做外围管理监控系统的增强，都能让他真切了解系统的内部实现。这样还能让新人亲手走一遍开发流程——比如Code Review、测试、发布流程。
+
+但在实战积累方面，有一点是需要我们注意的，那就是要**控制压力**。曾经有一个新毕业的学生被我们放到一线，每天都在经历信息轰炸，除了要学习云计算的系统知识，熟悉一大堆公司内部的名词和系统之外，他还要做客服和生产环境应急事故处理。
+
+一系列的任务给他造成了很大的精神压力，因为他觉得自己的精力投入和实际能力的提高根本不成正比。久而久之，他甚至出现了失眠的情况。
+
+这件事让我意识到经理必须去控制压力，对于这种情况可以做两方面的调整：一方面，实战训练外必须配合定期谈心，了解新员工的实际困难，帮忙疏通精神压力。另一方面，就是要安排专门的师傅带新人，而且要让师傅的业绩和徒弟成长挂钩。
+
+之所以这么做，是因为我自己还是新员工的时候，碰到了一个很好的同事，我的网络知识基本上都是他教的。我问他什么叫组播，他把单播、组播、广播、任意播全部都给我讲了一遍，这样还不够，还要给我演示来帮助我实际操作。
+
+我也见过新人向同事提问，被问到的人却像挤牙膏一样地传授知识，或者面露鄙夷：“这个你都不懂！”这种情况如果总是出现，时间一久，新员工就会对请教问题本身产生抗拒。所以，我现在会跟团队明确要求，不要让我看到“挤牙膏”现象的存在。
+
+但即使我们这样强调了，团队里还是会出现新员工不愿意主动请教的情况，这些都需要经理去了解问题出在哪里，并且及时解决。做得好的，我们要当面表扬。要是发现问题，不管被请教的老员工是多高的级别，都要纠正。
+
+如果是理念不同导致矛盾，这个时候我们可以开谈心会沟通。员工培养关乎我们团队的未来，这些年轻员工不起来，我们团队的发展后劲就会不足，所以从领导到高级别员工都必须重视员工的培养，并且要愿意花时间、花精力在年轻人身上。
+
+## 3.提高软实力
+
+除了技术动手能力，一个人要成长还有其他方面的考量，我们公司经常要跟总部一起做设计审核。新员工做的设计常常会被打回来，备受挫折。很多时候备受挫折并不是技术原因导致的，而是员工软实力不足。
+
+软实力具体可以从这些角度思考：你自己的逻辑够不够强？说服力如何？讲话气场够不够？碰到高级别领导能否有理有据坚持自己？
+
+你可能要问了，这些问题都好难啊，怎么提高啊？一个字，练！
+
+比如做系统设计，我们都是要去跟总部领导做设计审核的，虽然可以客客气气地在内部先做一次Review，但是不能暴露员工临场高压下反应不足，面对技术领导不敢直言辩论的问题。
+
+所以，经理和技术骨干要跟员工做真实工作的情境模拟。虽说是模拟，其实跟真的一模一样，区别就是没有总部领导在，这里的目的不是检查员工的技术能力，而是通过模拟来锻炼他的思维、逻辑和表达等软实力。
+
+怎么模拟呢，我举个具体案例来说明。我们监控组为提高安全性，要对客户使用的监控系统加上权限管理流程。下面是真实模拟中的一些问话：
+
+- **检验员工有没有极简思维**。这个客户Onboard为什么要客户发申请，默认给客户权限不行吗？我们要同时从技术和用户体验极简两方面考虑，沿着这个思路我们再想想在客户体验和技术复杂度上要怎么做权衡。
+- **考察员工逻辑是否清晰**。这里多了一个校验真的能够更安全吗？我们来理一下思路，什么时候会出现校验失败呢？如果现在实际的场景都是校验成功，而我们为了这个永远成功的校验，却要客户多输入额外的参数，这里的逻辑是不是存在问题呢？
+
+事后，我问了这些同学对于模拟的反馈，他们都说很好。但是跟他们关系很近的人给我的反馈却是：跟我模拟这些，这些同学压力很大，希望我以后要多给一些鼓励。
+
+根据这样的反馈，我注意到除了模拟高压场景，最后还是要给一些鼓励。比如经理可以鼓励员工对领导直抒己见，关于这点，这里有一个具体的例子：
+
+我和小D完成系统设计审核的演练后，我让小D就当前的工作安排反驳我，并和他说如果做到会给他加分。小D有点急了，憋了半天说：“许总，你老盯着我去跟总部的工程师死磕Onboard体验，但我当前最重要的事情是定系统Schema，我现在需要专注，你这样要求我最后可能两件事都做不好。”
+
+这个回答有点惊到我了，虽然他没有反驳我的技术决策逻辑，但他说出了我要求他同时搞两件事的风险，而且他说的也是有道理的。通过这样的锻炼，我希望他以后跟领导讲话自信心强一些。后来小D把自己对这个项目不满意的点，写了一个长总结，我还分享给了副总，副总看完也认可了。
+
+还有就是Mentor（导师）机制。这里的Mentor 跟我前面谈的师傅是不一样的。我入职eBay以后，我的老板就给我找过导师，而且这个导师一般会由不在同一个汇报线上的高级别员工担任。
+
+为啥找不在同一个汇报线上的人呢？因为，这样能让被培养人讲话时减少一些负担。资深高级别员工可以给出建设性意见，很多都是这些导师多年经验所得。“拔高两个汇报级别考虑问题”，“组织内的很多问题本质上都是信任问题”，这些金玉良言都是我当年的Mentor跟我说的，让我受益匪浅。
+
+## 4.给员工提供专注的机会
+
+不管是什么级别的员工，想构建自己的核心竞争力都需要积累，而想要不断积累，必须要有专注作为保障。有一本叫《异类》的书提出成为专家要投入一万小时，还有一本《刻意练习》提过，要有效的投入而不是纯粹重复。其实两本书都是在强调专注的重要性。
+
+我觉得人在同一个时间点只能专注一件事，什么叫专注？就是我们的心思都在这个事情上面，但凡有空余精力就都在思考这个事情。一个人什么事儿都做但方向上总是换来换去，和他在某一方向上专注发展三年不换方向，明显是后一个情况他更有可能成为所选方向上的专家。
+
+我这里有一个反例，这个例子也是我自己觉得有愧于老T的地方。老T是我们部门的高级别人才，思路清晰，人又有担当，是我在有困难搞不定时会想到的人。
+
+最近三年，我先是在项目A快垮了的时候找他出山。花了一年，项目A才转危为安。后来我又因为支付问题和很多业务开发抱怨防火墙影响上线效率，找他解决防火墙自动化的问题。期间还有关于PaaS，Cloud UX，Traffic Rebalancing的问题……诸事不决，我总会找他。
+
+但是这一切导致了老T精力被分散，没有办法在某一个方向上做长期积累，提高自己技术竞争优势，老T曾跟我说过他觉得自己的知识输出大于输入。
+
+而反观老J， 一直在监控耕耘。后因为要搞AIOps，所以在业务指标异常检测这个方向上继续深耕，从零开始持续投入近三年时间，最近他的文章还被AI顶会接受。
+
+我上个月做反思，发现身为经理我做得不够好，没有给老T留出一个让他专注提升的空间。我不但应该抑制自己遇事动不动找老T帮忙的冲动，还应该把让老T分心的非核心事务给砍了，不让老T分散注意力。我后来跟老T商量，明确了他主攻“平台安全”这个方向，并约定说无论如何我们都会坚持这个方向至少三年。
+
+安全方面是需要长期积累的，老T现在会有针对性地去学习Web安全，跟公司安全部门谈合作，把安全审核流程集成到软件开发流程中，自己负责云计算SSO（单点登录）的事情。对组织领导来说也已经明确了老T的方向，所以会主动帮他在这个安全方向上寻找机会，构建他的支撑结构。我也为老T有这样的发展而感到高兴。
+
+## 5.把握“挫折”的度
+
+最重要的这点放在最后这里说。经历挫折是促使自己成长最快最有效的方式。
+
+我前面讲到，管理的本质跟教育是一样的。做父母的都知道，孩子学走路摔两跤是必须的，学游泳喝两口水才学得快。就连学习专栏也是同样的道理，你读十遍都不如你去吃一遍苦，经历一些难相处的人、困难的事提高才快。
+
+经历挫折不难，难的是度的把握。做父母的可以接受孩子摔两跤，但是肯定不希望骨折和意外。做经理的可以接受一两件事情没有做成，但是不希望员工的自信给打击没了。
+
+小沈从传统行业加入互联网行业，一年不到，他提出离职，我问他：“你我认识这么多年，你就这样放弃了吗？你现在放弃之前的苦就白受了，小沈，你相信我再坚持一下，你一定行的。”
+
+小沈却回答说，他太压抑了，哪怕知道我说的都是对的，却觉得自己让我失望了。他在这时已经受不了了，只想早点解脱。
+
+这件事就是做经理的只专注了锻炼而没有关注心理建设，小沈需要的是更多的关心和有经验的人切实与及时的指导。我当时的问题是直到他扛不住了才去鼓励，太晚了。
+
+后来我从管理一个十多人的团队，直接升级成管理五十人的团队，我当时搞砸了，甚至一度撑不住想退出，所幸后来坚持下来了。自己遇到这样的挫折，再回过头反思小沈那件事，我才发现小沈为什么扛不住这件事儿，其实本质上是做经理的没有把握好挫折的度。
+
+到底怎么掌握度呢？我见过两种方法。一种中规中矩，逐步提高难度。切忌把人扔进火坑自生自灭。另一种是压一压被培养人的耐受性，评估他的心理承受力在哪个点上。这种方法跳过了之前的逐步提高阶段，就跟孩子入学后的摸底考试一样。
+
+具体操作时无论用哪一种方式，都要保持跟被培养人的频繁沟通（1:1、散步、吃饭），不要让他的自信心垮了，他可以吃苦，但是经理要不停地表现出对他的信任，并且还能在他跨不过去的时候拉他一把。
+
+经历挫折和授权是有关系的，做家长的老是护着孩子担心这担心那，你的孩子老也长不大。做经理的不愿意授权，担心这个做不好，那个不完美，员工就永远也成长不起来。对于高级别员工，经理特别要坚持高要求，但是要把具体实施留给员工自己做。
+
+老板就曾给过我这样的反馈，说我激情有余，拉着一帮兄弟一起冲锋，但是我对部下的要求其实不高。而且我对细节的关注也不足，很少针对具体的细节，指出部下做得不好的地方，导致我们部门的员工很少经历挫折，即使没有达到更高目标也很少被经理提醒，于是成长速度有限。
+
+## 总结
+
+人才培养是组织的重中之重，这么重要的事情当然要一把手亲自抓。我们先要认清自己肩上的责任，管理不单单是御人，还是育人，一字之差，后面这个“培养教育”的格局高很多。
+
+从我自己的成长之路总结，我认识到：员工要成长进步，首先要有自己的主动性，这是内驱；然后去实战锻炼，理论辅助；除了技术之外的人情世故、逻辑、影响力也要锻炼，这里要讲究实用，相信真实模拟的效果；人不是神不是计算机，不要多线程，就是要独占CPU，做一些艰难取舍来专注一个方向发展。
+
+相应地，作为经理，我们要给员工创造能够专注发展的空间。捷径无他，天将降大任于斯人也，必先苦其心志，劳其筋骨，方能增益其所不能。
+
+最后请记住，作为经理人我们要对自己说，我可以承认我有差距，但我绝不怀疑自己有能力赶上。培养员工，我们要让员工足够强，强到他随时可以离开；对员工又要足够好，好到让他选择留下来。
+
+## 思考题
+
+你团队里的员工按照能力分有顶级，中等，垫底三类。你在这三类员工中如何分配你的时间？
+
+管理的本质跟教育是一样的，回顾你自从有记忆开始到现在的经历，找回那些促使你成长的关键时刻，想一想怎么复制这些时刻？
+
+欢迎在留言区晒出你的经历和疑问。如果有收获，也欢迎你把这篇文章分享给你的朋友。

极客时间专栏/geek/技术管理案例课/一线经理：开始带员工了/10 | 裁人：“心要慈、刀要快”，做好裁人这件事.md

@@ -0,0 +1,154 @@
+<audio id="audio" title="10 | 裁人：“心要慈、刀要快”，做好裁人这件事" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/94/67/9440a3b2151a0e412725a0ca46131c67.mp3"></audio>
+
+你好，我是许健。今天我想和你谈谈“裁人”这个沉重的话题。
+
+“裁人”这道坎儿对于一个经理来说，是必须过的一道关。甚至可以说，**一个裁过人的经理，才算是真正“毕业”的经理。**
+
+经理需要在哪些情况下裁人呢？公司业绩有起伏，不得不启动末位淘汰；经理招人也很难做到从不走眼，招进来的人的确不适合；经理要促进组织转型或者推进项目，但是有的人思想跟不上这个步伐，成为团队发展的阻力。
+
+经理想把裁人的决定真正落实下去，其实很难。为什么我们觉得难呢，无非是因为这三点：下不了裁员的狠心，不能直面被裁的员工，以及觉得自己做了一件对被裁员工很不好的事情。
+
+所以，我们要通过心理建设下定决心，做好裁人的操作准备给自己增加底气，通过恰当的沟通协调把裁员的负面影响降到最低。
+
+## 裁人的心理建设
+
+我为什么要先和你谈心理建设呢？要知道裁人不单单对于被裁员工心情影响很大，对做这个决定的经理来说，心理压力也很大。如果经理不把心理建设做好，就很难下定决心“落刀”。
+
+那我们怎么做心理建设呢？这里有两种思路，第一种是站在组织整体效率的视角思考，第二种是从被裁员工的视角思考。
+
+**1.裁人的共性原因：影响了组织整体效率**
+
+我们来思考一下经理为什么要裁员，换句话说，通常发生什么状况，才会让经理做裁员决定呢？我给你列几种典型情况：
+
+- 员工能力不行，不能完成任务，并且也看不到提高的希望了。如果不裁掉他，他完不成的工作就需要能力更强的员工做，这样很有可能导致能力强的员工有想法。
+- 员工情商太差，在待人处事上有严重缺陷，并且规劝无效。如果不裁掉他，团队的整体协作会受到影响，甚至导致优秀员工离职。
+- 经理对组织有更高的目标和追求，没有额外的招聘预算，只能采取末位淘汰来做组织升级。如果经理不裁人，就无法去招更优秀的人，团队就没法完成更高的目标。也就是说，不裁人危害到组织发展了，业绩拿不出来，受影响的是整个团队。
+
+那前面列出的这些情况有什么共性呢？没错，这些情况最终都指向了同一个终点：如果不裁人，就会影响整个组织的效率。
+
+说到这里，我们会发现，裁人这个决定虽然很痛苦，但对于组织发展来说却是有利的。我们作为经理，有责任也必须下决心做这个决定。如果不做这个决定，经理就需要承担更加严重的后果，开始只是连累团队其他人、长远来看甚至影响组织发展。
+
+所以，两害相权取其轻，其实我们是在做一个对团队，对团队其他成员的成长更有利的正确选择。
+
+**2.对于被裁员工，离开也不完全是件坏事**
+
+有一个很重要的心理建设视角，常常被我们忽视。那就是对被裁员工来说，他离开了真的是一件坏事么？我们想想，那些准备裁撤的员工过得开心吗？他能轮到末位淘汰，他的经理、同事平时不会流露出对他能力的质疑吗？！答案是会的，所以多数情况下他每天上班的心情也不好。
+
+另外，面对种种压力，这些末位的员工生活质量也不会高。如果他换一个更适合他的地方，说不定他的业绩会变好，他每天的心情也会更好，反而是成全了他。这个心理建设本质上要强调的是经理要对被裁者抱有同理心。
+
+说到这个同理心，其实更多的是帮助经理对自己的裁人决定释怀。要知道，对于经理来说，决定裁人的过程是漫长且痛苦的，尤其是裁掉团队里比较资深的员工，我们来看一个例子：
+
+V刚从一名技术骨干转做经理，接手了一个新团队，但却遇到了一个棘手的问题。
+
+情况是这样的，这两名同学级别都很高，A同学算是勤恳，但才不配位。B同学跟不上团队转型的步伐，承担的工作无论是难度还是工作量还不如级别更低的人，也不愿意承担更多责任。
+
+对V来说，这样的团队配置他并不满意。A同学还能管得住，但B同学他就驾驭不住了。团队本来就不大，最资深的两个人都不能用。这个问题不解决，影响的是团队整体的积极性。比如团队里资历较浅但更有干劲和潜力的同学，就会觉得公司待人不公，明明他们做出更多贡献，但待遇级别都比不过A和B。
+
+V也做过努力，先是和两个同学沟通、协商具体的提高方案，前前后后花了一年时间，但是一直没能达到期望。在公司业绩疲软，很可能裁完人也没法补人的情况下，V还是决定裁掉这两个人，我在心里给他竖了大拇指。
+
+最后，V还和我分享了他是怎么释怀的：与其让这两名同学在舒适区呆到最后，再出去已经很难找到工作，还不如在这两名同学还有能力的时候让他们认清现实。
+
+我回顾上面这件事，能总结出2点：
+
+- 如果我们觉得再不裁人已经开始影响团队整体公平了，就应该果断采取措施。哪怕付出沉重代价（比如消耗大量时间做裁员准备，拖慢交付进度，损失人手）也在所不惜。哪有轻轻松松就能提高团队效率的事情呢？
+- 裁人前做最大努力去争取，如果还是达不到预期经理就要敢于决断。裁人纠结很久，真正做了决定也就做了。
+
+## 裁人的操作准备
+
+HR有一句话，叫招人要慢，裁人要快。这个“快”可不是经理觉得一个人业绩不行，就马上把他裁掉，而是说我们要在保密的情况下做充分的准备工作，公开之后就尽快完成，以减少这个人离职对组织和周边员工的影响。
+
+做了裁人决定后，我们需要做哪些工作呢，我们可以从提前铺垫、评估影响和获取上级领导支持三个维度思考。
+
+**1.提前传递业绩不满意的信息**
+
+无论是业绩考评还是裁员，最忌讳让人意外。我这里说的意外，不是说经理没能提前跟被裁的同学说你要裁掉他，而是没有提前铺垫，就是事先没有传递过不满意的信息就去裁员。
+
+那怎么做这个铺垫呢？经理对被裁同学现在的业绩表现是不满意的，而且就这个问题我们应该和这个同学做多次沟通。沟通的目的是让他明确经理的期待，比如这位同学工作不积极主动，代码质量也很差，我们就可以像这样给他提要求：
+
+我希望你做工作的时候会主动拿出整个项目的时间表，把所有的场景预想一遍，列出每一个场景下你的代码逻辑是什么样的，我不希望再看到你被别人追着要进度的情况。提交的代码必须有单元测试，并且做失效性分析。
+
+你看，相比泛泛去讲却不给建设性意见，经理这样做要求更明确，因为我们的要求是落到具体场景上的。
+
+那如果谈完以后还是不见效，我们就只能采用更加直接的沟通方式，直接点明后果。比如说，我觉得你在跟客户还有跟同事沟通的时候使用情绪化用词，甚至针对人做负面评价，这样不合适。**我不希望看到第二次，如果再出现，我不得不让你离开公司。**
+
+**2.裁人前的评估与安排**
+
+如果提前铺垫，多次沟通仍不见效，我们就要未雨绸缪，开始做裁人的影响评估了，我们可以从事和人两个方面来评估。
+
+首先是从事情上评估，目的是避免裁人影响到团队的工作。换句话说，就是经理要提前预想好，怎么安排被裁员工手上的工作？谁可以分担？
+
+我们可以根据工作的难度和性质去考虑如何做安排：
+
+- 被裁员工的工作没什么难度。这是最简单的情况，他的工作很容易被其他人分担，经理只需要直接让其他员工接手。
+- 被裁员工的工作有一定难度，其他员工想接手还需要专门的培训。有些工作只有被裁员工才了解细节，但对团队的业务也很关键。这种情况经理必须提前做准备，甚至有时准备期长达一年。怎么准备呢？经理可以安排其他员工加入协作，来分担被裁员工的工作量。
+- 被裁员工的工作找不到人来接。比如因为系统太老没有人愿意来接，这种情况经理可以另辟蹊径，考虑干掉老系统的可能性，用新系统来接管老系统的功能。
+
+其次是人，为什么千万不要忽略人的评估呢？因为人是有感情的，经理必须考虑一个员工被裁对周边员工的影响。具体我们可以根据被裁员工的类型，考虑怎么做预案。
+
+员工能力不行，态度很好。这里我们要区分能力不行是否已经影响交付，如果员工的能力影响交付才要考虑裁撤。这样的员工态度很好，如果裁掉这类员工，团队里的其他员工可能会觉得领导和公司没有人情味，一味看业绩。
+
+所以经理就需要提前在团队里做铺垫，因为业绩裁员真的没有人情味吗？业绩老是垫底的员工，其实工作并不开心，换个地方很可能更合适他，生活质量也能得到提高。因为业绩裁人真的有问题么？我们要明确，团队的共同目标就是用业绩产出和产品质量说话的。一位员工，态度再好，如果能力不行，就需要其他员工分担他的工作，而且未来还会一直是团队配置上的短板。
+
+员工能力很强，但协作很差。对于这一类员工，我们可以考虑安排难度较大、但又不需要太多跟别人交互的工作。工作中不可能一点跟别人的交互都没有的，**如果实在到了影响团队团结协作的地步，就必须解聘。**裁掉这类员工，在安抚周边员工这件事上反而相对简单一些。
+
+这里要反复确认的是：我们认为该员工协作很差是不是事实？他是跟某些人还是跟所有人合不来？甚至他是不是只跟经理本人不合拍？做好这些确认，能够让我们**避免误伤有能力且有性格的人**。
+
+**3.获得上级领导的支持**
+
+上级领导是裁人发生突发事件时的坚强后盾。很多情况我们都需要获得领导支持，才能解决问题。比如万一被裁的员工闹起来，那时有老板主持大局就非常重要。在裁人后的过渡阶段，如果团队内部无法消化这个人的工作，也需要领导的助力和协调。
+
+而且上级领导对裁人这件事要拥有知情权。裁人可不是一个小的决定，即使团队内部就能消化掉被裁人的工作，我们也要跟直属领导沟通好。一般比较成熟的二线领导（经理的经理）一定会跨级了解情况，也就是说经理的上级对于要裁的人也是有了解的。
+
+## 裁员的沟通协调
+
+裁员的沟通和协调是最后一步，说明我们已经准备和员工摊牌了。沟通协调的目的都是为了避免意外情况发生，要注意缩短和员工谈解聘到员工签解聘协议并离开公司的时间，减少裁员对周边人的影响，尽量好聚好散。
+
+**1.做好准备，启动裁员沟通**
+
+虽然理想状态是好聚好散，但我们也必须做最坏的准备，根据实际需要可以先去除被裁员工的权限，避免对公司造成破坏的所有可能性，然后想办法把被裁员工从所在团队支开，避免被裁员工情绪激动，影响现有团队的其他成员。
+
+**还有一点要注意，就是不要和被裁员工说“跟你的业绩无关”。**我就犯过这个错误，那次是公司做内部调整，我部门也受了影响，不得不裁掉业绩排后的一批员工。我去沟通时就说，这是公司战略性调整，所以你的职位被拿掉了，这次裁员跟你的业绩无关。我当时觉得这样说，被裁员工心里感觉会好一点。
+
+但事后HR提醒我不可以这么说。原因有两点：第一，被裁员工可能会拿着“他没有业绩问题”来跟公司闹，要更多的赔偿，甚至直接打官司；第二，其实经理和HR都知道裁掉的人就是业绩靠后的，被裁员工多少也会猜到，沟通中我们不必主动提这个话题。
+
+**2.把对话引导到赔偿协议上**
+
+一旦裁员的沟通启动，经理和HR都希望尽快签字落实，所以沟通时就要尽快把对话切到协议签字上。比如可以说**要不我们先看一下赔偿协议和金额吧，这时候大多数人就不会再纠结为什么被裁的人是我，而HR也可以在这时介入跟员工讨论赔偿细节**。
+
+这里我还想多说两句，并不是所有被裁员工都有赔偿，比如下面这种情况就没有赔偿：个人业绩不达标。
+
+每家公司的政策不一样，我们公司，如果经理选择走正式的业绩改进计划，就会协同HR跟员工明确每一个阶段的业绩目标并存档，存档后按月check情况，如果不达标就没有补偿，整个过程会持续3～6个月。
+
+**3.政策范围内，能多帮就多帮一些**
+
+经理做出裁人决定，对被裁员工的影响是很大的，我们能确定他承受得了吗？不会有意外吗？如果不能保证，我强烈建议经理在裁人前，一定找公司的人事部门去了解法律细节。事实上，在我们公司就会有HR专门协助经理处理裁人的事情。
+
+为了尽量避免发生意外，一种有效的方式就是经理提前了解被裁人身体、心理和家庭情况，如果发现被裁员工这三方面存在很大风险，我们可以这样做：
+
+- **身体状况不佳，找合适时机沟通。**曾经有位身体不好的员工，我们没有直接做沟通，而是先询问身体状况，那时这位员工正在看病，我们一直等到他复查完毕，拿到医院的评估后才和他做了沟通。
+- **心理状况不稳定，沟通要持续跟进。**有次裁员我们就遇到了被裁员工有轻度抑郁症的情况。因为经理在平时就会关注员工的心理状况，所以他知道这个事儿。因此，这名经理选择在公司外一个相对私人一些的环境和他做沟通，并且后续做了数周的跟进。后来经理和HR在政策允许范围内，尽量考虑了员工现实情况去做安排，这名员工也接受了解聘协议。
+- **被裁员工家庭负担比较重，要在力所能及的地方多做协调。**员工被裁后很难负担家人重病和房贷的支出。可是开弓没有回头箭，一旦启动裁员计划，是不可以撤销的，这一点没有商量的余地。但我们确实做了在政策范围内力所能及的事儿，HR 专门帮忙被影响员工联系医保社保，主动提供公司内部其他在招聘部门的招聘信息。
+
+这里概括一下，我们要注意一个核心点，“心要慈”，就是我们不能把人逼入绝境。这样做，被裁员工强烈反弹和做出极端行为的机率就会减少很多。
+
+## 总结
+
+裁人是个沉重的决定，为了组织运转更高效，有时经理就是要做这个艰难决定，这是经理的责任。对于要被裁掉的员工，在这个环境下他工作和生活的质量也并不高，换个环境对他自己也是一种解脱。
+
+真正要裁员，提早做铺垫，经理对被裁同学现在的业绩表现不满意，要通过多次沟通指出员工的问题，并提出具体的改进建议。如果多次沟通仍不见效，那么经理就要做足准备，评估对事和对人的影响，争取到上级的支持。
+
+在裁员沟通前，经理必须做最坏的准备，把可能发生的情况都先过一遍，最好找公司HR帮我们审核一遍。
+
+沟通中注意不要和员工说裁掉他和业绩无关，而且要把对话引导到赔偿协议上。沟通协调的核心目的是什么？其实就是缩短员工解聘到离职的时间，降低人员变动带来的影响。
+
+另外，了解员工身心情况、家庭负担也很必要，不能把人逼入绝境，政策范围内，我们尽量多帮一些。
+
+最后请你记住一句话：心要慈，刀要快。意思就是我们内心很希望被裁掉的人将来能过得好，操作起来铺垫和准备工作做到位，一旦落刀就要果断，尽快解决。
+
+## 思考题
+
+1.团队里有一个同学业绩不达标或者不能达到你的期待，还有一个月他的合同就到期了。你是否给他续约，或者说什么情况下你会给他续约，什么情况下你不给他续约呢？
+
+2.你很希望团队能够转型并到达新的高度，你的团队成员虽然都很努力但是不足以到达下一个阶段，这时你准备怎么做？你能列出你这么做以后团队的收益和风险吗？
+
+欢迎在留言区晒出你的经历和疑问。如果有收获，也欢迎你把这篇文章分享给你的朋友。

极客时间专栏/geek/技术管理案例课/一线经理：开始带员工了/11 | 员工关怀：发自内心地关心人，是一切的基础.md

@@ -0,0 +1,140 @@
+<audio id="audio" title="11 | 员工关怀：发自内心地关心人，是一切的基础" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/fd/0b/fd7d9b9045e894f822aa4d10f584880b.mp3"></audio>
+
+你好，我是许健。今天我们来谈谈员工关怀这个话题。
+
+一提到员工关怀，我们首先想到的，就是人事部门在节假日赠送的生日贺卡，中秋月饼什么的。但这种关怀的方式，员工并不会有什么强烈感觉，因为这并没有体现出经理对员工个体的用心。
+
+将心比心，你现在闭上眼睛回顾一下，想想那些你的领导专门花在你身上的时间和精力，想想那些让你和领导的关系走得很近的事情。我敢说一定不是那种每个人都有的贺卡月饼什么的。
+
+你可能觉得这并不是什么大事，但正是不重视这些点滴“小事”，这些能让人和人之间的心理距离贴近的“细节”，就会产生一些负面的影响。
+
+首先，这会影响员工的情绪和积极性，员工工作只是拿钱做事儿，会和上级的关系很疏远。其次，经理虽然了解员工的工作能力，对手下的人情感心理还是很“陌生”，这不但让经理很难知人善任，手下的员工也不容易对经理“归心”。
+
+最后，有句话说“人心散了，队伍就不好带了”。不关心人的经理，他与手下的团队之间缺乏感情纽带，那么团队的凝聚力就会很差。
+
+所以今天，我就结合自己这些年的工作经历，给你讲讲我理解的员工关怀是什么样的，希望这也能给你带来一些启发。
+
+## 我是关心人的人吗？
+
+我相信很多踏上经理岗位的人，都会说自己是关心员工的。我曾经也这么认为，甚至觉得自己比大多数经理都要关心部下，因为我很关心员工的职业发展。我老婆甚至还跟我开玩笑说，我花在培养员工身上的心思比自己女儿还要多。
+
+但后来发生的一些事儿，却让我对自己有了新的认识。
+
+### **1.一个离职员工给我的反馈**
+
+曾经有一个员工合同快到期了，虽然他很想续签，但我觉得他能力有限就没有同意。他听了我的决定后非常激动，要和我单独沟通。
+
+他是这样和我说的：“许健，你是不是做经理不久？你说我的能力有限，要看跟谁比，有些人我认，有些我不认。你除了给我安排任务，跟我谈业绩，你找我谈过心吗？你了解我真实的需求吗？你了解我的生活状态吗？”
+
+没等我作答，他继续说：“也许外企的经理就是这种风格，因为你们给得起高工资，但是缺乏了对人心的关注。我之前民企的老总，他非常关心我的工作和生活，这让我想尽全力为他工作。而在你这里我没有这种感觉，在冷冰冰的工作里，有的只是赤裸裸的上下级关系。”
+
+他的这段话真的让我想了很久，给了我很大冲击。不过，我不会因为他说这些话就撤回决定，但这是我当经理后，第一次听到还有“关心除工作之外的事情”这一说。这次经历在我心里种下了一颗种子，也让我开始真正去正视这方面的问题。
+
+### **2. 正确认识自己**
+
+我开始思考，我平时忽视的员工情况，以及我应该在什么情况下对员工进行关怀。为了正确地认识自己，我想从日常工作的细节下手做分析。我问了自己几个问题：
+
+- 有员工离职，我会想到可能他是没感受到我的重视，觉得与其等我给他升职还不如早点跳个槽吗？
+- 有一个员工很踏实但是不善言辞，他也不会提升职要求，我会从他积极主动地去学新东西，还有承担更多工作这些细节里，感受到他强烈的升职愿望吗？
+- 我能在交谈中从对方的一个眼神闪烁中抓到异常吗？
+- 我平时是更喜欢给员工说教，还是听员工分享呢？
+- 谈到要主动关心员工的时候，我是理性思维跟员工分析利弊，还是用感性思维切身体会员工的感受呢？
+
+通过追问上面这些问题，我终于承认自己其实不是很会关心人的人。而且我也从我的父母和妻子那边得到了同样的反馈，原来我的性格真是这样的。
+
+认识问题是解决问题的起点，所以作为经理想要做好员工关怀，**第一步就是正确认识自己，看到自己在这方面的差距，并且要认可这个差距，然后才能进步**。
+
+那在认识到自己的问题之后，我又开始思考，为什么我会给人那种冷冰冰的感觉呢？
+
+从当经理的第一天开始，我接受的就是全套的“西式管理”培训。什么是西式管理呢？西式管理更多关注授权、业绩考核、冲突管理、团队目标设定、执行跟进等等。虽然西式管理也关注人能力的提升，但并不太关注人心，很少把管理和私人关系、员工生活甚至家庭联系起来。
+
+这和**关注“人心”的中国式管理差别非常大**。中国式管理就是指，**作为经理，我们不仅要想着怎么培养员工的能力，怎么通过激励、奖惩获得更高的效率、更多的产出，还要把员工当成有情绪起伏、有家庭压力、有感情需要的，一个立体的人来看待。**
+
+可是说句真心话，不同的经理就是会有不同风格，我本身也不是那种一有时间，就很喜欢跟别人在一起的人。但尽管如此，我还是很希望自己能成为一个有人情味，会发自内心关怀员工的人。那我到底该怎么做呢？
+
+## 怎样做好员工关怀？
+
+我之前在[领导特质](https://time.geekbang.org/column/article/277494)那节课里说过，经理要做打不死的小强，答应别人的事情就一定要做到。
+
+但这里就有一种特例：公司的压力导致加班加点、压力山大或许还可以扛，但是如果家里又上有老下有小，老人身体一旦出问题，或者孩子的教育出问题，这样的情况我们还能坚持多久呢？
+
+推己及人，我发现其实员工关怀就是一件将心比心的事儿。无论经理本身是什么风格，只要我们想要关心他人，办法总是会有的，具体都有哪些办法呢？接下来我就结合别人的经验和我自己的感悟给你说一说。
+
+### **1.拉近关系，与员工成为朋友**
+
+我认为领导和员工之间应该形成强烈的感情纽带，这个纽带从刚刚形成的时候就需要我们不断维系，然后通过一些事件把这个感情推到下一个阶段。
+
+这就需要我们主动去了解员工的家庭情况了。其实工作几年以后，我们也都是拖家带口的人了，身上的负担都不轻。人不是机器，谁都会有喜怒哀乐。而这些不单单只跟工作业绩有关，也会跟家庭有关。了解这些情况能够更好地帮助我们全面、客观地看待员工的工作情况，更重要的是：能够很好地拉近人和人之间的心理距离。
+
+那具体怎么做呢？如果你本身和员工之间的联系并不紧密，那**我们可以先用爱好和倾听建立和员工之间的联系。**
+
+我们部门就有一个爱好很多的经理，他爱好抽烟、喝酒、吃饭、打球、游泳、弹琴等等。这位经理就跟我说过，我们可以经常找一些骨干员工谈谈心，一起抽烟，一起运动。不为别的，只是听听员工抒发情绪，自己做个好听众就行了，这样在无形之间，我们的距离就会拉近。那平时工作之余，我们一起聊聊天、散散步，互相分享一些家里老人和孩子的事情就会很自然了。
+
+再比如，我们也可以借助一些活动，让我们的家人熟悉起来，这样自然而然我们和员工的关系就会亲近很多。就像我们公司每年的Family Day就是家属互相认识的好机会，母亲们在会议室里陪着孩子玩，做父亲的光是看到这一幕他们之间的关系就近很多。
+
+我们部门的X还组织家长带上孩子做演习，自己去扮演拐卖孩子的坏人，来培养孩子的防范意识。如果部下不会觉得拘束，我们甚至还可以安排员工都带上各自的家人一起吃个饭，或者一起郊游。这些都是很好的活动。
+
+为什么我要强调和员工成为朋友呢？比如以我自己来说，我觉得如果离开eBay , 会有种很难面对领导的感觉。
+
+我们想想是不是这个道理？在这种情况下，团队骨干是不会因为外面多一点钱、多一点权而动离开的心思的。部下和经理的关系从纯粹的上下级关系转变成上下级和朋友的并存关系。
+
+### **2.了解员工家庭情况，主动提供帮助**
+
+当我们和员工的关系拉近了之后，我们自然就要去关心员工的家庭情况。
+
+虽然说，在正常流程下，如果一旦发生私人问题和工作相冲突的情况，员工应该跟领导还有团队沟通，减少负面影响。但有些员工是不会主动和经理说这些私人问题的，他不说，我们就不知道，如果他工作出了问题就会很疑惑。就像我们部门的Z在父亲手术室外面还在处理工作，心里承受着巨大压力和不满，就算在这种情况下，他也没有告诉经理家里有事。
+
+因此，我们当经理的就是要有这份心，去主动去了解。我们可以经常关心一下员工有没有异常情况，比如最近请假频繁，或者平时经常加班最近一到点了就会准时走……
+
+**当了解到这些家庭情况之后，我们可以主动为员工提供帮助。**通过和其他经理时不时的闲聊，我注意到还有个经理对部门骨干的家里情况也蛮了解，像是谁买了新车，谁家里老人生病了，谁正在为孩子上学的事情烦恼，这些事他都知道。而且他还会动用自己的私人关系去帮助员工，介绍老师和医生。
+
+我也知道，帮员工联系老师和医生，这不是每一个经理都能做到的，如果经理没有这个人脉就不行。但这不代表我们不可以多问问员工的情况，如果员工家里有什么事儿，尽量帮员工做个安排协调，分担一些工作的事情，这是所有经理都可以做到的，哪怕在闲暇时间互相分享一些育儿心得也很好。
+
+### **3.两类特殊情况**
+
+前面我说的算是员工关怀的基本方法。这里我还想单独强调两种情况，分别是员工住院和员工的孩子出生。这两种情况，我都亲身经历过，所以讲起来更有感触。
+
+**先说说员工住院这个事。**下属住院，我建议当经理的一定要亲自去医院探望一下。我们部门有一个礼拜连续两人因为肾结石发作被送去医院。我下班后跑到医院，去的时候几个同事已经在了，家属正在陪着挂水，虽然我也帮不了太多的忙，但是心意一定要到。
+
+二线经理也应该跨级去关心一线员工，一方面员工会觉得部门领导重视他，同时也是拉进跟一线员工心理距离很重要的一环。有一次，一线员工小刘住院，那时候我已经是二线经理了，他的一线经理自己买了慰问品去医院看了小刘。这事儿我是后来才知道的，我觉得一线经理做得很对，同时也觉得自己做得还不到位，我本该想到和一线经理一起看望小刘的。
+
+千万不要把这些看成“管理技巧”，而是要设身处地去体会别人当时的心情，能够做一些事儿就做一些。
+
+**再来说说孩子出生。**我个人觉得，员工的孩子出生一定要慰问。因为我自己孩子出生那会儿，领导就特意慰问了，所以现在想起来还是觉得很温暖。
+
+我老婆怀孕那年蛮辛苦的，光保胎就住了三次医院，最长那次住了一个月，期间也是起起伏伏。最终结果还是很好的，医生都说能满月出生真是奇迹。
+
+陪产假过后我回到公司，老板叫我去一下她的办公室，谈完工作后，老板拿出一个小礼盒，说恭喜我为人父了，这个过程不易，她有一份小礼物是给我女儿的。我走出老板办公室的那一刻，感觉心里暖暖的，比老板给我升职要更开心。你看，**用心的力量，有时比加工资还厉害。**
+
+其实也不是只有中国人才很注重人和人之间的私人交往，老外也一样的，只是不大容易到那一层而已。因为三次住院，我的总部领导S也知道了我老婆怀孕并且也大致知道预产期，等我老婆去医院分娩那天，我就留了一个消息给S说休假一天。
+
+非常巧的是，我女儿刚生出来我还在产房的时候，S打电话过来，他说许健是不是你老婆要生了，现在情况怎么样？我回答说S你知道有多巧吗？我现在就在产房，我女儿刚从妈妈肚子里出来，我真没有想到女儿出生后接到的第一个电话是你跨了个太平洋打过来的。
+
+电话那边S也觉得真是太巧了，并真心祝贺我。挂掉电话的那一刻，我觉得我跟S的心理距离近了好多，我甚至觉得这通电话难道不是缘分吗？不然怎么这么巧呢。
+
+“以人为本”不是嘴上说出来的，而是日常细节体现出来的。经理发自内心地关心人，是一切的基础。
+
+## 总结
+
+马云曾经说过，员工离职的原因总是有两个：钱，没有到位；心，委屈了。在钱这方面，做经理的，当然要给员工争取利益，但我们更容易忽视的其实是员工关怀。
+
+我把这些年一些点点滴滴回忆了一下，其实做了这么多年的经理，虽然发生的大多数事情都是跟工作相关的，但是我觉得若干年后真的能记住的，以及愿意回忆的一定不是那些具体的工作细节，而是这些人情冷暖。有了这些感情的纽带在，团队凝聚力才强。
+
+每一个领导都有自己的领导风格，有些领导就是跟部下保持距离的，这里没有好坏之分，但是我自己更希望做一个有人情味的经理。我心目中理想的上下级关系是像刘备和张飞、关羽这样的，彼此信任度很高，不但是上下级还是好兄弟。
+
+我们永远没有办法唤醒一个装睡的人，作为经理是否真的从内心就关心人，其实是我们自己最清楚。发自内心地关心员工，基于这个出发点，我们就会更有同理心，就能想到主动去关注的员工情绪、态度和他的烦恼。
+
+员工关怀向来都是以心换心的，带着这样的认识，我们自然会想到，要了解员工和他家人的情况，对员工的异常表现更加敏感些。如果觉察到异常情况，经理还要想到主动给员工提供帮助和支持。
+
+总之，**经理要把员工当成有情绪起伏，有家庭压力，有感情需要的立体的人来看待。**只要我们用心，相信员工一定能够体会得到。
+
+## 思考题
+
+<li>
+有一次我跟总部的D在微信上打字谈工作，我跟他关系很好，于是就说了一些最近工作上的困难，我觉得自己很难。这时候D突然不打字了，而是给我发语音消息。你觉得D为什么要改成语音而不用文字？
+</li>
+<li>
+你怎么看待领导请部下吃饭，不报销自己掏钱买单这件事？
+</li>
+
+欢迎在留言区晒出你的经历和疑问。如果有收获，也欢迎你把这篇文章分享给你的朋友。

极客时间专栏/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. 临场不要退缩，我们思路要清晰，答辩环节要是碰到领导和同仁的质疑，我们要做到有理有据地回复。
+
+在上级经理主持考评这个部分，其实我把会议之前的设定标准，按比例分配晋升名额和投票选举的方式也一并给你做了讲解。这里要注意的是，作为二线经理组织主持考评会议，不要想着找个轻松的办法就能用流程生成结果，把自己从冲突中摘出来。
+
+按比例分配和完全尊重投票结果，都是为了规避冲突而实行的次优解。作为部门一把手就应该不畏冲突，强势把组织的年度奖励资源，给到你最希望鼓励的行为和人身上。
+
+## 思考题
+
+作为二线经理，我们在项目审核和技术分享会议中能发现很多优秀员工。然而，最终业绩考核时，我们更容易忽略对这样的人给予肯定，这类人就是在一线起到了关键作用却不善言辞的骨干，那我们该怎么避免这件事儿呢？
+
+欢迎在留言区分享你关于考评这件事的经历和疑问。如果读完文章有所收获，也欢迎转发给你的朋友。

极客时间专栏/geek/技术管理案例课/开启技术管理之路/01 | 领导力：如何在实践中应用不同层次的领导力？.md

@@ -0,0 +1,134 @@
+<audio id="audio" title="01 | 领导力：如何在实践中应用不同层次的领导力？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/3e/7c/3e5d9ed8eeac106570c71fac391f167c.mp3"></audio>
+
+你好，我是许健。今天我要跟你聊一个听起来比较“虚”的话题——领导力。
+
+在今天的内容开始之前，我先给你重现一段发生在eBay上海研发中心的对话。当时我是监控组的经理，Ralph是监控组技术主力，所以很有可能转为经理。
+
+当时，总经理对我们的项目进度很不满意，总经理是这么对我们说的：
+
+“Ralph，难道你一定要带着经理的帽子才能管事吗？你说说看，有什么东西在阻止你去管理监控组！”
+
+“许健，不要跟我说你只是负责整个Global监控的一部分，从行政上来说你是只管监控的一部分，但是那不意味着你就不能对总部监控产品规划施加影响！”
+
+老板说这两句话的时候很严肃，她对Ralph的核心要求是，不需要经理的帽子也应该可以很好地带团队；而她对我的要求是，不需要Global Leader的帽子也应该可以对总部跨区域项目施加影响。
+
+这种超出了我们的权力范围的要求，迫使我开始思考，如果不用经理的权力来带团队，那我们该用什么来带团队呢？答案我想你已经知道了，就是领导力。
+
+有一个很好的解释是这样说的：你有权利对我说“不”，但是你选择说“是”，这体现的是我的领导力（Leadership）；你想说“不”，但是碍于我是你上级你不得不说“是”，这体现的是我的经理权（Management）。那接下来我们就来谈谈**领导力**。
+
+## 领导力的境界
+
+有一本书叫《领导力的五个层次》，不知道你看过没有。这本书里把领导力从低到高分成了“职位”“认同”“生产”“立人”“巅峰”五个层次。下面这张图说明了这五个层次，你可以看一下，还可以分享给你的朋友、同事，一起交流、探讨一下，你们是怎么给领导力评级的。
+
+<img src="https://static001.geekbang.org/resource/image/1c/a0/1c8bfb666a3eb4735559f2c5473aaea0.jpeg" alt="">
+
+经理权其实就是领导力中**最低**的那个层次，也就是靠职位来进行管理。
+
+### 第一层：“不得不听你的”
+
+用“职位”来管理，是领导力中最低的层次，其实就是用你作为经理的权力（掌握绩效评定）让别人听你的，很显然，这是有弊端的。
+
+我们做经理以后，你会跟不同性格、不同能力的人打交道。有些刺儿头脾气很冲，你使用经理权，他根本不买账。不过大部分人不是这样的，他们不会跟你顶，但这不代表大部分人就赞同你的观点，所以他们在执行时同样不一定能符合你的要求，这样的情况，你一定要学会分辨。怎么做呢？
+
+如果你想让A做一件事，能当面交代就当面交代，因为这样你能观察到他在答应的时候是不是有犹豫，比如眼神会不会正对你，语气是不是坚定。实在不行，你还可以跟部下直接口头确认。
+
+比如我一般会这样做，找一个房间单独问部下：“如果我说的有什么问题，你一定要现在提出来。如果你现在不提，等到资源投入后因为方向不对失败了，我们整个团队都会受影响。同样，你个人在这个项目里有什么诉求？可以一并提出来，如果你不提而我又没有主动想到的话，对你来说就是损失。但如果你提出来，至少我知道后可以想一想怎么安排。”
+
+如果部门要发展，就必须有更多有独立思考、敢于提出不同见解的人。如果有人能用清晰的逻辑驳倒你的观点，你应该感到高兴，因为你的团队多了一个潜力股。
+
+相反，如果你长期只能听到附和的声音，很大可能是你开始搞“一言堂”了；当然，有很小的可能是你英明神武，大家对你佩服得五体投地，所以没有不同见解。这样的后果就是，决策一旦出现偏差，会影响整个团队的交付。
+
+这里我要专门提一下，使用经理的权力虽然属于领导力层次最低的一层，但不代表你不能用。有时候使用经理权来促成执行落实是有必要的，这一点我在下一节课展开解释。
+
+### 第二层：“认同你的观点”
+
+在“职位”之上，就是用“认同”来进行管理。
+
+有一次我们需要做一个迁移项目，将现有的模块迁移到新技术栈，要在一个季度内交付，时间比较紧迫。大家进行了一番头脑风暴，决定拿一个不是很重要的模块先来试水。因为项目时间比较紧，我就直接介入了。
+
+我觉得，一开始就应该迁移最关键、最复杂的模块。这是因为，当时时间真的太紧了，即使我们成功地把试水的模块迁移完成，也不能保证项目可以准时交付。相反，如果我们先把最重要、最复杂的模块迁移成功，其他的模块基本就是秋风扫落叶。而且，只有迁移最复杂的模块才能更早地把问题都暴露出来。我把我的思路说了一遍，很快，所有人都同意了这个观点。
+
+在这一点，你必须用清晰的逻辑来获得大家的认同，如果你所在的组织就是鼓励认同来获取领导力而不是权力至上的文化，那听谁的不听谁的，就不是以职位高低来衡量了。
+
+### 第三层：“跟着你能出成绩”
+
+在“认同”之上，是用“生产”来进行管理，也就是说跟着你能出成绩，用出成绩这个结果来领导。
+
+看到这里，你可能会说，那我只要跟着一个够厉害、能出成绩、能多拿资源和好处的领导，就容易升职加薪呗。可如果是这样，这第三层不就跟第一层经理权没有什么区别了吗？区别不过是领导在手段上用威逼还是利诱而已。
+
+其实出成绩并不只是意味着“利益”。如果你的同事有能力，那么除了权和钱，他们一定希望自己能够做成一些自己认为有意义的事情，这种事情才是真正的“出成绩”。但是有意义的事情哪有那么容易做成呢？这时候，如果你作为经理能够帮助他们扫除做事的障碍，获取做成这件事所需要的资源，那这些有能力的同事就会愿意跟着你。
+
+通俗点来说，你与你的部下是各司其职，你负责人手和获得上级领导支持，你的部下负责搞定技术。如果你作为领导搞不定人手、拿不到领导的支持，是你无能；如果你的部下搞不定技术，就是部下的失职了。
+
+做经理不容易。如果你的工作就是给部下交待任务，而不能提供部下完成工作所需要的支持，那什么人都可以做经理，还需要你来做什么呢？当然，作为部下，你也要有“利用好你的经理来完成重要工作”的意识。
+
+### 第四层：“跟着你能提升个人综合能力”
+
+在“生产”之上的领导力层次就是“立人”，也就是通过“你能培养人”来进行领导。怎么说呢？就是让你的部下变强，强到随时都可以离开你；同时你要对他足够好，好到他很强，但是还是选择留下来跟你共事。
+
+很明显，做到这一层，我们要从两方面来看，一方面是你要有培养部下的能力，要么你能够提供平台，要么你有足够的洞察力能够直指员工的瓶颈，释放他的潜力；另一方面，我觉得也是比较难做的，就是发挥你个人的人格魅力，使得你的员工愿意跟着你。这一点尤其针对专业技能高于你的高级别员工，非常有效。这个部分，我会在你要如何培养人的部分详细展开。
+
+### 第五层：“你已经成为时代的楷模”
+
+在“立人”之上的第五层，就是“巅峰”了。说实话，以我目前的能力，对这个层次也只能仰视，但是仰视不代表我们没有什么可为。
+
+作为一名经理，你完全可以经营自己的“品牌”。在公司内部，你跟其他部门开会，在公司内部进行全员演讲、内训或者校招宣讲会，都会让你的部下看到你在交互中强悍精干的形象。在行业中的自身“品牌”经营也是这样，对技术峰会、技术博客等内容进行投入，这不但对自己有利，还能帮助部门吸引到好的人才。
+
+人的本性是追随强者，成为时代楷模或许听上去有些遥远，但经营好自己的品牌这件事，从当下就可以做起。
+
+## 信任：一种高阶领导力
+
+前面这五层模型总结得很好，尤其是在初做管理的时候，读很多这类的图书可以给我们提供理论支撑。
+
+但是，当我真正做了很多年管理，亲身经历了很多事情之后，我明白了一件非常重要的事：**知道得再多，没有实际操作，都是白搭**。所以，我开始在工作中有意识地培养自己的领导力，提升自己的领导力。
+
+我慢慢发现，管理工作中真正的挑战往往出现在高级别员工身上。这促使我去思考，比起已知的理论框架，哪些行为是最能帮助我在现实中确立领导力的。最终，我从以往的工作经历中提取出了“信任”这个关键词。为什么我要讲“信任”呢？我还是先给你讲个真实的故事。
+
+S是我在美国的虚线汇报领导，我与他共事多年，我们的大部分沟通都是通过邮件完成的。有一个阶段他在工作上不太顺，我甚至担心他会不会离开。有一天，我突然接到S的电话，我清晰地记得我是在“雨人”会议室接了他的电话。
+
+那天，S很激动，他对我说：“许健，我刚接手了数据中心部门，我想在Expressonboarding上大幅提高效率，你知道我很信任你，我想把招聘预算从美国挪给你，你就在上海组建团队，我知道你一定会帮我搞定这件事的。”要知道，平时我们的招聘预算都是要申请很久的。
+
+S之所以不是以日常写邮件的方式告诉我，就是因为这件事对他真的很重要。这通电话让我体会到，他对我们这批离岸研发中心骨干的信任和期待。大领导亲自打电话给我，给人、给钱，让你去做一件对他很重要的事情，我当时很激动，马上找了相关的骨干立即开始招聘，同时还主动调整了上海现有团队的优先级，并且立即安排去美国出差了解一线情况。
+
+直到发生了这件事，我才知道了一种新的压力，一种“来自信任的压力”。执行开始后我们每周安排跟S的review，有任何对总部的依赖都会第一时间告诉他，让他帮我们解决依赖。因为我们无论如何也要尽全力去做出成绩，不能辜负了S的信任。
+
+你看，你不需要命令你的部下去做事情。只要你告诉他，你多么需要他，他对于事情的成功有多么关键，而你信任他，并且把关乎自己切身利益的事情托付给他。一旦出现这种压力来自信任的情况，上级领导基本上不需要用任何方式来盯进度。古人说“士为知己者死”就是这个道理。
+
+这个方法其实是一个普适的方法，不是单单针对高级别员工。我强调高级别员工，是因为他们在技术和专业知识上，很有可能是在你之上的，这个时候对他们的信任就显得尤为重要了。
+
+## 如何确认是否给了部下信任？
+
+“给信任”这件事说起来好像很简单，但想要做到这点你绕不开一个问题：你怎么知道自己是否给了部下信任？或者这个问题可以换一个表述方法，那就是：你怎么才能知道你的部下是否感受到了信任？
+
+要解决这个问题，我们得先确认你自己是什么类型的领导，有给部下信任的领导，那自然也有只把部下当资源用的领导。
+
+不会给部下信任的领导是三天两头查岗，还不放权，那部下也就只会进入这样一个状态：你叫我做什么我就做什么的被动状态。因为作为部下，他们只看到了任务，看不到信任，也看不到自己的未来发展。
+
+你可能觉得“要给部下信任是理所当然的”，自己也做到了。但是我告诉你，在现实工作中会出现灯下黑的情况，就是你**自己可能意识不到，你其实就是那个不给部下信任的经理**。
+
+那问题来了，我们怎么能够做到自我发现呢？一个非常简单的方法就是看你自己的状态。
+
+你如果发现自己做得非常累，你就要给自己提个醒了。比如，你每天都需要搞到凌晨1点，但是事情并没有减少的趋势，凡是有点分量的事情都需要你亲自处理。这是你没有给予部下信任的第一个预警。
+
+如果在你如此忙碌的情况下，组织效率还没有提升，就更需要反思自己是不是管得太过了。这种情况下，你需要观察一下部下是不是被你压制在被动模式下。
+
+如果你把你部下的工作都做了，你的部下怎么能够得到成长呢？所以，请你试试多信任一点自己的部下吧，给他们多一点自由度，只要能起到培养人的效果，承担一些风险是值得的。
+
+## 总结
+
+经理的帽子当然能帮助你来领导别人，但如果你不想止步于此，那么让你更进一步的关键因素就是领导力。关于领导力的层次，我可以通过问三个递进式的问题来总结：
+
+1. 如果今天你已经不是这个人的经理，他还愿意听你的吗？
+1. 如果今天你已经离职，他愿意追随你吗？
+1. 他愿意降薪追随你吗？
+
+我想这三个问题的答案不需要我多说了。对于高级别员工，特别是专业能力在你之上的员工，领导力的体现不一定是你能真的帮到他们什么，你可以听听他们的意见，赏识他们，给予他们充分的信任。
+
+当然，你还可以看看你的领导平时是怎么做的，也多想一想他为什么这么做。除此之外，我推荐你多看看人物传记。我认为，真正讲清楚领导力的书，书名里面都没有“领导力”这三个字。
+
+## 思考题
+
+- 如果你作为员工，发现领导把你当资源用或者对你授权不够，你准备怎么把你的这个感受反馈给领导而不产生副作用呢？
+- 如果你已经走上了管理岗位，你可以想想权力的本质是什么？你为什么可以对别人提出要求？
+
+欢迎在留言区晒出你对领导力问题的思考或疑惑。如果今天的内容给你带来了启发，也欢迎你把这篇文章分享给你的朋友，在提升领导力的路上一同进步。

极客时间专栏/geek/技术管理案例课/开启技术管理之路/02 | 经理权：如何有效使用经理权？.md

@@ -0,0 +1,96 @@
+<audio id="audio" title="02 | 经理权：如何有效使用经理权？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/88/c8/88142a213981df51fd61b6167787f8c8.mp3"></audio>
+
+你好，我是许健。今天我要跟你聊一聊，怎样来使用经理权的问题。
+
+上一节课中我们介绍了领导力的5个层次和获得领导力的重要方法——信任，今天我就和你谈谈其中最低层次的领导力，也就是用“职位”来领导。
+
+为什么说用“职位”来领导是最低层次的呢？不是说它很low，而是它的应用最为普遍，也是最容易被用错的。人类的思维有一种很奇妙的模式：当我们对一件事的理解本来是A，机缘巧合下对这件事的理解升华到了B后，我们就很容易开始一味地、机械地使用B，而摒弃A。
+
+对应到领导力这里，我们虽然讲领导力是有高低层次的，但你要提醒自己，不能一味地去追求只用更高的领导力来进行管理。对于不同的人、不同的场景，我们要使用不同的领导力层次，有时候，我们就是要使用经理的权力，强制聚集组织力量来交付业务价值。
+
+在工作中我们经常会遇到“不管部下是否同意，领导都要求部下去执行”的情况，这就是领导在使用“经理权”。
+
+## 慎用经理权
+
+使用经理权，说白了就是用职权来压人。这种方法是有效的，但我们要慎用它，因为当你每一次使用经理权时，消耗的都是你平时积累的领导力储备。
+
+那么，我们在**什么样的情况下必须坚持使用经理权呢？**就是业务拖不起的时候。
+
+具体来说就是，当你没有时间来让所有人统一意见，又必须促成事情往前推进，这时候，我们必须要用经理权来实现“独裁”。如果你的方向或者举措是正确的，效率就会很高。
+
+这就出现了一个新的问题，经理权该如何使用呢？在回答这个问题之前，你需要先了解一下“假民主”和“真独裁”这两种形式，了解清楚使用它们的风险，才更容易理解怎么去使用经理权。
+
+### 假民主
+
+什么叫假民主呢？就是负责人已经明确表露出意向，然后还征询意见。
+
+不知道你有没有遇到过这种情况，我反正是遇到过。有一次，部门想开会重新评估一个项目的优先级。负责人一上来先重申了之前的评估结果，然后挨个儿询问与会者的意见。但是，讨论结束之后，负责人来了一句：“不管你们同不同意，这个议题已经谈了很久了，我都要你们执行。”
+
+你看，既然这个负责人已经决定了，还询问个啥呢，是不是？
+
+如果用一句话概括，“假民主”会消耗领导者的公信力。
+
+虽然碍于你是领导，大家当你的面不会说什么，但是心里对你的处事方式并不赞同，对你的印象大打折扣，觉得你来虚的。大部分的经理都具有两种身份，既是部下又是领导，如果你自己都不喜欢假民主，那就更不要对人对己实施两种标准了。
+
+### 真独裁
+
+我刚才说了，我不喜欢假民主，但在需要的时候，我赞同果断使用真独裁的方式。
+
+最近，我们有个部门里的两个产品线需要合并，下面的人各执一词，意见不一致。这时候，我们负责合并事宜的主管解决这个问题的方法就是独裁。因为这个主管往后退是绝对不可能的，产品线合并必须完成，这是公司的战略决策。
+
+但是上面虽然拍了板，下面执行的时候可没那么容易。这时候最好的办法就是用高压手段果断独裁。虽然做这个决定对公司来说只是一句话的事儿，但是对主管本人来说是担着上下双向风险的，万一最后合并效果不好，他不仅要负责任，还要考虑底下的人会不会拿这个来说事。但是，箭在弦上不得不发，事情再拖下去只会继续浪费组织的执行力。
+
+我说“慎用经理权”就是因为有多方面的风险存在：一是人员离职的风险，员工可以接受你偶尔使用经理权，但如果你经常使用，有想法的人一定会离开；二是个人地位的风险，万一你难得使用了一次经理权，还把事情搞砸了，你在组织里的威信何在？
+
+## 到底该怎么使用经理权？
+
+那我们到底该怎样使用经理权呢？方法只有一个：**要么不用，要用就必须落实它。**因为这是你最后的手段。如果你用了经理权后，这事儿还不能落实，那你在组织里也就基本上没有什么威信可言了。
+
+但实际工作中，落实你的决定并不容易。如果你使用了经理权，底下人还是不听，公然反对怎么办？或者，底下的人看似听了，其实并没有真的在实施，这种情况又该怎么办？到底怎么才能让他们真正“听从”你？怎么才能使用并落实经理权呢？
+
+我这里根据这么多年的经历总结了两点经验，你可以参考一下：一是把握关键人物态度，二是持续跟进进度。
+
+### 1.把握关键人物态度
+
+首先，在做重大决定前，你一定要备足功课。在拔剑之前，你需要先在自己脑子里过一遍，影响这件事情落实的关键人物有哪些。然后，了解清楚这些人的态度，小事开大会，大事开小会。
+
+如果你想取得这些关键人物的支持，事先进行一对一沟通和开小会是最直接的，可以确保之后落实决定的时候顺利进行。
+
+我就见过有人在会议上直接当着大家的面对经理说，我不同意你的决定，而且我也不会按照你说的做。如果有好几个性格比较强的在会议上这么说，你怎么办？你能确保会议上会有人站出来替你说话吗？
+
+当你做了一段时间经理以后，看电视剧、看历史、看育儿，都会觉得跟工作中的事情很像。你看过《雍正王朝》里面八爷九爷十爷逼宫的那段戏吗？雍正本来是要谈改革旗务的大事，结果八爷党联合隆科多和关外的旗主王爷当着满朝文武逼宫，如果没有十三爷危急关头拿下京郊两大营的兵权，还有张廷玉基于史实驳斥八王会议站不住脚，雍正的威信就崩盘了。
+
+这种情况在现实生活中不是不可能发生。就像电视剧里描写的大多数官员都不说话一样，现实生活中也充斥着“沉默的大多数”。如果你是剧中的雍正，为了国家要改革旗务，动旗主王爷的奶酪，在已知八、九、十这三个王爷跟你不和的情况下，你会做哪些不一样的准备呢？
+
+就因为不是所有的人都同意你的决定，所以在推行重大决定的时候，**你要做最坏的准备**，底下的人可能在执行时打折扣，甚至是阳奉阴违。比如你说要做A，他执行的时候扭曲对A的理解，当你发现不对的时候为时已晚。也有可能底下人主观很想配合你，但是由于理解偏差或者能力不到，导致你最终想推进的事情失败。
+
+### 2.持续跟进进度
+
+在把握好关键人物的态度后，你不要以为把决定下达了就万事大吉了，接下来你一定要持续跟进进度，这样才能保证事情有结果。
+
+如果是一个三个月的项目，那每周你都要看进度、看执行细节。三个月可以发生很多变数，因为是使用了经理权，你更需要及时了解变化，及时做调整来保证你的决定按照既定思路得以落实。
+
+如果不是你亲自执行，那负责执行的人必须跟你一条心，他要高度认可你的理念，并且你们之间必须有很强的信任。然后，你需要跟他做持续的交互，帮他解决执行过程中碰到的阻力。如果一个人跟你之前没有深度合作过，只是嘴皮子上让你觉得他跟你想的是一样的，那么在你把事情交给他之前，请多一个心眼，谨防他的执行动作走样。
+
+具体方法就很简单了，你可以向他提问，问清楚他计划的执行细节，确保他的理解跟你的期望是一样的。
+
+我见过一个Case，一个能力比较强的经理跟上级经理说，他会出面搞定组织内部最大的内耗问题，上级经理最后做出组织重组决定，将大量执行力交给这个经理，但是调整完了以后却发现这个经理解决内耗的方式并不是该上级经理希望的方式。
+
+向上管理也是这样，但凡要牵涉组织重组或者领导准备交付重要任务时，你最好主动去约领导时间，跟他说你准备怎么做，确保你在执行方向上和领导没有不一样的理解。
+
+权力是公器，不到万不得已最好不要使用。一旦你使用了，就必须保证它能成功。在使用经理权时，我们要做好的希望，坏的准备。不要以为你做个决定就万事大吉了，一定要跟进到结果出来为止，你的权力使用才算是真正完成了。
+
+## 总结
+
+好了，今天的内容讲完了，对于经理权的使用，不知道你有什么感受呢？
+
+其实写这篇文章就是想告诉你，踏上管理岗位后你在专注提升自己的领导力的同时，不能机械地去追求更高层次的领导力，而彻底放弃使用经理权。
+
+经理权要慎用，不代表不用，也正是因为要很少使用它，所以用到了就一定要见效。要见效不是喊喊口号就可以的，我专门列举了一些我的经验供你参考：搞定关键人物、亲自或者找你信任的人抓执行情况。
+
+## 思考题
+
+- 你在会议上使用了经理权，好几个人在场，你的刺头儿部下说：“我不同意，你要做你找别人做”，你怎么办？
+- 如果你的领导开会强势宣布一个决定，该决定对你所管理的部门有冲击，你怎么办？
+
+欢迎在留言区晒出你的故事或者观点。如果你的朋友也正为如何使用好经理权的问题发愁，也欢迎你把这篇文章分享给你的朋友，和他们一同交流、探讨。

极客时间专栏/geek/技术管理案例课/开启技术管理之路/03 | 领导特质：一个合格经理人应有的4个待人处事原则.md

@@ -0,0 +1,125 @@
+<audio id="audio" title="03 | 领导特质：一个合格经理人应有的4个待人处事原则" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d3/03/d3ef6d2ce6ae008f3a8532b050bee703.mp3"></audio>
+
+你好，我是许健。
+
+前面我们聊了领导力和经理权。基本问题我们现在理清楚了，今天我们来聊聊一个合格经理人应有的4个待人处事原则。
+
+事实上，很多性格不同的人能够胜任同样的工作，但是千千万万的“领导特质”总有一些共性的内容。我不敢说自己是成功的领导者，这里我更多的是基于自己这么多年的管理经验，总结的一些经理人普遍具有的优秀特质。
+
+如果你能了解这类优秀特质，然后在平时的待人处事中去实践，就能让你在人际交往里更加得心应手。此外，这还能帮助你构建更好的信任关系，有助于别人更好地了解你是什么样的人，这在容易产生误会的场合能极大减少对方从负面解读你的机率。
+
+## 特质一：待人真诚
+
+我要讲的第一个特质非常简单，就是“待人真诚”。看起来是不是特别简单？可你做得到吗？
+
+不要小瞧了它，如果你拥有了“待人真诚”这个特质，那么即使你不认可对方的意见，对方也不会怀疑你有什么私心，会相信你是优先考虑了团队利益；即使你因为员工的错误惩罚对方，对方也不会认为你是在挑刺。
+
+“诚以待人，行光明正大之道”，我觉得这一条原则就像大厦的根基，决定了整个“领导者大厦”的高度和抗风能力。
+
+而之所以把“待人真诚”立为第一条特质，我在开篇第一讲也强调过，信任，是第一领导力。而真诚，就是建立信任的前提，如果没有真诚作为前提，无论你做什么、说什么，都难以获得他人的认同。因为你永远不知道站在你面前的人功力到底有多深厚，能不能看出来你的小心思，所以对于你来说，最保险的做法就是一律待人以真诚。
+
+既然待人真诚是我们的基本要求，那么，怎样的行动才会真正地体现出待人真诚呢？具体来说，**如果一件事我没有办法说服我自己，我是不会试图去说服你的。**
+
+前不久，我的一个好朋友说他那边有一个非常好的机会，问我有没有合适的人推荐。我觉得我有一个很有能力的部下，其实是有可能去争取这个机会的。但是他如果离开，对我、对我们部门的影响都很大。
+
+我可以选择不推荐他，并且也不告诉他曾经有这件事发生，可按照我的价值观，实在找不出理由不告诉他。当天我纠结了很久，最终还是选择坦诚相告，告诉他有这个机会。
+
+然后，我也真诚地告诉了他，我选择不推荐他去的理由。我一直给团队强调，做经理要和团队共进退。如果我自己都把身居要职的部下推荐到别的公司去，那大家还怎么相信我说的，会带着大家披荆斩棘去往更好的明天呢？
+
+并且，我也承诺给他在公司内寻找更好的机会。我跟你讲这个故事，不是为了说明我这样做是对还是错，而是想跟你说明待人真诚的作用。因为我是真诚的，所以部下非但没有质疑我的出发点，相反会更能接受我的做法，而且充分感受到我对他的信任。
+
+## 特质二：雪中送炭
+
+**不以别人位高权重而阿谀奉承，不以别人落魄潦倒而让关系疏远。**这句话其实是待人真诚的另一种延伸，而一个合格经理人，一定是多去做雪中送炭的事儿。因为职场中的信任都是慢慢积累的，现在想想，我觉得自己正是秉承了这样的特质，才在工作中获得了不少人的信任。
+
+我常常思考下面三个问题，你可以跟着这个思路，想想自己有没有过这样的情况：
+
+- 看到领导的邮件和消息就立马回复，部下的邮件和消息有些就不回复？
+- 领导在位置上的时候，你高规格接待，花很多时间和精力去构建关系，领导调离岗位或者离开以后，你的态度却一下子冷却了？
+- 对公司里看上去没有什么权势的人，也给予足够的尊重和支持？
+
+这三个问题其实都指向一个终极问题，**你的待人处事是不是以对方有多少价值为标准**。在职场中，这样做这样想，你可能觉得无可厚非，司空见惯。但是我的建议是不要这样，这样不仅是势利的表现，最主要是太短视了。
+
+位高权重者有很多人去锦上添花，不缺你一个。这么说可能不能让你信服，毕竟道理大家都懂，但是眼前的利益就是最重要的呀。接下来，我就通过自己经历过的一个事情，给你具体讲讲我为啥这么坚持这条处事原则。
+
+大概4年前，总部将我们部门的下一代技术栈两大核心产品调整到了另外一个部门。这意味着我们部门的业务就剩下维护现有产品了，等新一代产品成熟，现有产品也终将被取代。加上新来的副总如日中天，部门内开始有流言，说我们部门原来的领导是不是会离开了。
+
+过了一段时间，我们部门的一些同事纷纷转到新副总的部门去了。我也犹豫过，但最后我没有去，因为我坚守了“雪中送炭”这一点，所以没有被一时的风向影响到内心。
+
+当时我为什么没有跟风？我觉得不能做那种丢下现有团队的人，要么就让我兼管，要么我就在原部门留守。原因有两点：第一，新产品还没有上线，公司的业务都在老产品上；第二，老领导现在也很困难，留守的团队士气低迷，我必须以交付的业务价值来给大家打气。
+
+所以，我把我所有的精力花在稳定原有团队上，坚定地帮助老领导按时按质交付年度计划。当组织大部分成员都把重心放在关心新产品的时候，我还是不遗余力地去把现有产品的稳定性和客户体验做好。
+
+记得这个期间，有一次老领导问我团队现在怎么样。我跟他说你放心吧，有我在，不会散。他说有你在，我放心。最后经过不少波折，在上海总经理的帮助下，我兼管了老领导和新副总在上海的两个部门。
+
+在适当的时候雪中送炭，人家才会觉得你有担当，才会格外信任你。
+
+## 特质三：小心承诺
+
+之所以把“小心承诺”这件事提出来，是因为我踩过的一个大坑。当时我过于关注维护自己的“领导力”，食言反悔，导致在一段时间里被贴上了“反复”“不可托付”的标签。
+
+故事是这样的，我和我们部门的两个部下一起去美国出差，因为我在总部领导面前过早让步，所以其中一个部下因为失望和我发生了严重争执。
+
+争执本身只是一个导火索，却把我对该小组缺乏领导力的问题暴露出来了。而另一位部下对我也非常强硬，认为我缺乏对总部领导的影响力，所以要求我回上海后按照他的安排补课。我知道补课这个建议是对的，当时犹豫了一下还是答应了。
+
+在接下来的一段日子里，又发生了一系列事情，我基本感受不到这两位部下对我的尊重。我觉得自己已经完全失去领导力了，心情非常差，差到我已经不想跟他们一起工作，最后我还是食言了，我决定不会按照他们给我安排的计划去补课。
+
+我现在回头来看，**食言这件事本身比失去领导力要严重得多**。就食言我得出的教训就是：不要轻易答应别人，宁愿当时自己说，要好好想一想，也不能轻易答应又反悔。如果你犹豫了，就必须警惕起来。因为事情还没有启动，你的态度就不坚定，这本身就是一个“食言”的预警信号。
+
+当然，小心承诺不是遇事儿推托，而是为自己的承诺做好准备工作。比如，你可以用一个checklist，来确认自己是否应该做出承诺。
+
+- 完成这件事情你需要哪些支持？这些支持你都有吗？
+- 如果你需要的支持现在你没有，你在答应别人之前能去做一个调查看看你到底需要哪些支持吗？你在答应别人的时候，你把需要的支持提出来了吗？
+- 你理顺一起做事儿的人了吗？跟着你去做这件事情的人，是可以跟你一起承担困难并且坚持走下去的人吗？
+- 静下心来问问你自己，你愿意为了这个承诺付出什么，牺牲什么？你心态调整到位了么，能达到无论如何你都会义无反顾，不放弃吗？
+
+<img src="https://static001.geekbang.org/resource/image/4e/97/4ed09b3387d7b430b28d8966ec331b97.jpeg" alt="">
+
+如果Checklist里的东西你都想清楚了，那你就去承诺吧。要么不答应别人，答应了就一定要做到。只要答应了对方，不管外面有什么诱惑，都不要再有动摇。
+
+## 特质四：意志坚定
+
+意志坚定其实是小心承诺在精神层面的保证。承诺了就要做到，说起来简单，但实际做的过程中你就是会遇到很多困难。都有什么困难呢？我拆解了一下，我们一起来感受下。
+
+- **事情本身的难度**：一个技术难题解决不了，于是你要承受很大的交付压力。
+- **应对压力的难度**：和人相处不顺利，甚至是委屈，你要承受很大的精神压力。
+- **稳住团队的难度**：如果你放弃了，你的队伍很可能也会垮，怎么办？
+- **取得协同的难度**：完成承诺的事情依赖外部协同，缺少资源（人手、资金）是肯定不行的。
+
+管理的主体和客体都是“人”，非常复杂，这一重一重的难度压下来，如果你没有坚定的意志，肯定是办不成事情的。
+
+我举个例子，帮助你更好理解上面说的问题。在某项目上，我跟总部领导意见不一致。首先，跟总部领导意见不一致本身就让我心情不好。然后，在坚持自己的主见的过程中，一线执行团队又开始有人离职，这不仅会影响交付，还会对其他在职员工产生心理影响，甚至还有不明情况的其他人，开始拿这个问题在公司的内部论坛来说事儿。
+
+但是，我跟副总承诺过完成这个项目，所以“不退”是我的底线。那么，我是通过哪些办法来坚定自己的意志呢？
+
+- **想好对策**：面对事情本身的困难，从决心上我不会有一丝一毫的动摇，就算最后要我自己加班加点去写代码，我也照干不误。
+- **调整心态**：压力面前心情不好？那我自己调整心态，想一想医院里ICU 的重症病人，再不济随便去上海哪个急症室看看，在生命面前其他烦恼都是浮云，我的这些因为跟总部领导意见不一致导致的心情问题真的啥也不是。
+- **理顺思路**：我想要稳住团队，脑子要清楚，不能自乱阵脚。我应该拿出切实措施稳住在职员工，再次询问他们的诉求，在不影响交付的前提下及时调整。并且通过小步迭代，让大家尽快收到产品反馈。
+- **求助上级**：取得协同方面，马上去寻求帮助，找老板沟通，首先告诉他，我的承诺不变，所以他不需要考虑我会不会动摇，但是为了项目成功，我有现实的困难需要他的帮助。
+
+至少在我写这篇专栏文章的时候，我觉得可以做成前面和你说的这个项目。其实这有点像长跑，虽然你的意志说你很想坚持，但是你的身体真的受不了了。但如果你真的坚持、再坚持，越过那个“坎”了，整个人就会达到质的提升。
+
+总之，意志坚定会支持你持之以恒地向目标努力，就像打不死的小强。我也承认自己也不是任何事情都一定能够坚持下去，但当我做出承诺以后，我会通过各种方式树立意志坚定的人设，绝不轻言放弃。
+
+## 总结
+
+在谈术之前，如果可以的话我们一定会先谈一下道。在这一节里我也是一样的思路：
+
+我给你把**待人真诚、雪中送炭、小心承诺和意志坚定这四条特质**串联一下，你就会发现，**它们都围绕着一个核心——那就是“信任”**。
+
+首先，一个人就要待人真诚行光明正大之道，这个是基础。待人真诚了，你才能赢得他人的信任，而信任正是我们的第一领导力。
+
+其次，我特别强调了要多做雪中送炭的事情，一个人不要太功利。这个特质也是真诚的一种执行层面的延续。在构建人和人之间的信任关系上，效果要比锦上添花好很多。
+
+然后，你要小心承诺，这样能降低风险，以免你准备不足食言，甚至失去别人的信任。如果你不希望对自己的定位就只是可用之人，而是还希望自己是一个可信之人。要做到这一点就必须是言而有信，并且不管你是面对诱惑，还是面对困难，都会坚持把承诺兑现。
+
+最后，我觉得意志坚定也是让自己更“可信”的一个精神保障。作为经理人，意志坚定不仅可以让你的上级更放心把重要的事情交付给你，而且意志坚定这点，对于团队在困境中继续向前是非常重要的。
+
+你现在是一名经理，是一个团队的一把手。你在做，你的团队成员在看，你的待人处事原则，会直接影响你的团队的待人处事方式。
+
+## 思考题
+
+1. 如果曾经跟你合作过的领导和平级离职，也就是不再掌权，你会做些什么？
+1. 即使我反复说了要做打不死的小强，如果你在实际工作中还是觉得压力很大，做得很不开心，但是你又有承诺在先，你会具体做些什么，来增加自己坚持下去的可能性？
+
+欢迎在留言区晒出你的思考。如果有收获，也欢迎你把这篇文章分享给你的朋友，说不定也能帮助他思考自己的处事方式。

极客时间专栏/geek/技术管理案例课/开篇词/开篇词 | 一个技术总监的管理“自白”.md

@@ -0,0 +1,77 @@
+<audio id="audio" title="开篇词 | 一个技术总监的管理“自白”" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/1e/04/1ef9412d44d9aec5559f94c9650c3404.mp3"></audio>
+
+你好，我是许健。欢迎来到我的“技术管理案例课”！
+
+我是一个在IT行业摸爬滚打了16年的老兵，算起来我走上管理岗位也有8年了。现在我是eBay基础架构工程部的研发总监。和很多人不同的是，我不是“被迫”走上管理岗位的，我是主动要求的。
+
+记得那会儿我差不多已经工作了8年，感觉自己在技术上还可以，但是离独当一面还是有一定差距的。那时我就想多做点事，不希望哪天有什么机会轮到我的时候，却发现自己能力不够。于是，我找到了我的老板，跟他表明了自己的想法，希望能够得到更多锻炼的机会。
+
+虽然我已经做足了心理准备，但是真的走上管理岗后，我还是进入了迷茫期。我觉得自己的技术竞争力在消退，团队里人的问题也层出不穷，比如：当时我大部分的精力都放在了开会上，所以没有沉到一线了解细节，也没能静下心去梳理团队的长期规划，更没有专门找时间，去培养自己跟团队关键人员的信任关系……最终这些问题在一次组织变动的时候就一起爆发了。
+
+那时候，我真的觉得自己撑不住了。
+
+现在回过头来看，我感恩经历的这所有事情，这些酸甜苦辣塑造了现在的我。回顾自己这些年的成长，我发现**<strong>技术管理最有效的学习方式有两种：一种是在实战中自己反思和总结；另一种是有人结合真实的案例，一对一地给你分享经验。**</strong>
+
+所以，我想通过这门课把自己经历的这些“坎儿”分享给你，一对一地给你分享我的经验。如果你现在还不是经理，我希望你看完课程后，能更好地理解经理的思路，从而指导你更有效地工作；如果你已经是一名经理，也正处于迷茫期，希望我的案例分析能和你产生共鸣，给你提供一些参考，让你少走一些弯路。
+
+我先给你分享一个之后课程里还会细讲的案例吧。
+
+有一次，在一个项目A上，我跟总部领导意见不一致。首先，意见不一致本身我心情就不会很好。在我坚持自己的主见的过程中，团队里又有人离职，员工离职直接影响到项目交付，也会影响到其他在职人员的士气。雪上加霜的是，有些不了解的情况的人也开始拿这个在公司论坛上来说事。我当时真的是负重前行，觉得十分艰难。像这种复合的难题，到底要怎么处理呢？
+
+我的解决方案具体有下面四个维度：**想好对策、调整心态、理顺思路和求助上级**。
+
+首先针对业务交付，制定出最坏情况的应对对策；然后你自己要做好情绪管理，直面困难；接着清醒地分析团队怎么稳住，不影响交付的前提下满足团队人员的诉求，提振士气；最后，还要有“把上级纳入你的团队”的思路，团队外部协同上遇到问题时，你一定要主动求助上级。
+
+你看，我只是随手给你举了一个发生在我身上的例子，其实背后有一系列可以思考的内容和对策。放到我们管理的层面，这样的事情经常发生，怎么处理呢？其实我觉得方法都是一样的。
+
+那对应的，我就想用我这一整套的思维方式和做事方法来给你讲这门课。具体我会怎么给你讲呢？
+
+首先，我一直有记录、总结、复盘的习惯。做管理这么多年，我把我自己经历的挫折、受过的委屈、获得的赞赏，全都系统梳理了一遍，并精选了一些做技术管理的过程中最有共性的、同时我印象最深刻、促使我成长最快的案例，与你一一进行抽丝剥茧，逐个复盘分享。
+
+其次，我还会和你分享这些常见问题的解决方法。我不仅会给你展示应该怎么做、怎么说的正确方案，我还会把那些很多人都会犯的错误，都给你一一列出来，让你清晰、明确地知道这之间的差距。除此之外，我还会给你讲清楚，这些解决问题方案背后的思考路径。这样，你不但掌握了管理提效的方法，也能参考我的思维方式，建立你自己的“管理模型”。
+
+每一个成长飞速的选手，都有一套行之有效的复盘方法。因此，除了方法，我还希望你能从这门课中学到工作复盘的正确路径。这样，你还可以拓宽自己看问题的视野，学会怎么用复盘优化自己的管理能力。做案例分析时，我也是在带着你不断演练复盘的技巧。我将把我遇到的困难、应对方法，以及事后反思、迭代的全过程，按步骤为你一一呈现。
+
+为了带你循序渐进地学习，我会通过**技术管理之路的开启、一线经理、二线经理、技术决策者4个模块**，逐步分享我的心路历程和实战案例。
+
+你可以先看看下面这个我为你梳理的**技术管理技能全景图**。你可以结合自己的情况快速对照，看看自己哪些做得比较好、哪些做得还不够、哪些目前还没想到。
+
+<img src="https://static001.geekbang.org/resource/image/85/5a/85e0cc95627583a3b1398b3f4eb7195a.jpeg" alt="">
+
+学完了这4个模块的内容，你就掌握了我这8年的技术管理实战经验。这一门技术管理案例课，其实就是**带着你经历“挫折”**。我们就像侦探一样，回到每一次“事故”的现场，抽丝剥茧地剖析问题，找到解决方案，并总结方法论。
+
+那我就先带你感受一下“受挫”的滋味吧。
+
+挫折一：
+
+你现在是一线经理，团队里有好几个高级员工，他们个人能力强，性格也很强，想法跟你不一致的时候是会直接“开炮”的。你虽然戴着经理的帽子，但实际上你“领导”不了他们。怎么办？
+
+挫折二：
+
+你现在已经是二线经理了，开始带经理，团队也变大了，你突然发现自己的时间完全不够用，每天在各种会中串场。但是忙碌的你并没有管理好自己的团队，你发现你把自己给架空了。想要管理好一个更大型的组织，你一筹莫展，怎么办？
+
+挫折三：
+
+现在你需要做很多技术决策了，但是你持续和更高级别的领导意见不一致，总部领导不开心，你自己也不开心，决策根本落不下来。你发现自己陷入这种情况，又该怎么办？
+
+这几个场景还是很典型的，不知道你是不是正处在其中。可以先想一想，面对这样的问题，你有解决方案吗？如果你的问题还没解决，或者你对现在的解决方案还不满意，那就和我一起在课程里探索吧。
+
+相信，在课程结束的时候，你会和我一样，感谢这些挫折。因为每一次挫折都不会打倒我们，反而是遇到挫折之后，总会让我们发现问题、分析问题、找到解决方法，最能提升我们的管理实力。
+
+说了这么多，那到底啥是管理呢？我们没必要执着于一个最正确的定义，核心是这个概念能指导我们的实践。
+
+结合自己的经验，说到底，我觉得**管理就是通过培养人来做成事**。也就是说，管理要交付两个维度的结果，一个是交付业务价值，另一个是培养人，这两点相辅相成。
+
+培养人不是天天跟员工苦口婆心，不是天天跟员工客客气气，而是高标准严要求，严师才能出高徒。管理者要有父母心，我正是因为希望你好，才对你这么严。把你带到山顶，一把把你推下悬崖看你自己爬，在你快摔下去的时候却又能拉你一把。
+
+做成事意味着管理是需要不断地交付业务价值的，但也不是什么价值都要交付，我认为你要“集中力量办实事儿”，你要有你的主线并做聚焦和长期投入。而在你选择这条主线的同时，也意味着你放弃了其他的主线，真正难的其实是抗拒诱惑、学会放弃主线外的干扰项。
+
+管理更多的是一份沉甸甸的责任。你的决策、你的情商、你的逆商很大程度决定了你的团队和团队成员的发展。你所有的决定，都不再只关乎你一个人的利益。从此，你也就基本告别“随性”了，想发脾气的时候你要忍，遇到困难想放弃的时候你要坚持。
+
+我之前看过一张图，图片里面画了一个人，这个人自己背上插着一把刀，但是另一边他还在鼓励别人，看到后我真是很感慨。做管理其实也是这样啊，你就是那个自己身上插着刀，还要负重甚至负伤前行的人。
+
+<img src="https://static001.geekbang.org/resource/image/73/36/731e01f6fd1e534571e3dedd4ded4536.jpg" alt="">
+
+好了，说到这里我已经感觉很激动了。我非常期待想要给你分享我踩过的那些血泪坑，把自己这些年经历的案例拿出来，希望能用我的反思，给你一些参考和启发，希望带你养成学习和反思的习惯，让你少走一些我走过的弯路。
+
+当然，我更希望你今后无论遇到怎样的“坎儿”，都要坚定自己的信念，摆好心态，越挫越勇，成就团队，成就自己！让我们一起开启这趟管理的旅程吧！

极客时间专栏/geek/技术管理案例课/技术决策者：开始定战略了/22 | 技术决策（1）：技术管理者做什么，团队效率才最高？.md

@@ -0,0 +1,173 @@
+<audio id="audio" title="22 | 技术决策（1）：技术管理者做什么，团队效率才最高？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/78/6b/78de26ddde83d324c542e640d740916b.mp3"></audio>
+
+你好，我是许健。
+
+前面两个模块，我给你分析了作为一名一线经理常见的坑，从关注事情到同时关注事情和人的转变，在招人，培养人，裁人方面的注意点，以及跟领导和跟高级别员工的沟通心得。接着在二线经理的部分，我们又用具体的例子从变革管理，冲突管理，组织和文化，危机管理等多个方面介绍了一名二线经理相对于一线经理所面临的进一步的挑战。
+
+从今天开始，我们进入课程的最后一个模块：技术决策，这个模块是我特意放在最后的，而且我认为正是因为有了这个技术决策模块，才能体现技术管理和一般管理的区别。这个模块，我设计了3讲，今天就先来带你讨论：启动一个项目时，技术管理者都应该做什么，才能让团队的效率最高？
+
+为什么要讨论这个话题？我先给你举个很简单的例子。
+
+有这么一个部门，当前最大的痛点是开发效率不高，而开发效率不高的原因是测试困难，测试困难最大的问题是因为缺少高质量的测试数据。如果你是部门领导，你会怎么做呢？
+
+如果你做出的决策没有从“高质量的测试数据”这个关键事项入手，很可能就走偏了。比如我们把大量的研发力量投入构建新一代的基于容器的持续交付CD pipeline（持续交付流水线）  ，你就算构建的这条流水线很先进了，但无法提高测试数据质量，也就无法提高开发效率。
+
+而且因为要做新的CD pipeline， 要投入了大量的人手，这些人手本来可以去做更有意义的事情，这么一算，因为这个决策，团队效益还可能是负的。
+
+你看，一个部门具体做什么本质上是由这个部门的一把手决定的。我们课程前面讲的所有管理技巧，如果没有这里说的做正确的事情，那就都是浮云。
+
+好了，说到这里，做一个正确决策的意义和价值，我想就不用再强调了。那接下来我们最关心的问题就是，到底怎么才能做到呢？接下来，我就带你一步一步来找到答案，这第一步就是定义好问题。
+
+## 定义好问题
+
+有一句话叫做“优秀的人眼中都是活”，这句话说得有道理，不过，放到我们现在说的战略决策场景下，这样是不够的。
+
+在实际工作中，不会像文章里我一开始给你举的例子那样，痛点和难点都那么清晰。你通常会看到很多的点，但是作为经理，你不能眼里全是点，你需要更进一步，尽快找到那个“打蛇打七寸的点”。因为你要带着团队在这个点上长时间投入，这是关于你整个团队接下来几年发展的点。
+
+我们还是结合具体的例子来看。以我们部门的PaaS团队来说，团队遇到很多挑战：
+
+1.我们整个技术栈正在往Kubernetes转，目前是当前系统和新系统双线作战，我们是不是应该把现有系统彻底淘汰？
+
+2.我们虽然迁移到新技术栈，但有一些顽固问题长期无法得到解决，比如IP分配冲突，实现自动且无风险的删除操作（删除一直是高危操作，因为删除造成业务影响被开除的员工在我记忆中有好几位了），以及淘汰不再使用的线上应用。
+
+3.公司正在往流量管理设备软件化、分布式化演进，PaaS的团队成员要不要加入这个方向呢？比如Istio或者Envoy。公司因为做支付对基础架构安全性要求越来越高，PaaS团队要不要去做基础架构安全方向？
+
+这是几个比较典型的挑战事项，其实我还可以列出很多。那问题来了，我们现在不是选择太少，而是选择太多，那我们应该按照什么样的原则来做决定呢？PaaS的经理曾经让我在以下**三个因素**中做排序：
+
+1.能不能产生业务价值，注意有些能产生业务价值的事情并不需要很强的技术支撑，比如系统集成和客户服务质量。
+
+2.技术实施有深度，员工做了这个项目自身市场竞争力提高显著。
+
+3.解决问题的范围可控，对外依赖少。
+
+我最后的排序是1 &gt; 3 &gt; 2，PaaS的经理说他也是这个排序。那接下来我就按照这个顺序，从业务价值、范围可控到技术深度，带你逐一剖析。
+
+不过这里我需要强调一点，**如果你没有办法把现在手头的日常工作的效率提高从而空出人手，那就先别去想新东西了。**也就是上面PaaS团队的3个挑战，在淘汰老系统和解决固有问题完成之前，做新东西这个决策根本实施不了。
+
+### 业务价值
+
+我们先来看有没有业务价值。可以说，凡是启动新的项目，大家都会说自己是为了业务。我想说的是：**有没有业务价值不是你说了算，而是你的客户说了算。**可是又有人说，不可以用户说了算，“用户很多时候不知道他们要什么”，你看乔布斯都这么说。
+
+可是我们毕竟不是乔布斯，如果一个人想要就业务价值发表看法，我通常会先思考下面这两个问题：
+
+- 说这句话的人到底花了多少精力跟客户在一起？
+- 说这句话的人之前是否有过让客户惊艳的经历？
+
+如果两个问题的答案都是否，那还不如踏踏实实地先去解决几个我们明确知道的客户痛点，再发表高论。
+
+回到前面PaaS团队的问题，我们来对比一下下面对于业务价值不同的表述：
+
+<img src="https://static001.geekbang.org/resource/image/d1/b5/d1fa4651e54aeda1be654cec072cbab5.jpeg" alt="">
+
+通过对比，你有没有发现两种表述的不同呢？
+
+表述1更多的是在说技术实现或者陈述一个任务，而表述2才是真正的从价值层面来阐述为什么我们要做一个投资。
+
+我举个很现实的例子做解释，测试环境稳定性的问题，如果按照业务表述1大家的关注点就是那100%的迁移指标，但是业务表述2强调的才是真正的测试环境可靠性问题。
+
+事实上也是这样的，这件事我们就是因为没有强调真正的业务指标，后来导致一大堆客户抱怨，甚至投诉到了CTO那里。而IP分配的顽固问题是我现在向团队反复强调的点，不要在我面前再反复说我们要用新的IPAM替换RAS，请明确我们的问题解决方案，迁移只是方法，彻底杜绝IP冲突问题才是目的。
+
+### 范围可控
+
+定义好了我们的目标，也就是确定了业务价值，我们来讨论问题范围。你是在公司做事，**需要按阶段交付业务价值。**你的交付时间拖得越长，别人对你期待越高，失败风险越大。
+
+以PaaS团队IP网段的问题来说，最初分配其实是网络部门管理，而网络部门并不隶属云计算部门，如果我要PaaS团队解决这个问题，必须评估网络部门的配合程度，最好网络部门有专人负责并绑定他的年度业绩。
+
+我给你总结一下“问题范围可控”的注意点：你把解决问题的依赖全部列出来，然后对每一个依赖评估重要程度和你对这个依赖的控制力有多强。对于关乎你成败的重要依赖，如果你的控制力不够，要么你能够得到领导的足够支持搞定这个依赖，要么你能够重新审视你的技术决策，看看能不能去除这个依赖。如果都搞不定，请问问自己，这个问题是不是应该你来解决?
+
+<img src="https://static001.geekbang.org/resource/image/e0/ae/e077f2b16418d7cfd58fa7d4e25b43ae.jpeg" alt="">
+
+### 技术深度
+
+最后来说技术实施深度的问题。虽然在定义问题的考虑因素时我把它排最后一位，但这却是我在技术决策中最棘手的一个问题。
+
+为什么这么说呢?因为事情都是人做的，团队成员除了交付业务价值外，还会关心自己的市场竞争力。如果实施的技术深度不够，也就是说不足以让成员感受到他自身的实力会因此提升，那他的积极性是不高的。
+
+还有一个很现实的问题摆在眼前，如果不是奔着市面上很火的技术方向走，你很难招到高质量的人才。相信我，我也曾给自己打气说“真正优秀的人才，才不看技术栈，哪种技术只要做到极致都是高手。”但现实让我不得不重新审视这个问题。比如虽然我很想给PaaS团队补充优秀人才，但无论从数量还是质量上说，我在Kubernetes方向收到的简历都优于PaaS。
+
+具体到PaaS团队的问题3，也就是如果做基础架构安全方向，如何更加快速地满足安全合规要求呢？我的思路是这样的：
+
+**第一，业务价值优先，技术必须服务于业务。**这也是我们在定目标的时候，为什么先强调业务价值而不是技术手段。这里需要我们好好学习一下PCI的DSS（支付行业数据安全标准）和GDPR（通用数据保护条例）规范。安全合规要求涉及用户隐私信息的交互不能泄漏，不能篡改。
+
+**第二，首选公司内长期不能得到解决的棘手问题。**特别是那些历经几代技术变迁却长期无法解决的问题，尤其值得我们关注。比如不影响业务前提下，我希望我们具备给大规模基础架构做安全强化的能力。
+
+具体来说就是如果安全需要，我们就可以迅速给任意应用之间通信升级TLS版本。要知道我们公司上一次只是给PCI环境应用升级TLS到1.2就动用了业务开发，流量管理运维，网站监控多部门一起在War Room会战了数个月才完成。
+
+另外我还想发展一项能力，就是能给安全需要的任何应用添加粒度更细的权限管理。
+
+**第三，我不想跟趋势斗了，看看有没有什么新的技术趋势可以用****乘数效应解决问题。**如果去看看业界做安全的公司现在在解决什么问题，安全方面有什么重要的会议和期刊，这个时候零信任，Beyondcorp，Istio，OAuth，APT 这些名词就会进入我们的视野。从趋势来说，我会倾向决策模块往Beyondcorp多维度决策引擎方向发展，执行模块往Envoy Sidecar这样贴近应用的非侵入方式发展。所以我们的专注点应该放在智能IAM和Envoy上。
+
+**第四，试图以最短路径交付效果，绝对要克制贪念，控制作战范围，小步迭代。**比如我一定要使用Istio加Envoy来实现更细粒度的应用间隔离，还是就使用Envoy和公司内部已经有的IAM/IDM系统集成呢？我倾向于第一阶段先跟公司现有系统集成，逐步过渡到Istio的方式。而智能IAM的事情，也应该先选取一个核心系统部署智能IAM，而不是一上来就要做一个又大又全的新方案。
+
+其实关于技术深度这个问题，我是层层深入和筛选关键点的。首先框住为业务服务这个大框架，然后第二层着眼解决现在的难点，接着第三层是选择符合趋势的技术，最后第四层是选择实现的路径。
+
+<img src="https://static001.geekbang.org/resource/image/50/21/50a374e1f692843b1696308512be9021.jpeg" alt="">
+
+好了，到这里，定义好问题的三个核心要素我们就讲完了，也就是业务价值、范围可控、技术深度。
+
+公司都是很珍惜能够解决问题的人才的，**但是其实能够发现好的问题的人才更可贵。**这需要你首先有这个心，然后出这个力，还要长期坚持，因为定义问题是一个从模糊逐渐清晰的过程。
+
+目前我们部门副总已经明确了安全方向，但是具体哪个部门做什么还没有很清晰的界定，在PaaS 团队的这个问题上，我就特别缺少帮助我定义问题的人才。
+
+那接下来，我们就来看看定义好问题后，怎么找到关键的人。
+
+## 找到关键的人
+
+eBay其实很早就开始做云计算了，在我加入云计算部门之前已经做了两代产品，但是都失败了。
+
+失败的原因我的分析是这样的，云计算部门是由一群软件工程师组成的，而解决基础架构自动化程度不够的问题，却一直是由基础架构运维部门在负责。后来第一代受到认可的云计算自研系统之所以能成功，原因之一就是大领导做了组织重组的决定，把运维团队里最懂eBay基础架构日常问题的最重要的骨干挪到了云计算部门。
+
+我们公司现在正在做自己的支付系统，于是整个公司对安全越发重视。副总更是直接说，我们基础架构工程部接下来最重要的事情就是平台安全。那作为经理我就想到了两个问题：
+
+第一，我们公司做支付已经做了两年了，为什么我没有想到应该提前布局安全，而要副总现在说了我才开始思考。
+
+第二，亡羊补牢未为晚也。我们可以做什么产品能帮助到公司的平台安全。
+
+我找到了总经理，希望她帮忙找安全部门的副总牵线搭桥，然后我主动申请做了公司安全部门在上海的总联系人。通过这个途径，我开始慢慢地熟悉安全部门的各级领导。
+
+我还准备做一件事，就是找到eBay的PayPal部门拆分时分到PayPal去的老同事，向他们学习PayPal在处理支付安全时基础架构部门所经历的变迁，最好能够帮忙引荐其核心人才取经。我的专栏写到这里，我突然觉得甚至可以直接给PayPal的CTO写邮件，看看他会不会回复我。
+
+这里有一点不知道你注意到没有，**我们这里往往需要找到的那个人是领域内专家，而不是通才。**而作为技术经理，除了找有兴趣有潜力的部门内人才做培养计划，也应该不遗余力地的去寻找外部的高手咨询，甚至直接劝高手加入。
+
+## 人理顺了吗
+
+即使你能够定义了一个很好的问题，你也找到了关键的领域专家，你就真的能顺利地启动新的项目吗？答案是不一定的。要知道，如果你推出的是一个颠覆性预案，你就是动了被颠覆的那个产品团队的利益，很容易遭到反对。而很多时候，新的产品刚出来的时候都还是原型，并不成熟，被人找到理由拍死也是有可能的，那这时候怎么办呢？
+
+我想提醒你的是，不要老想着颠覆别人，其实这又回到了决策透明和信任的问题上来了。这就需要我们把相关的人给理顺，这不是一件简单的事儿，需要我们平时花功夫去和项目相关的核心人员沟通交流，尤其是那些持反对态度的关键人员。
+
+我们部门的架构师老T说过一句话很经典：**你要把有可能提反对意见的意见领袖变成你的盟友，帮着你去说服其他人。具体方法就是把问题抛给他，让他参与进来帮你一起想办法，这样他会觉得最终的解决方案有他相当大的贡献。**而很多人因为自己内心要独占功劳或者占大部分功劳的原因，不去主动拉意见领袖入伙，结果后续立项反而遇到更大的阻力。
+
+讲到这里，我们基本上就可以作出一个正确的技术决策并启动项目了。不过，还有一个点我要特别交代下，这也是我自己这几年特别有感触的一点，那就是把握趋势。
+
+## 把握趋势
+
+eBay中国研发中心作为离岸研发中心，这几年的发展很快，现在几乎所有的重点投资项目我们都有参与，而且重要性很高。但是我时常问自己一个问题，每一年总部确定的新启动的重点投资项目中，有哪些是我们部门首先提出来的？结论是很少的，为什么呢？
+
+我的结论是除了总部信息量比我们大之外，另一个主要原因是我对技术趋势的研究跟进不够。我在这里做个回顾，看看技术趋势相关的内容都是在何时出现的：
+
+- 谷歌在2014年开源Kubernetes，在2015年发布了BORG的论文，而我在那段时间却从未关注过谷歌的频繁动作，那基于Kubernetes的最新一代云计算平台自然不可能由我发起。
+- 最近开始火起来的Clickhouse系统，在被总经理教育眼光不够之前，我从未意识到该系统对OLAP分析的潜在巨大影响。而ClickHouse开源的时间早在2016年。
+- 谷歌的Spanner系统和相关论文发表于2012年，在我们公司启动分布式数据库项目之前，我从未听说过谷歌的Spanner系统和相关论文。
+- 据说我们公司的图片存储系统多年前启动时，也是总部的高级别技术专家看了Facebook的Heystack 相关论文。我查了一下，Facebook的这篇论文发表于2010年。
+
+我自己复盘的收获是：当你看到一个比较火的开源系统已经是比较晚了，往前推是业界前沿的技术公司发表的文章（哪怕不是开源的），再往前推是对应领域顶级会议上的论文。
+
+你看，这其实就是**了解技术趋势的时间线：领域内顶级会议论文-业界前沿技术公司文章-开源项目。**你越早能把握这个趋势，你就有越多的时间来准备你要发起的项目。
+
+## 总结
+
+最后，我们来总结下这节课的内容。技术决策的正确与否、质量高低决定执行效率，方向错了什么都是空的，不单影响业务，还会影响团队成员的成长。
+
+今天我们一起梳理了技术决策的准备过程怎么做，首先你要学会怎么定义一个问题，从业务价值高低，解决问题的范围可控和技术深度三个层面来考量，权重依次降低。
+
+技术决策很依赖领域内专家，作为经理我们要去找到这样的人，让他给你提供信息。有时候我觉得我们找专家的劲头，要跟做销售差不多，要动用一切的人脉去找。
+
+接下来，秉承我一直坚持的人和事并行的思路，人一定要理顺，特别是公司里那些意见领袖，你不把他们拉进你的队伍，他们就有可能成为阻力。而且让他们参与进来，还能给你一些技术决策参考，何乐而不为呢？
+
+最后，作为一个技术经理，把握技术趋势会极大帮助你做出有前瞻性的决策，这也是我们的一门必修课。
+
+## 思考题
+
+你能分享一个自己经历的新项目启动的例子吗？你能同时复盘一下，从这个项目启动之前的准备工作中学到的思路吗？
+
+欢迎在留言区晒出你的经历和疑问。如果觉得有所收获，也欢迎把这篇文章分享给你的朋友。

极客时间专栏/geek/技术管理案例课/技术决策者：开始定战略了/23 | 技术决策（2）： 拥有辩证思维，才能在纠结中负重前行.md

@@ -0,0 +1,154 @@
+<audio id="audio" title="23 | 技术决策（2）： 拥有辩证思维，才能在纠结中负重前行" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/97/bb/9742cbd44754b313cf76087f5cdbfebb.mp3"></audio>
+
+你好，我是许健。今天我们聊一聊技术决策的辩证思维。
+
+但凡重要的技术决策，决策过程一般都是很艰难的，决策时需要考虑的点又是千头万绪，再加上决策效果通常是影响重大的，这些直接导致决策者处于焦虑纠结的状态。
+
+我自己也时不时陷入这样的状态，为此我很想总结出一些方法论指导我做决策，就像专栏前面的文章中多次提到的那样，我会从自己实际已经经历的事情和正在经历的具体案例中做分析、做反思。
+
+最后我发现自己总结出来的指导思想就是辩证思想，但是思路还是比较零散的。为了把零散的思路整合起来，我就去看了有关辩证法的资料，其中的重点就是毛主席的《矛盾论》，重新整理了思路，我才觉得较之以前系统了很多。
+
+今天我就想跟你分享一下怎么用辩证的眼光来看待和分析技术决策，希望可以帮助你做出更合适的技术决策。
+
+## 让你觉得痛的才是决策关键点
+
+我在专栏中曾多次提到，想要从根本上有提高的事情都不是简单的事情，如果一个重要的问题已经存在很久了，那你也不要有不经过艰苦奋斗就能解决这个问题的幻想。
+
+但是即使有了这种认识，对我们做技术决策又有什么帮助呢？接下来我们先看一个例子：
+
+我们公司之前的配置管理系统ODB已经服务十年了，里面存放了各种系统的模型，一方面由于很少去除过时的模型，这导致很多模型动辄上百个字段，而且里面还有很多无用字段；另一方面，数据量的膨胀使得ODB系统性能越来越无法满足需求。
+
+一开始我们尝试在原有系统上做改进，但改进版本也就是ODB 2.0系统研发失败后，领导最终下定决心做一套新系统，取名CMS。又花了半年多开发完CMS核心，接下来迎面而来的挑战就是原来围绕ODB的周边系统搬迁问题，对于大部分人来说都会将未知的事物默认为有风险的，这时没有人愿意做小白鼠。
+
+所以，我们必须把一套众人皆知的、具有足够代表性的复杂系统从ODB无缝搬迁到CMS，这样才能有底气说服其他系统搬迁，而这个足够有代表性的系统就是第一代云计算系统Stratus。
+
+第一代云计算系统做迁徙的项目由我们云计算部门负责，我让J做了项目实施评估，最后J告诉我预计需要24周，这个时间投入是我自己预计的两倍还多，而且还需要全组每周两次加班。
+
+当时我问J为什么要这么大的投入呢？要知道这个决策一旦定了，基本上就意味着我们全组半年内任何其他的事情都干不了。J给了我一张单子，上面列出了所有需要修改的源代码文件列表，还有所有的测试需要的投入。
+
+另外，J跟我解释了他特别设计了两处细节保证整个迁移步骤顺利：
+
+第一处细节是设计ODB和CMS读写开关，一开始Stratus仍然读ODB，然后保证下游还没有迁移到CMS系统能正确工作必须双写ODB和CMS，逐步过渡到Stratus读CMS双写ODB和CMS，再过渡到只写CMS。
+
+第二处细节是在切换过程中如果一个任务启动的时候是读ODB，那么即使在执行过程中全局切换到读CMS，为了数据一致性该任务还是应该继续读ODB直到任务完成。
+
+我还记得J跟我说：“许健，要么你找别人来负责这个项目，你要是让我来负责，我就是需要这么多时间和这么多人。”我当时有一种孤注一掷，也就是把所有家当都投进去博一把的感觉。
+
+后来实际执行中，我们发现上线前的各种测试比之前预计的更复杂。最后的结果是在J的预估投入之外，又加了一个月的高强度集成，我们才交付Stratus On CMS这个任务。但是我们上线没有导致任何生产事故，总部的云计算负责人K事后专门给我和J写邮件，K说我们做的工作就像是在高速公路上不熄火换引擎，我们做这么大的动作没有出事故非常不容易。
+
+多年后在做AI Ops异常检测平台的项目时，J还让我做过更难的选择：“许健，我们现在有两种做法：一种是我们按照现在的方法做，三个月后我能交付一个效果比现在好的方案，但是这个方案还是没有办法使客户大规模上线；第二种是我们用新办法投入六个月，到时我们有可能取得突破，使得大规模上线客户成为可能，也有可能什么都做不出来。” 我最后选择了第二种方案。
+
+因为J比较资深，所以一般我让他处理的问题都很关键，而每次他在跟我落实具体投入的时候都让我觉得挺痛的。这么多年下来我开始“喜欢”上这种痛的感觉，如果我认定的重要问题在做决策的时候自己不觉得痛，我反而会觉得不对头，一定遗漏了什么关键点，毕竟世上没有天上掉馅饼的事情。
+
+总结下来就是：**如果你不觉得痛，宁愿相信有什么地方不对劲，那么****就应该继续挖，直到挖到那个让你痛的点为止。**这个思路在我做决策的时候屡试不爽。
+
+比如最近我们要在年底前交付基于Kubernetes的流量管理方案，老孟是总负责，我问老孟需要我做什么吗？他说不需要，我当时就跟老孟说我的感觉不对，这么重要的一个项目，我怎么觉得你给我提的要求一点也不痛呢，然后老孟说了两点要求：
+
+- 现在总部领导一直在强调中美团队合作不够好，信任有问题，但是这个项目要说服总部领导把执行全权交给老孟负责的中国团队完成。
+- 有一个关键依赖是全局流量切换模块GTR，该模块负责人身上的高优先级工作很多，能不能让他承诺把我们对GTR的依赖排进优先级。
+
+这两个要求就有点难了，特别第二个点如果我搞不定我只能自己贴人去做GTR ，这意味着我要砍别的项目了，相当于割那边的肉补这边，这对我来说是很痛的。但是这个感觉让我至今难忘，因为这种痛这说明我们在解决核心问题了。
+
+后来我回顾这个项目，发现项目的交付和后来老孟提到的两点紧密相关，可以说是绕不过去的“痛点”。中美合作的要求如果不落实，就会导致决策缓慢、拖慢整体节奏；关键依赖不解决，后续迁移就跟不上，因为一个新系统如果不去接手原来系统的流量，那就不能算作“完整交付业务价值”。
+
+## 矛盾的普遍性和特殊性
+
+前面我们更多的是从决策的艰难程度去谈，但只是靠着这样的感觉去指导我们做决策还不够，所以我们还要考虑到矛盾的特性。
+
+毛主席在矛盾论中说：“我们的教条主义者在这个问题上的错误，就是**不懂得必须研究矛盾的特殊性，认识个别事物的特殊的本质，才有可能充分地认识矛盾的普遍性，充分地认识诸种事物的共同的本质。**”
+
+我现在看到这句话特别有感触，我觉得我们部门之前就是没有懂得这个道理，才导致我们做了很多努力，却没有特别出色的业绩。这个道理就是想要研究矛盾的普遍性，先要研究矛盾的特殊性。我给你举个例子说明：
+
+我之前在[组织管理](https://time.geekbang.org/column/article/291930?utm_source=pinpaizhuanqu&amp;utm_medium=geektime&amp;utm_campaign=guanwang&amp;utm_term=guanwang&amp;utm_content=0511)那一节的思考题里面曾经提到过开发效率的问题，事实上提高业务开发的开发效率是我们的核心任务，我们有一个团队专门负责测试效率这个事情。
+
+这个团队开发了不少工具来提高开发效率，比如CD Pipeline（持续集成流水线）；测试覆盖率和自动化率统计报表，我们内部又叫这个报表耻辱墙，因为他们把这个报表贴在公司的各个人流量大的场合；还有一个叫My Stage的可以给开发人员创建独立的测试环境的系统。
+
+但问题是这么多年了，业务团队始终在不停地抱怨测试效率低下，而负责测试效率的团队除了抱怨测试环境的基础架构不如生产环境稳定之外，也抱怨开发团队没有对这个问题足够重视，没有编写足够的测试用例。
+
+在今年年初的时候我曾经思考过这个问题，我觉得以一个团队去服务上千名业务开发，如果平均用力，很难起到显著作用，还不如集中力量，盯准一个业务团队在一个点上深入挖掘，我建议在上海集中把支付团队的测试效率提上来，我选择这个方向考虑了下面三点：
+
+第一点，支付是我们公司这两年的重中之重，支付团队的测试效率是值得投入的。
+
+第二点，必须深入一线，并且派遣我们组织内的高级别技术人员到支付团队内部去。以保证我们能够在这个点取得突破。
+
+**我认为之前团队最大的失误就是浮在表面而不是深入一线，因为组织内最优秀的人都在做平台而没有去一线了解具体情况，所以最后做出来的平台，总是由于这样那样的原因，让业务开发的测试效率提升无法达到预期**。
+
+第三点，这也是我考虑问题的重要方面，上海有150多人的支付团队，如果我们在上海按照第二点提到的思路来做，是有本地的支持的。
+
+真正做起来以后，其实也碰到了一些问题，进度没有我想象的顺利，但是我们认为找支付部门做攻坚就是正确的策略。
+
+为什么这么说呢？因为我们正是通过给支付团队做服务这个**“特殊用例”**，才陆续发现了持续集成流水线不规范、消息中间件系统在支付测试场景使用不便、集成测试用例不稳定、多测试环境跟外部第三方支付供应商集成遇到的安全限制等一系列问题。
+
+在努力了一个月之后，支付部门有两个Scrum团队已经开始在日常工作中采用集成发布的流水线。这正是因为我们深入到别人的业务中了，才能体会到这个部门需求的特殊性，再然后把众多特殊的个案做归纳汇总，才会慢慢积累经验，总结出共性。
+
+我现在回头看，这其实就是给我们做技术决策提供了一个很好的思路，**不要一上来就说我要做一个平台，更好的方式是你有一个做平台的心，但是从解决一个具体的客户的问题开始，把这个客户服务好，从中了解实际的需求，解决好了以后再去找下一个客户，在特殊性中总结普遍性。**
+
+这个思路到底靠不靠谱，我们还是要用实际操作去验证。最近我们重新启动云原生体验（Cloud Native Experience）的开发，其实去年我们做过一次，但是做出来的效果并不好，每一个试用的客户总有一些需求我们不能很好地满足。
+
+于是这次我们重启项目之前，内部先开了一个会，团队的骨干老T在会上就直接说：“我很不喜欢我们的项目叫**Generic** On Tess （Tess 是eBay 的基于Kubernetes的云解决方案的代号），我觉得如果现在就奔着Generic去，我们很难成功。”这里老T说的“Generic”其实中文就是通用的意思，我认同老T的想法，觉得不能一上来就搞普遍性。
+
+那个会议我们讨论了3个小时，会后我找到项目负责人，我说我们在2020年第四季度和2021年第一季度各选取两个具体的客户吧，我们先特殊，再普遍，具体计划如下：
+
+第一，上海的数据分析部门因为安全合规要求，正在搬迁他们的应用到新的符合安全要求的Security Zone， 我们2020第四季度的目标是让这个部门的所有跟云平台的交互都能在我们新的Cloud Native的平台上无缝完成。
+
+第二，年底前，我们云计算部门应该能够完成 PCI DSS的合规审核，这样我们2021年第一季度就专注支付部门的应用采用云原生的方式部署，对我们自己的要求也应该是支付部门能够在我们的平台上无缝完成日常工作。
+
+这样我们就从两个具体的部门用例中学习他们的特殊性，并总结公共的普遍性。在跟数据分析部门接触的这几个礼拜下来，我们确实发现他们实际碰到的问题跟我们的想象有不少差别，比如他们把一个系统下的不同组件放在同一个应用实例下，而我们原先的模型是一个组件一个应用实例；再比如他们的应用很多是有状态服务，但原先我们认为他们大部分是无状态服务。
+
+根据实际情况，我们及时做了技术解决方案的调整，如果我们不从一招解决所有客户问题的“普遍性”思路，转变成先解决一个具体的客户的“特殊性”思路，那么这个调整就不会发生，我们就很容易重蹈覆辙。
+
+这里我还要额外提一句，如果你去看主席的矛盾论，关于矛盾的普遍性和特殊性我在本节引用的那句话，还有后半句：“**另一方面，不懂得在我们认识了事物的共同的本质以后，还必须继续研究那些尚未深入地研究过的或者新冒出来的具体的事物**。”
+
+这给了我未来做决策的指导，我在这里可以预测一下，当我们明年对数据分析和支付部门的用例学习整理进行平台化推广给更多部门后，我们还会再次碰到下一个阶段的特殊性问题。
+
+比如说，数据分析部门跟数据打交道的特殊性，以及我们公司没有成熟的数据测试平台在测试环境提供高质量测试数据，很有可能我们的云平台需要去适配实际业务需求，也就是在生产环境下部署数据分析部门测试应用，使得这些测试应用可以获取生产环境数据。这就是主席说的“新冒出来的具体的事物”。
+
+## 用发展的眼光看待矛盾
+
+我清楚地记得有一次公司的高管Debasish在到上海考察，那时他说我们整个部门（包括中美）是**“一直活在明天”**的部门，意思就是我们老是说我们要用最新的技术，用下一代的系统来解决基础架构管理的难题，却不踏实解决现在眼前的问题。
+
+我在之前的[文化建设](https://time.geekbang.org/column/article/293315?utm_source=pinpaizhuanqu&amp;utm_medium=geektime&amp;utm_campaign=guanwang&amp;utm_term=guanwang&amp;utm_content=0511)中提到我们部门要变成“说话算数”的部门，这里我认为最大的阻碍就是要求我们做的新东西太多了，所以我一直对做新东西持保守态度，但是最近我对做新的系统这个问题的认识有修正。
+
+我在[组织管理](https://time.geekbang.org/column/article/291930?utm_source=pinpaizhuanqu&amp;utm_medium=geektime&amp;utm_campaign=guanwang&amp;utm_term=guanwang&amp;utm_content=0511)那节课中提到的Account Resoure Quota的例子，我在相当长的时间内是认为该项目不能有效解决Capacity管理的难题，而且该项目并没有得到Capacity团队的充分认可。
+
+但是随着项目的推进，我有了进一步的认识，我开始问自己Capacity团队已经按照现有的方式管理公司资源这么多年了，为什么在控制资源利用率的前提下，加快客户获取资源的速度这个问题一直没有显著进展呢？
+
+如果我们全面地做分析，就应该把事情和人都考虑到：Capacity团队用现有方式来管理资源，而ARQ的发起人对于现有管理方式不满，这个矛盾事实上打破了原有的平衡。**矛盾暴露了，正确地解决了，事物就发展了。事物就是在矛盾的不断产生和解决过程中得到发展的。**
+
+ARQ这个新项目的启动暴露了矛盾，迫使整个组织重新审视Capacity和Quota的管理方式的意义是积极的。很残酷的一点是，不启动新项目搞“革命”，就很难引起Capacity团队的足够重视。
+
+我再用同样的思路看上文中提到的CMS取代ODB的历程，对公司最大的意义不在于CMS的性能更高，而在于ODB到CMS的迁移这件事的效果，它会迫使围绕ODB打造的所有周边系统重新整理。
+
+进一步说，周边系统整理意味着什么呢？这意味着这十年来积累的所有业务模型得到系统梳理，很多臃肿的模型就可以瘦身了，这就跟一个长期不盘点的仓库因为要引入电子账务系统不得不做一次大的盘点一样。
+
+**辩证地看问题，不再只看矛盾的一个方面，也要看到其对立面。**“活在明天”的云计算部门因为既要做新的系统，又要维护现有系统，头尾不能兼顾导致人员辛苦但是客户反馈却不好。这个情况当然要改善，但这个矛盾同时也存在积极的一面，就是一直在暴露公司基础架构管理的问题，在解决矛盾的过程中，不断推动更先进的方式引入进来。
+
+**辩证地看问题不再静止地看问题，而要发展地看问题。**在当前系统的客户满意度不够的时候，主要矛盾是解决当前客户问题，所以应该以提升现有客户体验为主，研发下一代系统解决明天的问题为辅助；而当前客户满意度提升后，要用更少的资源满足更多需求的这个效率上的矛盾，就会成为新的关注点，那时我们就可以考虑以研发下一代系统为主，维护当前系统为辅。
+
+当我用这样的想法再来看待Openstack和Kubernetes，Service Mesh和集中式流量管理，零信任网络和传统防火墙自动化等问题时，顿时觉得清晰了。
+
+其实，**这些新技术的引入就像一条鲶鱼，可以起到暴露矛盾的作用，打破原来的平衡，关键问题就会逐渐浮出水面，这是好事不是坏事。**我们会因此更加清醒，及时地发现问题，从而想方设法解决问题。
+
+所以这里我想给你的建议就是，我们要辩证地看待和分析技术决策，首先看方向和脚踏实地要兼顾；其次要客观看待矛盾，关注到困难的积极意义，通过“变革”解决问题不断前行；最后不要幻想有“一招鲜”的办法，而是要用发展的眼光看问题，根据当前主要矛盾选择合适的决策方案。
+
+## 总结
+
+今天我跟你分享了做技术决策的辩证思维，这些思维方式都是我这些年来在不自觉中总结出来的，也希望可以帮助你更加系统地进行技术决策。
+
+首先，如果你在决策中不觉得“痛”，就是一个很强的信号。因为**所有值得你去努力的方向都没有捷径，所有能根本上提升组织和个人的方法操作起来都不容易。**这个痛的信号提示你可能有什么关键的点没有考虑到，这时候不要自我感觉良好，请一定把那个让你觉得痛的点挖出来，这个方法在我所做的技术决策中被反复证明有效。
+
+接下来，在你准备执行决策，特别是解决一个比较大的平台级别问题时，建议不要一上来就要做又大又全的平台，而是应该脚踏实地找一个细分客户方向入手，在一个一个特殊性的解决过程中总结问题的普遍性。**要带着一颗做平台的心，从具体的案例开始**。这样才接地气。
+
+作为技术经理，我们越到后来需要处理的技术决策就越复杂，当你**看到事物的一个方面，一定要提醒自己去看一下它的对立面。**比如在你看到一个技术的好处时，一定要想一下你需要付出的代价。看到新技术所引入的不确定性等风险的时候，也要考虑到它打破原有平衡的积极意义和潜在的大幅提升效率的可能。
+
+最后提醒自己要用发展的眼光看问题，每一个阶段有该阶段的主要冲突点，你的技术决策需要以该阶段的主要冲突和矛盾为基础。而周边环境的变化很可能导致矛盾重点的变化，这时我们也要及时作出调整。
+
+<img src="https://static001.geekbang.org/resource/image/32/e8/324b1bee1ce1f7395f2fa8509892c7e8.jpeg" alt="">
+
+## 思考题
+
+我们副总最近确立了我们部门以平台安全为第一优先级，并成立了一个单独的团队来负责这件事，副总说平台安全需要做好几年，但是目前我们并没有很清晰的平台安全架构和执行计划，如果你是这个新成立团队的负责人，你准备怎么做？
+
+能否找一个你现实中的项目的技术决策，最好是那种很纠结的技术决策，然后我文中提到的辩证思维来分析这个技术决策案例并分享出来。
+
+欢迎在留言区晒出你的经历和疑问。如果有收获，也欢迎把这篇文章分享给你的朋友。

极客时间专栏/geek/技术管理案例课/技术决策者：开始定战略了/24 | 技术决策（3）：持续跟进进度，执行细节决定成败.md

@@ -0,0 +1,181 @@
+<audio id="audio" title="24 | 技术决策（3）：持续跟进进度，执行细节决定成败" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/cc/e2/cc64dcyy5a3e7def6397de15bd3aaee2.mp3"></audio>
+
+你好，我是许健。今天我们来聊一聊技术决策的执行问题。
+
+我在[人才招聘](https://time.geekbang.org/column/article/282069)中讲了招聘的时候要追问细节，在[进阶心路](https://time.geekbang.org/column/article/286095)里提到二线经理要下沉两个汇报级别到一线了解细节，在[危机管理](https://time.geekbang.org/column/article/293155)中还提到过我自己被架空的一个重要原因是没有深入到日常的团队运营中去，本质上就是没有去了解关键路径的关键细节。
+
+为什么我一直这么强调细节呢？因为我自己经历了好几次教训，追根溯源才发现都是因为忽视了细节，准确地说是对**关键路径的关键细节**不够重视。
+
+今天我想跟你聊的就是技术经理如何把控细节，如何通过技术细节交付好业务，培养好人才。
+
+## 做完决策就可以了吗？
+
+首先，我们做完决策就可以了吗？答案是否定的。
+
+我看过一本叫《执行》的书，里面有这样一段话：“这样做领导当然舒服喽，你只需要站在一旁，进行一些战略性的思考，用你的愿景目标来激励自己的员工，而把那些无聊的具体工作交给手下的经理们。我在这里要提出的是，这种思考问题的方法是错误的，它很可能给你带来难以估量的危害。”
+
+我对这句话深有体会。做决策只是起点，如果止步于此，等于空谈，为什么这么说呢？如果我们觉得决策做完了就万事大吉，那么常常就会有这样的后果：
+
+第一，是经理自己被架空。哪怕我们通过决策把工作优先级聚焦到了核心问题，但决策落地最后还是要靠执行的。如果不能把握关键细节，完整地跟进进度，经理就容易把自己架空。
+
+第二，会导致业务价值无法按时交付。有一次总部领导质问UX小组半年内没有交付业务价值，事后我跟UX小组的经理复盘时，才发现我们当时对于关键依赖的解决不及时，人员不够专注，而且起初的设计也过于复杂。但得出这三条总结已经是事后诸葛亮了。
+
+第三，就是无法解决部下的困难，再远大的目标最后还是要一步一个脚印地推进，技术经理要了解一线的具体困难，采取行动解决，否则会直接影响到自己的领导力。
+
+我这里想说的是，无论是一线技术经理还是二三线技术经理，尤其是二三线技术经理因为会花更多的时间考虑战略文化等事务，所以更要时常提醒自己去了解关键路径的关键细节。
+
+我们不要把自己架起来，因为一个项目一个产品不是静止的，在项目和产品的发展过程中会不断的出现问题，这些问题你不能单方面的等着下属自下而上汇报，也应该由上而下去了解。
+
+只有注重了关键的细节，你才能对你手上的关键产品和项目有比较全面的了解，才能持续地根据实际情况做后续的技术决策，**技术决策不是一次性的买卖，需要为了达成目标做持续修正，项目没有交付前就不能放松警惕。**
+
+## 关键细节如何把握？
+
+我们知道了执行细节很重要，那具体应该怎么把握这些细节呢？
+
+一般在执行过程中我会同时使用下面三种方式来了解执行状况，从而保证执行达到预期效果：
+
+### 方法一：执行负责人要制定可衡量的阶段性目标
+
+我的经验是计划会变这一点我认可，但是我不接受因为这个理由就不去制定计划。
+
+虽然我们可以理解很多事情很难估计时间，强行制定时间表的话最后也许就不能交付。那么很难估计时间的话，目标到底怎么制定呢？
+
+我的方法就是必须定计划这一条没有商量余地，但是可以做拆分，直到拆分的单元可以很好地做衡量。
+
+具体来说，就是如果季度目标不准就定月度，月度目标不准我们就每两周一次的Sprint目标，再不行我们就定每一周的周计划。
+
+### 方法二：定期的项目评审和周报
+
+为什么我要强调定期呢？定期的作用就是给执行负责人传递一个明确的信号，也就是他的上级技术经理正在持续关注他的进度，愿意及时解决他的实际困难。
+
+同时，这么做对执行负责人也是一种压力，每一次到了项目评审和周报的时间点，他都需要给领导和给同仁看到进度。
+
+关于项目评审和周报有下面三点注意事项：
+
+第一点，我不要听流水账，所以负责人要对照项目之前定下的阶段性目标来汇报进度。
+
+第二点，如果项目进行过程中有阶段性目标达成，或者有值得肯定和表扬的点，我会要求负责人单独注明。
+
+第三点，项目中碰到的问题也需要单独标注，这一条非常重要。我一般会建议执行负责人用绿，黄，红三色来对问题分类。绿色是已经解决的问题，黄色表示虽然出现了问题，但是执行负责人已经拿出了具体的措施在解决问题，目前还不需要上级领导介入，而**红色表示要求上级经理介入或者提供帮助。**
+
+在[辩证思维](https://time.geekbang.org/column/article/295028)一节中我讲到自己的一个思维习惯，就是重要的项目在决策过程中要挖掘痛点，如果没有挖掘到，我就会觉得有潜在问题，然后继续深挖。
+
+同样的，在决策执行过程中我想给你分享我的另一个思维习惯，如果我在项目评审和周报里只听到好消息，从来听不到困难和坏消息，我就会给自己提一个醒：这么重要的事情，在执行过程中这么一帆风顺正常吗？这会直接导致我找一线骨干做Deep Dive。
+
+### 方法三：不定时地找团队一线骨干做Deep Dive
+
+在日常工作中，技术经理要下沉两个汇报级别，去找一线骨干了解细节。其实我们在做关键项目的执行时更应该如此。
+
+具体怎么做呢？我是带着希望这个项目成功的心去“挑刺”的，我通常会这样去思考：**如果有三个原因造成我这个项目失败，是哪三个原因？我现在可以作出什么举措降低失败几率。**
+
+通过找团队的一线骨干了解细节，我发现自己对项目的了解更加全面，也能尽快发现实际操作下来经常发生什么样的问题，下面三类问题是最常见的：
+
+第一，对性能压测和失效性分析重视程度不够。我们部门在吃过几次苦头以后，在这一点上已经比较重视了。墨菲定律在我们部门负责的项目上几乎次次灵验。
+
+第二，对关键依赖过于乐观。现在我们部门对于关键依赖我的建议是：没有书面承诺交付时间的，就当这个依赖没有搞定，应该找高级别技术主管介入。
+
+第三，技术实现时夹带必要功能之外的加分项功能。从我们部门目前实际的执行历史看，在核心功能交付前，所有锦上添花的功能都应该全部砍掉。
+
+## 持续跟进的注意事项
+
+前面我们说了关键细节如何把握，但细节更多的还是一些关键节点，在技术决策的执行中，持续跟进还需要一个线性的思维，树立起对决策、对自己角色以及对未来如何做预判的认识。
+
+### 决策不等于落实
+
+请你跟着我回顾一下自己做经理的经历，我们总能轻易举出一系列半途而废的事情，这些事儿都是我们做了决定但是却没有跟进，最后不了了之，没有落实。那么问题到底出在哪里呢？
+
+**第一种情况，就是做了“建议”没有跟进。**这里我专门用了“建议”这个词，而没有使用“决定”这个词，这是因为如果我们都不去跟进确认，就不能算作决定。
+
+我给你举一个具体的例子来说明。我们部门已经多次出现误删操作，因为权限管理太松，发生过不应该有权限的人误操作，结果删除整了个测试数据库的情况。最近一次是因为数据质量问题，系统误删了生产环境流量入口，幸好部署了高可用HA防护才没有出大事。
+
+我做复盘的时候，想起我虽然一次一次建议要引入保底措施，在删除逻辑中加入流量检查保护。但到目前为止，我只是反复在强调不采取措施的风险，这个风险就是一旦出问题影响业务，会导致打乱我们所有的原定计划，然后全员都要去做系统可靠性强化工作。
+
+我的部下不是笨蛋，如果没有落实一定有现实的困难，需要我去了解具体的困难。很有可能落实这项工作是需要以牺牲功能开发为代价的。再联想到我一直强调“说话算数”，也就是我们部门承诺的功能一定要按时按质交付，我觉得问题出在自己只是做了建议，但没有继续跟进。
+
+我们不止一次踩了坑，还是出问题，想要改变一定是艰难的，那这个艰难决定一定是组织一把手来做。
+
+**第二种情况，就是没有落实标准。**在我们部门最常见的就是出了一个生产事故，于是在风头上大家都很重视，制定出一系列举措。问题是我们很少会去重现那个生产事故，通过测试进一步确认我们落实的那些举措的有效性，也就是在下一次发生类似事故时，我们指定的举措是否真正能够起作用。
+
+比如说我们上个月发生的一件事儿，因为一个BUG，PaaS系统的一个超级账号抹掉了整个测试环境监控系统，这个事故我们花了四个小时才恢复服务。
+
+在复盘会议上，团队成员觉得以后我们可以在20分钟内恢复服务，但这个想法没有落实到测试环境中检验，其实很难立住脚。
+
+所以我明确要求监控组一定要复制一套一模一样的线上系统，再做一遍删除系统后恢复的模拟测试。要知道，我们设想中可以20分钟完成的恢复操作，和真的做一遍，验证一下在20分钟内能不能恢复是不一样的。
+
+其实本质上这类问题都反映了技术经理的重视程度，特别是和经理是否能够持续重视密切相关。作为技术主管，你选择要落实自己做过的决策，为了真的落实你就会愿意花时间。
+
+更重要的一点是你愿意延后、甚至取消你想做的其他事情，来给你自己和你的团队腾出精力专注落实这项决策。
+
+### 经理也是执行者
+
+**就算我们已经给关键项目安排了负责人，作为主管经理，我们同样也是执行者。**怎么理解这句话呢？经理不是在项目启动的时候定一下方案，然后安排一下人手，接着定时听听汇报，做做1:1 和Deep Dive就够了，经理得为员工办实事，这就是我说经理也是执行者的意思。
+
+我自己在听定期的工作汇报或跟一线骨干做Deep Dive，经常跟团队成员说的话是这样的：领导的工作不单单是给你分配任务，也包括帮你解决你的困难，领导最不希望看到的就是到了快交付了你跟领导说因为这样那样的原因，项目不能如期交付。
+
+所以，**如果你觉得有风险需要领导介入，就应该第一时间跟领导沟通。你要有这个气场可以给领导安排工作。**
+
+在我们一个冲突比较激烈的项目中，我甚至对技术负责人说过这样的话：“这个项目如果你搞不定技术实施是你失职，如果我搞不定Alignment 是我无能。”
+
+其实这么说，就是因为我认为经理本身也是执行者，关于这个问题，我有三条原则和你分享：
+
+第一，如果部下反映了问题，我能够解决的必须马上解决，不能拖，更不能石沉大海。
+
+第二，如果部下反映的问题我不能马上解决，那我需要告诉部下我大概在什么时候可以解决。
+
+第三，如果我评估下来我也无力解决，我会告诉部下不能解决的原因。
+
+当然，原则还是要结合实际场景才能体现，总结一下就是我们应该把定期的工作汇报会议变成解决问题的现场办公会议，而不是一个给领导单项汇报工作的汇报会。作为领导，要给部下反馈和采取后续动作，做得好的不要吝惜表扬，碰到问题了领导也是执行者需要切实解决困难。
+
+### 早点到真实环境历练
+
+我们都知道，管理“未知”是最难的，有时候我们可以预判后面执行还会有这样那样的问题，但这些问题你是很难事前预料的，这时候应该怎么办呢？我的做法就是早点放到真实环境去历练，争取尽早暴露问题。
+
+我结合具体的业务案例来说一说，我们公司因为要应对购物季的流量高峰，每一年在购物季之前，都需要流量管理团队加班，加班的任务就是把数千对负载均衡器上的流量平均分配好。
+
+今年因为疫情原因，eBay网站流量高峰提前到来，这也导致了问题的加剧。副总给了死命令要在今年三季度结束前完成流量重分配100%自动化。
+
+因为这样的情况，我在跟流量管理团队做定期审核的时候最最关心的问题，就是什么时候可以Dry Run（在线上模拟运行）。我担心自动化没经过试验，存在影响业务稳定进行的风险。事实上，我们在所有功能都开发好以后Dry Run的自动化成功率只有10%，强化一个月后达到70%，再强化一个月后达到80%。
+
+今年年底前我们需要交付的Os Patching也是一样的，公司的安全合规要求越来越高，这对我们全网Patching的挑战就越来越大，十几万台机器的OS Patching从半年一次到一个季度一次，甚至到明年要达到每个月一次，我们觉得引入独立集算法可以增加升级并行度加快速度。
+
+但真正跑起来，应用重启后也许不能自动恢复到正常状态，多应用同时重启压垮下游服务，NOSQL类应用升级时数据重平衡时间过长，这一系列问题让我们举步维艰。最后，我们得出的结论就是早点去战场上历练吧，我们只有提前去线上摸爬滚打，才能把十多年积累的“垃圾”都暴露出来。
+
+## 通过关键细节做人员选育
+
+作为一名技术经理，最后还是要回到人才培养上来。我认为重要的关键项目除了交付业务价值，另一个重要作用就是培养人才。那具体怎么培养呢？
+
+我最近半年最大的收获就是**指出关键细节上的差距。**技术主管只有深入一线了解关键细节，才有可能对执行这些项目中的骨干提出有建设性的高质量意见。这些意见对于项目骨干的成长意义重大。
+
+不知道你是否记得，我在[员工沟通](https://time.geekbang.org/column/article/279026)那一节就提过跟高级别技术骨干不能光谈原则，必须落实到具体的细节。我之所以能够重新审视我们部门的执行文化，并作出改变，正是因为自己的老板指出了我在细节上的差距。
+
+当时我的老板指出我鸡血很足，但是对部门要求并不高，而且她拿着兄弟部门的团队业绩，人才梯队甚至还有对派遣人员的培养计划来做佐证。如果我领导不拿着具体的细节给我看，恐怕不会有这么大的触动效果。
+
+这么做的好处是当你给具体的细节的时候，听的人其实已经从具体的实例中自己得出了你想要的结论，这时候你再说出结论，就更容易被听的人接受。
+
+这个抓细节的思路我也应用到了自己培养部下能力的过程中。比如我跟经理X确定了他今年必须有一个目标，这个目标是培养他的左右手到没有他在也能独当一面的水平；我还找到我们部门的技术骨干E，跟他探讨一下为什么我们部门的关键项目不能由一名骨干带上一批派遣人员来实施，而兄弟部门却可以。
+
+有了细节当作切入点，我们对手下的培养就不是空谈的方向了，而是拿着关键细节作为抓手，引导员工尤其是项目骨干找到矛盾点，在解决矛盾的过程中提升自己的水平。
+
+## 总结
+
+今天我给你分享了技术决策后对执行细节的掌控是项目成败的关键。
+
+首先我提到了作为经理，特别是高级别经理的一个大坑，也就是整天关注战略层面的宏观问题，听听报告而忽略对关键项目的关键细节的把控。
+
+接下来，我给你总结了掌握执行细节的三个方式，分别是设定可衡量的阶段性目标，定期做项目审核和周报，以及不定时跟项目一线的骨干做Deep Dive。我们始终要未雨绸缪，时常问问自己如果我这个项目失败了会因为什么原因，从而及早作出安排。
+
+然后，我们要认识到做技术决策不是一次性的买卖，技术经理必须用发展的眼光做持续跟进。决策不等于落实，技术经理可不能就听听报告，你需要及时了解关键细节使得你能够及时指出调整。
+
+我特别强调了技术经理应该把工作汇报的会议开成现场办公的会议。我们不可能一次性掌握所有情况，很多事还处于未知状态，我们就很难推演怎么降低风险。所以，我建议是尽早到逼近真实战场的环境中去历练，毕竟实践出真知。
+
+最后我们还是回到执行细节对人才培育问题上的意义。我自己对部门的要求还不够高，这一点我觉得是我们部门这两年来人才培养上的两大缺陷之一（另一点是给关键骨干全权负责关键项目的机会）。意识到这一点，我在今后还会继续提高，通过细节入手，让团队成员变得更强。
+
+我的建议是，对我们的骨干要高标准、严要求，而指出他们的问题时，就要拿出具体的细节上的差距。**高标准严要求，甚至是用严厉的语气明确说出来哪个具体的点做得不够好，这对唤醒人的自我觉悟，提升人的能力帮助很大。**
+
+## 思考题
+
+请结合你的实际经历，分享一个你自己注重执行细节的正面案例或者反面案例。
+
+我们大部门有一个小组既要维护现有系统又承诺了新系统的多个子系统的研发，但是该小组经常需要救火，承诺的时间点也出现不能准时交付的情况。总部领导跟我谈起这个状况时，说他会给该小组经理更多的压力，你怎么看待总部领导给更多压力的解决方案呢？
+
+欢迎在留言区晒出你的经历和疑问。如果有所收获，也欢迎你把这篇文章分享给你的朋友，说不定就能给他一些启发。

极客时间专栏/geek/技术管理案例课/特别加餐/用户故事 | Weehua：愿每一个管理者都能勇往直前.md

@@ -0,0 +1,117 @@
+<audio id="audio" title="用户故事 | Weehua：愿每一个管理者都能勇往直前" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/df/e1/df6558691e0b41f6660fc05affd1a4e1.mp3"></audio>
+
+你好，我是Weehua，目前在上海一家互联网公司担任技术Leader，主要负责大数据和数据仓库相关技术管理的工作。
+
+和许健老师一样，我也是主动要求走技术管理路线的。我工作已经有8年了，在我工作的前6年，一直在做一线开发，经过自己的努力，我已经证明了自己可以把项目做得很优秀，升职加薪不是问题。我也给自己定了新的目标，那就是做更大、更有价值的事情。
+
+不过我深知自己一个人再厉害，有很多事情不是一个人可以搞定的，而是需要一个团队一起去努力完成。所以我找到了一个机会之后，就正式走上技术管理这条路了。从0到1搭建团队，在这2年多的技术管理过程中，我犯了很多错误，也踩了很多坑，现在想起来还是一把辛酸泪。
+
+记得刚开始带团队的时候，我感觉自己已经是管理岗位了，所以做了技术决策之后就交给下属去执行了，但往往项目要交付时才发现执行中有许多漏洞，中间却缺少跟进和了解细节。
+
+后来我的团队壮大了，又有新的问题产生了。那是在团队发展中期，团队成员由原来的不到十人，一下子发展到二十多人。相应地，团队要负责的事情复杂度也变高了，服务的BU从1个增加到3个，业务线数量翻了一倍。
+
+面对业务交付压力，这个时候我把主要精力放在了项目推进上，很少顾及员工的工作状态，更没有及时做沟通反馈。这就给后面做绩效考评“挖了坑”，团队里有一些同学一直自我感觉良好，到了考评时和自己的预期相去甚远，自然会产生不满，甚至还发生了一些冲突。
+
+总之，我这一路跌跌撞撞走过来，心理上的确经历了很大的压力，有一个很痛苦的过程。正是这个时候，我遇到了极客时间上许健老师的这门课程，了解课程大纲以后，我毫不犹豫地买下了这门课程，决定跟着许健老师一起学习，同时复盘自己这2年多的技术管理经历。
+
+学习这门课，我希望可以看到自己管理工作中的不足和差距，提高自己的认知水平，不断地优化自己的管理工作，精进自己的管理能力。
+
+我们都知道，管理是一门实践学科，需要自己不断实践和总结才能得到提高，但如果有人可以一对一地给你分析经验，其实是一种很有效的学习方法。
+
+这门课最最打动我的，就是课程大量的真实案例。这些案例都是源于老师的真实经历。丰富多样的管理案例，简单清晰的分析总结，让我感觉到这门课非常接地气。
+
+同时，许健老师所在的公司eBay，这是一家优秀的外企，众所周知，外企的管理是非常规范的。许健老师在eBay工作这么多年，在这门课里也沉淀了他最正宗、最地道的管理实践经验。看到老师对自己经验的真诚分享，我觉得受益匪浅。
+
+说到这里，我也想给你分享一下我学这门课的方式方法和心得体会，希望可以给你带来启发，也借此表达我对许健老师的感谢。
+
+## 我是怎么学习这门课的？
+
+因为这是一门管理案例课，只有自己也“代入”其中，才能更深入地思考。所以我采用了**泛读和精读相结合的“三步学习法”**。
+
+<img src="https://static001.geekbang.org/resource/image/74/a2/743ea8105282e613f116a77cd9543ca2.jpeg" alt="">
+
+**第一，“泛读”听音频。**这个过程，主要是在上班的通勤过程中，以听音频为主。这个目的主要是大概了解课程的内容，弄懂每节课的重点是什么。
+
+**第二，“精读”听音频。**这个过程，我会选择下班后或周末的一个独处时间，边散步边听音频。因为已经有了第一次的“泛读”，这个过程中会加入一些自己的思考，我会基于课程的内容，回顾自己的工作中和文章内容相似的部分，然后进行对比反思。
+
+听完之后，结合课程最后给出的问题，我一定会停下来思考总结，一定给课程留言，强行让自己思考。特别是对于课后思考题，一定要思考作答，建议自己回复之前一定不要看其他人的回复，这样可以学习其他小伙伴的思考角度。
+
+**第三，精读文章内容和留言。**这个过程，是我在学完整个课程之后，为了系统性地整理学习笔记而做的。每天早上9点之前到公司，在会议室里学习1个小时，主要是精读文章，记录笔记。最最最重要的，一定要把文章的留言和老师的回复都精读一遍，留言中许健老师的回复和一些同学的追评，也是干货满满，相信你看过以后也会有所收获。
+
+我每次在回复课程的课后问题之后，都会顺便提出和课程内容相关的，自己在工作中实际遇到的问题。这里我分享一个小技巧，在描述问题的时候，你要尽可能说明提问题的上下文环境，这样许健老师在回复的时候，就能针对你提出的问题给你“量身定制”的回答，让你可以更好地理解课程内容，并把技术管理的理论方法结合到实际工作中。
+
+## 最有收获的文章
+
+分享完我的学习方法，我还想分享几篇让我最有收获的文章。
+
+[**领导特质：一个合格经理人应有的4个待人处事原则**](https://time.geekbang.org/column/article/277494)
+
+这节课从做事的原则讲起，升华到领导应该怎么待人，我感觉对我触动很大。我的体会是，作为领导，正直是最基本的品质。
+
+因为做事的能力固然重要，但是在职场上或生活中想长久地发展，一些做人处事的原则更能起到关键作用。更何况，我们的待人处事原则，还会直接影响到自己所在团队的待人处事方式。
+
+[**向上管理：你知不知道你领导真正的烦恼是啥**](https://time.geekbang.org/column/article/280295)
+
+在这节课里，有两个观点让我眼前一亮，同时也茅塞顿开。这两个观点分别是领导也是你的团队成员和不做“奴才部下”。
+
+在遇到困难的时候，领导一定是团队中最能给你支持和资源的人，我们应该要学会求助，和老板建立好沟通渠道。作为一名管理者，一定要做一个独立思考的人，面对领导的要求不要一味地服从，在领导面前不卑不亢。
+
+为啥说茅塞顿开呢？因为我最开始做管理的时候，这两点错误都犯过。
+
+比如和上级沟通这件事儿，我反思自己原先不去沟通深层次的原因，主要还是嫌麻烦，和领导沟通其实挺消耗精力和时间的，而且感觉大部分老板都在忙事情，不会留很多时间和下属沟通。
+
+**但是向上沟通这节课给我了一个新的视角，重新审视自己和上级的关系。**
+
+首先，要把领导也当作是自己团队的一员，而且是最重要的一员，有了困难，要及时和上级沟通反馈，寻求帮助。
+
+其次，一定要站在上级的角度去看待问题，和上级对齐目标和期望。比如说解决一个问题，A是我团队职责内要做的事情，我自己认为我把A做好就足够了，但是上级希望我做好A的同时，也可以推动协助做好上游B和下游C，这样才能彻底解决问题。
+
+如果我不能在高一个层级看问题，不能和上级对齐目标和期望，那最终结果一定是自己认为事情做好了，但上级认为你做得不够好。
+
+正是这节课带来的启发，让我好好复盘了原先自己做得不到位的地方。**其实想要把过去犯过的错，转化为自己的经验和能力，就是要有这种推翻、改变和重建的过程。**
+
+**变革管理和冲突管理**
+
+> 
+[13 如何从“拥抱变化”到“发起变化”？](https://time.geekbang.org/column/article/286834)
+
+
+> 
+[14 如何进行高压对话？](https://time.geekbang.org/column/article/287841)
+
+
+> 
+[15 没有双赢的情况下，如何推进事情发展？](https://time.geekbang.org/column/article/289308)
+
+
+> 
+[16 冲突不可怕，可怕的是引发信任危机](https://time.geekbang.org/column/article/290075)
+
+
+变革冲突这块儿的主题和内容，对于我个人来说学起来确实是一个挑战。因为对于大部分初中级的管理者，很少遇到需要发动变革的事情，即使遇到了也很难有勇气去做变革管理。
+
+回顾自己这两年多的管理工作，感觉有好几个阶段都遇到了需要直面冲突和工作突破的情况，但那个时候的我感觉认知还达不到这个层面。
+
+我的领导风格比较温柔，不是那种强硬派的，刚开始害怕面对冲突，不想起冲突。工作中遇到的困难分析得不够深入，拿出的解决方案也不够一针见血，更别说想到用变革的方式，去搞定重要却迟迟不能解决的关键问题了。
+
+经过仔细研读，结合自己当下的工作，我会尝试着去直面冲突。比如，面对高压对话，我会重点关注双方的利益，准备一些相关的客观事实和数据，同时也会在心里进行模拟对话。
+
+虽然才实践了几次，效果暂时还看不到，但我个人面对冲突的时候更加从容镇定了，我想这也是一种提高。日拱一卒，不期速成，因为方向找对了，相信这种量的积累最终会带来质的飞跃。
+
+## 我的学习心得
+
+聊完了我的学习方法和印象最深刻的几节课，我还想和你聊聊我的一些心里话。
+
+大部分讲管理的书，关注点放在了理论和方法。而这门课我深入地去阅读和思考之后，看到的不止是许健老师的技术经验、方法论和思维方式，还感受到了许健老师为人的气度和做事的态度。做事的原则和方法固然重要，但做人的原则才是最核心的，做事先做人。
+
+这几年来，公司一路快速发展，而我身处其中，回顾自己工作中的林林总总，的确遇到了各种各样的困难和问题。我在这门课的案例中，可以找到自己的身影。因为我也同样犯过错误、踩过坑，老师在课程里提到的很多案例，我都感同身受。
+
+学完整个课程，我最大的体验就是仿佛和许健老师一起经历了他这些年管理工作中的风风雨雨。经过学习，我不但对自己过去管理工作中的失败和错误有了重新的认识，还产生了很多精神上的共鸣。
+
+从课程里我可以感受到许健老师的那种坚强，那种韧劲。这种劲头能让人从错误失败中不断地总结反思，重新站起来。同时，老师有很多话都给了我很大的精神鼓舞，让正处在低谷期的我有了重新战斗的勇气，给我指明了方向。
+
+印象很深的一句话就是：**我可以承认自己距离强者有差距，但是我绝不会对自己失去信心。**
+
+面对工作上的困难，我会重新思考总结自己哪方面确实没做好，我会积极地去和老板沟通，获取上级的反馈，然后调整自己把工作做好。最后，无论结果怎么样，我都会有一颗感恩的心，接受当下的自己，不断学习提高。
+
+最后，我想借用许健老师的一句话送给你们：去追求更好的自己，但是不要太计较结果，活在当下。希望每一个管理者，都可以意志坚定，勇敢地面对困难，勇往直前！

极客时间专栏/geek/技术管理案例课/结束语/结束语 | 时时反思，优化管理能力.md

@@ -0,0 +1,88 @@
+<audio id="audio" title="结束语 | 时时反思，优化管理能力" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/0d/64/0d27559b017ae8cbc1e716c341f79564.mp3"></audio>
+
+你好，我是许健。
+
+今天，技术管理案例课这个专栏就要和你说再见了。还记得开篇词里的那张“经理人成长路线图”吗？
+
+在过去的两个月里，我们一起沿着这条路径，从开启技术管理到一线经理，再到二线经理，最后到技术决策者，剖析了几十个案例，边分析、边反思、边总结。现在到了最后一站，我自己还是很感慨的，不知道你的感受如何？
+
+在写这篇结束语的时候，我感觉自己就像是在一个毕业典礼上，台下坐着的是跟我一路走来的你们。那这个时候，我该跟你聊点啥呢？
+
+回归到初心，我很希望这个课程不仅仅给你分享我在技术管理上的经验，还能给你带来一些人生思考。因为我越来越体会到，技术管理课里面的很多道理在人生道路上也是一样的。
+
+所以最后我想给你分享三个关键词：**父母心、为人真诚、反思精进**。这三个关键词，既是我做技术经理多年来最深刻的体会，也是我所坚守的人生态度。
+
+### 父母心
+
+有了女儿以后，我看了不少学龄前育儿的书，越看越觉得其中的理念跟管理是相通的。书里谈的不是数理化，而是一个人最最根本的东西：好奇心、同理心、韧劲、乐观、遇到困难不轻易放弃……
+
+我不禁问自己，为人父母，我对子女的期待是什么？如果只能有一条，真的是出人头地吗？我相信大部分的父母都不是这个答案。我的答案是希望我女儿有积极向上的价值观，将来长大了有独立思考的能力，哪怕有一天我不在了，她依然能够很好地过自己的生活。
+
+那换个角度，在公司做一名管理人员不也一样吗？交付业务价值固然重要，但是我们真的只为交付业务价值吗？除了给员工赋能，让他们得到技术上的提高，作为经理我们还对员工的职业发展，甚至对员工的待人处事也有很大的影响。
+
+**做一名经理对员工要有一颗父母之心，如果你做得好，就可以把员工的潜力激发出来，让他们成为更好的自己。**
+
+### 为人真诚
+
+第二个关键词是为人真诚，众多的管理方法都更像是术，而在这些技术之上是道的层面。这个真诚既是我们对自己真诚，也是我们对身边所有人都保持真诚的态度。
+
+说到真诚，我觉得它更接近于一种价值观判断，甚至是道德要求，所以我才在专栏里反复强调德的重要性。我觉得这不单单对我们做一名经理有帮助，对于做人也是一样的。
+
+先说说对自己真诚。在这个专栏里，我从一个技术经理的角度分享了我的很多经验教训。我想表达的就是，想提高就得多经历一些事情，特别是经历挫折。
+
+踩坑不可怕，可怕的是不能真诚面对，不能想方设法地赶上来。那当我们顺风顺水的时候呢？这就是另外一种形式的考验了。我们也不要膨胀，而是要始终带着一颗感恩的心。
+
+再说说对别人真诚。遇到事情不能冲动，碰到冲突态度要好但话要重。对一个人好，有时候也可以一针见血，因为对人真诚当然也包括指出对方存在的问题，他可能会不好受，但是相信平静之后大部分人还是可以理解的。痛了，改了，就是更好的自己。
+
+### 反思精进
+
+第三个关键词是反思精进。最初我还想过给这个专栏起名为“技术管理反思录”，因为做管理这么多年了，我能逐渐成长、成熟起来，不断优化自己的能力，其实离不开反思精进这个方法。
+
+让我不断反思精进的动力，其实来源于我想成为一个怎样的人。我在公司的第一任导师叫卢俊，他跟我第一次见面的时候只问了我一个问题：“许健，你想清楚你想要什么了吗？”
+
+这个对话离现在十多年了，但我还是印象深刻。当时我想了两个礼拜，跟卢俊说我要做一个受人尊敬的人。
+
+为什么我特别想要成为一个受人尊敬的人呢？可能有家庭背景的影响吧。小时候我的家境不是很好，父母下岗，周围人对我的评价就是“只会死读书”，可能就是因为这些导致我特别想证明自己。
+
+我一直相信人生是长跑，再难的事你也挡不住我数年的死磕，何况我还能通过反思总结不断精进呢？我还会去读书以史为鉴，我还会抱着“天将降大任于斯人也，必先苦其心志，劳其筋骨”的“阿Q"精神主动找罪受。
+
+我在8月24号开学典礼直播的时候说过，我蛮希望这个专栏是能够持续修正的，而不是写完就完了。
+
+《实践论》里说“实践、认识、再实践、再认识，这种形式，循环往复以至无穷，而实践和认识之每一循环的内容，都比较地进到了高一级的程度。”
+
+这个专栏，是不惑之年的我在反思回顾自己的职业生涯，更准确地说是自己的人生经历总结出来的，经历过的人才能更加体会到其中的纠结。很多事情想做好，都不容易的，所以也希望你身处顺境时正视自己，遇到挫折时不被外界干扰。
+
+同时呢，我也希望你能带着自己的独立思考来学习这个专栏，拥有自己对各种事情的判断能力，以我的经验为一种参考，去总结出自己的管理体系。你可以通过留言区把这些分享出来，这也是一种反思精进。
+
+### 人生的意义
+
+最后，我再多说几句，和你聊一个比较大的话题：人生的意义。
+
+其实本来想写到这里就结束这次“毕业典礼”了：大家都对自己高标准、严要求，不断去经历，然后反思总结修正再去努力做到更好，多么完美。
+
+可是人生的路并不完美，而人是感性的，有坚强也有脆弱，我觉得很有必要在最后跟你探讨一下生命意义的问题。
+
+几年前我去美国出差，总部的运维高级总监Dennis请我吃饭，我其实是想跟他聊聊业绩和目标的，但他竟然跟我聊了一个关于人生的话题。他说：“许健，我儿子结婚的那天，我就觉得自己的人生圆满了。”
+
+我当时觉得Dennis你不跟我谈在工作上如何“开疆拓土”，反而跟我谈这个做什么呢，但是随着年纪增长，我看多了一些身边的人情冷暖，生老病死。现在想来，我觉得每一个人在人生的不同阶段会有不一样的诉求。
+
+现在的我开始理解Dennis跟我说的话了，我甚至觉得很有可能我的导师卢俊在十多年前问我“想要什么”这个问题的时候，也许他自己也在思考他这一辈子的意义。
+
+我现在的心态是这样的：我还是觉得一个人活在世上应该不断努力不断精进，但是目的不是出人头地，而是自我实现和这一路的风景。
+
+如果你现在就要离开这个世界，闭上眼睛回顾这一生你会想起些什么呢？那个时候你会想起的事情和人才是你现在应该珍惜的。
+
+这就是我最后想送给你的话：**去追求更好的自己，但是不要太计较结果，活在当下。**
+
+最后的最后，我想分享几句歌词作为结束。我自己很喜欢听歌，而且常常是单曲循环。此时此刻，此曲此心，与你共勉。
+
+> 
+<p>心若在梦就在<br>
+天地之间还有真爱<br>
+看成败人生豪迈<br>
+只不过是重头再来</p>
+
+
+这里我为你准备了一份[毕业问卷](https://jinshuju.net/f/iPky2M)，题目不多，希望你可以花两分钟填一下。也十分期待能听到你的声音，说说你对这个课程的想法和建议。
+
+[<img src="https://static001.geekbang.org/resource/image/63/1c/635e55d2b317a0d920319abe2178a21c.jpg" alt="">](https://jinshuju.net/f/iPky2M)

极客时间专栏/geek/技术管理案例课/结束语/结课测试｜这些技术管理的问题，你都掌握了么？.md

@@ -0,0 +1,15 @@
+
+你好，我是许健。
+
+《技术管理案例课》这门课程已经全部结束了，十分感谢你一直以来的认真学习和支持！
+
+我给你准备了一个结课小测试，来帮助你检验自己的学习效果。
+
+这套测试题共有 20 道题目，均为多选题，满分 100 分，系统自动评分。
+
+还等什么，点击下面按钮开始测试吧！
+
+[<img src="https://static001.geekbang.org/resource/image/28/a4/28d1be62669b4f3cc01c36466bf811a4.png" alt="">](http://time.geekbang.org/quiz/intro?act_id=225&amp;exam_id=704)
+
+最后，这里有一份[毕业问卷](https://jinshuju.net/f/iPky2M)，题目不多，希望你能花两分钟填一下。十分期待能听到你说一说，你对这个课程的想法和建议。<br>
+[<img src="https://static001.geekbang.org/resource/image/63/1c/635e55d2b317a0d920319abe2178a21c.jpg" alt="">](https://jinshuju.net/f/iPky2M)