这里是Z哥的个人公众号
每周五11：45 按时送达
当然了，也会时不时加个餐～
我的第「142」篇原创敬上
回顾了我自己的职业发展历程，一路从普通码农，慢慢成长为Team Leader，再到主管，最后到目前的技术总监。
随着自己的慢慢成熟，发现不少新晋的一线技术管理者正在趟进我曾经踩过的坑里，有感而发，想通过此文分享一些自己的经验给大家。不一定你能完全认同，但是相信或多或少会对你有所启发。
作为一线技术管理者，平时所接触到的很多事情与原先还作为一线技术人员时无异。
但是恰恰是这种熟悉感会让我们陷入到老的惯性里面去。继续沿用原来的做事方式去做事。
如此一来，为啥要让你做技术管理者呢？继续保持在原来的岗位不是更省事么。
这个道理很浅显易懂，但现实是，的确有不少人没意识到这个问题。
当然了，大家也并不是100%不变。很多新晋的一线技术管理者会把自己新的职责分为3个部分：
这里的前两点每个人都知道是自己的新职责，但是投入的精力并不多。
社会的分工协作演变到这个阶段，不可能让两个不同的岗位之间做的事情有那么高的重合度。
而我所理解的一线技术管理者应该要做的事情分为3个部分，但不是上面罗列的这3个，而是：
并且大致会占用到你的精力比例为，30%，20%，50%。
/01 人（30%）/
管人并不是简单地制定一些规则，然后一刀切。每个人都是不同的，有自己的特殊性。
比如，每一位成员的优点和弱点是什么？这需要花时间不断地深入了解。怎么了解呢？
通过了解他们的经历，成长背景，家庭情况，并且与他们的沟通等多种途径去了解。
了解了这些个性化的特点之后，便可以有针对性的安排任务、训练。而不是对所有人都采取一套方法。也不是用自己认为对的方法去训练别人，要用对方更乐于接受的方式对待他。
再如，人的情绪和状态总有起伏，没有人会一直稳定在某一种状态下。那么如果你想给一些有挑战性的任务给他，你得选在他状态好的时候，否则挫败感会让他的状态进一步下滑。相反，如果你想让他较差的状态得到好转，得给一些在他舒适区内的任务给他。
在人方面还有重要的一点，就是「招人」。这个事情如果放松了，你在内部做的很多人员管理的工作都会大打折扣，被外部的新力量给冲刷掉。
我在这方面也踩了很多坑。总结得到的核心要点是：招人，「志同道合」最重要。
能力什么的都可以培养，而且如果本身就是志同道合的人，培养的意愿和动力也更足。但是只关注能力好的人，他们却不一定与你志同道合。如此一来，你们之间的协作成本，管理成本就会变高，团队的作风也会出现多种不同的风格，这不利于整体形成合力。
/02 资源（20%）/
作为一线管理者，虽然资源还算不上多。但是相比还是一线开发人员那会，你能掌控和借助的东西的确多了。那么如何将这些资源的价值发挥到最大化，是你要考虑的问题；而不是仅仅是，把使用资源当作一项任务，差不多用用就得了。
比如，一般此时你会拥有组员的奖金决定权。这个时候你要考虑的是，这个奖金到底该怎么分才能最大化提高大家的战斗力，而不是怎么分才能让组员没有怨言。前者是在往最大化价值发挥，后者则是完成一项任务而已。物的决定权也是类似的。
作为一线管理者之后，你就成为了组织中的夹心板。上面有上级，下面有下属，横向还有其他组织的同级。
维护好与这些人之间的关系是一件难事，但这也是你的宝贵资源。能不能撬动这些资源帮你做事，对你有着事半功倍的作用。
对大多数人来说，平时和下属相处的时间最多，所以很多人习惯于偏向下属一方，毕竟更有利于自己管理。而缺少站在其他组织、上级的角度考虑问题。
这样的话，你基本很难去撬动这些外部资源，因为别人可能很少能感受到你对他带来的价值。
所以，你需要真正的做好这里的利益平衡，而不仅仅是方便自己。
另外，你的下属是你的最重要资源，没有之一。能不能扬长避短，让1+1的结果更大，是你需要不断思考的问题。
/03 具体的事（50%）/
在管理里面，一线管理者管的事情颗粒度是最小的，是确保能成功落地的最后一环。所以这部分会占据他们一半以上的精力。
如果某件事一个人做需要m个工时来完成，那么n（n>1）个人来做，理论所需工时是m/n，但是实际的时间一定比这个多，结果是（m/n）*α（α>1），α就是协作成本。技术管理者要做的，就是尽量降低协作成本。
所以「管事」的终极目标用一句话来概括就是：让多个人一起做事像一个人一样协调。这是一个没有协作内耗的理想目标，虽然无法达到，但是我们可以通过流程、制度来无限接近于它。
不过关于这两点，我的个人观点是。流程尽量少制定，能不要就不要，只在特别重要的链路上做流程标准化。
因为流程的标准化是一个成本很高的事情，这是在统一大家做事的方式，看上去能提高最短的那块板，这的确没错。但是你会把最高的那块板也一起截短了，会对一部分人产生束缚。
而重要的链路经过打磨的时间也越多，相对越稳定，在这里做流程标准化可以避免新人进来犯错，总体来说利大于弊。
相对来说，多制定「标准」则没有「流程」的这种问题。因为标准只表示一个结果，做到什么程度，并不约束你怎么做，每个人可以发挥自己的聪明才智来达到这个标准。
你唯一要做的就是考虑是不是有什么地方可以把标准卡死，避免标准形同虚设。
有些情况实在卡不死的，可以通过增加一些措施来往这个方向引导，比如，制定完代码规范后定期进行培训、复盘、抽查等等。
用质问和批评的方式是最差的方式，这本质上是在把你的想法强加给大家。
其实不管是流程还是制度，它们的目的无非是提高以下两个方面。
所以，正如前面所说，不如结果先行，把标准或者说目标定出来。然后跟踪你的下属完成目标的过程，可能你会发现他们选择的方式比你之前预想的还要好。
做技术管理者，必然会遇到的一个典型问题是「技术选型」。
你选的技术下属不认同，下属选的技术你不认同。这个时候你可以强制要求他用你指定的那个，最简单直接效率最高。但是可能在你下属心里就埋下了别扭甚至埋怨的种子，日后可能会存在一些不可控因素。
所以，你最好是能够身体力行，去了解一些这个技术的核心特征。这在这个时代并不是什么难事，然后再去与他沟通，真正说服他，达成一个共识。
或者当你了解完之后发现的确是下属选的那个技术更好，你应该认可他，给他鼓励。如此他才会有积极性再下次继续提出自己的看法，否则以后慢慢就变成了一言堂的局面。
团队做事想要效率高，就得耐心营造认同感。可能一开始会花比较多的时间，但是随着磨合的继续，花的时间会越来越少。
我再推荐几本我之前看过还不错的技术管理书籍给你，有兴趣的可以去看看。
- 《格鲁夫给经理人的第一课》，Intel创始人以技术思维解读管理这件事情。里面有一个核心词「杠杆率」，以这个为圆心来理解管理这件事。
- 《技术管理之巅》这本是偏实战的书，作者分享了自己很多具体的事例，包括团队搭建、组织架构、产品开发流程等等。
- 《重新定义团队：谷歌如何工作》这本主要是讲人和团队的，谷歌的人才培养方式，团队管理方式。毕竟是洋货，以打开视野为主，可以从中取一些自己认为合适的点来实践下。
这篇呢Z哥分享了下我自己对一线技术管理者应该做些什么以及怎么做的理解。
首先要避开一个误区，一线技术管理者的任务不仅仅是，任务安排、协调沟通、做自己原来做的事。这就把自己圈在一个很小的范围里了。
一线技术管理我个人认为分为人、资源、事3个方面。对你精力的好用占比大致是30%、20%和50%。
对于人，主要是要了解每个人的特点、根据他在不同时期的状态帮助他成长。另外，招人的时候，找到志同道合的人比什么都重要。
对于资源，最大化利用是路人皆知的事情。但是要撬动同级、上级的资源为你所用，首先你得有利他之心。
对于事，主要是提高工程质量和工程效率，其中制定流程和标准是不不可少的。但是注意尽量多标准少流程为宜，流程会扼杀“长板”。
关于技术选型的冲突，一定要身体力行，沟通到位，避免强行要求导致逐渐形成一言堂的困境。
管理者就是古时候打仗的将军，一将无能，累死三军。如果你的团队正在疲于奔命，那么不妨思考一下是不是你的管理方式有问题？
有一句鸡汤说的没错，管理者以成就他人作为自己的工作目标。你成就了你的下属，你的成就自然也不会差。
原创文章，转载请注明本文链接: https://zacharyfan.com/archives/1187.html
关于作者：张帆（Zachary，个人微信号：Zachary-ZF）。坚持用心打磨每一篇高质量原创。欢迎扫描二维码~
定期发表原创内容：架构设计丨分布式系统丨产品丨运营丨一些思考。
如果你是初级程序员，想提升但不知道如何下手。又或者做程序员多年，陷入了一些瓶颈想拓宽一下视野。欢迎关注我的公众号「跨界架构师」，回复「技术」，送你一份我长期收集和整理的思维导图。
如果你是运营，面对不断变化的市场束手无策。又或者想了解主流的运营策略，以丰富自己的“仓库”。欢迎关注我的公众号「跨界架构师」，回复「运营」，送你一份我长期收集和整理的思维导图。
