技术管理从0到1，并没有你想象的那么难！

技术和管理是两种完全不同的岗位。国家政府的官员或者企业的管理者一般是从文科走出来的，这个和技术还是略有差异的。程序员多是理工科，他们垂直的把写代码这个事情做好就可以了，但做管理需要考虑的事情就多了，包括事情的前后因果关系、可能会遇到什么情况，这是一个需要提前布局和比较费心思的事情，他和程序员闷头来做框架还是有一些差别的。所以当一个技术人员想去做管理的时候，他要问自己几个问题。

第一是自己的沟通能力够不够好，因为管理者有非常多沟通的事情需要做。

第二是看自己的计划和布局能力怎么样，程序员只是做自己眼前的事情，但做管理不同，管理就跟下棋似的，需要棋看三招，所以你的计划、你的布局能力是很重要的。

第三个就是自己有没有承受挫折的能力，因为所有的技术人员在刚开始转管理的时候，都会遇到一些坑，这些坑就像自己原来做技术给自己埋的坑一样，是一个未知的坑，因为你从来没有做过管理，肯定会在一些坑里面摔一下，这就需要你有很好的克服挫折的能力，只有心态好你将来才能转到管理者岗位上去。

三十岁不适合做技术，该转管理了？

对于 30 岁不适合做技术，该转管理的说法，我觉得是个误导。大家知道国外有一些非常资深的老程序，像我的一些同学，在 google、Facebook 这样的公司，他们还在编程序。

在国内技术人员也有一条上升路径，并不是说自己到一个年龄必须去做管理。做管理做到一定程度，你会发现它也是一个专业，它跟做程序一样，术业有专攻，有的人比较内向，他就是喜欢自己钻研东西，包括我有一些北大的同学，现在一直还在做技术，而且做得很好，管理岗也不是每个人都适合，比如那些沟通能力不够好的，你硬让他去转管理，那样挫败感就比较大，到头来还得重新回到程序员，重新做起。

这跟自己的性格，你想做的事情，和刚才说的这个挫败的承受能力都有关系，不一定非要做管理。我们现在的团队也有非常资深的做算法、做架构的，其实做程序员也是往上走，从程序员到架构师再到首席架构师，这是一直做技术的上升路径。做管理的可能就走向了总监、CTO、CEO 等，这两条路虽然不一样，但每条路其实都能往上走。

管理之路分两步走

管理之路其实分两步走，第一个就是从纯技术人员到中层管理，总监这个级别，第二个就是从总监到 CTO，走到技术一把手的位置。这是两个不同的阶段，现在很多做技术的小伙伴可能还在第一个阶段。

我做了一年技术以后，开始做项目经理，管理 40 多个人，当时因为年轻嘛踌躇满志，觉得管的人越多越好。后来发现由于管理经验不足，自己还是挺辛苦的。当时由于没有很好的把这 40 多个人调动起来，很多人都闲着，我和一个小团队却每天忙得团团转。

做技术做的是乘一的工作，但管理就需要通过杠杆的方式把人调动起来 ，做的是乘十的工作，要调动十几个人、几十个人来干这个事情，不能看到问题就自己撸袖子干了，要抑制住自己的冲动，我那会就没控制住。 而且那会觉得人要多，但其实人不在多，而在精。你不能找很多和这个团队水平不搭的人，那样人越多你越累。

第二个阶段就是从中层领导去扛事到高层领导去成事，我觉得是一个 99 度到 100 度的过程，很多 EGO 的小伙伴正在面临这个问题。其实很多坑只有你自己经历过才会真的明白，可能你会通过看我们这样的直播获得一些经验，自己避免一些坑，但实际上还是需要自己去体验。就像我后来再去系统学管理时发现，很多坑是可以避免的，但当时就是想不明白。

做管理需要跨过哪些砍？ 管 & 理

按照我的理解，管理应该分开讲，其中管就是管人，能调动他的积极性，让他自发地主动地去解决问题，而不是通过行政命令。理是理事，一件事情一般是很复杂的，尤其是对初次做管理的人，你会发现它像一团毛线团一样，很乱，理就是把这个毛线团拆成一个个线头、把事情理清楚，然后找到合适的人去做，而不能自己去做。

 识人需要经验

第二个，做管理者很重要的一点就是要学会识人，究竟什么样的人适合做什么样的事，这个需要有经验。过去大家编代码的时候都是和机器打交道，机器做的是一加一等于二的工作，但人处理一件事情的时候会受很多因素干扰，比如他能力的范围、认知的范围、沟通能力的一些局限等。他究竟是一个技术型的人才，还是一个管理型的人才，或者是沟通型人才，你得能识别出来，然后给他合适的工作。这中间涉及到招聘等一系列事，都是识人的工作，因为只有做好识人，才能把工作交出去，做成乘十的事。

 跨过裁人砍才会成熟

做管理另一个要跨过的砍，也是我识别一个人是否可以做总监级别的标准之一，就是看他会不会主动裁人。因为开始的时候大家都是一起写代码，都是自己的兄弟，但在什么时候需要把这个人裁掉，其实是一个很难跨过的心理的砍。我见过很多的总监都是因为你好我好大家好，没有去裁人，最后让团队变得越来越臃肿，自己越来越累。就像我之前 40 多人的那个团队，当时就该裁掉至少三分之一的人，这些人并不适合项目的氛围，应该勇于裁掉，而且用合适的手段去裁掉，包括怎么安抚现有团队，怎么让人合适的离开，只有经历了这个过程，你的管理次才会成熟。

技术管理者容易犯的错误

第一个误区是人越多越好。初次做管理的人会认为团队越大越好，越大越有成就感，显得自己能力越强，其实这是一个误区，做同样的事情，自己的团队越小越好，因为管理到一定程度以后，你会发现精英团队这件事情非常重要，一堆人乌合之众比不上少数精英，因为人越少越容易协调，反而更加轻便。

第二个误区是技术越先进越好。从技术转管理的人一般会有这种想法：我要用最新的技术，我要赶上时代潮流。但真正做管理你会发现技术够用就好。这个尺度的把握，直接涉及到你能不能从中层管理迈到高层管理。你的技术节奏究竟迈多快，迈得太慢了，你的技术跟不上，技术成为瓶颈，迈得太快了，投入很多资源，没有满足业务需求，因为你做的特别慢嘛，很多东西太超前了，架构太复杂了，反而业务落到后面了，开发不出东西，投入成本又高。所以技术不是越先进越好，而是适合当前这个状态最好。

第三个误区是机群越多越好。我经常能看到一些报备技术文章，称自己是如何把机群从 100 台扩大到 1000 台的，反过来想这家公司的业务却没有增长十倍，他的机群增长了十倍。正确的思路应该是，越好的技术应该是越小的机群里面你的性能越高，比拼的是这个。以后升到 CTO 也好、管理层也好，或者投资人的角度，机群越大越好并不是一个好的商业逻辑，正确的做法是在自己合适的成本和合适的情况下去投入。

第四个误区是认为责任不是我的。管理者的语言里不应该有“这不是我的问题”，标准化的答案应该是客观的去描述问题：这个事情是一个什么样问题，我现在的解决方案是怎么样的，需要哪些资源把这事情解决掉，这才是管理者的标准答案。因为作为中层管理者来讲，很重要的一件事情就是扛事，能把这个事情扛起来，而不能说遇到各种问题的时候把责任推出去。不扛事的这些管理者将来是没有办法走向高层管理的，也不会受到提拔。最后想说，所有的 title 不是公司给你的，是你自己挣出来的。你自己真的到那个位置上扛了那些事情，公司自然就会把这个 title 给你。

技术管理者如何进行自我管理？

其实这个问题还是要分两个不同阶段，中层管理和高层管理是不同的。

对于中层管理来讲，你对事情的分析可能要花 30% 的时间，剩下的百分之 60% 时间就是在沟通——向下沟通，向上沟通，横向沟通，把你心理预期的这件事情能够沟通明白，让其他部门知道这件事怎么做，让老板明白对这件事情的预期。然后剩下 10% 的时间在做向下的管理，自己写代码的时间会越来越少。

高层管理会花 80% 的时间去找人，然后用剩下 20% 的时间来做沟通，因为你需要找能够乘 10 的人来做更多的事。其实做到中层或再往高层的时候，你发现自己的生活的时间会被挤得越来越少。

但无论做中层管理还是高层管理，终身学习是不变的，技术方面的学习、管理方面的专业培训、以及像极客时间这样的知识付费产品我也有订阅，作为管理者你的认知边界就是整个团队的边界，所以自己要不停地去学习。

技术人员如何提升自己的领导力？

第一，员工激励。传统公司可以通过 KPI、年底总结来激励员工，如果是创业公司，员工激励要和你的业务闭环挂钩，像我们易观用的就是项目创新奖，每个季度有一笔钱，奖励项目上有突出贡献的人，拿第一奖金池的人会比最后的高好几倍甚至十倍，这种差异能够激励大家奋发图强往前做。随着业务的稳定会换一种激励方式，这个是每个公司根据自己情况制定的，我的原则就是不能吃大锅饭。

第二，团队管理。我的做法是设立一个 slogan，给团队定个性，比如今年我给我们技术团队的 slogan 就是让未来技术开箱即用，就是不能用起来特别复杂。类似 slogan 这种事情需要每个技术管理者去制定，保证大家朝着一个方向努力。除此之外还有一些关键词，像易观的开放、勇敢、创新、快乐、独立等，这些是管理者对员工和团队的要求，需要你去思考和制定。

第三，项目管理。项目管理究竟是用瀑布模式还是 Scrum 模式，这个分情况。做外包公司基本上走瀑布的管理模式，因为你好控制需求、控制进度，内部研发推崇 Scrum 模式，因为它可以快速响应需求。如果大家做互联网相关业务，推荐敏捷模式更多一些，因为它的周期比较短，就像刚才说的精益创业，咱们精益试错，快速迭代，形成最小的 mvp，形成业务闭环，然后让用户去用，再通过数据来看到表现，从而快速调整产品方向。