mod

极客时间专栏/乔新亮的CTO成长复盘/对管理工作的复盘/07 | 管理者最重要的三个任务（一）：组织调整到位.md

@@ -0,0 +1,162 @@
+<audio id="audio" title="07 | 管理者最重要的三个任务（一）：组织调整到位" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/ba/de/bae17e4145b33eb6fae92ea0yy21eede.mp3"></audio>
+
+你好，我是乔新亮。欢迎来到我们专栏的第二章：**对管理工作的复盘**。
+
+在我身边，有些朋友技术很牛，别人调试了一个礼拜的 Bug，他三下五除二就搞定了；别人玩不转的高并发架构，他没用多久就设计完了。领导天天表扬，隔三差五还能给团队做个技术培训，很开心。
+
+接着有一天，公司组织调整，程序员成为了管理者，整个人就懵了：不知道该干嘛。有的人是天天写 PPT，其实内心觉得管理是个很虚的事情；有的人坐着管理者的位置，干的却仍然是写代码的活。不懂管理，这是初级管理者的典型问题。
+
+如果将视线拔高，你会发现，管理能力有些欠缺的技术总监、技术 VP，甚至是 CTO ，也都是存在的。我培养过许多技术总监，也经常收到猎头发来的“高薪求聘 CTO”的需求，说明当下在业内，仍然十分缺乏优秀的技术管理人才。
+
+确实，做管理者不容易，大家都是一步步走过来的。前面我们讲了很多次关于“上台阶”的认知，每次登上一个台阶，挑战都会很大，需要时间去学习和适应，这很正常。
+
+复盘这些年带过的精英团队、万人团队以及创业团队，我发现有一些知识，如果早一点掌握，能帮助快速搭建起关于管理的知识骨架，让你成长得更快、更系统。管理者需要做的工作很多，但如果只做三件事，会是哪三件呢？
+
+在我看来，有三大管理任务始终最为核心，最应该在团队内率先落地，分别是：
+
+1. 组织调整到位；
+1. 加强协同效率；
+1. 激发团队活力；
+
+你可能会想，这是不是过于简化了？要知道，做多容易，做少难，浓缩的才是精华，要学会将复杂的事情讲简单。
+
+而且，这三大任务并不是孤立存在、毫无联系的，它们相互促进，共同实现「促进业务增长」、「建立企业竞争壁垒」等几个主要目标，同时构成了一个企业 IT 能力建设的增长飞轮。下面，我们先来拆解一下这个增长飞轮。
+
+## 拆解 IT 能力建设的增长飞轮
+
+<img src="https://static001.geekbang.org/resource/image/93/29/934083db86162c46e0799510a538c529.png" alt="" title="IT 能力建设的增长飞轮">
+
+在这张图里，飞轮有四个“叶片”，其中「端到端的产品管理」、「增强协同-项目管理」以及「绩效与激励体系」部分，其实就分别对应着管理者最重要的三个任务。在“飞轮图”左下角的「战略层面」部分，则代表着飞轮运转之后，给企业带来的业务增长。
+
+下面我们来尝试理解一下，飞轮是如何运转的。但是你要注意，**这张图的核心是飞轮本身，并不是其中某个单独的叶片。**
+
+飞轮的 1 号叶片，是绩效与激励体系。毕竟，没人会给企业免费打工，这是企业开始招聘、开始运作的起点。虽然我始终在说，对于个人不要为了薪资而工作，但对于管理者，金钱奖励仍然是最有效的激励措施之一 —— 尤其是在初中级岗位中，拥有正确认知的同学相对较少。
+
+那么管理者要做的，就是通过团队成员的投入产出比评定绩效，通过阶梯式绩效建立有行业竞争力的激励体系。把这些做好了，在 2 号叶片 —— 项目管理部分，管理工作就有了一个好的基础。
+
+说到项目管理，你一定比较熟悉，主要是立项、项目控制、风险管理、结项等。其中，立项非常重要，在大部分情况下，一个好的立项可以大大提高项目成功的概率。那么什么是好的立项呢？有三项工作一定要落实，分别是：
+
+- 目标清晰：每个业务目标、产品目标、技术目标都要清晰且可量化；
+- 责任到人：上述每个目标都要责任到人，不能都是项目经理扛，项目经理扛不了的；
+- 承诺到位：如果需要外部组织配合，要得到外部组织的明确承诺；
+
+如果上述任何一个条件没有落实到位，就不能立项；如果企业正处于快速迭代的阶段，可以适当放松要求，但开完项目启动会的一周内，以上三项都要落实到位，否则项目进入高风险关注列表。
+
+**在用人方面，要尽量提高人才密度。**同样一份工作，宁可用两位中高级人才来完成，也不用三位初级人才来完成，主要原因是要考虑管理成本。
+
+只会做项目还不行，我常说，做项目赢在当下，做产品赢在未来。高效地落地项目，是为了产品能更好地孵化出来。在 3 号叶片 —— 产品管理部分，重要的是建立面向产品的组织架构和机制，以产品为核心让组织运转起来。也就是说，项目管理是手段，目的是建设优秀的产品。
+
+产品的在企业内成功孵化，最终是要在市场上证明自己价值的，为企业带来业务上的高速增长。这就来到了 4 号叶片 —— 企业战略层面。
+
+这一部分我们主要关注业务增长，而业务增长又可以从长期、短期两个维度来理解。当下我们围绕产品做的许多工作，并不一定能帮助业务立刻跨上一个台阶，有些可能是在半年后才会深度影响业务的增长。但要记住，业务的增长一定是和产品能力的建设密切相关的。
+
+最终，业务的增长带来企业营收和利润的增长，进而让激励体系变得更有吸引力。有关企业 IT 能力建设的增长飞轮，就正常运转起来了。
+
+那么除了业务的增长，这个飞轮还能带给企业哪些价值呢？我认为在飞轮的运转过程中，企业的品牌是在不断被建立的。此外，随着越来越多的产品逐渐组成平台，甚至是形成对外云服务，企业积累的 IT 力量在不断增强，这也将在行业内形成真正的壁垒。
+
+到这里，我们回过头，再看一下增长飞轮，任何一个叶片的缺失，其实都会导致飞轮停转。如果你只做绩效与激励体系，虽然短期内大家很开心，但时间一长，企业就要倒闭了，最终害了所有人；反之，如果只做项目管理和产品管理，不做激励体系，那你就成了“活雷锋”，花企业的钱为业界输送人才。
+
+所以，我们在讲解管理者的三大任务时，是从“激励”到“增长”，按顺序介绍的。但这是一个飞轮，你可以从任何一个叶片开始看，在不同的启动点，关注点也不同。当然，图片能展示的内容有限，要让增长飞轮转得更好，我们还有很多内容需要讨论。但那都是后话，不要着急，接下来我们先来详细聊聊管理者的第一个要务：组织调整到位。
+
+## 构建面向产品的组织架构
+
+组织调整到位，在今天这个时代，就是要构建面向产品的组织架构，对应了「IT 能力建设增长飞轮」的叶片 3。
+
+那为什么要先讲组织调整呢？因为组织架构是公司协作的基础，它决定了各团队如何思考、如何协作。如果组织架构不调整，研发团队是一条线、测试团队是一条线、产品团队是一条线，这在IT 团队里天然就形成了一定的壁垒和鸿沟，导致一些正确的战略决策落地执行慢，公司内团队协作效率差，容易扯皮。
+
+所以在你有权限、有能力，时机恰当的情况下，我建议优先调整组织架构，从**职能型研发组织结构**，调整为**产品型研发组织结构**，也叫做“Pizza 型团队”。
+
+比如，职能型研发组织架构的特征是：
+
+- 每个研发中心为一个最大产品团队；
+- 二级部门按岗位职能划分为多个专业职能部门，比如产品经理团队、研发团队，还有进一步把研发团队划分成开发团队、测试团队的；
+- 每个人员仅归属到一个职能组织；
+- 三级部门人员按编制无限扩充；
+- 三级部门团队 leader 任命从岗位职能中挑选/竞聘，比如研发能力强的当研发团队 leader，测试能力强的当测试团队 leader；
+
+产品型研发组织架构的特征是：
+
+- 每个研发中心为一个最大产品团队；
+- 二级部门按产品下分多个产品组织为三级部门，每个产品组织均形成一 个产品团队；
+- 每个人员至少归属到一个产品团队，暂不限制归属产品数量；
+- 每个产品团队约为 7 ~ 8 人，人数受限，最多 10 人；
+- 每个产品团队产品经理、开发、测试齐备，是一个可以独立作战的小分队；
+- 三级部门产品团队 Leader 可以是团队任意成员；
+- 产品团队 Leader 要求（综合能力）：专业能力、领导力、汇报能力；
+- 团队 Leader 任命原则为能者居之，能上能下；
+
+你想一想，这里面最重要的变化是什么？我觉得有以下几个方面：
+
+**第一，产品经理、开发、测试，形成了一个整体，被赋予共同的文化价值观，为共同的目标去努力，战斗力变得更强了。**
+
+愿景、文化、价值观很重要。团队成员正在做的工作，是否被赋予了意义，会对工作的执行效果产生巨大的影响。比如我们彩食鲜的愿景是：希望全国人民，在生鲜食材方面能吃上可信赖的食材。当一个包含众多关键岗位的战斗小分队，都一起为这样的目标努力时，力出一孔，战斗力肯定比单打独斗强。
+
+**第二，无论是产品经理，还是开发、测试，都开始和业务部门熟悉起来，和运营同学坐在一起，为自己的产品负责。**
+
+以前，业务觉得 IT 傻，啥也不懂；IT 部门觉得业务部门是这个时代的傻瓜，啥也不会。在我的团队里，这些都不存在，所有人都要熟悉业务，不需要熟悉业务的岗位一律外包出去。连运维都要求去学习业务，只有知晓了业务的特点，才能把运维做好。业务部门和 IT 部门是兄弟，兄弟齐心，其利断金。
+
+心在一起是团队，心不在一起就是个团伙。为什么很多公司的业务团队和  IT 团队心不在一起？其实根本原因是组织整体架构设计的有问题，局部的优化不能从根本上解决问题，需要体系化的解决方案。
+
+彩食鲜的业务部门和  IT 部门关系非常好：互相理解、互相支持；胜则举杯相庆，败则拼死相救。我相信，这是大家都向往的团队氛围。而我思考的是，怎么去营造这种文化氛围。答案是，要从底层开始进行设计，把最基础的架构设计做好。
+
+**第三，管理者开始能通过一套统一的绩效考核体系，去考核不同岗位的团队成员。**
+
+以前我们如何考核研发人员？可能是 Bug 数量，也可能是宕机时间。其实在大部分业务驱动型公司里，考核这些指标的意义真的有那么大吗？如果业务都死掉了，系统再健壮又有什么用？如果你的产品能给公司带来一两个亿的利润，偶尔宕机一次又有什么关系？
+
+最终一切都要变好，但在前进的过程中，如何去寻找平衡，这是管理的智慧。**身为管理者，你要学会灰度管理，不断在业务发展和技术能力建设中间寻找平衡**。此外，管理者要将所有人的目标调整到业务发展上，联合大家一起寻找最优解，避免各方只关注局部优势，不看全局发展。
+
+我对 IT 团队的定位是，IT 必须成就业务。我也建议你，如果能够影响公司的 IT 策略，一定要通过利润和营收，考核 IT 产品给业务创造的价值，同时考核业务部门的IT化水平。
+
+我曾经和亚马逊零售部门的专家沟通过，发现亚马逊很早就开始将业务部门的 IT 化水平纳入考核。在一定时期内，如果采购部门的系统自动化程度不够，采购单是无法人工下发的。
+
+具体到方案，你可以以产品线为单元考核，参照成熟度模型，设立有挑战的绩效目标。然后用业务价值的增量部分，按百分比抽取，回馈给产品团队。
+
+你可能会想，如何估算业务价值呢，这有点难吧？其实也不难，**业务价值参照公司、部门的收入和利润进行换算；如果出现不能直接计算的情况，按人效提升、人力节省的程度进行换算**。在这里，我们可以用“开源节流”这个概念来给工作更明确的分级：
+
+帮助企业增长、扩大市场份额的工作属于开源类工作，这些事情能做就做，要优先处理。比如让企业内连接、协同效率更高，让数据共享更透明，帮助决策更高效之类的任务，基本都属于开源工作。
+
+节流类工作的优先级次之，具体是指人效提升、人力节省等。当然，有些工作既能开源，又能节流，效果最好。
+
+别觉得复杂，有一个基本的设计原则，可以助你理解以上内容：**企业做增长，个人看成长；鼓励每个人凭借自己的成长，在团队内贡献更大的能量，赢得企业的发展，最后在越来越大的蛋糕里，共享利益。**
+
+还有很多其他的细微差别，我就不再展开谈了，留给大家在实践中体会。重要的是，这么干下来，整个 IT 部门的氛围完全变了，业务就像爸爸，贡献行业知识；IT 就像妈妈，进行科技赋能。双方共同抚养了一个既懂业务又懂技术的孩子 —— 产品。
+
+这孩子的能力构筑在平台的能力之上，拥有过去积累的所有经验，持续学习、不断进步、越来越强。当企业坚持对 IT 长期投入时，就会形成复利效应，让这个孩子所能贡献的价值越来越大。最终受益的还是“爸爸”和“妈妈”。
+
+## 如何做组织架构的选型？
+
+当然，不是说所有公司都要立刻构建面向产品的组织架构，你也不要看完专栏，就跑去找 CEO “谈心”。
+
+关于如何在“职能型研发组织”和“产品型研发组织”间做选型，我有三个比较关键的考量标准，供你参考：
+
+第一，如果公司在技术方面还存在比较大的挑战，建议选择职能型研发组织。比如说，产品经理、开发、测试的能力很差，还有很多技术挑战不好解决，这时不要冒失转型。
+
+第二，如果技术挑战所剩不多，不要犹豫，建议转为产品型研发组织结构。
+
+第三，通过设置技术管理办公室、云部门统一建设基础平台和研发管理平台，降低对于大多数开发、测试的专业能力要求。对于  200  人以下的研发团队，设置一个技术管理组织就可以，将研发规范管理和基础平台能力建设两个功能凝聚在一起；如果团队规模超过  200  人，就要尝试分成技术管理办公室和云部门，前者负责研发管理规范，后者负责基础技术平台的研发。
+
+你可能会说，我还没有权利做组织架构设计和调整，我能得到什么呢？在专栏的第一章，我讲过，要学习看清楚问题的本质，养成遇到问题多思考的习惯。现在，你就可以结合自己的工作，好好想一想，这套调整方案背后的本质是什么呢？
+
+如果你是个项目经理，可以想想做过的项目，调整自己的视角，想想如何利用类似的思维模式解决项目问题；如果你是个架构师，想想这个和架构设计有什么异曲同工的地方？
+
+无论你是产品经理、测试经理还是资深开发人员，都可以结合自己的工作，想想有什么触类旁通的问题。
+
+虽然以上管理措施，并不是每一位管理者都有权立刻执行，但要学着先听、先了解。交流得多了，你可能会发现，其实成功的高层管理者，在管理方法上，都有许多共通之处。提前接触这些内容，有助于你拔高自身认知，更清晰地看待当下的成长路径和工作目标。
+
+同时也不能看过了就扔一边去了。每过一段时间，就要记着来拿出来重温一下，会特别有好处！
+
+当然，你也不用担心此后的每一讲都与中层管理者无缘，我们的内容将涉及多个层次、多个维度。
+
+如果你已经是一名拥有决策权的高层管理者，那就太棒了，以上所讲方案均来自我在环球易购和彩食鲜的管理实践，欢迎留言与我交流技术与业务团队管理心得。
+
+## 结语
+
+到此为止，我们专栏第二章第一讲的内容，就接近尾声了，内容从认知部分跨越到管理部分，不知道你听得怎么样？
+
+作为管理者，要学着带领出一支能征善战的队伍。这一讲，就是在讲如何搭建一支能适应“现代战争”组织形式的队伍。
+
+接下来的两讲，我们会重点讲一讲如何加强协同效应、如何激发团队活力。这三讲，将共同构成技术团队管理的“三板斧”。
+
+都做完了，就可以带团队去打胜仗了：每个季度定有挑战的目标，组织团队拿下这个目标。胜仗打得多了，就会养成赢的习惯，就会将“打胜仗”当作一种信仰。当这支团队再看到有挑战的任务时，就会兴奋地冲上去，然后拿下它！
+
+希望大家都能成为各自企业内的“常胜将军”，我们下一讲再见。

极客时间专栏/乔新亮的CTO成长复盘/对管理工作的复盘/08 | 管理者最重要的三个任务（二）：加强组织协同效率.md

@@ -0,0 +1,159 @@
+<audio id="audio" title="08 | 管理者最重要的三个任务（二）：加强组织协同效率" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/8f/bd/8f2f001d71b1d96f09f67ceb68b42bbd.mp3"></audio>
+
+你好，我是乔新亮。
+
+上一讲，我们聊了聊管理者最重要的三个任务之一：组织调整到位，也顺便讲解了下「IT 能力建设的增长飞轮」。因为怕有些同学忘了，所以我们再看一遍这张飞轮图：
+
+<img src="https://static001.geekbang.org/resource/image/93/29/934083db86162c46e0799510a538c529.png" alt="">
+
+在这一讲里，我们主要来关注一下飞轮的叶片 2 ：增强协同，也就是管理者的第二个重要任务：加强组织协同效率。
+
+为什么要把加强协同放在这么重要的位置来讲呢？
+
+其实我刚刚成为管理者时，也没有这个认知。但后来随着职位不断上升，薪资也水涨船高，我发现自己变得有点焦虑起来，因为我没想明白一个问题：我的价值有那么大吗？
+
+那段时间，我不断地问自己：
+
+**你凭什么拿这么多工资？**
+
+我常常讲，比较健康的情况下，薪资的来源一定是公司收入的分成：公司赚了 100 元，你拿 1 元钱。那么当你可以拿 2 元钱的时候，意味着你给公司创造了 200 元的收入。早期做普通程序员的时候，这个逻辑是没问题的 —— 一个优秀的程序员，产出确实能达到初级程序员的 2 - 3 倍，甚至是 4 倍。
+
+可是如果说拿  10  倍程序员的年薪，可能吗？对于个人来说，从概率上来讲已经很难了；但对于带团队的管理者来说，从概率上来说，可能性还是很大的。假如一支团队一年为企业贡献 1000 万利润，在你的带领下，年利润贡献变成了 2000 万，甚至一个亿，两个亿，那么管理的价值就显现出来了。
+
+管理者带领团队最大的价值是向管理要效益，让团队价值大于个体所能贡献的价值之和，通俗讲就是 1 + 1 &gt; 2。所以说，加强协同效率，是众多管理工作里，最基础、也最重要的部分之一，几乎算是管理者的“天职”。
+
+你可能会想，老乔，协同不就是要让同事快点回信息、快点写代码、尽量别吵架吗？别说得这么玄乎！
+
+当然不是了，我们这里讲的协同，可不是单纯的催同事干活。如果要用一句话去总结，我认为是：**协同，就是让所有人向着同一个目标狂奔，并妥善解决奔跑过程中的合作问题。**
+
+这里有两个关键指标，一个是「目标聚焦」，一个是「顺畅合作」。下面我来分别讲讲，为什么以及如何实现这两个关键指标。
+
+## 认知与工具层面的目标聚焦
+
+我们先来聊聊，为什么要做目标聚焦？有两个关键认知，你一定要先体会一下：
+
+- 无论你的能力有多强，需求是永远做不完的；
+- 因为需求做不完，所以要努力通过全局视角思考，做到战略上的“舍九取一”，进行单点突破。
+
+这两个认知，我们在后面的内容里会详谈，这里我们就先记住，然后思考你的公司里是否有这种情况：
+
+- 团队各做各的，心没往一起去，影响团队产出；
+- 团队间互相扯皮，出了问题互相推诿，影响团队产出；
+- IT 团队的同学，有时候会说：你看我做了一个很好的东西，但是他没有配合好，所以没有发挥价值；
+
+……
+
+你往东，我往西，结果可不就是大家原地拔河，毫无进展吗？这些问题的本质，在于大家的目标不对齐，每个人都只关注自己的一亩三分地，无视团队整体的目标。从公司的角度看，这在一定的时间内，其实就已经是浪费了公司的资源，没有最大化协同的价值。
+
+那么，怎么让团队具备全局思维，劲儿往一处使呢？
+
+首先有 4 大协同手段需要实施，下面我们来逐步讲解。在可操作性方面，以下 4 条是从简单到复杂排序的。
+
+1. 沟通协同：一般通过飞书等即时通讯软件来实现；
+1. 日历协同、会议协同：这里是指全员、尤其是管理者要做到日历公开，只要空白的时间段，就意味着可以预约会议，减少协调成本；
+1. 文档协同：一般通过石墨文档、飞书文档等共享文档实现高效协同；
+1. 目标协同：一般通过 OKR 来实现上下目标对齐。在彩食鲜，中高层每月、每季度对齐目标；执行层每日、每周对齐目标。
+
+以上几个都很简单、清晰，很容易理解，在公司内部，这属于打造协同文化的基础工作。虽然简单，但是作为管理者，要每周，甚至每天关注：
+
+- 在团队内，是否有影响协同效率的事情正在发生？
+- 哪个组织、哪个人阻碍了协同效率的提升？
+- 团队成员是否因为缺乏大局观，影响了更大组织目标的达成？
+
+……
+
+要公开表扬、鼓励协同做得好的组织和个人；对影响了协同效率的组织、个人私下进行批评、沟通。有需要的话，也可以在公开场合进行批评，这样团队很快就会知道你想要的是什么：我要组织成功，我要大家有大局观。
+
+最重要的是，一定要花心思去关注团队的协同情况，这里没什么捷径。我基本上每周（有时候是每天）都会问团队：有没有问题需要我解决？有没有意外情况？
+
+我建议你也这么干，不但如此，还要关注团队的 OKR 和任何意外情况。可能听起来有点泛，怎么保持关注？盯紧两个指标就好，一个是结果指标，另一个是过程指标。
+
+彩食鲜的产研部门三季度目标是“销售支持 100% 在线化”、“财务对账 100% 在线化”，这两个“100%”都属于结果指标；系统稳定性、生产环境 Bug 数量、千行代码 Bug 率、服务响应时间……这些都是过程指标。
+
+好的管理是什么呢？平时看过程指标，考核看结果指标。过程指标不但要每周看，而且要每天看，要养成习惯。有些管理者是只看结果不管过程；有些管理者天天盯过程，把结果指标忘了。两者都是大问题。
+
+## 尽一切可能打造极度透明、信任的文化
+
+以上我们谈的更多是协同工具，没什么稀奇的，你可能也正在用其中的部分甚至全部协同工具。
+
+从工具层面上讲，当别人靠摇旗擂鼓进行团队协同的时候，如果你拥有一台电话，就能做到相对的高效协同，就能在市场竞争中脱颖而出。
+
+如果你和别人一样，都在用邮件、微信群进行协同，协同效率就没有差别，也就谈不上太多的管理效益。
+
+但两者的关键区别是什么呢？答案是，信息的透明度不同。从旗语、鼓声到电话，再到微信群、邮件，信息同步的难易度在逐渐降低。你也能看到，其实非常多的公司化行为都是在追求信息的透明化程度。
+
+所以加强协同，从表象上是工具，是四大协同手段；本质上，其实是打造极度透明、互相信任的文化。
+
+比如，很多公司都喜欢开会。一有任务就召开一个立项会，来自产品、研发、销售等各个部门的十几号人，互相协调时间，坐下来低效讨论。我听说过的这类案例有很多，从上班开到下班，一天都在会议室里，让人很痛苦。
+
+其实你可以反过来想想：开会是为了什么？（看，前面我们讲了要学会思考问题的本质，就要时时不忘去练习）其实就是为了保证信息透明、保证协同，花费时间，努力对齐所有人的思想、目标、时间点和工作内容。
+
+是不是感觉做得不太聪明了？
+
+单纯在开会这一点上，我觉得字节跳动做得就很棒。他们开会前  10  分钟，将会议内容同步在共享文档里，参会者共同修改，对文档进行评注，然后大家一起过文档内容，效率真的提高了很多。
+
+但这样做有一个前提：信息是高度透明的，所有人都知道目标是什么、会议材料是什么，这样才能在共享文档上做有效修改。如果你连目标都不知道、项目背景都了解不足，还怎么修改，怎么协同？**不够透明的信息，最终都会花掉团队更多的时间成本。**
+
+所以协同的真正关键就是极度透明，无论是目标还是必要信息。越透明，大家的思想就越容易对齐，协同效率就越高。**没有透明就不要谈协同**，在现在的市场环境中，那只能算作低效协同，实践价值不大。
+
+## 问题必须提前暴露
+
+经常同步好消息，这点其实不难做到。但也要请大家设身处地地想一想：你会将坏消息主动同步给领导吗？
+
+比如，线上生产程序存在无人发现的内存泄漏；公司要做容器化，事到临头发现服务器没准备好；因为个人能力，进度严重拖延，马上接近公司级重点项目的 Deadline ……
+
+在很多公司里，答案都是：不一定。但这些问题才是高效协同最重要的部分：及时暴露问题，才能及时解决问题。一方出了意外，导致整个项目组都阻塞住，这是严重的协同问题。
+
+因此，我在彩食鲜制定了两项规定，不容破坏：
+
+1. 问题必须暴露，不许隐瞒，这是红线。有问题不上报，发现后直接开除；
+1. 允许犯错、试错，不以指标决定绩效评分，最终以复盘情况决定绩效。
+
+第一项规定是军令，保证协同的核心价值和底线；第二项规定则是为了给予团队安全感，给大家成长的空间，鼓励大家冲击更有挑战的目标。一项高难度的任务，即便结果不尽如人意，只要复盘时说得通透，一样能在绩效考核中拿高分。
+
+有人看到这里就想吐槽：第一条规定那么严厉，第二条规定还要创造安全感，怎么可能呢？
+
+你要注意，发现问题后主动暴露问题其实并不难，不存在能与不能的问题，只有愿与不愿的问题，所以我们严格规定。
+
+而第二项是个能力问题，今天这么多有挑战的目标，不确定性的因素非常多，怎么鼓励人人奋勇当先，不以  KPI  来进行考核。**在彩食鲜科技中心，确定性工作使用**  **KPI，不确定性工作使用**  **OKR，效果很好。**
+
+因为团队成员都是活生生的人，对于人来说，安全感很重要。没有安全感的团队不止绩效差，协同性更差，因为信息不再透明了。没人会在不信任的环境中说出心里话，兴许一个说不好就被开除了。
+
+允许试错/犯错、信息极度透明、事后的客观复盘、绩效评定的公开化和透明化，不断地持续做这些管理工作，团队成员会越来越互相信任。这反过来会提升组织的协同效率。
+
+这上面的两项规定，体现了管理的辩证思考，管理的灰度，我们后面有一讲会单独讲这点，困扰很多初级管理者的也是在这里。
+
+## 结语
+
+今天我们聊了新晋管理者的第二个重要任务：加强组织协同效率。我们大概总结一下：
+
+1. 协同就是向管理要效率，是管理岗位存在的基础意义；
+1. 管理者要通过四类工具和基础认知，时刻盯紧协同中的目标聚焦问题和意外情况；
+1. 效率是相对的，其关键是极度透明的文化，没有透明就谈不上高效协同；
+1. 工具选择只是提高协同效率的一部分工作，给团队带去有底线的安全感往往更加重要。
+
+你可能会想，老乔，等一等，前面你讲了，协同的关键词有两个：目标聚焦，顺畅合作。关于怎么做到「顺畅合作」，你还没说呢？
+
+不是不说，只是可以简单说，因为确实不难。目标聚焦部分我们其实回答过了，也讲解了协作的客观方法。掌握这些方法后，如果还会出现影响团队合作的情况，那更多的是当事人的态度或格局问题：
+
+第一，对方不愿意配合，是态度问题。管理者发现后要及时出面，说服解决；
+
+第二，对方愿意配合，但确实很忙。管理者及时出面，判断哪个需求更贴近大的目标，以公司的利益为主，大家都要在大的格局看问题、做决策；
+
+第三，无论为公为私，双方吵起来了，乌烟瘴气，以至于管理者都不好插手。这点倒是难倒了很多人。
+
+我和许多管理者聊过，相当一部分人都喜欢在这一点上纠缠不清，有一些管理者简直就是团队的“居委会阿姨”，耗费大量的时间调和团队矛盾，最后不但效果不理想，团队的风气还变坏了。
+
+其实解决办法很简单，我告诉团队，**彩食鲜 IT 团队有不同观点，要通过沟通来解决，不能决策的找上级管理者决策，但绝对不允许在办公室吵架（不是辩论），如有发现，直接开除**。然后，问题就直接解决掉了。前面我们也提到了，对于团队成员个人来说，不难做到但又影响很大的规章制度，要坚决执行，贯彻到底，没有那么多花里胡哨的管理手段。
+
+这就是保障团队间顺畅合作的秘诀，更多考验的是管理者的认知，而不是手段。
+
+此外，你也要记得，任何时候都带着辩证的思维去思考，不能听了课程就盲目照搬。很多大厂协同效率就是很低，一方面是因为企业规模变大了，一般情况下，企业规模和协同效率成反比；另一方面，可能也在于，这些公司当下压根不需要追求协同效率。
+
+如果你所在的公司商业模式优越，或者正在风口上高速增长，千万别追求什么管理的效益。我建议你忽略这些管理细节，尽一切力量狂奔，帮助公司滚雪球，把市场做大。如果这时停下来雕琢细节，有可能会丧失先机，因小失大。
+
+但我们也要意识到，任何一家公司都不会永远野蛮生长，增长曲线终有一天会趋于平缓。尤其是在今天：我们的市场正从「供不应求」过渡到「供大于求」，从增量时代过渡到存量时代 —— 这时，管理的意义就凸显出来了。可以说，任何一家公司最终都要追求管理的效益，也就是追求协同效率，这只是时间问题。
+
+好了，关于「加强协同效率」的话题，到这里就要结束了。像以前一样，如果有问题，就在评论区向我提问。
+
+我们下一讲再见！

极客时间专栏/乔新亮的CTO成长复盘/对管理工作的复盘/09 | 管理者最重要的三个任务（三）：激发团队活力.md

@@ -0,0 +1,151 @@
+<audio id="audio" title="09 | 管理者最重要的三个任务（三）：激发团队活力" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/94/0f/949000dc5914f5a664568797123d7d0f.mp3"></audio>
+
+你好，我是乔新亮。
+
+前面两讲，我们聊了聊管理者最重要的任务（一）和（二）：组织调整到位、加强组织协同效率。
+
+有同学看完后，留言提问：这些都做了，但某个部门事情较杂，人员主动性较差，每天按部就班地工作，没什么激情，怎么办？
+
+别急，这一讲，我们就来聊聊如何激发团队活力，补上管理者三大要务的最后一块拼图。
+
+## 寻找同路人，管理要慎重
+
+我相信，现在在读专栏的你，要么已经是管理者了，要么有志成为一个优秀的管理者。那么不妨想想，如果将激发团队活力的任务交给你，你要做的第一件事是什么？
+
+- 请团队吃饭、打王者荣耀，和大家打成一片？
+- 召集大家开会，给大家发表一场振奋人心的演说？
+- 一对一和团队私聊，说说对下属的期望和规划？
+- 同步一个关于绩效和奖励的好消息？
+
+……
+
+很棒，都没错，视具体情况都可以操作，但都不是第一件要做的事。如果让我说，我认为要激发团队活力，管理者的第一个任务是找到同路人。
+
+以前大家只觉得公司找合伙人需要同路人，其实这还不够，最理想的情况是，团队内的每一个人都是同路人。如果短期内达不到，我们要试着在长期内不断追求同路人文化。
+
+激发团队活力，其实解决的是关于人的问题，而许多有关人的问题，其实都是思想问题。你看一些讲建国早期历史的电视剧，大家在路上相遇，互相称呼“同志”。同志是什么意思？同志就是志同道合的人，同德则同心，同心则同志，就是同路人。
+
+那个时候，我们经济不发达，物质条件不丰富。在最困难的日子里，全国勒紧裤腰带，展现出了惊人的凝聚力，挺过了许多天灾人祸。
+
+你想想，如果企业团队的激励能接近类似的效果，这家企业会拥有多么可怕的战斗力？
+
+反之，如果找不到同路人，你会发现自己陷入很多负面的管理细节里，一直迟到的同学怎么沟通？一直吵架的同学怎么沟通？能力差还不学习的同学怎么沟通……一大堆问题在等着你。
+
+其实会出现这样的情况，不一定是你的管理手段不够丰富，而是你没替团队找到同路人。
+
+至于怎么找到同路人，其实包含了很多琐碎的工作，比如：认真规划面试工作、企业文化宣传、激励措施制定……最关键的是，开除那些触碰底线的人，尤其是能力很强、但触碰底线的人，因为这样的人对团队其他成员的影响力很强。比如说，我们团队不允许抱怨，你可以反馈问题、随时找我商量解决方案，但不允许私下、不停地抱怨，否则立刻开除。
+
+你可能会心里有点不舒服，老乔，我感觉你这样有点冷酷。你要明白，管理者的职责不是保证每个人都成功，而是保证组织以及留在组织中的成员成功。如果管理者只做好人，最后大家短期都开心，长期组织死掉了，最终是把所有人都害了。
+
+另外，那些会导致员工被开除的制度，一般只是在工作态度上有所限制。换句话说，这些规定没有执行方面的难度，只要你愿意遵守，就一定不会犯错。
+
+在[《08 | 管理者最重要的三个任务（二）：加强组织协同效率》](https://time.geekbang.org/column/article/307105)这一讲里，我们也提过类似的问题：彩食鲜不允许在办公室吵架（非辩论），如有发现，直接开除。
+
+有时管理者做类似决策一定要果断，等到团队气氛已经被少数人破坏后，补救起来反倒比较困难。成年人都会形成自己的逻辑闭环，各类行为习惯是有惯性的，要做改变非常困难。董明珠说格力最为重视校招，很少在外招聘成熟的管理者空降，为什么？就是要保证在格力工作的，全部是同路人。
+
+当我们找到同路人加入组织后，在管理方面反而要慎重再慎重。一些同学常常不自觉地犯一个错误：对管理上瘾，在团队管理方面投入的精力越来越多，好像不多管点，自己就失去了在企业内存在的价值。短期来看，还是非常值得肯定的，管理者确实要多上心、多付出，但长期看来就有问题了。
+
+一个比较关键的认知是：管理是为了不管，管理的目的是为了将不那么能自我驱动的人，变得更主动、更积极，而不是当个监工，越管越严。
+
+**如果管理制度只是越来越多，最后公司会被制度束缚住手脚，响应外部市场的速度会越来越慢**。做的事都对，但结果是输给了市场。管理要从少到多， 然后还要从多到少，这个过程中什么发生了变化？
+
+团队成员的构成变了，团队里面出现了越来越多的自律、自驱的同路人。**先管，向管理要效益；然后慢慢不管，团队自律、自驱，管理逐步达到无为状态**。整个过程体现了用发展眼光看事物演变的辩证统一的哲学观，具体到过程中某一个点，要有灰度管理的思想。
+
+首先，如果你始终处于工作饱和状态，个人是很难上台阶的 —— 做初级管理者都天天熬夜了，做高级管理者不得天天不睡觉了？要想办法逐渐用更少的工作量，达成更好的效果；
+
+再者，应该人人都希望自己团队都是自驱力强、创造力强的成员。如果管理介入得太多、太死板，那些自驱力强的人才，就会逐渐离开团队，因为他们失去了自由和空间。
+
+最终我们理想中的样子是，所有人都很自由、都不需要管理。那么其中的另一个核心就是，团队是否具备开放平等的工程师文化，这样的文化才能激发工程师的积极性。
+
+这一点，你一定要慎重，既不能不管，也不能管理过度，要在文化上下功夫。
+
+## 赋予团队使命，打开考评与晋升通道
+
+找到了同路人，也把握好了管理的尺寸，还不够。其实使命和愿景是很重要的，有没有带着一股信念去做事，效果完全不一样。
+
+我们做的许多工作其实都是有意义的，是让社会变得更好。就看你能不能找到这个意义，并把它赋予团队。在彩食鲜我总说：以人为本，让员工、客户、合作伙伴更卓越。
+
+有时候工作也很有挑战、也很累，但你的工作让用户过得更好、更轻松了，是不是很有成就感？
+
+很多公司其实内部是贴了很多标语的，但光贴是不够的。为什么我的团队总叫我“乔老师”，因为我总跟他们一套一套地讲道理。**只有频繁地重复输出，坚持言传身教，使命和愿景才能从墙上走下来。**
+
+此外，管理者也要让团队感受到实际的业务和工作压力，制定有挑战性的目标，让大家一起去比拼工作成绩。
+
+但是这个对比，一定是同赛道的对比。如果你让员工和经理比，那赢得永远是经理；你让高级工程师和初级工程师比，赢得永远是高级工程师。长此以往，考评就失去了意义，对弱一点的普通成员也是一个打击。
+
+评奖、做绩效，每个团队都做，但考评赛道的划分，你的团队做了吗？划分赛道很关键。
+
+有了考评，就要有晋升的通道。在管理复盘的第一讲里，我们分享了职能型研发组织和产品型研发组织的区别，有一个细节不知道你有没有注意到：在产品型研发组织里，团队 Leader 的任命原则是能者居之，能上能下。为什么？是因为要让考评和激励有实际意义。
+
+我常常跟人说，如果一个 leader ，提拔上去就下不来了，无论干得多烂都在上面挂着，组织不就成为了一潭死水了吗？也谈不上什么激发团队活力了。
+
+同样，我们打开的是一条晋升通道，管理者做得不好被罚下去了，以后做得好了还可以再上来嘛。**组织内是同赛道进行对比**，他可能在管理赛道上是倒数，但在普通员工赛道就又是“优等生”，又变得很有竞争力。第一次做管理者，可能做得不好，降职了；一段时间后，第二次做管理者，可能就吸取了许多教训，变得更熟练了。
+
+从管理手段上讲，每个赛道就如一列高速行驶的火车，跑在前面，给火车带来动力的员工，要进行奖励，叫做“**给火车头加足油**”；跑在火车后面的，拖慢了火车前进的速度，就是“尾巴”，这个赛道的尾巴，要“**切尾巴**”，到下面一级赛道去。
+
+所以作为高层管理者，不要怕对下级管理者进行任免；作为小团队的管理者，也不要对任免心生抵触。玻璃心的成员是不适合当管理者的，华为内部讲：“板凳能做十年冷”。十年说得有点久了，一年还差不多。如果一点委屈都受不了，团队是不会有凝聚力的。有上有下，团队的活力才能被充分激发出来。
+
+到此为止，这一讲是不是和你想象的不太一样：说好了要激发团队活力，结果老乔讲了半天和激励无关的内容。
+
+别着急，上面我们谈的都是压力，可光有压力也不行，还要给团队动力。站在管理者的角度，就是要尽可能地发现团队每一个人的优点。
+
+## 管理游戏化，发现每个人的优点
+
+其实，这和管理者的个人风格关联度比较高，有些同学比较活泼、性子比较跳脱，做管理者时也擅长发现别人的优点。
+
+有的同学可能自我要求比较高、比较严肃，因而对下属的要求也比较严格，总觉得下属只有各方面都做得不错时，才能得到表扬。
+
+其实不是这样的，每个人都有优秀的地方，不能等他做到十全十美再去表扬。管理者要设计一套体系，努力去发现团队中优秀的个体，有些人虽然不是最勤奋的，但他是最有契约精神的；有些人虽然不是代码实力最强的，但他是进步最大的。在彩食鲜，我们设置了八个奖项，未来还要设置更多：
+
+- 金苹果奖：工作成绩好，业务价值高；
+- 烂草莓奖：还需要继续努力不断提升；
+- 最具协作力奖：团队协作做得好；
+- 最具契约精神奖：使命必达，保质保量完成任务；
+- 持续改进奖：敢于试错，在自己的工作岗位不断尝试，持续改进；
+- 最佳专业技能奖：专业技能强，技术第一名；
+- 最佳服务满意度奖：时刻将客户服务放在第一位；
+- 月度最突出贡献奖：当月团队贡献最大；
+
+这些奖项其实与奖金无关，也不是那么正式，我们每周、每月都会评奖。你说，与奖金无关，大家还会有动力吗？
+
+其实是有的，我们团队一个小伙子拿了奖高兴了半天。我开玩笑说，这又不能换钱，这么高兴干嘛？他说，那也高兴，从小到大，没拿过奖。
+
+很多人喜欢玩游戏，因为游戏是即时反馈，付出就立刻能看到效果。团队内的激励和评奖也是这样，我们要把管理游戏化，给大家频繁的正向激励。
+
+涉及奖金的绩效当然也要做，但穿插在日常工作中的激励手段同样重要，千万不要忽视。
+
+## 激活团队，重要的是细节
+
+说了这么多，其实你会发现，很多都是宏观层面的内容，有些是制度问题、有些是文化问题。
+
+但其实光喊口号是不行的，激活团队、打造文化，是要抓很多琐碎的事物，频繁的动作很重要。
+
+比如在彩食鲜，我们是要求团队每天打卡的，但打卡结果不与奖金挂钩、不需要补考勤、没有罚款，管理者也不会单纯因为迟到去批评一个团队成员，简单一句话，打卡只是记录了数据。
+
+那么为什么要打卡呢？
+
+首先，这个动作会让团队成员有时间意识；
+
+其次，当团队的产出和工作态度出现问题时，打卡数据会成为一个参考信息。
+
+比如项目在不停地延期，有个人还迟到早退，这样的情况就应该重点关注，看到底是家里有特殊情况，还是心态有问题需要调整？
+
+再比如项目做得又快又好，有人还是按时下班，说明他的能力已经超过现阶段的公司要求了，应该给他更有挑战性的任务，让他可以成长。
+
+诸如此类，关于文化和激励，都是一些琐碎的细节，但如果长期不关注，就会造成连锁的负面反应。
+
+至于激励是否与金钱挂钩，界限比较模糊，要根据实际情况来定。我更推荐按业务价值确定激励数额：业务增长，大家吃肉；业务停滞，大家就要咬牙努力。这样激励团队，得到的结果是什么？是团队时刻把成就业务放在心里。
+
+## 结语
+
+到这里，关于如何激发团队活力的话题，我们就讲完了。同时，管理者最重要的三个任务，也为你梳理完毕。
+
+你可能会想，老乔，接下来呢？接下来该做什么？
+
+组织调整到位、协同效率提高、团队活力激发，都做完后，下面就是打仗了。带着团队去打仗，把业务增长做出来，让 IT 能力建设的飞轮转起来。让团队把「赢」当成一种习惯，有时候，一场胜仗比任何管理方法都管用。
+
+如果你觉得，关于这部分内容，听得还不过瘾。别担心，在整个第二章的管理部分，我们还将沿着脉络，继续深挖技术管理者的必备素质。你可以在读的过程中，揣摩一下，哪些部分是贯穿全篇，始终强调的；哪些更偏向认知，是需要具体情况具体分析的。
+
+同样，如果有问题、有想法、有感触，欢迎在专栏下方留言。我常说，沟通创造价值，分享带来快乐。如果你觉得有用，也欢迎大家分享出去！
+
+我们下一讲再见！

极客时间专栏/乔新亮的CTO成长复盘/对管理工作的复盘/10 | 管理的人性哲学：金刚之怒，菩萨慈悲.md

@@ -0,0 +1,151 @@
+<audio id="audio" title="10 | 管理的人性哲学：金刚之怒，菩萨慈悲" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7f/bc/7f2fb48f29d5d56e6aa5b7ee407c5abc.mp3"></audio>
+
+你好，我是乔新亮，很高兴我们又见面了。
+
+前面我们讲了管理者最重要的三个任务，也就是所谓的“三板斧”。为什么要抡这三板斧呢？是为了自顶向下地搭建优越的架构和制度，最终让业务增长，让飞轮转起来。
+
+换句话说，这是个体系化的解决方案，是顶层设计。
+
+在这一讲里，我们将视角拉低，去近距离地看看在体系内工作的团队成员，想想管理者如何在细节上彰显领导力。
+
+稻盛和夫有句话说得好：“一切管理问题，最终都是人的问题。”
+
+那么到底如何解决人的问题呢？
+
+我对这个问题的思考是：除了体系化的措施外，在很多时候，管理还是一门面向人性的哲学。如何既有“金刚之怒”，又有“菩萨慈悲”，是管理者破局的关键。
+
+## 金刚之怒，菩萨慈悲
+
+如果你经常去寺庙，可能会发现，寺庙里经常供奉着一尊名叫韦陀的佛陀护法，职责是护法安僧，穿着盔甲，拿着金刚降魔杵，很威严。在背面则会看见一尊弥勒佛像，慈眉善目，笑口常开，叫人看着就开心。
+
+两个截然相反的形象，出现在同一座寺庙里，冲突吗？其实不冲突。管理也是一样，金刚之怒和菩萨慈悲，就象征着管理的两面性。
+
+其实在管理这一章的前三讲，我猜有些同学应该是没好意思留言。因为在体系化的管理方法里，可能很多细节都显得有点“冷酷”。比如：
+
+- 办公室吵架，开除；
+- 工作受了委屈后不沟通、不解决，一直抱怨，开除；
+- 生产有问题时，隐瞒问题，开除；
+
+……
+
+看起来都是金刚之怒，一怒就把员工开除了。但你仔细地想想，这些规定真的冷酷吗？不是的。
+
+用沟通替代吵架和抱怨、用求助替代隐瞒，其实都不难做到，很多事情甚至就是一念之差。所以当我对员工宣布这些规定时，我知道，只要大家想这么做，是一定能做到的；如果有人不这么做，说明他可能就不太适合团队，不是我们的同路人。
+
+最终我们保证的是组织成功，让留在公司这条“大船”上的人能够受益，我觉得这才是真正的为了员工好。
+
+在我眼里，真正“冷酷”的行为是：发现组织气氛变坏的苗头，不及时制止；发现个别员工影响组织成功时，不及时沟通。最终，优秀的人受不了了，离开了。组织因此垮掉了，公司倒闭了，所有人都遭殃了。这才是真的冷酷。
+
+所以，常常有朋友问我，老乔，都说慈不掌兵，但我是个比较和善的人，怎么办？我是不是不适合做管理者？
+
+其实在我看来，仁慈不代表啥也不管，严厉也不代表没有人情味儿，金刚之怒和菩萨慈悲不是矛盾的。最近，我就有过两次实践，遇到了两类典型案例，此时正好与你复盘一下。
+
+## 案例一：如何与员工沟通加薪问题
+
+最近有一个团队的核心骨干，到办公室找我，要求加薪。认真听他讲完诉求后，我把他狠狠地喷了一顿。
+
+为什么呢？因为他有一句话是这么说的：“……我知道周围很多人工资都比我高……”
+
+我直接说，你这属于严重的违规啊！公司内不允许互相打听薪资，这是规定，为什么不遵守呢？
+
+你看，到这里其实属于金刚之怒：公司的规定要严格遵守，尤其是会对其他人产生影响的、文化方面的规定。
+
+不过我接着对他说：“不过客观来讲，你的薪资确实偏低了。”
+
+这个是事实，其实即使他不说，这次调薪我也会将他算进去。但这个薪资低是有历史原因的，在上一家公司工作时，他的薪资就不高。当他来到彩食鲜时，薪资也没有实现跨越式的成倍上涨，这是客观事实。
+
+当下为什么薪资低？因为你的起点低，这是自己过去的选择造成的，要为自己的选择买单；未来薪资为什么会上涨？因为你在为团队持续地产出价值，两三年以后，你的薪资可能就满足了自己的期望。
+
+他听了后，也认可了这个道理，表示就算不涨薪，也要留在团队，因为可以获得成长。后来，他还问 HR ，能不能把家里人也内推到公司来。
+
+于是，事情圆满地解决了。后面这段话，就属于“菩萨慈悲”的范畴了。
+
+所以你看，什么叫“金刚之怒，菩萨慈悲”？金刚之怒是你要按照规章制度，为团队划定界限。菩萨慈悲是指作为管理者要有同理心，你要设身处地地去理解员工的境况，真心地为他着想，二者其实是不冲突的。
+
+很多时候，作为高级管理者，对团队的情绪的感知能力是很弱的，很多问题在管理者眼里就是个数字而已。但对员工而言，那就是全部。在某个时刻，心理状态是有很多变化的，管理者要学着去理解员工，设身处地地为员工着想。
+
+面对加薪的诉求，管理者确实容易感到为难，但比这更大的挑战还有很多。在上一讲，我总说，团队 Leader 要能上能下，如果升职以后就不再降职，团队还怎么保持活力、怎么打仗？
+
+但升职容易，降职难。怎么处理绩效差的员工，怎么沟通降职问题？这也和“金刚之怒，菩萨慈悲”的管理哲学密切相关。
+
+## 案例二：如何处理员工的绩效和降职问题
+
+在彩食鲜，KPI 和 OKR 系统里的几个数字，不会直接决定你的绩效和薪资水平。因为有些同学为团队付出比较多、为业务牺牲比较大，虽然 OKR 看着不突出，但实际做了很多事。
+
+所以在每个季度结束时，我们会开一场述职会，由其他人共同现场打分，保证公开透明。打分项则涵盖了团队价值贡献、产品能力提升等各个纬度，讲得好可能绩效就好，讲得差可能绩效就差。
+
+你可能想，那技术人不成了靠嘴吃饭的人吗？也不能这么理解，在「组织调整到位」那一章，我们说了，团队 Leader 的必备能力之一就是“汇报能力”。
+
+一则，就算是技术人，也要把语言表达能力重视起来，对团队协作和职位晋升都有好处；二则，很多时候，表面看是说不清楚，实际是没想清楚。所以这个绩效考评机制，还是相对公平的。
+
+但问题是，不管有多公开透明，绩效考核总是有好有坏，有第一、有垫底的。那么绩效得分比较低的团队成员，往往就很难接受这个结果。
+
+一个多月前，在我们 Q3 的述职会上，评分倒数第一的小分队的 leader 要被降级，他本人其实就不太服气：他觉得自己付出了很多，也为组织创造了很多价值，不应该是这个结果。
+
+于是，我当着述职现场所有人的面，和他公开地聊了聊这个问题：
+
+第一，这么多人在现场公开打分，你就是倒数第一，要承认这个结果；
+
+第二，会讲很重要，要锻炼汇报能力。你做的 PPT 完全不合格，如果光凭 PPT 和汇报结果打分，你的得分应该更低。恰恰是因为大家知道你平日里的成绩，才会出现这个分数；
+
+第三，你在团队管理方面得分很低，为什么？因为你只是个专业的产品经理，很多管理工作都没有做。就连团队内部发生吵架现象时，都没有及时地介入和做调整。既然你身在管理岗位，就必须承担起相应的责任，为组织的一切问题负责。
+
+以上三点，他是接受的。
+
+其实，很多让人感觉难以操作、场面尴尬的管理问题，就是被这样化解掉的。但仅仅这样做还不够，这只是完成了“金刚之怒”部分，一个人嘴上或许会同意，心里可未必服气，时间一长，很容易在心底产生疙瘩。
+
+于是接下来，我对大家说：“虽然他评分倒数第一，但他在过去三个月间进步非常大，拿的薪资也很低。所以说，就算今天他被降职了，我还是要给他加工资。”
+
+我也直白地和大家说，按评分，他理应被降级。但目前，我手头没有更合适的 Leader 人选，所以我决定把他重新提拔上来，再给他机会去学习和锻炼。
+
+最后，我对这位 Leader 说：“xxx，你要感激。5 月份的时候，团队给了你上台阶做事的机会。你不是没做好，但却是同赛道里较差的。我认为你确实进步很大，这次的机会要好好把握住。”
+
+先把这位 Leader 降职，这是金刚之怒；再把他提拔回来，这是菩萨慈悲。整个过程中，我一句假话都没有讲，说的全都是最实在的评语。而且我也知道他是很努力的 —— 他只是需要更多的时间。
+
+当然，也要注意，无论是“金刚之怒”还是“菩萨慈悲”，都不是仗着管理者的身份滥用权力。尤其是**当你批评下属时，越严重的批评越要选择私密场合进行，一定不要骂人**；如果是通报批评，一定是有目的的、谨慎的。
+
+作为管理者，要遵守规则，你的权力不是对下属“威逼利诱”，而是督促大家和你一样，都去遵守公司的规则。
+
+## 金刚和菩萨，本为一体
+
+前面，我们讲了两个案例，都是真实发生在公司内，由我亲手解决的。
+
+我相信，你很容易就能体会到这套管理哲学的含义，甚至在读这篇专栏前，就已经接触过类似的理论了 —— 这并不是什么新奇的概念。
+
+但在这两个案例中，都有一个比较隐蔽的细节，不知道你是否注意到了：
+
+金刚之怒和菩萨慈悲，往往是同时发生的。
+
+比如在第一个案例中，我批评那位同学违规打听薪资，随后就提出要给他涨薪；在第二个案例中，我指出那名 Leader 绩效倒数第一的原因，但随后就让他“官复原职”。
+
+尤其是在最近几年，我越发深刻地认识到，只有当金刚之怒和菩萨慈悲同时出现时，管理的效果才能达到最佳。
+
+有一部分管理者，天生脾气好，只有慈悲没有严厉，只有夸奖没有批评。一段时间后，员工开始变得飘飘然，无法接受任何岗位和薪资调整。其实这就叫做“捧杀”，等于管理者间接害了这名员工，断绝了他的成长道路。
+
+还有一部分管理者，自己有压力，脾气暴躁，不尊重员工，对员工没有帮助、没有指导，功绩自己来拿，问题下属来背，团队的士气怎么可能好。
+
+我和团队经常讲的一句话是， **你们所有的问题都是我的问题，你们所有的功劳都是我的功劳**。那有了这点认知后怎么做呢，功劳都让下属拿，问题最终都让自己扛。你说，随着时间的推移，我还会发愁如何与团队建立信任感吗？你想想，这个时候，金刚之怒是不是就有了根基？
+
+夸奖员工的时候，要指出员工可以继续提高和成长的方向；批评员工的时候，也要肯定他的努力和做得好的部分。这样员工才能找到平衡，不断成长。
+
+所以，最聪明的管理者，会将金刚之怒和菩萨慈悲，辩证统一地结合在一起，时刻让团队成员认得清现实，看得见方向。
+
+## 结语
+
+这一讲，我们聊了聊管理的人性哲学。
+
+在你尝试实践的时候，还有一点需要格外注意：**管理者的管理风格和个人形象是强相关的**。
+
+比如，我是在团队中的形象是：比较有主见、有权威的管理者（我自己是这么认为的），所以我的很多沟通、措施，不会受到团队成员公开的、强硬的质疑或挑战。
+
+但如果你的形象是：脾气很好、非常民主的管理者，在套用我的一些管理方法时，可能就要针对性地做调整。
+
+在他人心目中，管理者的个人形象有很强的先入为主色彩，如果早期比较和善，后期如果想变得威严一点，也不太容易。当然，每个人的形象和风格都有所不同，不代表哪种形象或是哪种管理风格更好，只要适合当下的团队氛围，有切实的效果，能帮助团队成长、业务增长，就是最好的。
+
+金刚之怒是规则，菩萨慈悲是同理心，管理者的一体两面，从建立信任出发，持续做事赢得团队信任，最终打造一支高绩效、有战斗力的队伍！
+
+最后，虽然前面提及了许多关于人性的哲学，但我始终认为，**一个人最可贵的品质是真诚**。在前面的两个案例中，我反复强调，虽然对当事人是批评与夸赞皆有，但并没有一句假话、虚伪的话。人人都有优点，只是需要管理者慧眼识珠。你要真的去理解他、体谅他，为他着想。
+
+相信员工很聪明，相信周围的人比自己聪明，基于这点认知去做事，唯有真诚才能建立信任，笨办法就是最好的办法。
+
+我们下一讲再见！

极客时间专栏/乔新亮的CTO成长复盘/对管理工作的复盘/11 | 全局思维和持续完善体系的建立，让团队持续成长.md

@@ -0,0 +1,137 @@
+<audio id="audio" title="11 | 全局思维和持续完善体系的建立，让团队持续成长" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/99/7e/997de6f83c86d4bebaea8fef94227a7e.mp3"></audio>
+
+你好，我是乔新亮，很高兴又与你见面了。
+
+在技术管理领域，有一个很古怪的现象，不知道你是否有注意到：很多管理者，在面对团队成员的争吵时，会选择冷处理、和稀泥，也有人干脆沉默以对，直接忽略这个状况。
+
+但你肯定知道，理论上，管理者是应该介入争吵，及时调停的 —— 不然团队士气和协作就会受损。
+
+那为什么会有这样的情况出现呢？原因可能是多种多样的，但一个主要的原因，可能是缺乏全局思维。注意，这个评价不单针对发生争吵的双方，也针对不作为的管理者。
+
+只要是争吵，情况一般都比较类似：双方各有各的道理，互不退让。作为管理者，也不想影响任何一个人的积极性，所以两头为难，干脆不管。
+
+其实，如果缺乏全局思维，就会经常面临这样的决策难题。有个成语叫作“盲人摸象”，意思是说，几个盲人要通过触摸大象，来描绘大象的形象。于是，摸了象牙的人说，大象像一根长棍；摸了象腿的人说，大象像一棵大树；摸到大象肚子的人说，大象像一堵墙……
+
+他们说错了吗？**站在个人的角度，没错；但站在全局的角度，<strong><strong>可能每个人都**</strong>错了</strong>。很多管理层面的问题，其实都可以用“盲人摸象”来形容，道理极其相似。吵架，只是缺乏全局思维造成的众多问题之一。
+
+2019 年在环球易购时，我就经历过这样一件事。
+
+## 高可用设计或许是个“伪命题”
+
+在环球易购，我们主要做的是跨境电子商务，服务遍布很多国家和地区，其中有一条线路，是通过光缆连接美国达拉斯到深圳的机房。
+
+我去了没多久，在检查基础设施的高可用建设时，发现线路居然只有一条 —— 很明显不符合高可用设计的思想。因为光缆是有可能被挖断的，底层基础传输网络的抗风险能力太差。
+
+作为技术管理者，看到了风险，当然要想办法解决了。
+
+但着手解决时，相关业务部门却不愿意为新增加的光缆付费，说目前部门的压力大，不愿意承担这个费用。听到这种说法，我带领的团队对此很是不屑一顾 ——什么压力大，简直就是不懂啥叫高可用。
+
+你看，一个典型的问题场景出现了，技术人员在想：明明有问题，不想着去补救，出问题的时候可别找我；业务部门想的是：我这业务压力这么大，你还要纠结什么架构设计，啥也不懂。
+
+站在各自的角度，他们说的都对，根源在于看问题的视角不够高，缺乏全局思维。
+
+我和我的团队说，首先，我们要学着去理解业务部门；然后，我们来分析下，对于企业而言，这种设计到底有什么样的风险。
+
+其实，这条光缆的问题不会对 C 端业务造成影响，只会影响后台的统计分析。接着，我们向上看，根据过往经验分析：如果光缆被挖断，相关业务会中断多久、影响范围有多大？
+
+最后，技术团队将相关调研整理、总结，和业务部门坐下来相互对齐，得出结论：业务影响处于可以接受的范围，结合公司情况，暂不增加备用光缆。
+
+到我离开环球易购时，其实这条线路仍然只有一根光缆。光缆也被挖断过，但无论是 IT 部门还是业务部门，都能接受这个结果，没有争执和推诿。因为这是站在全局视角，大家研讨得出的结论，虽然有利也有弊，但都在预估范围内。
+
+你看，当我们去各类技术会议学习分享时，大家经常探讨高可用、高并发的架构设计。但在实际的工作中，这类设计不一定能实现，甚至也不一定在当下对于公司是最合理的。
+
+类似的问题还常见于中台建设。
+
+这两年中台特别火。很多技术 leader 好不容易把中台研究明白了，觉得这个设计思想好啊，回去就要搞，结果业务部门不愿意，说：
+
+“你说做中台、做中台，说了半天就是架构更好了。我们这个月的 KPI 都要完不成了，还要支持你做个半年不见效的中台？”
+
+于是，技术 leader 把自己气得够呛，觉得这哪叫“技术驱动型科技公司”，没有一点长远眼光，自己留在公司就是浪费青春。
+
+那么这又是一个有关全局思维的问题，我们要回答的，其实不是中台在架构方面的优劣势，而是在半年以上的时间维度里，中台对于整个企业，在营收增加、业务增长方面的优劣势。
+
+如果说得清楚，其实业务部门也有不小的接受可能，因为大家不但需要考虑短期增长，也会追求长期增长；如果说不清楚，其实中台做了也是白做，属于管理者自己没想明白。
+
+所以，在前面的章节里，为什么我总是强调：研发团队要有业务思维，业务团队也要接受技术指标考核呢？一个重要原因，就是要赋予双方更高维度的视角，让大家在工作中有全局思维。
+
+## 全局思维与向上管理
+
+当然，以上我们说的全局思维，都是站在更高的维度，将技术视角和业务视角统一起来，学会用业务增长的思维看待技术建设。
+
+但全局思维又不仅仅局限于此。很多人觉得老板的问题很难回答，因此比较怕和老板对话，为什么呢？因为和老板相比，你缺乏全局思维，格局不够高，因此面对老板的提问，常常感觉出乎意料、难以回答。
+
+而这一点，在每一个职级都会有所体现。一般情况，在同一家企业内，CTO 的全局思维通常强于技术总监，技术总监的全局思维通常强于技术经理，而技术经理又强于普通程序员。
+
+会出现这种差异，当然有信息不对称方面的原因，但同时也有思维格局上的高下之分。比如，很多企业都在推行“公开透明”的企业文化，但基层员工仍然和高层管理者在思维层次上有极大偏差。为何？因为从上到下，没有培养全局思维的意识。
+
+每次周会，都会有许多下属讲自己的工作情况，我的回应经常是：“**你说的都对，但这个有什么用？产品是什么，用户是谁？对用户有什么好处，对公司有什么益处？**”
+
+请注意，我不是在质疑或者否定下属，而是在强迫下属站在全局的视角去思考。
+
+刚才我们讲的是自上而下的思考模式。这段时间，也有很多同学留言说，乔老师，能不能讲讲向上管理？其实向上管理，就恰恰相反，属于自下而上的思考模式。
+
+很多 CEO 其实很讨厌“向上管理”这个词，一是听起来确实让人不大舒服，像是在沟通中，掺杂了很多心机和花样；二是在很多 CEO 眼里，“向上管理”属于伪命题：是 CEO 真的需要被管理，还是下属自以为比 CEO 更明智？
+
+听起来，是不是有点耳熟？对，这其实和下属吵架有一个共同的逻辑：双方都没说错，只是视角局限在自己这一侧。
+
+所以，所谓的向上管理，其实不像很多新媒体文章说的一样：说话先赞同再反对、和老板培养感情，等等。
+
+这些当然可以做，但都只是锦上添花，属于沟通技巧，不算向上管理。**真正的向上管理，是培养全局思维，把自己的思维拔高，和老板站在同一个维度看待问题，同时保持密切、顺畅的沟通**。
+
+不然的话，你的所思所想跟老板压根不在一个频道上，怎么“向上管理”？时间长了，老板只会觉得你自以为是、恃才傲物。
+
+那么如何培养全局思维呢？
+
+说起来倒也不难，主要是**从两个维度去尝试重新思考问题：一是时间维度，二是空间维度**。
+
+所谓时间维度，是指遇事不要只看当下得失，要学会站在未来六个月、一年甚至三年的维度看得失。很多让人难以决断的问题，只要站在更长的时间维度去看，就会豁然开朗。
+
+空间维度，则是指，不要只站在自己的视角看待问题，要时常做好身份转换。比如技术人员要考虑，站在业务部门的角度，会如何考虑这个问题？站在财务部门的角度，会如何考虑这个问题？站在 CEO 的角度，会如何考虑这个问题？这是个人所处空间上的变换。
+
+你可能会想，听起来很简单，就是挺累啊，一个问题要在不同的角度思考这么多遍，烦死了……
+
+其实，这就是思维和认知能力养成的特点：说起来都不复杂，但做起来需要绝大的毅力和耐心。在我们专栏的第一章，大部分认知能力都存在这样的学习特点。但与第一章的许多认知不同，那些属于个人成长相关的认知，而全局思维属于团队管理方面的认知：管理者不但自己要具备全局思维，还要让团队也拥有全局思维。
+
+这么难养成的认知，怎么传递给团队呢？这时就需要建立持续完善体系，让团队持续成长。可以说，如果没有持续完善体系，团队根本就不可能具备全局思维。
+
+## CTO 也可能犯错
+
+在向团队灌输全局思维时，你可能会很头疼。因为有时团队就是不理解、就是不接受，甚至会表现得很偏执，让人只想在心里骂娘。
+
+这时，你要提醒自己：**既然大家都通过了公司面试，就说明基础能力还是有的，没人真的是傻瓜。团队是能进步的，要给团队进步的时间**。
+
+其实我们专栏从上架到现在，我一直在重复这句话。很多管理者，表面上支持“试错容错”的文化，但骨子里就没期望过大家会成长。
+
+哪怕是 CTO，都会犯错，何况是普通员工呢？不给大家留出成长的时间和空间，怎么带领团队打胜仗呢？
+
+2015 年年底到 2016 年年初，我在苏宁工作，曾带着团队做关于容器编排的技术选型。当时，针对容器编排管理工具，有两个选择：一个是 Swarm，另一个是 Kubernetes。
+
+当时我们确实是努力站在全局视角去思考的：
+
+在当时，Swarm 的架构简单，是  Docker  内嵌模块，部署运维成本低，在业务角度有利于降本提效；Swarm 是 Docker 的原生编排工具，支持度好，容器的启动速度高……
+
+相比之下，Kubernetes 当时的情况就有些不尽如人意，所以我们最终选择了 Docker + Swarm 来做容器化改造。
+
+结果，还不到一年，我就知道自己做了错误的决策。你可能也看到了，Kubernetes 后续的成长速度非常惊人。于是，我召集团队，承认了自己的失误，立刻做了调整。
+
+后来复盘这件事时，我发现，在做技术选型时，我们少考虑了一个关键因素：大厂的支持能力。如果再有类似的选型工作，我一定会将大厂的支持能力作为重要的选择条件。
+
+但回到全局思维这件事上，犯错实属正常，哪怕是 CTO 也一样。就像我们常做的 A/B Test，这本就是体系建立工作的一部分。
+
+所以，当你实践这一讲所收获的认知时，如果有不耐烦、不如意的时刻，一定要提醒自己：不要急，这很正常，这些都只是成长的浩瀚大海中的一朵小浪花，都是建立持续完善体系所需的正常工作。
+
+## 结语
+
+这一讲，我们重点聊了聊管理维度的全局思维和持续完善体系的建立，这是一个不断迭代的过程。
+
+一个组织就如同一个人，如何让这个组织有格局，并且能快速学习、持续迭代，是管理者一个重要的能力。迭代，就意味着前面有不完美的地方，在全局视角下具备纠错能力，用更短的周期、更快的速度持续完善，这样组织能力也会随着时间，不断登上新的台阶。
+
+最近，我和一些 CEO 聊天，问他们过去在管理上最大的失误是什么，有好几位都是想了半天也说不上来。为什么？不是因为没犯过错，而是因为对于他们来说，试错、迭代都是正常流程，被正常迭代掉的问题能叫失误吗？当然不能，那本来就是规划之内的情况。你想想，自己和这些 CEO 是否有这种认知上的差距？你能否以同样的心态，看待自己的成长？
+
+**我相信，你一定能做到快速成长。或许现在，也可能是未来的某一天，你也会是那个“没犯过错”的 CEO。**
+
+今天的内容到这里就结束了。下一讲，我们会重点谈一谈，在具备了全局思维后，如何在战略上做聚焦、做取舍，真正做到 CEO/CTO 级别的认知协同，为跨上新的台阶做好准备。
+
+我们所讲的管理者“三板斧”、管理哲学、全局思维、战略聚焦等内容，都是关联在一起的，你在看的时候，要注意前后对照，串联起来。这样的成长才成体系，才不会有失偏颇。
+
+如果有问题，欢迎随时向我提问。我们下一讲再见！

极客时间专栏/乔新亮的CTO成长复盘/对管理工作的复盘/12 | 管理战略上的聚焦和放弃：有舍才有得.md

@@ -0,0 +1,149 @@
+<audio id="audio" title="12 | 管理战略上的聚焦和放弃：有舍才有得" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/9c/97/9c7038c4d832547682e34ea2ea496997.mp3"></audio>
+
+你好，我是乔新亮，很高兴又和你见面了。
+
+上一讲，我们聊了聊全局思维和持续完善体系的构建，目的是为了拔高自己的视角，赋能整个团队。但有一个问题也会随之出现：视角拔高了，看到的问题也就变多了，需要做的工作也就变多了，怎么办？
+
+你可能会想，做啊，成长的机会来啦！
+
+心态很好，很棒！但同时我们也要认识到，管理者不是超人，一个人很难同时在多个有挑战的任务上，全部实现突破。
+
+如果你不去区分工作的重点，就可能就会引发种种连锁问题。好一点的情况是，你把任务都完成了，累得够呛，但全都没有亮点和突破，流于平庸；坏一点的情况是，你高估了自己的执行能力，多个任务严重 delay，产生协作问题，也非常影响自身心态。
+
+你可能会想，这么吓人，那我还是不要主动给自己找活干了？
+
+当然也不要这么想。我认为，企业现阶段存在的那些价值大、急迫、有挑战的工作任务，如果看到了，就可以去主动接下。但接任务的同时，要学会聚焦，在企业战略上聚焦、在管理工作上聚焦、在个人成长上聚焦，先实现单点突破，再横向扩展至其他领域。
+
+用直白的话说，就是“伤其十指不如断其一指”，越是宏大的成长目标，越要徐徐图之。
+
+比如说，我们的专栏到现在已经更新超过十讲了，单是管理者的基本任务就有“三板斧”之多，你听了、学了之后，要怎么实践呢？肯定是一点一点实践，一口一口“吃饭”。**在一定时间内，只将注意力聚焦在其中一个板块上。对于初级管理者来说，这一点尤其重要**。
+
+以前，我们常常只在讨论企业战略时谈聚焦，就像阿里巴巴曾鸣说的：“战略，就是决定该做什么，不该做什么。”
+
+但本质上，无论是对于一名普通程序员来说，还是对于一名初/中级管理者来说，聚焦都很重要。
+
+在我刚毕业时，就曾经切实尝到过「聚焦」带来的益处。
+
+## 普通技术人聚焦个人成长
+
+刚毕业时，我在神州数码做一名普通的程序员，后来跳槽至麒麟远创，薪资变成了 2.5 倍。
+
+如果你还记得专栏「认知」部分的内容，应该会知晓我的这段经历。不知你有没有想过，为什么我在工作不到两年后的第一次跳槽中，就能让薪资上涨 2.5 倍呢？
+
+在做个人成长的复盘时，我觉得其中一个重要的原因是：我在不经意间，做到了个人成长的战略聚焦。
+
+刚到神州数码，我就在负责工作流引擎的研发工作，这个工作内容持续近两年。到我离职时，我在团队内的标签就是：“工作流引擎方向的技术专家”。
+
+请注意，一个程序员身上可以有非常多的标签，比如：Java 专家、架构专家、算法专家、存储专家……但在那时，我身上的标签只有一个，也就是工作流引擎专家，这就是聚焦。
+
+而麒麟远创愿意以 2.5 倍薪资招募我，也是因为我能在非常重要的岗位上，承担起与“工作流引擎”相关的工作。这就成了我的突破点，是我能上台阶的核心原因。
+
+这就像我和咱们专栏许多读者都说过的，一定要做“T”型人才，也就是说，首先要在某个维度成为专家，广度都是深度的附属。
+
+如果在神州数码时，我今天学学存储、明天学学算法，怎么可能在这么短的时间内就有所突破呢？很多同学在极客时间是什么都学，没有目的也没有方向。这种学习精神固然是可贵的，但人的时间是很有限的。
+
+可能你还要谈恋爱、还要和朋友聚会，最后留给每一项技能的时间都不是很多。说白了，在今天这个知识爆炸的时代，学习一些基础技能很简单。
+
+我有信心在三个月内，成为一门编程语言的专家。而且，学习能力像我一样，或者比我更强的人一定很多。这就意味着，你耗时一年，分心学到的 Java 编程知识，可能还比不上别人认真投入三个月的学习成果。
+
+更别提许多人工作了三年、五年后，还不敢称自己为某一门编程语言的绝对专家。
+
+现在，我越发明显地感觉到：这个社会不会奖励面面俱到，但都很平庸的人，光环永远属于那些有明显优势、有明显长处的人。
+
+**成长就是为了变得更优秀，而优秀的含义是：做同样的事情，表现比别人更好。**
+
+我也曾见过一个朋友，在创业公司做到技术总监，去到大厂却拿不到一个高级技术专家的职称，非常可惜。为什么呢？因为无论是在分布式、数据库还是团队管理领域，他都是浅尝辄止。面试一问到深度技术问题，立刻就傻眼了 —— 完全没接触过。
+
+请注意，他可不是不努力。他也会天天加班，只是不够聚焦而已。
+
+所以，聚焦不但会影响成长的速度，还会影响成长的质量。
+
+这里，我们说的是在程序员阶段，如何在成长中贯彻聚焦的思想。因为这一阶段，你的角色是 “Do”，执行公司派发的任务。所以，所谓「聚焦」更偏向个人成长。比如，花两周的时间，让自己的代码变得优雅整洁。
+
+注意，此处的重点在于“有目标”，用目标指引自己的学习，找到工作的重点。找到重点，是为了让自己在这一领域变得更优秀。目标可以很小，但长年坚持下来，优秀就会变成一种习惯。积累得多了，更宏伟的目标就是实现了。
+
+当然，这种成长不是线性的。到了初/中级管理者阶段，要做到「聚焦」，也会相对复杂一些。
+
+## 初/中级管理者聚焦双线成长
+
+作为初/中级管理者，你的角色变成了“Manage”，职责是协调团队完成任务。
+
+话虽如此，但很多身处这一阶段的管理者，并未脱离一线工作（我也不建议大家过早脱离一线技术工作）。
+
+因此，你可能会问：乔老师，这时我到底是聚焦个人技术成长，还是聚焦管理能力呢？我感觉我的技术还没那么强，能直接聚焦管理工作吗？
+
+对于这两个问题，尤其是后一个，**如果你非常纠结，可能就说明你的技术能力还不够，两手都要抓。**
+
+当初我在下定决心走管理路线时，对自己的技术实力是有很大信心的。而这种对于技术的坚持和信心，也为我后来的管理工作提供了相当大的支持。可以说，越往高处走，越能感受到这种技术积累对自己的价值。
+
+技术与管理两手抓，肯定是加倍的累，这毫无疑问。但反过来看，这也是成长的好机会，你很幸运，这么早就有了跨台阶的机会。我们前面讲了，五年就要登上一个新台阶，多难啊，这样的机会多宝贵啊。
+
+想要加速成长，就只能付出比别人更多的努力。世界上没有容易走的路，如果走得太容易、太顺遂了，也可能会给未来埋下更大的隐患。
+
+那么，技术钻研到什么程度，才可以放心聚焦管理技能呢？我认为，当你的技术深度，足以辅导团队做技术选型和决策时，就可以聚焦管理了。但具体时机，要靠你自己去判断，因为每个团队的情况都有所不同。
+
+打好技术基础后，先别急着聚焦管理层面的工作，最后问问自己：**你真的想做管理吗？**
+
+其实在 IBM 的一段时间里，我是向公司申请在纯技术路线发展的，也为此付出了很多努力，成为了 IBM 认证架构师、全球技术学院成员……
+
+促使我转向管理岗位的直接原因，是我意识到：有许多工作价值，只能靠团队的力量实现，个人能力再强大也于事无补。我认为，管理的价值会随着团队规模的扩大而增加，在一般情况下，会超过大部分技术专家的价值。
+
+但这毕竟是我的想法，于你而言，还是要慎重考虑。
+
+如果以上问题，你都已经思考得很充分了，那么恭喜你，可以聚焦管理工作了，尝试去思考管理的价值所在，让自己在技术方面的专业度，成为做技术选型、技术决策的重要支撑。
+
+如果你没有头绪，可以按照我们前面分享的内容，一步一步聚焦「管理三板斧」的落地。
+
+比如说，先聚焦「组织调整到位」，把组织建设做好。你可能会说，老乔，我的团队只有五个人，怎么聚焦组织调整啊？你讲的那些我都用不上。
+
+错了，我们讲的许多管理内容，其实和管理者下辖的团队规模关系不是特别大。团队只有五个人？没关系，你要同直属领导说清楚：你所负责的技术或业务，要实现什么样的目标？理想状态下需要多少人？
+
+我是在 2020 年三季度末，开始接手彩食鲜的  BBC  业务。当时，整个 BBC 平台部门的人数还比较少，我接手后，直接将编制调整到原来的两倍以上。为什么呢？因为我的目标是，部门业绩要季度环比增长 70%，这个人员编制，是按我的业务目标来配置的。
+
+千万不要觉得团队有多少人，就承担多少人的工作量。如果你是这么想的，可以重读一下上一讲：「全局思维和持续完善体系的建立，让团队持续成长」，再深入地理解一下，这里我们就不再展开了。
+
+你看，上面所说的就是聚焦「组织调整到位」。当然，你还可以聚焦「加强协同效率」、「激发团队活力」或者「管理的人性哲学」，只要合理，就都没关系。
+
+重点是要聚焦，实现突破，啃下一块硬骨头，再去啃下一块。
+
+对于管理工作来说，聚焦的终极目标是「组织成功」，这是个体系性问题。要学会在一定程度上，**忘记个人的辛苦和努力，因为那只能代表你的个人成长**。
+
+## 舍九取一，聚焦和放弃紧密相连
+
+讲到这，你不妨思考一下：做好聚焦，难吗？
+
+我认为，只要认知到位了，做聚焦其实不难。很多人其实都了解「聚焦」的概念和价值，但真正去实践的人却不多。
+
+因为困难的不是聚焦，而是舍弃。
+
+许多人会下意识地忽视这一部分，心里盼望着：在一定时间里，我聚焦了重要的工作，同时又没落下其他任务。
+
+可这几乎是不可能的。
+
+我个人经常出席一些技术或管理会议，这样的分享机会让我个人非常受益，因为我的准备通常很充分，对这样的交流和分享机会也很重视。在筹备每场演讲时，我个人的时间和精力是高度聚焦的。
+
+但也有很多技术管理者，虽然参加了会议，却十分敷衍，说自己：太忙了，又要加班、又要陪家人、又要聚会，没有时间好好准备。
+
+什么都舍不得放弃，最后的结果只能是：现场演讲效果不理想，不但花了时间，还没有获得相应的收益。
+
+所以，你一定要留意：在大部分情况下，**没有放弃，就意味着没有真正聚焦；有舍弃，才有收获。**
+
+我常常说，舍九取一，只有舍弃掉 90% 干扰事项的人，才可能真正聚焦那 10% 的核心任务。
+
+那么聚焦哪些，放弃哪些，如何决策呢？这就又回到了我们上一讲的内容：培养全局思维，只有看到全局，才能做好聚焦。**看清问题全貌，是做好聚焦的大前提。**
+
+## 结语
+
+今天，我们聊了许多关于聚焦的问题，也有一些关于舍与得的思考。但对于高级管理者来说，如何在 “Lead” 的角色下，做好企业战略层面的聚焦，则没有谈。
+
+因为对于企业和高级管理者来说，对聚焦的思考，要与企业情况、产业趋势紧密相关。每家公司的情况都有所不同，是不存在标准的答案的。
+
+对于普通程序员和初/中级管理者，也要灵活、辩证地看待这个问题：
+
+第一，所谓聚焦，不是让你随心所欲地乱选发展方向。要多问问自己，企业现阶段最需要的能力是什么？行业目前最稀缺、最有市场的能力是什么？如果公司目前需要 Golang 开发，结果你去学了三个月 Java 开发，学完以后发现工作中用不上，就有点尴尬了；
+
+第二，不要因为做了聚焦，就回避其他一切任务和需求。该付出的时间和精力，还是不要吝啬，只是要时刻记得：自己是有目标的，自己是做过聚焦的，要为之努力。
+
+到这里，本节内容就基本结束了。后面，我们还有两篇关于「全局思维」和「战略聚焦」的延伸分享，更加贴近实际工作，名字分别叫作「需求做不完，应该怎么办？」（初/中级管理者篇）、（高级管理者篇），希望能给你带来更多启发，也欢迎你持续关注，多提意见。
+
+我们下一讲再见！

极客时间专栏/乔新亮的CTO成长复盘/对管理工作的复盘/13 | 风险管理：世界是脆弱的，持续管理风险非常重要.md

@@ -0,0 +1,179 @@
+<audio id="audio" title="13 | 风险管理：世界是脆弱的，持续管理风险非常重要" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d7/82/d78f93b4f3fd45017ffc15be9fbb9b82.mp3"></audio>
+
+你好，我是乔新亮。
+
+这一讲，我想和你聊聊有关风险控制的话题。
+
+世界，其实是非常脆弱的。几天前，我接到一个电话，得知一个原来公司的下属，因为车祸意外去世了。我和他关系很好，但此时只能感叹生命无常；2020 年，仅仅因为国内外对口罩文化，以及一些疫情防控措施理解的偏差，新冠病毒就得以在世界范围内不断传播，难以遏制……
+
+今天，可以说我们做的任何决定都存在风险，风险可能会成为真的“险情”，也可能永远都只是个风险，这只是个概率性事件。但“墨菲定律”告诉我们：如果事情有变坏的可能，不管可能性有多小，它总会发生。
+
+刚加入苏宁的时候，我去评估各个系统的高可用方案。其中一类，就是 UPS（不间断电源，Uninterruptible Power Supply） 供电方案。提供服务的是一家世界知名公司，这家公司和数据中心团队多年前共同决策了“ N + 1 ”型保护策略，也就是说，假如系统存在 N 个 UPS，任意一个出现问题时，都不会使业务受到影响。
+
+可我本来是想要的是 “2 N” 型保护策略，也就是说，假如系统存在 N  个  UPS ，即便全都出现问题，业务也不会中断。但团队反馈说“ N  +  1 ”方案已经非常成熟，并称：很多金融机构也在使用 “N + 1”策略，多年来没有出现任何问题。当时，我对 UPS 方案不太熟悉，听到对方这么说，也就同意了。
+
+结果，怕什么来什么。有一天，“N + 1”型策略失效，一个机房断电了。意外出现后，为了确保业务连续性，我不得不连熬了三个通宵。
+
+从那以后，我就打定主意：一定要做好调研、做好风险控制，绝不接受自己不熟悉的方案。
+
+如果你是做金融、做架构的同学，对这样的故事一定很熟悉，因为无论是金融业务，还是架构设计，都对系统风险十分重视。在技术维度，如何做好风控，已经有非常详尽的教学和方法。
+
+但当我们回归管理话题，又应该怎么聚焦风险控制呢？如何在与人打交道时，做好风险控制呢？
+
+我们通过一个典型案例来聊聊。
+
+## 打卡，本质上是个风险控制手段
+
+在互联网这个圈子里，打卡是一件特别有意思的事儿。
+
+- 有的公司严格打卡（很多公司还是指纹打卡），迟到一次扣 50 块钱；
+- 有的公司虽然打卡，但可随意补签，并不严格限制；
+- 有的公司没有打卡，上班下班全靠员工自觉，HR 一般还会在招聘启事中自豪地写出来；
+- 有的公司是开始不打卡，后来开始打卡，还很严格；
+- 也有少部分公司，是一开始打卡，后来逐渐开始不打卡；
+
+……
+
+可以说，大家的做法千差万别，但整体上，可以归纳为以上几种方式。那么，哪种做法更好？
+
+我猜你一定会说，不打卡好，因为这么干更有互联网范儿，员工自驱度更高，等等。
+
+别急着下结论，我们先把思维拔高到全局视角，重新审视这个问题。在公司的角度上，打卡只是个行为，更准确地说，应该叫“考勤”。
+
+考勤，顾名思义，就是考核出勤，是 CEO 要迫使公司全体人员，遵守工作时间。简单些说，就是 CEO 想：我都按月发工资了，你们起码按时来上班吧……
+
+其实到这里，我们的思维还可以站得再高一点。**为什么要按时上班？从目标和结果来看，这是为了让团队有一个稳定的工作产出，也就是说，要给组织的价值产出定一个下限。**
+
+这背后的逻辑是：虽然同样是 8 个小时的工作时间，每个人能做出多少成绩是不确定的。但无论你的能力是强是弱，每天至少干够 8 个小时。长期来看，产出不合格的，就培养，培养无效就淘汰掉；产出超过预期的，就提拔，逐渐成为公司内的重要成员……
+
+这么一看，在互联网圈内盛行的加班文化、996 文化，就很好理解了：这是老板要提高组织产出的下限，从公司全员每天至少有 8 个小时的产出，“提升”到全员每天至少有 12 个小时的产出……
+
+但一个每天工作 8 小时的员工，和一个每天工作 12 个小时、14 个小时的员工相比，谁的价值更大呢？不确定，因为员工能力千差万别，工作态度也是千差万别。只是一般来说，在同等级别做对比，工作时间越长，价值越大。
+
+所以你看，这就是个有关风险控制的行为措施，如果全公司的价值产出始终低于生产成本，公司就倒闭了，老板要控制这个风险。
+
+## 风险控制，重要的是尺度
+
+说到这，你可能就急了。老乔，看来你是支持 996 了！还给加班、考勤找了个这么“清新脱俗”的借口。
+
+我得声明一下：我经常跟我的下属说，希望大家不用疯狂加班，一张一弛、文武之道，要合理调节自己的生活和工作节奏。
+
+但彩食鲜是需要打卡的，这点也很明确。但我们虽然打卡，却不与任何工资、绩效挂钩，没有任何实际利益上的影响。很多人不信，琢磨着：不可能，嘴上说着没影响，暗地里肯定给数据好的加薪，给数据差的绩效减分。
+
+我也很无奈，只能和大家公开去聊：到底是不是这么做的，大家注意去看就好了，时间会证明一切。如果你实在不相信，我也没办法，团队协作是建立在信任的基础上的。
+
+那么，每天让全员打卡，同时又不与绩效挂钩，打卡还有什么意义呢？
+
+答案是，**打卡是为了收集数据，作为团队健康度评定的重要依据**。
+
+如果数据显示，一个人天天五点、六点下班，工作产出却不怎么样，说明他的成绩不好，还不努力。这很可能是他干得不开心了，问题出在心态上，直属 leader 要找他聊聊了；
+
+如果一个人天天加班，但产出很不错。说明他可能工作太过饱和，或者工作方法有问题，管理者同样要去关注一下；
+
+反过来，如果一个人天天五点、六点下班，产出却还是非常好，说明了什么？说明他的能力超过了当前岗位的要求，很可能正在等待成长机会，管理者更要主动联系，给下属上台阶的机会；
+
+当然，如果一个人天天加班，产出还很差。管理者就要和他深度聊一聊，到底是哪些部分出了问题。
+
+你看，这样的组织是不是更有活力了？通过一个打卡数据，是能非常清晰地看到组织的健康程度的。彩食鲜要求打卡，就是为了长期达成这种效果。
+
+以上每一种具体行为，都是在控制风险，而且控制的范围很广，包括价值产出、团队建设、防止人才流失，等等。但在大部分情况下，管理是不能走极端的，把握好尺度是管理真正的奥义。
+
+**有的人做风险控制，会试图把一切情况都控制在手里**：指纹打卡、迟到扣钱、缺勤开除；有的人是压根没有风险控制的意识：从不打卡，也不关注，找不到人就微信问问……
+
+哪种风险控制做得对？我觉得可能都不对。前面我也讲过，要有全局思维，站在公司最终利益的角度进行决策，时刻问自己：这么干对业务增长有啥用？管理是为了不管，不是为了将一切都攥在手里。**高层应该给予团队一个关键且唯一的价值导向：我们需要并奖励那些自驱力强、有 Owner 意识、不需要我去管理的团队成员。**
+
+如果你把打卡拿捏得很死板，“打卡”这件事，就与高价值、高自驱、有创造力等企业文化导向割裂开来，变成了一个需要额外背负的“讨厌”任务。团队能清晰地感知到：leader 对我完全没有信任可言。大家会将打卡当作一个机械性的任务去完成，按时打卡却毫无建树成为组织的新常态。
+
+最终，团队内可能充斥着各类听话却没用的“老好人”。因为，这就是管理者通过实际行动给出的要求：你们必须按时打卡，其他的另说。
+
+至于完全不关注打卡的管理方法，在团队规模很小时，或许可行。但随着组织规模的快速提升，问题就会逐渐暴露：对组织健康度的感知越来越差、对组织人均投入产出比的感知越来越差……
+
+所以，很多企业的情况是：早期小而美，是个充满了信任、不需要风控的极客团队；融资一到位、规模一扩张，立刻与前一种企业殊途同归，成为管理到牙齿的“传统企业”，恨不得把 GPS 都给员工装上……
+
+哪种做法好？当然是都不好。有时过分注意风险、有时将风险完全抛在脑后，过犹不及，这都属于没有拿捏好风险控制的“度”。
+
+因此，很多人觉得管理“务虚”，其实不对，管理只是用专业的认知和技能，去给出位于“灰色地带”的团队协作方案。
+
+## 有效的风险控制：高层不能战略懒惰
+
+前面我们通过打卡考勤这件“小事”，聊了聊在管理层面，风险控制的尺度问题。
+
+有没有注意到，在彩食鲜，尺度虽然对了，但执行起来很困难？leader 要结合那么多人的打卡数据和工作产出作分析，再一对一进行沟通。这样的风险控制，工作量真的不小。
+
+所以说，管理者这个岗位，理应，也确实是非常辛苦的。也恰恰是因为这样，在实际情况中，最能偷懒的往往不是基层员工，而是高层管理者。
+
+因为员工的工作单纯明确，还会受到 N 个层级的管理者考核；而高层管理者的角色不是 Do、Manage，而是 Lead，主要解决战略问题，工作复杂模糊，能接受到的引导、考核非常有限。
+
+所以，在我的观察下，高层战略懒惰是个很普遍的现象。大部分企业懒得都快”退化“了，却仍然没有意识到问题的严重性。因为高层每天都在干着中层管理者的工作，面对战略难题迟迟不能解决。
+
+还是回到打卡这件事，管理者想要偷懒是很容易的：严格打卡，一个季度迟到 10 次绩效 B，迟到 15 次以上，直接协商离职。
+
+这么干多省事啊，通过数字定绩效，系统都能帮你搞定。
+
+但最有效的风险控制，永远是率先发生在高层的。注意，这里我要强调“最有效”。
+
+自下而上，也能做好风险控制。比如，团队出现矛盾、人才大量流失，普通员工反映到经理、经理反映到总监、总监反映到 CTO、CTO 重新做个调研和了解、CTO 和 CEO 开个会，问题解决了。
+
+而自上而下的风险控制，则是要求 CTO 先将这件事想明白，对风险有充分评估，和 CEO 开个会，将问题解决掉。
+
+显然，第二种方法更高效，更容易达成目标，对组织的伤害也更小。
+
+如果你是高层，一定要时刻提醒自己：今天有没有偷懒？有没有和中层管理者抢工作，却对战略问题、全局问题视而不见？
+
+当然，如果你是普通员工或初/中级管理者，也大可不必为此埋怨高层管理者。在前面的章节里，我曾反复强调：要有同理心、要有全局思维，每家公司在特定阶段都有自己的难处，要学会理解。**我们常常讲同理心，说的不光是高层对基层要有同理心，也包括基层对高层的同理心。**
+
+## 实际可操作的风险管理
+
+抛开高层战略不谈，基层也可以有行之有效的做好风险管理的办法，这关乎自己的成长。就像我们曾提到，项目立项有三点要求，需要尤其重视：
+
+1. 目标清晰；
+1. 责任到人；
+1. 承诺到位。
+
+这三点来自我实际的工作经验总结，非常简单实用。如果在某一次项目执行中，相关人员没做到，往往就意味着风险已经产生。所以，风险控制是个长期工作，要持续不断地推进。
+
+第一点，目标清晰，是指目标要逐条写下来，按照 “SMART 原则”公示。“SMART 原则”出自彼得 · 德鲁克《管理的实践》，其含义是：
+
+1. S=Specific，目标必须是具体的；
+1. M=Measurable，目标必须是可以衡量的；
+1. A=Attainable，目标必须是可以达到的；
+1. R=Relevant，必须要与其他目标有一定的关联性；
+1. T=Time-bound，目标必须具有明确的截止期限；
+
+第二点，责任到人，是指每条目标必须与责任人一一对应。你可能会问，老乔，我们目标比较大，下面有一堆责任人，怎么对齐？
+
+很简单，将每位参与者的名字都写在文档里。名字排在第一位的，要负责将目标拆解、分派下去，如果目标没达成，他负最终责任；当然，如果目标实现了，他也享有最大的功劳。举个例子，如果将公司业绩的总体增长量化成 OKR 的其中一个 O，那么 CEO 的名字就应该写在第一位。
+
+第三点，承诺到位，此处在有外部部门参与协作时，显得尤为重要。很多项目比较急，大家又比较忙。可能还没等到协作部门明确的承诺，大家就急吼吼地启动了。这么干肯定是不行的。
+
+以上三点，任何一点没做到位，都属于没做好风险控制，会让项目产生极大的管理隐患。
+
+不过，即便你将以上三点都做到了，也不代表项目就不会出问题。
+
+第一，余下的解决思路大致可以归纳为：要么向上求，要么向下求。也就是说，要么由高层去体系化地解决，要么深入细节，协调沟通好团队内和团队间的各类问题。
+
+“向上求”一般只能由高层完成，“向下求”的发力点则很多。每周周会，我都会问下面的 Leader 们：有什么问题需要我帮忙解决吗？同时，我在制度中规定，如果有问题，必须及时暴露问题；如果当时没有暴露问题，我会去了解原因，是当时没有意识到问题的存在，还是其他原因；如果隐瞒不报，严肃处理。你看，这就是管理的逻辑闭环，让机制能够运转起来。
+
+第二，在文章的开头，我们也说了，风险是个概率性事件，概率只能升高或降低，几乎不可能归零。说白了，即便你的架构设计得再好，如果所有机房都地震了，一样没办法。**人要有勇气接受一些风险，因为彻底规避风险的代价太大了**。这里又涉及到辩证看待问题的思维方式，如果时间允许，建议你仔细揣摩一下。
+
+## 结语
+
+俗话说得好，人无远虑，必有近忧。
+
+技术人对“高可用”设计耳熟能详，因此对风险控制也多有接触。但恰恰越熟悉的概念，就越容易成为盲区，尤其是在管理领域。很多概念在初见时，甚至会感觉是有些矛盾的。
+
+要在管理层面做完备的风险控制，出发点一定是“假设每个人都会出问题”。但结合我们前文所谈的“打卡”事件，风险控制又是要建立在信任的基础上的 —— 在打卡的同时，却不与绩效直接挂钩。
+
+因为我相信团队里的每个成员都很聪明、也很职业，相信 ta，敞开心扉与 ta 沟通。管理不能因噎废食，不能因为个别成员有问题，就拒绝相信所有人。如果仅仅因为不信任，就无限制增加各种管理手段，最终就等同于绑住了公司的手脚。
+
+我必须要再重复一遍，**管理是为了不管**。这是在经历了这么多年的技术管理工作后，我领悟到的特别深刻和精华的一点。
+
+谨记，当你陷入矛盾或者两难境地时，就意味着可能每一种选择，在特定环境下都是正确的，你需要的是全局思维、拔高视角。
+
+在高维视角来看，打卡最终的目的是提高产出，让团队自驱。这样一来，我们就很容易制定方案。
+
+我常常跟团队说，今天我们的很多制度和措施，都是建立在信任的基础上的，但是请千万不要破坏这种信任。你看，这种“耳提面命”，也是一种成本很低的风险管理。
+
+如果你还有其他好的方法，或者想要提问，也欢迎在评论区留言。我们一起交流、一起复盘、一起成长。
+
+让我们下一讲再见。

极客时间专栏/乔新亮的CTO成长复盘/对管理工作的复盘/14 | 需求做不完，应该怎么办？（初|中级管理者篇）.md

@@ -0,0 +1,157 @@
+<audio id="audio" title="14 | 需求做不完，应该怎么办？（初/中级管理者篇）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a6/8d/a6b645e69bcb089yya116fd4a855a28d.mp3"></audio>
+
+你好，我是乔新亮。
+
+在前面的内容里，我们讲到，技术管理者既要具备全局思维，也要做好战略聚焦。站在 CTO 能力建设的维度上，这当然是非常关键的。
+
+具体到实际工作中，我该如何去锻炼这些能力？全局思维和战略聚焦，又如何帮助我做好当下的工作呢？
+
+所以，在接下来的两讲中，我决定暂缓专栏前进的脚步，邀你坐下来，围绕一个实际问题好好聊聊，这个问题就是：“需求做不完，应该怎么办？”
+
+相信聊过之后，我们对管理的认知会更丰满、更透彻。
+
+## 需求永远都做不完
+
+最近几年，经常有人问我：老乔，你平时是不是特别忙？其实我不怎么忙，空出来的时间都用来思考公司业务了，尤其是在最近的一年。
+
+我相信，这个答案和很多人想的不一样，可能也包括你。原因很简单，在当下的互联网大厂里，光是普通程序员，就已经很忙了，管理者身上的责任更重，那么理应更加忙碌。再者，我平常总是提倡“高层不能战略懒惰”、“高层要以身作则”，这样一来，岂不是一天都睡不了几个小时了？
+
+在某些成长阶段，这么想倒也不算错。比如，你刚刚登上了一个新台阶，成为了技术经理、总监、CTO，感觉辛苦是很正常的，睡眠时间确实也会受到影响。
+
+但我必须要告诉你，**对于任何一名走管理路线的技术人来说，工作状态长期<strong><strong>过于**</strong>饱和，都是一个危险的信号</strong>：说得功利些，这会导致你很难升职。试想一下，如果你管理 100 人都难以抽身，又怎么管理 1000 人、10000 人，并承担更多的决策任务呢？
+
+在跨上新台阶的早期，辛苦很正常；**在新台阶工作了一定时间后，还是很辛苦，就要好好反思自己的工作方法和认知了**。
+
+既然这样的状态不正常，我们就不妨简单分析一下，所谓的技术人很忙，到底是在忙什么呢？对于大部分管理者来说，我相信忙碌的原因可以用一句话总结：需求太多，做不完。
+
+程序员升任管理者之后更是如此，因为除了在一线完成项目，还需要做好团队管理、团队建设，处理和部门有关的“杂事”。很多技术人，本来还能耕耘好自己的“一亩三分地”，可自打负责整个团队后，就很少睡过囫囵觉。
+
+我猜，此时正在阅读这篇专栏的你，也是如此；又或者，以后的你，很可能会遇见类似的情况。所以，今天我打算聊聊，当需求做不完时，应该怎么办？
+
+首先，你要知道，需求永远都做不完，工作永远都做不完，这是个无限游戏。所以如果你对我说：“老乔，我太忙了，需求太多了，一个接一个。”
+
+我只能回答：“没错，你想想，需求什么时候做完过？”
+
+很多同学觉得老乔说的“管理三板斧”、培养全局思维、聚焦能力、风险意识，说的都对，可我就是没时间干。最近需求太多，每天都加班。可需求永远都做不完，忙完了这个月的，还会有下个月的，你打算什么时候开始提升自己呢？
+
+需求是做不完的，这是事实，但也不代表我们就束手无策，就应该放任自流，这会极大影响我们的成长速度。 而且我们之前聊过，在技术管理者的职业生涯里，最好每 5 年就能跨过一个台阶，不然可能会进入职业生涯发展瓶颈，遇见种种诸如“35 岁中年危机”之类的困扰。
+
+当然，你也别担心，从我的个人经历来看，解决这类问题的方法并不复杂。只是对于初/中级管理者和高级管理者来说，方法各有不同。
+
+## 初/中级与高级管理者的定位差异
+
+首先，针对“工作/需求做不完”这个问题，我认为**初/中级管理者和高级管理者应该区别看待。前者主要解决效率问题，后者主要解决价值问题。同时，效率问题要和价值问题围绕同一目标进行对齐**。
+
+什么意思呢？“价值问题”的核心是要对需求的价值和正确性作出回答，明确需求在公司季度目标中的地位，决定需求的优先级。本质上，这是个高层战略问题。
+
+而在很多公司里，初/中级管理者，很少有砍需求、调整需求的权利，在公司级战略决策里也没有话语权，所以只能解决效率问题，当需求下达时，尽量做到最好。
+
+听起来有点残酷，像个“工具人”，但事实如此，你只有接受现状，才能改变现状。
+
+看到这里，你可能会想，太啰嗦了，说这些有用吗？
+
+当然有用，做好自我定位太重要了：如果你是初中级管理者，还喜欢天天找 CEO 聊价值和战略问题，可能会“死”得很惨 —— CEO 会觉得你做的不好，还给自己找借口；如果你是高级管理者，却仍然在处理效率问题，那就是严重的失职，战略上过于懒惰。
+
+如果你已经做好了自我定位，接下来我们就聊聊，需求做不完，初/中级管理者应该怎么办？
+
+## 难度最低的办法：保持专注
+
+前面我们讲了，需求做不完，但初/中级管理者仍要解决效率问题。
+
+若是在培训体系健全、手下皆是精兵强将的企业还好，管理工作倒也挑战不大；若是下属能力偏弱，普遍缺乏独当一面的能力，情况就不一样了：
+
+1. 你被迫开始高度关注团队任务的执行情况，在早期甚至需要代替下属完成部分工作；
+1. 你被迫开始重视团队建设，因为缺乏“猛将”而苦恼；
+1. 一般初/中级管理者还承担着部分一线工作任务，工作任务繁重（这里我也不建议初级管理者脱离一线任务）；
+
+……
+
+这时，项目管理需求、团队建设需求、正常的研发需求纷至沓来，不少管理者就开始吃不消了。这同时也是最初我在技术管理岗位上的真实写照。
+
+那时我沉迷于并发式处理工作，一会回个邮件、一会回个微信，经常同时关注好几件事情，像电视剧中的职场强人一样：八面玲珑，自我感觉效率还挺高。
+
+后来因为职位不断提升，需要处理的问题也更加复杂，不得不用更多的时间专注思考一个问题。时间久了，我才突然意识到，原来“并发式”工作法弊端很大，其实专注做事的效率更高。
+
+首先，如果你一会看看钉钉（或者飞书）、一会看看邮件、一会回复个紧急需求，大脑在繁杂事项间不断切换，一天下来会很累。我认为这是导致效率降低的主要原因之一。
+
+其次，专注做事情更有目标感，相应地也更有成就感。现在许多人都会列出一天的工作清单，但成就感往往来自任务的完成数量，比如今天划掉一大片待办事项，就会很开心。这当然没问题，也算是一种从工作中找到成就感的方法。但我认为，**对于脑力劳动者——尤其是管理者来说，更好的方法是从月度、季度工作目标中寻找成就感。**
+
+我常常对我的下属说，周报不能写流水账，我不想知道你今天做了啥、明天做了啥，又不是怀疑你磨洋工。哪怕你一周就写一件事，只要对季度目标的达成有利，我觉得都没问题；反之，哪怕你一周写了一百件事，如果和季度目标没关系，我认为可能都是白费劲儿。
+
+你看，**其实专注做事的认知和目标导向等企业文化，都是相辅相成的**。
+
+## 80 分管理者：学会时间管理
+
+当然，保持专注仅仅是解决效率问题的第一步。若是给初/中级管理者打个分，此时你能得 60 分，勉强及格。那些拿到 80 分的管理者还掌握着另一个方法：时间管理法。
+
+说到这里，你可能会微微撇嘴：我当是什么了不得的秘籍，原来就是被各路畅销书、公众号重复了百八十遍的时间管理。
+
+没错，时间管理是个基础概念，任何人都可以通过看书掌握这项技能，我亦不打算一步一步解释方法论。但据我观察，知道“时间管理”这个概念的人很多，但真正将时间严格管理起来的人却很少。
+
+其中一个主要原因是，意外太多了。当你辛辛苦苦做好了一天的时间规划，一个突发情况就可能将其全盘打乱，比如领导叫你开会、线上出了个 Bug，等等。反复几次，所谓的时间管理还有什么意义？计划赶不上变化，大家常常这么安慰自己。
+
+可随着管理经验的逐渐丰富，我发现一个明显的事实：**一个始终在处理紧急问题的管理者，不可能是一个优秀的管理者，管理者不应该是职业“救火队长”**。这就意味着首先，要学会用团队力量解决部分紧急任务；其次，在时间规划中，要为紧急问题预留时间；最后，即便是紧急任务，也要有取舍，也要区分优先级，尤其是初/中级管理者。
+
+说白了，你要时刻想着自己的 KPI 、OKR 是什么，在每个季度末、月末，上级会通过哪些指标考核你？我相信，考核标准一定不是你回复领导消息有多么及时。
+
+你看，很多事情其实并不复杂，想清楚利益关系，就知道该怎么做了。优秀的高级管理者永远希望下属有思考、有权衡，能优先做最重要的事情，能成就业务；而不是只知道听老板的话，不懂得思考。
+
+接下来，我们再看看满分管理者的特质。习惯了专注做事，做好了时间管理，提升的只是你个人的工作效率，作用有限。只要团队中存在几个能力偏弱的下属，你的工作状态就可能被打回原形，继续疲于奔命，该怎么办呢？
+
+## 100 分管理者：思维陷阱和认知灌输
+
+作为管理者，经常被迫承担团队成员的工作任务，这是对初/中级管理者最大的限制条件，也常常是“需求做不完”的主要原因之一。
+
+在我摸索着做管理工作的那些年，有一本书对我影响很大，书名叫做《**别让猴子跳回背上**》。这本书里将推动任务进行的下一个步骤称为“猴子”。而对于每只“猴子”，都会存在一位解决者与一位监督者。一般情况下，下属是解决者，管理者是监督者。
+
+比如说，正常情况下，管理者期望出现的情境是：管理者下发一个任务，员工给出行动步骤并负责执行，管理者对每个步骤的关键节点进行检查。最终，任务成功完成，员工是每一个行动步骤的推动者和执行者，“猴子”始终留在员工身上。
+
+说个夸张点的场景，员工一遇到困难，就会习惯性地来问管理者：怎么办啊？管理者想了想，让你做比我自己做还累，于是说：算了，还是我来吧。
+
+在这个情境里，“猴子”跳到了管理者的身上，员工变成了监督者。在组织内，就会出现十个员工督促一个管理者工作的悲剧后果，Leader 忙的要死，员工闲着没事。
+
+这是一本小书，我读了之后启发很大，你也可以找来看看。这里我们不仅是要从这本书中获取养分，还要把理论再简化一下，聊聊我认为其中最关键的部分：授权与审查，简单说就是分配工作、检查工作。
+
+怎么样？听起来又是一个基础工作，但实践总和理论不一样，很多人什么都懂，就是做不好。尤其是初级管理者，很容易做到一半，就变成亲力亲为了——“猴子”又跳回了背上。
+
+有人吐槽，我有什么办法，项目快到 Deadline 了，下属还没做完；还有人说，我这叫团队建设，这是培养下属的能力。
+
+错了吗？没错，作为一个技术经理，明天客户就验收了，今天下属还解不完 bug，我当然要撸起袖子亲自上阵；有的人就是领悟能力差一些，手把手教了两三遍也学不会，有时确实让管理者心里有点无奈和“幽怨”，但短时间内没有更好的办法。
+
+这些事我都干过，但在做的同时，我还会多做一些重要的附加工作。
+
+首先，我会做好自己的心理建设，规避两类思维陷阱：
+
+**思维陷阱一：下属为何这么笨？**
+
+管理者下意识地将员工与自己做对比，因而开始抱怨，比如“他怎么这么笨”、“怎么这点工作都做不完”、“能力怎么这么差”……
+
+你要明白，**下属的工作能力本来就不如你，不然也不会拿着比你更少的薪水，成为你的下属**。规划下属成长路径的时候，要注意参照系，比如与同级、同经验员工对比，而不是跨阶对比。这是一大思维陷阱，要及时跳出来。
+
+**思维陷阱二：教会徒弟，饿死师傅？**
+
+初/中级管理者有很大概率遇到能力很强的下属，心中会产生一些莫名的危机感，以至于在工作中不由自主地藏私。别觉得这是耸人听闻，其实类似的事常常发生。
+
+如果你也有类似问题，一定要反复告诉自己：不要总是担心自己，让别人有发展，自己迟早会有发展，因为这至少证明你的管理能力在上升。
+
+**我认为作为一个初/中级管理者，至少要培养两名能力很强的下属，才算合格。**
+
+好，这是两类应当避免的思维陷阱，如果不多加注意，无论做什么动作都容易走形。
+
+在此后的授权与审查过程中，**每当我不得不替下属完成部分工作，我都会告诉他：这是你的工作，我是在替你完成工作**。一定要让下属意识到，“猴子”还在自己背上，不能总是指望 Leader。
+
+新人入职，管理者短时间内辛苦一下无可厚非，但要有度。一般情况下，我给高级岗位员工的适应时间是一个半月，给初级岗位员工的适应时间是一个季度。如果员工始终无法满足岗位要求，那就要坚决调整。
+
+管理者要为整个组织的成功负责，所谓“金刚之怒”的落脚点就在于此，这也是无奈和理性之举。不然，管理者一定会陷入麻烦，最终导致组织的失败。
+
+从长期看，在管理方面，你要做的就是不断重复“授权-&gt;审查”这一流程，工作自然轻松很多。
+
+## 结语
+
+不要以为职位越高，工作就一定越忙。我个人的经验是，从初级管理者到高级管理者，在工作量方面其实是更轻松了，做初级管理者时是最累的，当然，我说的是身体累，而不是心累。高级管理者，要在战略认知能力、看清全局能力和抗压能力等方面接受考验。
+
+这也是为何我们要如此关注“需求做不完”的问题 —— 管理者只有变得轻松了，才能迈上新的台阶。
+
+**保持专注、学会时间管理、做好授权审查，在我眼中，这是初/中级管理者解决效率问题最有用的手段**。
+
+但当你成为有决策权的高级管理者时，情况又有所变化，下节课我们继续聊聊《需求做不完，应该怎么办？（高级管理者篇）》。

极客时间专栏/乔新亮的CTO成长复盘/对管理工作的复盘/15 | 需求做不完，应该怎么办？（高级管理者篇）.md

@@ -0,0 +1,134 @@
+<audio id="audio" title="15 | 需求做不完，应该怎么办？（高级管理者篇）" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/cd/56/cdea6a09af6b2252e56f03dba107d056.mp3"></audio>
+
+你好，我是乔新亮，很高兴又和你见面了。
+
+上节课我们聊到，面对“需求做不完，应该怎么办”这个问题，首先要认识到需求是永远做不完的，但要尽量节约各类需求对管理者精力的影响。
+
+在此基础上，我们对管理者的工作重点进行了拆分，认为初/中级管理者主要解决效率问题，高级管理者主要解决价值问题，并聊了聊初/中级管理者提升效率的三个要素。
+
+在这一节，我想和你重点聊聊，高级管理者如何解决价值问题，并对最近两篇内容做一个简短的总结。
+
+## 需求处理量提升至 150%，仍然无法满足业务方要求
+
+前面我曾介绍过自己，也多次提及在苏宁的那段工作经历。
+
+我进入苏宁的职位并不算高，最初只是一名总监。一年后就获得了晋升，Title 变成了总裁助理，同时直线管理 CTO 办公室和苏宁云研发中心，管理的团队规模急剧增加。我记得，当时直线管理了 500 多人，虚线管理有近 5000 人。后来又经历了几次升迁，到最后离开苏宁时，我的 Title 是科技集团副总裁，研发团队规模已经达到 10,000 余人。当时苏宁的技术系统也很复杂，大概存在 4000 多套系统，日高峰发布接近 4000 次。
+
+可以想见，这样的团队规模配合这样的技术系统，需求量该有多么可怕。
+
+所以，在最初一段时间，我的压力非常大：业务方怨言很多，主要是需求处理不及时，积压严重。
+
+于是，我重点推行「管理数据化」，主抓技术团队的“产能问题”。其作用还是相当明显的，大概一年后，在规模不变的情况下，技术团队处理的需求量大致提升到了 150%，但业务方还是不满意。
+
+为啥呢？因为需求是永远做不完的。
+
+到这里，我有两条路可走：
+
+1. 继续解决效率问题，将需求的处理量提升到 200%、250%、300%……
+1. 像高级管理者一样，转而解决价值问题。
+
+在上一讲，我们提到，所谓“价值问题”，就是要对需求的价值做出回答，明确这个需求在公司季度、年度目标中的地位，决定某个业务需求的优先级。
+
+说白了，技术部门拼死拼活干了一整年，所做的需求并不都是有用的。谁来对这些需求的必要性和优先级作出回答？谁来衡量这些需求的价值有多少？
+
+我认为只有解决了价值问题，才能在更高维度上保证公司越来越好。
+
+同时这个选择也关乎你的个人定位。你会发现，**表面上公司是在为了需求积压而焦虑，实际上是在为业务发展的困境承受煎熬和困扰。**
+
+如果你对自己的定位是个高级管理者，那就必须直面这类问题；如果定位是初/中级管理者，我们大可以好好做架构，继续跟进效率问题，保持职级不变。
+
+你可能会说，需求处理量都提升到 150% 了，还能怎么提升效率？
+
+去除各种花哨的外表后，答案其实很简单：压榨内部团队。在这一点上，许多管理者倒挺有一套的。只是“提升效率”要适度，否则容易造成团队的抵触和人才的大量流失。不要看到华为在加班，就学着人家一起玩“狼性文化”，你的激励体系、薪酬体系、考核体系和华为不一样。
+
+**这里我想再重复一遍，高级管理者解决价值问题，初/中级管理者解决效率问题，一切取决于个人定位。**
+
+我对自己的定位和要求是高级管理者，所以我选择了路线二，解决价值问题。
+
+## 建设产品型研发组织结构，做战略上的聚焦
+
+怎么解决价值问题呢？根据这些年的经验和思考，我认为第一步是要由“项目驱动”转向“产品驱动”。反映在体系架构上，就分别代表了“职能型研发组织”和“产品型研发组织”。这一点，我们在“管理三板斧”的部分，也曾重点介绍过。
+
+在大部分情况里，技术部门会为了层出不穷的需求疲于奔命，但业务上的颓势没有丝毫缓解。比如一个CEO 的困惑：为什么我在技术部门身上投入这么多成本，在物流时效方面却收获不到应有的效果？
+
+而当“产品驱动”的思想深入组织时，人人都是产品经理和业务专家，CEO 的焦虑应当是：为什么我们的物流时效产品比竞争对手差那么多？
+
+差别在于，**在“项目驱动”的模式下，可能没人对需求的价值作出负责任的回答 —— CEO 或 某事业部总经理单个人的精力不足以覆盖每一个需求；但在“产品驱动”的模式下，所有需求都应该是对产品价值的准确回答，因为这是团队共同的责任。**
+
+我认为，最终所有组织都要转变成面向产品的形态，这就是主要原因之一。
+
+回到“需求做不完”的问题上，在对组织架构进行上述调整后，你会发现需求的数量大大减少了 —— 过去存在太多 ROI 低、优先级低的“伪需求”。从前，如果研发团队一年需要处理 100 项需求，那么如今可能只需要处理 30 项需求。整体的需求数量大大减少了，目标更聚焦、力量更集中，且与 公司季度目标严格对齐。
+
+当然，这里有一个前提，就是团队能力尚可，技术上不存在太多挑战。作为一名高级管理者，如果麾下团队还时常面对许多技术挑战，那就说明还有太多基础工作没做好，要注意为团队先打好根基。
+
+## 深度干预集团战略和激励体系
+
+好，看到这里，你可能会想：嗯，听起来很简单，我学会了！
+
+如果我告诉你，以上方法存在两大最致命问题，你能觉察到问题出在哪吗？现在你可以停下来用一分钟的时间细细思考一下。
+
+可能你在心里已经有所计较，但想法还不够清晰，不妨与我接下来所说的对照参考一下。
+
+**问题一：**
+
+当团队存在“需求做不完”的困扰时，业务方往往是已经存在大量怨言的。这很正常，因为在业务方看来，当下的业务困境大半来源于技术部门的不合格支持。
+
+作为技术部门的老大，你不但不考虑如何完成更多需求，反而准备打着“面向产品”的旗号，将 100 + 需求处理量变成 30 +，恐怕有点过分吧。况且，这里不是说由 100 项需求直接裁剪为 30 项需求，而是立足产品和公司战略，设计出全新的 30 项需求。
+
+那么， CEO 为何要说服业务部门配合调整？谁来重新定义技术部门的 KPI 或 OKR ？谁又能罗列出这 30 项需求的具体清单？
+
+**问题二：**
+
+对于团队来说，架构调整是一回事，行为模式又是另一回事。表面上看，需求数量减少了，工作更轻松了；但实际上，人人都要设法对齐 OKR 、熟悉业务、思考产品，代码背后的工作变多了。一般团队很难在心态和行为模式上作出比较好的转型，很可能全员思维僵化，继续等待需求下发，下意识认为没有需求就等于没有工作。
+
+你可能会想，此时团队应该换血，招聘新人加入。可少数新员工很难影响到多数老员工，一段时间后，反而会是新员工被老员工同化。
+
+怎么样，是不是有些棘手？实际上，这两个问题，既是解决价值问题的最重要的两个步骤，也是本文话题真正的核心难点：单凭你自己，很难对价值问题作出完整解答，也很难真正解决「需求做不完」的问题。
+
+我们先来看第一个问题，答案是：CEO 对业务和产品的认知，决定了他会不会说服业务部门；CEO 应该重新定义技术部门的 KPI 或 OKR。
+
+**所以我们常常提到的数字化转型，其实是一把手工程，一把手最重要的工作就是战略聚焦。**
+
+从概念上讲，这听起来像向上管理，但实际执行起来却不太一样。我们前面也提到过，所谓“向上管理”，是通过全局思维将认知提升到“老板层次”，然后做老板的期望管理或某一项工作任务的认知管理。
+
+而这里却要求老板对公司的组织架构和业务驱动模式来一场大修，无疑相当困难。对于初/中级管理者来说，你甚至没有为难的必要，因为你只是个需求执行者；对于高级管理者来说，影响 CEO 一定要相当谨慎，不然很容易被理解成“为绩效不达标找借口”，壮志未酬身先死。
+
+不得不说，此类问题也曾让我困扰。我失败过、困惑过，有时也践行不了自己的管理理念。 不过，经过这两年的实践，现实已经充分验证了这套“产品导向”架构体系的优越性。
+
+对于第二个问题，答案是：**重新规划考核体系，并将业务部门纳入考核；重新定义激励体系，从面向需求转为面向产品。**
+
+影响 CEO 只是第一步，第二步是要辐射到业务部门甚至人力资源部门，这更加困难。技术人的脾气是将数据和细节做到极致，最终一定会将流程里的所有变量纳入体系、进行考核。但问题是，技术部门凭什么考核业务部门？又凭什么影响人力资源部门？所以说数字化转型是一把手工程，不完全是 CTO  的工作。
+
+对于任何一个产品，考核业务部门IT化水平，考核IT部门为业务部门带来的增长，就是业务IT一体化，业务就是IT，IT就是业务。
+
+高级管理者要思考的是如何让公司越来越好。当高级管理者看到公司挣扎、彷徨的根源时，会勇于直面问题。但对很多有心人来说，这一切就只是办公室政治斗争的具现。
+
+**所以，以上两大问题，或者叫作关键步骤，都未必能在一家企业内一并解决**。有时，退一步亦是海阔天空，你可以在接下来的职业生涯中，不断去探索最优解。
+
+## 结语
+
+我们前后用了两讲的时间，对“需求做不完，怎么办”这一问题做出了拆解。这里，我们再来整体梳理一下：
+
+首先，我们要认知到，需求永远都做不完。
+
+而在此基础上，初/中级管理者主要解决效率问题，高级管理者主要解决价值问题。
+
+解决效率问题依赖专注做事的习惯和方法、高效的时间管理方法和「别让猴子爬上背」的管理价值观；
+
+解决价值问题依赖产品型研发组织的构建、对 CEO 的影响力以及对业务及其他部门的影响力。
+
+**而经过这些年的历练，我认为，追求效率要适度，追求价值则要无所不用其极。**
+
+很多管理者在战略层面懒惰，逼迫下属用勤奋来解决战略问题，期望下属做得“又快又好”。试问，若我做得足够快，怎么可能做得足够好呢？基层员工在执行上的勤奋，无法弥补高层在战略上的懒惰。而对高层乃至 CEO 的认知影响，无疑是此类问题中，最困难的部分。
+
+当然，有时解决问题的思路要更活络。在下属无法对 CEO 的决策产生影响的情况下，通过外部咨询的方式给 CEO 提供转型意见，最终也“曲线救国”，成功实现了目标。
+
+如果你也有类似经历或经验，欢迎在评论区留言，与我互动。
+
+到了这一讲，我们在管理层面的复盘，就基本接近尾声了。
+
+如果你认真学习了前面的内容，你会发现：要解决一个实际的成长问题，往往会涉及多个过往不同方向的知识点，包括“管理三板斧”、全局思维、战略聚焦、管理哲学，等等。这一切都是融会贯通，互相促进的，只有这样，才能形成管理逻辑上的闭环。
+
+在管理方面，我的讲述要结束了，但希望我们的思考不会停止。你可以随时留言，我会尽可能地回复。同样，我们专栏的最后一部分：「对专业成长的复盘」也即将到来，欢迎你继续关注。
+
+让我们下一讲再见。

极客时间专栏/乔新亮的CTO成长复盘/对管理工作的复盘/加餐（一） | 如何通过演讲分享，打造自己的影响力？.md

@@ -0,0 +1,126 @@
+<audio id="audio" title="加餐（一） | 如何通过演讲分享，打造自己的影响力？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/50/f6/50bc5231e920d23e8d3145b8901eeef6.mp3"></audio>
+
+你好，我是乔新亮。
+
+私下聊天时，曾经有很多朋友问我：“老乔，我感觉你现在太有影响力了，很多朋友都知道你，我就经常听你的演讲和分享，非常棒。我自己虽然也在团队管理上有点心得，但不知道怎么讲出来，也不太敢讲。能不能给我分享分享啊，怎么提升自己的影响力？”
+
+每次听到这类问题，我都有点脸红。
+
+一方面我并不觉得自己是什么圈儿内的“技术网红”，也不是专业的演讲教练，不能给他太多专业性的意见；另一方面，在技术管理者群体里，这类困扰实在很常见。因为影响力虽然重要，但却不等同于“知识储备”或“个人能力”：代码写得好，和有影响力，是截然不同的两回事。
+
+那么，到底什么是影响力呢？百度词条写道，影响力就是用别人乐于接受的方式，改变他人思想和行动的能力。听起来是不是很厉害？和我们常常提到的“领导力”的概念很像。
+
+一位名叫“思维”的读者也曾给我留言，提到了《高效能人士的七个习惯》中定义的两个概念：“关注圈”和“影响圈” 。关注圈是生活中所有你关注的事物，影响圈则是你可以有所为、有所控的事物。
+
+大部分人聚焦“关注圈”，不停地吐槽、抱怨，却无能为力；成功人士习惯聚焦于“影响圈”，使影响圈不断扩大、扩张和成长。
+
+这么一看，就更有意思了。
+
+所幸，我觉得，**关于影响力的建设通常没有过于高深的门槛** —— 你又不是要成为明星，要上微博热搜。
+
+从我的个人经历来看，只要培养好一些基础的认知，做好一些力所能及的工作，还是非常有可能在技术圈儿具备一定影响力的。那么此后，无论是职业生涯上台阶，还是空降到另一团队进行管理，都会天然具备一定的优势。
+
+很多同学喜欢给自己打标签：纯粹技术人、内向、腼腆、不善言辞、情商低、不懂管理、不擅社交……我认为，不要总是给自己太多的负面暗示、太多的自我限制，不要将自己标签化。先去努力，如果努力后觉得实在是不喜欢，那时再考虑要不要继续。
+
+所以，我在「管理复盘」这一章的最后，安排了一份“加餐”，和你专门聊聊关于影响力提升的话题，希望能带给你一些额外的收获。
+
+## 从一上台腿就发抖，到 NPS 值全场最高
+
+像大多数技术管理者一样，我现在打造个人影响力的主要方式是演讲分享。起先是在公司内部、行业内部，后续逐渐走上各类大会的讲台，面对诸多外部听众。我相信对于大部分技术人来说，演讲分享也是成本最低、回报率最高的影响力建设方式之一。
+
+当然，刚参加工作时，我可没有这种规划，就是个普普通通的程序员，与大部分技术人一样，对演讲、交流什么的都不屑一顾。
+
+我记得很清楚，有一次和老家的亲朋好友闲聊，我说，我不喜欢那些夸夸其谈的同事，总觉得他们不干具体活，不知道一天到晚在想什么。那时我觉得，还是和计算机交流比较好，省事。
+
+你看，这就是我最初的认知：专心写代码、做自己的事最重要，夸夸其谈要不得。我想，这恐怕也是国内很多技术人的真实想法：靠嘴巴说算什么本事？程序员是技术工种，有本事写代码呀？
+
+转折发生在 2008 年，那一年我加入了 IBM 。加入没多久， Leader 就不断地提点我：“你要去扩大自己的影响力，不能光知道干活啊！要建立和客户的联结，这样人家有事才会找你呀！”
+
+虽然不喜欢，但我是个比较服从工作安排的人。于是就硬着头皮，开始尝试在公司内部请教、讨论、分享。时间一长，我发现自己其实还挺喜欢演讲的。为啥呢？因为在给别人分享的时候，其实收获最大的是我自己。这个观点你可能已经听我讲过了，但我建议你自己实践下，绝对会是不一样的体验。
+
+给别人讲东西，首先，你总不能讲错吧，要不然多丢脸？所以准备的时候，我会不自觉地从多个视角去推敲自己的内容，这能够让我思考得更为深入。其次，你总得让别人能听明白吧，要不然图个啥？你看，当你这样想的时候，不自然地就带入了用户思维，这等于你是在把演讲做成了一个产品，为了这个产品体验好，所以你会想，这地方我是不是举个例子比较好，这地方我是不是打个比方比较好，而这些打磨产品的过程，其实也是在强化你的记忆。
+
+最后，如果我讲得不错，那很快，同事们会夸我，会在各种场合给我一些正反馈。这些正反馈不管真假（现在想想，有的反馈也许就是同事的客气话），它会反过来激发我，让我觉得自己厉害，后面我做事的时候，就会给自己提更高的要求。
+
+对于我来说，在 IBM 的这段日子，我完成了从抵触分享，到喜欢分享的转变。其大半功劳应该归功于公司的培训体系和当时领导对我的提醒，少半功劳当然也属于自己 —— 大胆去做，并且付出得够多。
+
+当然，只是喜欢、只是认真还不够，还要想想，你的演讲能否打动听众呢？
+
+2016 年 10 月的 QCon 上海，主办方邀请我来做个主题演讲。还记得我当时演讲的题目是《传统企业如何转型互联网？苏宁六年技术架构的演进总结》，可以说，这场演讲对我的整个职业经历都产生了很大影响。
+
+虽然当时我已在 IBM 、苏宁参加过多次内部演讲，但还未在 1000  人以上规模的会议上做过演讲。为了保证演讲效果，我写了一万多字的提词注释，生怕自己忘词。
+
+这样的准备够认真、够刻苦吧？可那场演讲的满意度只有 73%。其实回过头看，这个数值并不低，但对比当年同场其他演讲 80%，甚至是 90% 的满意度，还是有些差。如果摆在全场 127 位讲师间进行比较，成绩可能更加“默默无闻”，为何？
+
+后来我复盘了很多次，抓住了几个细节：
+
+比如听众对理论居多、无实践案例的章节感触不大，对生动的案例则很有兴趣。比如在演讲中讲解架构理论时，观众会开始低头玩手机；当我用北京环线的城市规划比喻架构设计的核心思想时，现场正在玩手机、走神儿的观众就会把头抬起来；
+
+再者观众更喜欢走心、诚实的分享，不喜欢教条的宣讲。比如在这场演讲的开头，我谈起 2012 年还在 IBM 时，觉得苏宁就是个“卖电器的”，博得大家的会心一笑。事后想想，这也拉近了我和观众之间的距离。
+
+……
+
+从这场演讲开始，我才真正意识到：**单是乐于演讲、勇于演讲、精心准备还远远不够，还要有用户思维、产品思维，要思考观众真正想听的是什么**。
+
+其实做得多了，你总能在观众身上发现自己演讲的亮点和不足。现场演讲最大的优势，就是能和观众产生充足的互动，给你及时反馈。于是，发现了亮点，就发扬光大；发现了缺点，就复盘改正。
+
+到了 2019 年，我连续参加了 GTLC （全球技术领导力峰会）五大分站，收获了很多经验、结识了更多优秀的人、也对演讲技巧更加熟悉。我越来越发现，直观、幽默、自嘲都还只是优秀演讲的表象特征，**优秀演讲的真正内核是：从心底里放下架子、足够诚恳，明白自己是来交流的，而不是来讲课的。**
+
+很多人喜欢用成功者的叙事模式来做演讲，把自己说得很牛、很有洞见，好像从小就精通架构设计、团队管理，让观众越听越沮丧：你说的都对，但我做不到啊；你太牛了，我太差了。
+
+其实当你一步一个脚印地走过来才会发现：大家都是摸索着过河的，摔的跤都不少，爬起来的时候都是鼻青脸肿，没有那么多“技术天才”，也没有那么多“天生骄子”。
+
+这些认知反映在演讲中，就是不断告诉自己：别总说文绉绉的专业术语，多说些实在的大白话，多分享点有逻辑支持的实践经验。虽然听起来没有那么“高端大气”，但大家很爱听。在 2019 年最后一站 GTLC —— 深圳站，我的演讲满意度是 78.7%。活动结束后，工作人员告知我是全场最高，我听了很开心，但觉得还是要继续努力。
+
+2020 年，更多的企业邀请我做咨询，疫情期间我还参加了几场线上直播，接触了更多打造影响力的形式。但这个时候，打造影响力已经不是我对外演讲的唯一目标了。于我来说，演讲分享本来就是一件快乐的事，当你帮到别人并收获了反馈、感谢时，那种快乐真是无与伦比。
+
+## 认真是基础，真诚最重要
+
+遍观我的这段经历，不能算光芒闪耀，但也收获不小。我常说，努力就会有回报，很多人觉得这是鸡汤。
+
+到底是不是鸡汤，大家看看我在“影响力建设”方面的收获就知道了：
+
+1. **机会更多**：在每次工作变动时，都能有志同道合的 CEO 或其他朋友找上门来，让我免于待业在家，也无需苦苦等待猎头的消息，比如环球易购、彩食鲜、新东方、海尔集团等，我对此满怀感激；
+1. **信任更多**：无论是初来乍到，还是空降管理，我都更容易获得团队和 CEO 的信任，拥有更大决策自由和话语权，这份信任非常难得；
+1. **朋友更多**：每当我回归曾经工作、奋斗过的城市，总有许多老朋友约我聚一聚，喝喝酒。虽然出差永远很累，但我心里很快乐；
+1. **成长更快**：我更频繁地被邀请到各类场合做分享、做咨询。在这个过程里，我自己也在不断复盘、总结，成长速度大大提高。
+
+……
+
+说心里话，这些收获都很丰厚，但对我来说，它们都是附属价值。真正驱动我坚持演讲、持续复盘的原因只有快乐。所以我也建议你，如果真的不喜欢社交和抛头露面，那么尝试过就不要再继续。我觉得做“专家型人才”也很好，千万不要为难自己。
+
+有很多同学不愿意做分享，总觉得自己这点“粗陋见解”，容易让真正的专家和大咖笑话。其实每个人都是在不断成长的，许多观点和见解有一定的局限性。如果你现在不敢分享，以后也不会有勇气分享。就拿我自己或极客时间的其他专栏作者来说，谁敢说自己的分享独一无二、绝对正确？
+
+我觉得很少很少，几乎没有，但总有人会因为你的付出而受益，你自己也会在梳理分享内容的过程中成长。所以，勇敢分享不仅是一个利他行为，还是一个利己行为，真是好处多多。
+
+前两天，有读者在专栏下方给我留言，说我是唯一一位每条留言都回复的作者。我当然会回复大家了，因为看大家的留言，对我自身也有很多好处。这就是我常说的：**沟通创造价值，分享带来快乐。**
+
+当然，如果你发现了其他的路径，比如写公众号、做视频号，也不失为一个好选择，欢迎在评论区分享给大家，我们一起共同成长。
+
+**倘若你决定通过演讲和分享打造自身影响力，请一定要做时间的朋友，认真对待每一场分享和活动**。经常有朋友同我讲，工作实在是太忙，PPT 只能草草写一下，没时间准备演讲，怎么办？
+
+你不妨想想，自己一年可以参加几次对外分享？如果工作忙，就降低演讲频率，假如一年只有 1 - 2 次演讲机会，还不值得认真准备吗？前面我们讲过成长需要聚焦，关于打造影响力这事，你聚焦了吗？
+
+也是基于这个原因，我没有过多分享一些演讲的细节技巧，不是我不想，而是当你认真准备、认真复盘每一场演讲的时候，忘词、紧张、不会写 PPT、不会控场，都不应该是问题。
+
+技术人都是很聪明的，区别只是在于用何种态度对待问题。
+
+这里要注意，认真是迈出的第一步，真诚是要跟上的第二步。**大部分情况下，过度包装自己都不会带来益处**。当然，人都有虚荣心，我也有，但你要保证内容和实践经历至少是真实的，不能只顾着吹嘘自己，别总觉得自己很牛。
+
+最后，我想说，犯错、失败都很正常。理想状态下，我们当然要追求更好、最好；但现实情况是，不是只有满分演讲者才能收获好处。
+
+在 QCon 2016，我辛辛苦苦准备了万字注释，虽然满意度并不是很高，可这场演讲仍然给我带来了巨大的收益。演讲的内容被整理成文章在互联网上广泛传播（现在还能搜索到），后来很多邀请我加入的企业高管，都是通过这篇文章认识我的，其中就包括我离开苏宁后的下一站 —— 环球易购。
+
+所以你看，影响力的产生不一定是即时性的，它可能是一个“发酵”的过程，要坚信：有付出就会有收获。不要因为演讲没发挥好、文章没写好，就开始退缩，让影响力“发酵”一会，坚持做正确的事，做时间的朋友。
+
+## 结语
+
+当然了，于我个人而言，让我受益最大的影响力提升手段，是对外的技术或管理经验分享。但在不同的阶段，可能大家都有不同的方案。
+
+前几天，就有一位读者在专栏下方留言，说现在转技术管理的想法没那么大了，想在技术深度上增加自己的影响力，感觉写写博客、写写微信公众号文章也挺好。
+
+一点没错，够认真、够真诚，坚持不懈，相信你终会有所收获。关于如何做好演讲、如何打造影响力，我们就先聊这么多。如果你有其他疑惑，也欢迎向我提问。
+
+至此，我们专栏的第二章 —— 「对管理工作的复盘」，就基本结束了。后面，我会聊聊「对专业成长的复盘」，也是我们专栏的最后一个章节。
+
+期待与你在下一讲相聚。