⽕币⽹郑晔：如何成为一名卓有成效的技术管理者？
大家好，我是郑晔，来自火币网，担任首席架构师的角色。同时，我还负责一个开源项目 Moco，也曾经翻译过几本技术书，创过业，还写过专栏——《10X 程序员工作法》。如果各位是 TGO 鲲鹏会的会员，那么我的专栏对你们应该是免费的。
今天想为大家分享一个主题，名叫《卓有成效的技术管理者》。其实我一般喜欢分享技术干货，鲜有管理方面的内容。但今日正好来到西安做技术分享，加之这个话题已经在脑子里盘旋了很久，于是便把一些不曾对外讲的内容拿出来跟大家分享。
不知道在座的各位有没有看过《卓有成效的管理者》这本书，这本书的名字与我们今天的主题是类似的。当我讲管理话题的时候，我自然而然就会挑行业里比较重量级的人物的思想跟大家分享。那么，我们先看一下书中讲了什么内容，再对照日常我们工作的时候会跟这个有什么差别。
既然是讲卓有成效的管理者，肯定会涉及两个问题，即什么是卓有成效，什么是管理者。按照书里的定义，“卓有成效”强调对工作本身的贡献；“管理者“强调对组织能力和绩效的影响。
我觉得在座的各位既然能做到管理者的角色，那么在自己原来岗位上的工作绩效都是非常好的。但当你扮演了一个名叫管理者的新角色，绩效的定义就和做程序员时不是一回事了。这两个角色的偏差之大，可能让很多人在从程序员成长为管理者时，都需要做出思想上的转型。
很多人带领大团队做事时，会跟大家说我们努力往前冲，一定要把这个事做好，这个没有任何问题。但你有没有想过，怎样利用自己的能力或者影响力，让团队在与你共同工作一段时间之后，不仅能够完成任务，还能够提升自己的水平？这本书强调的不是一个纯粹的技术管理者，而是管理者的身份，需要你既能把工作成绩做的很好，又能把团队带的很好，这是非常有挑战的事情。
当谈及管理者面临的挑战时，这本书里也给出了参考答案。书里说，你的时间不再属于你自己，而是属于别人。不知道在座的各位是否也有这样的感觉？如果你的团队是一个刚创业的小团队，你会说我其实不错，我有大把的时间跟团队一起写代码一起奋斗；如果你的团队规模稍微大一点，达到上百人的规模，想坐下来写代码是不可能的事，除非你的职责可以被团队中的某人替代掉。
作为一个管理者，必须花大量的时间进行沟通，同时也容易将注意力局限在组织内部，很多时候团队事情做的很好，但是外面的市场环境一变，或者评价体系一变，之前做的所有事情就失去了意义。比如诺基亚，内部运转很好，管理非常好，但是外部的情况都变了，内部的运转情况也就失去了意义。此外，德鲁克也重点强调了知识管理。知识管理要靠知识、创新产生新的内容，这跟传统的管理方式有很大的不同。
对于处于变化之中的体系来说，上述问题还只是冰山一角，管理者需要面对非常非常多的问题。当我们谈及管理，其实是要找到一条让工作更有成效的道路。首先不妨让我们看一下书里的建议。
这话听起来跟一般的成功学书里强调的很像，比如我要认识时间花在哪，我一天很忙，都忙什么了？或者你要记住时间到底是怎么花费的，对自己的时间花费有清楚的认识。有了以上认知后，我们要把浪费时间的活动砍掉，有效利用整块时间。当然，后面还有很多时间管理的概念，时间管理的矩阵，如何定位出事情的优先级等等，对我们来说，能把最重要的事挑出来并且做好，是时间管理的前提。
最基本的是用人之长，需要让能力普通的同事也能够很好的工作，大家之所以能成为管理者，很重要原因的是大家能力相对强一些，那么你怎么能够让能力普通的员工也发挥自己的长处？
此外，怎么管理你的上级？这是当年此书给我印象最深的一点。在座的各位有些已经是公司最大的老板，这句话你可以理解成怎么管理你的投资人。在中国传统思想结构上，我们讲究尊卑有序，大家在管理下级时，通常会做得非常漂亮，而管理上级的时候气势就小了许多。你可能常常在思考，如何与老板要求资源，如何与老板讨价还价，如何让老板帮助你，或者你常常遇到老板提出一些不合理的情况，说实话就是你太纵容你的上级了。
之前有人说，高层管理者通常有一个很严重的问题——自我感觉特别良好。他们很擅长往下发号施令，接到下面反馈的内容却很有限。一方面，老板未必能够倾听下面的反馈；另一方面，下级也未必能有效的将问题反馈上去。这个问题是双向的，如果在有人觉得自己的老板只是个完全听不进去话的混蛋，可能你考虑的就是完全不同的另一个问题了。
这点对于技术管理者来说有挑战，技术管理者擅长的地方是什么？往往是技术，如果你只顾发挥自己的技术特长，团队很有可能会完蛋。太多的时间花在写代码上，团队谁来管理？这是需要权衡的地方。要把自己作为技术管理者的能力发挥出来，是一个需要多方权衡的问题。
有效决策，其实强调的是首先不忙于决策，尽可能做重要决策，一旦决定要做的事就要尽快行动；其次是对经常发生的事情确立原则，不重复造轮子。如果团队给出方案时出现冲突，需要拍板，你要勇于承担责任。
刚才提到很多怎样做到卓有成效的管理者，好消息是所有东西都是可以学的。掌控自己的时间，重视对外的贡献，用人所长，要事优先，有效决策，这五点是这本书强调的五个工作习惯。
我快速将这本书为大家简单的复习了一遍，但我们今天讲的主题是卓有成效的技术管理者，主题跟《卓有成效的管理者》这本书差了两个字。技术管理者和管理者，差别在哪？只差两个字——技术。我们是技术出身，优势是了解技术细节，但与此同时，你也很容易陷入技术细节，将其变成自己的劣势。
一旦陷入细节之后，你会忽略很多东西。比如你可能会忽略管理，尤其是刚开始进入技术管理角色的时候。你强调的往往是技术上的能力，是能否带领团队搞定这个事情，但这是一个团队，一个人能力再强也不可能把所有的活都干了。你的责任是带着团队把事情做了。
技术管理者在解决问题时，很容易忽略外部情况，比如我自己。前段时间，我刚带领一个团队，努力的把系统各种问题搞定，但是回头老板说，状况为什么跟我理解的不一样？我忽然意识到我有一段时间没有跟老板沟通了，这个地方肯定出问题了。于是我立刻跟老板沟通，看有没有有效的管理措施。
有时，我们也会忽略员工本身的成长。当你的团队有一个重要员工需要离职，你需要问自己这个哥们儿跟你干了这么长时间，他到底有没有得到自己想要的东西，你有没有了解这个人内心需要的东西是什么。我时常会回头看看跟我一起干的兄弟们能力有没有成长，如果他们只能在同样的问题上不断的重复，对他来说，跟你干和找任何一个公司干没有区别。你虽然很有本事，但跟下属没有关系。
一旦成为管理者，尤其是需要狂奔的时候、解决技术问题的时候，你可能会下意识地忽略这些问题，因为人的注意力有限。
技术管理者还有一个非常强的倾向，就是用技术解决问题。这个特质原本不错，但是不能所有问题都用技术解决。比如，老板扔过来一大堆需求让你明天就解决，你肯定搞不完，怎么办？我可以跟老板谈，我是否可以做现价交易功能，不做市价交易功能，老板想了想说可以。我继续说，手续费可不可以这期配置成固定的，下期改成配置的，老板可能说也可以。
当你用这种思路解决问题的时候，你的需求可以被砍成若干个，而不是一定要上线一个非常完整的交易系统。我没有写代码，我是在用沟通商讨方式解决问题。如果你的团队只能技术解决问题，往往是很伤人。我们是一个技术团队，但是我们首先应该想到如何不用技术就能解决问题。
刚才说的是作为一个技术管理者，我们固有的优势和劣势，下面说说我们如何做的更好。
既然要成为专业的技术管理者，我们就应该对整个软件开发行业有一个更好的认识。你得知道这个行业有什么，你才能决策我选择什么技术。当你成为技术管理者的时候，你的角色不仅仅是一个特定领域的技术专家。
比如说对软件开发过程，你要了解它是瀑布的模型，还是敏捷状态；你要了解现在的系统怎么做集成，是手工集成，还是每日集成，还是持续集成到持续交付。关于部署，你要了解是从应用服务器开始，还是 Docker 到 K8s。
我们自己公司内部招聘时，发现有一个非常有意思的现象，我们公司在同一个级别招两个角色——技术专家、技术总监，团队带的相对比较好的往往是技术总监。你是什么样的角色，你给自己的定位是什么角色，这两者往往会慢慢产生分歧。因为技术牛成为了技术管理者，但你不能靠技术牛来长期的维持在这里。如果你把自己定位成技术管理者，那么就意味着不仅要自己把这件事做好，还要带着团队把这件事搞定，你要选择一个适当的方式方法，让团队整体有一个很好的提升。
上面我们虽然讲过大家应该了解软件行业的最新发展，但是这里还有一个更麻烦的事，你能不能开放心态持续学习？你在做某一个决定、某一个技术选择、某一个过程选择的时候，到底是因为什么？仅仅因为你熟悉，还是它真的是好东西？
技术人员可能还有一个更大的风险，就是一种冒险的冲动。比如说微服务，如果轻易地走上微服务的道路，很多团队会死的非常难看。我就知道很多团队仅仅听某一个技术大会说微服务不错，就冒险选择了微服务方案，结果预定两个月上线的项目上了半年。
当然情况也可能相反，技术管理者会由激进的心态变成保守的心态。我之前做过一些咨询公司，去一些公司跟别人谈，比如说过程改进，朝敏捷的方向走吧？很多人反对，但说白了他也不知道自己反对什么，你能听出来，不是因为他现在的过程中做的很好，而是现在的过程他非常熟悉。
当你成为一个技术管理者时，你是什么样的心态，是一个开放的心态，还是一个封闭的心态，其实有非常大的差别。如果你是开放的心态，好东西会进入到团队中来。如果你是封闭的心态，团队就会变得闭塞。当团队有很多老员工时，你可能会对这种心态感觉尤其明显。
你应该有开放的心态学习知识，更重要的是要持续学习。持续学习不光是学习技术、学习软件开发相关知识，而是要持续学习你不知道的所有东西。最近几年，我看了很多书，但我发现技术方面的书占比越来越少，其他方面的书越来越多。如果非得在管理者的身份上套上技术两个字，想问题的范围会变窄。如果去掉技术符号，你能学的东西、要学的东西几乎是无限的，对于每个人来说都有很大的提升空间。对我个人来说，开放心态、持续学习是我从业近 20 年后，自我感觉还能提升的重要的一个原因。
最后一点，作为一个技术管理者，我们不仅要关注一个事情的表面，更要关注事情背后的本质。比如对于持续集成，我们真正关注的是能否实现很好的自动化；再比如，关于说验收标准，验收标准的格式是什么没有那么重要，更多的是在一开始你能否清晰定义结束的标志，就是以终为始。
讲了那么多关于技术管理的东西，本质还是回归五个工作习惯，你能否有效掌控你的时间；能否对外做出有效的贡献；能否充分发挥团队成员的能力；能否做到要事优先；以及能否做到有效决策。
郑晔：任何一个公司对研发来说都不是很有力的角色，对任何一个公司来说，老板最终关注的是结果。看你的团队有多大，如果团队规模很小，很多东西你跟老板会走得比较近，你多跟老板沟通，他会逐渐体量你一些，如果你的团队规模比较大，老板只能拿结果要求各位，你能做的事是什么？尽可能的把结果做好。
回过头来，如果你想把事尽可能的做好，一是管控老板的预期，不能让老板想什么是什么，老板也是人，欲望是无限的，你今年能干一个月的活，明年为什么不能干两个月的活，会给你规划 24 个月的工作量。二是自己对于内部尽可能达成目标，我要想达成目标肯定要把一切没那么重要的东西尽量往下砍。当你的团队规模够大，浪费会非常严重，把不必要的事想办法砍掉，尽可能完成老板预期目标是有可能的。用 MVP 的思路解决问题，从需求端先砍掉，再交给下面的人，要控制他们天马行空的想象力，让他们把注意力聚焦到问题的点上，道理大家都懂，真正做到我个人认为是非常困难的。
如果问我有没有一招制敌的办法，我的回答是，没有。我会经常跟我的老板沟通，大家互相设计预期。我一旦注意力钻进去我也会经常会跑偏，刚才讲的原则是大家容易听懂的，但是真正把它践行到实际工作中是非常困难的，你要时时刻刻提醒自己，为了让我自己内部的工作做好，一定要管好老板。
郑晔：我自己写程序写了十几年，看你的关注技术是哪方面的技术，你会发现技术没你想象的变化的那么快，应用技术变化的快。
比如说今天出来个 AI，明天出来个物联网，5G 又出来了。实际上你自己关注的东西是否变化的那么快？比如说我自己最关注的领域是软件设计，我翻了一下软件设计，最近几年比较火的 DDD，大概是 03、04 年出来的，十几年前的技术我十几年前可能已经看过了，再去理解新的技术对你来说难度不高。
你自己要想好，你想成为什么？你想成为技术专家，你得先在技术上有一个足够的积累，你想成为一个技术总监，你应该逐渐扩展对于软件开发整个过程的把控，这两条路发展变化都没有那么快，当你成为一个专家之后，你再学习新东西，其实你学的不是从 0-100，你学的只是其中很小的部分。
最近我也学新的东西，Facebook 新出来一个语言叫 Move ，我花了一两天时间看了一下，Move 最核心的概念是每个资源只有唯一的所有者，资源只能消费一次，并限制创建新资源。它解决什么问题？防止智能合约里面不小心搞错了，对数字货币安全的必要保障。有新的技术出来了，你能否很快的学习，取决于你之前有没有那个领域足够深的积累，如果你有积累再学这个东西，你学的都是差值，这个学起来是非常快的。不是说现在新技术不学，每天我也会关注很多新东西，哪一个新东西值得我花时间去看。
在我的职业生涯中，我有一段时间做了咨询，中间有两三年没做 JAVA，发现 JAVA 的东西几乎没有变，我花了 20 天捡起来，写了一系列的文章告诉别人应该学什么。
对于各位来说，你自己想好自己发展的定位是什么，如果是技术专家，你在技术上下功夫，把技术积累到一定的深度，学习会很快。如果你想成为技术管理者，软件开发过程管控的很好，这个领域变化也非常少，在我看来我为什么觉得这些年读的技术方面的书没有以前多，说实话我觉得值得读的书没有那么多。我觉得，你应该想好自己的发展路径是什么，在这个领域里你要有足够深的积累。
郑晔：刚才说要事优先的原则，谁都躲不开每天有各种各样的事，你会把自己的时间做划分，哪些事对你来说是重要的，哪些事是不紧急的。很多既不重要又不紧急的事就不要做了，有些事是不是非得你来做，这个事你不做让别人去做有什么不一样。
对于大家来说每天都很忙，能不能把这些事放出去，作为技术管理者总有一种错觉，觉得我很重要，你想多了，有些事你不做别人会做的很好。你一行代码不写，让你手下做的好的兄弟们来做，你要管理好你的老板，不要让老板有更多的需求，兄弟们就能很好的完成。你自己应该把注意力放在什么地方，肯定有一百件你不满意的事，你能不能同时解决，估计不可能，每个人的能力都是有限的，在一段时间内只能选择你认为最重要的事。
你自己最重要的事到底是什么？你不要把自己看的太重要，尽可能的让手下的兄弟们分这些活，其他不重要的事就不做了，这是一个做事划分的原则，能不能实践好这个原则，很大程度上是你把自己看的多重要。能甩出去的事尽量往出甩。