我们用一个日记的形式来展开本文，这本日记的主人公是一个工作了三年左右的工程师。

“HR 跟老板来找我说，恭喜我被升为团队的 Leader。这个时候出于程序员的本能，我的第一反应是买个机械键盘来犒劳一下自己，最好再弄一箱肥宅欢乐水。等我静下心来想一想，身边这么多人，隔壁老王也做的不错，旁边的小李做的也不错，为什么选我？”

仔细想一下，选择我无非是技术上我有专业的能力，我能解决这些事情；我的沟通能力、协作能力也还可以，至少不至于太糟糕。

我愿意带着团队去拼并且不是一个独行侠，有的人能力很强，但是不太喜欢跟团队打交道，那他可能不太适合做一线的管理者。然后有担当，这个担当不是说所有的事情出了问题都说老板这个是我的责任、这个我来做，是我的就是我的，这件事情我承诺了，我会负责到底。这里有三点，有能力、有意愿、有担当。

你可能会觉得我也很有能力，我的技术也不错，为什么不选我而是他？这说明在老板眼里，他对你的认知跟你对自己的认知其实是不匹配的，这个时候可以去跟老板聊一聊，看一下他认知当中的你是什么样的，如果有差距该怎样弥补。

“一个月之后，我发现我的生活并没有什么改变，虽然变成了管理者，但是意识跟身体好像还没有跟上。我应该向有经验的管理者去请教一下，变成一线主管之后会有些什么样的变化。”

一线的工程师所要做的事情就是完成工作，程序上线、测完不出问题，专业技能可以就行了。

进一步，假设是一个项目的 Leader，这时候除了专业技能上面能把代码写完，还需要去解决各种各样的问题，需要去指导别人，所以专业技能的要求会更高一些。还有一些技术决策，比如产品需求过来该怎么做；系统要做重构了需要做一些选型。作为项目 Leader 还会带几个人，这个时候只需要负责协调他们把这件事情完成，主要还是聚焦在技术层面上。

但如果是一线的主管，管理的团队可能有好几个系统，同时做好几个项目，一旦系统出了问题，联系不上系统 owner 的时候就会联系你，出了问题需要第一时间解决，你的人搞不定你就要顶上去解决，所以专业能力的要求会更高。

需要做更多的决策，比如这个系统一年的规划是什么样的？这么多系统他们之间如何协作？这些系统怎样去做标准化？新的需求过来往哪放？协调资源不再是那几个人，除了管理自己的团队之外，还需要跟上下游打交道，协调各方的资源，资源协调能力也有更多的要求。最后，是以前不会接触到的，思考团队该怎样建设，团队的成员如何培养，让他们能够一步步的成长起来。

“又一个月过去了，以前我的日子过得其实挺好的，虽然工作累，但心还是比较轻松的，但现在这么多项目、这么多人都挂在我身上，感觉不仅人累还心累。成为了一线技术管理者，我该怎样带领团队落实工作呢？”

中国有句古话叫官大一级压死人，大家有没有想过变成了一线的主管，我管着你，你就得听我的。在座有很多带的是 90 后甚至 00 后的同学，如果想靠强权管好这些小朋友，那他们可能第 2 天就不来了。不要依靠职位赋予的权利来带团队，在平时的工作当中，更多还是希望靠展现专业能力、个人魅力来影响他们，让他们愿意跟着你一起往前冲。

更好的发挥团队的杠杆作用，如果平时一个人的贡献度是 10，然后给你 5 个人，加你一共 6 个人，现在产出贡献度是 60 显然是不达标的，应该做出 70 分、80 分，把团队成员的价值发挥到最大。

这个时候要想怎样合理安排团队的工作，比如这一年在全公司的技术目标下面该承担哪些工作，然后把这个目标一个个拆解下去，让大家都知道在大的版图里面是在什么位置，并且拆解到个人身上，有些人可能一下就能明白过来，有些人需要给他拆得更细。

每个阶段要有明确的、即时的反馈。现在年轻的团队成员，你让他写个东西，他明天就写好了交给你了，你一忙给忘了，一个星期之后跟他说这个不好要改，他会想一周前你干嘛去了？如果忙可以第 2 天但不要隔得太久，不然会让他们感到非常的不舒服。

当取得了一些成绩的时候，不要吝啬表扬，最好在光天化日之下，在所有人面前说这个事情做得好。但如果是指出问题，就把他叫到个小会议室里面，人都还是比较爱面子的。好话放在台面上，需要改进的问题可以私下来聊。

带团队记住一句话“兄弟们，送死你们去，背黑锅我来”。真的出了问题，我给你们兜着，你们放心大胆的去做，但是别坑我，要有这样的担当。

“今天又被老板拉去谈话了，原来老板是怕我还没上道，赶紧来给我支了几招。我拿小本子记下了——团队成员是你最重要的投资，你在他们身上的每一份付出都会有回报的。”

你可能会觉得，以前一个人干得很快，带上他们之后节奏却慢下来了，很多人需要你的指导，觉得他们是个累赘。杰克·韦尔奇说过：在成为领导之前，自己的成长是成功；而成为领导者之后，帮助他人成长才是成功。在很多公司，人作为成本它是一项负债，有多少人，要投多少钱下去。转变一下思路，其实人也是资产，是会创造价值、带来利润的，团队的成员也是你的财富。

比如做全站架构改造的时候，有一年在做分库分表，我对团队的小伙伴说：不要看你做分库分表中间件，以后全站改造那么多系统要拆库，花一个月把这件事情做了，以后这么多团队在后面的工作开展的时候，每个人可以省下大半年的时间，这就是你的价值。有的工作看起来琐碎，但要让他看到他在大图当中的价值，让他知道我的工作是非常有意义的。

有一个理论叫双因素理论，它有两个因素：一个是保健因素，一个是激励因素。保健因素就是工资、正常的福利，给他们不会有任何的感受，这个是我应得的，没有就会跟你闹。

激励因素就不一样了，可以没有，但是当它有的时候，就会给人带来一种鼓舞、欣喜的感觉。在带团队的时候，要去充分发挥好激励因素的作用。跟他说这个事情做得很棒以后就归你了，他会很高兴；或者说这件事情做得很好，值得拿出去，比如去一些技术大会讲一讲，这样他也会很高兴，这就是一种激励因素。

“年中了，人生第一次要给别人打绩效，而且还是 271 的比例，强制的...... 好绩效打给谁倒还好说，关键那个差的该给谁呢，要不打给我自己? 一年还要打几次，赶紧向隔壁组老王请教一下。”

作为一线技术主管，打绩效真的是一门必修课。绩效管理是一种很有用的管理手段，能帮助你更好的了解团队，然后去管理它。每到一个时间会提醒你，该回顾一下大家干的怎么样了，之前的目标达到了没有。绩效管理不是简单的打个分，还有很多工作要做，做的不好的告诉他怎么改进，做的好的给他定更高的目标。

除了差的同学，中间那一段同学谈的时候也会遇到问题，他会想为什么给我个 C 而不是 B 自己做的挺好的呀。所以在平时就要给他们一个预期，平时就要告诉他们这个地方需要改进，而不是到年底的时候说，不好意思你绩效不好，年终奖可能没有了。

什么是我们说的公平、公正、公开？刘润老师给过一个很形象的解释。公平就是拿同一把尺子来丈量。一个同学，虽然产出不多，但他干的很卖力，你说干的好，有苦劳；一个技术很牛的小伙，虽然平时吊儿郎当的，但他解决了很多问题，你说干的好，有功劳。他们俩放在一起排序，谁排在前面？所以要用同一把尺子来衡量。

至于该用哪一把尺子，那是公正该做的事，而你就是定义公正的那个人。绩效该怎么打，一开始就要定下来，价值观占多少、业绩占多少，双方都认同，最后就按照这个标准来打分。公开是把整个丈量的过程展示给大家，让同意公正者来监督整个的公平，大家都认同就行。中国的高考到底合不合理？公不公正？其实是一个道理。

“团队里的小刘突然来找我，说要聊聊，顿时有一种不祥的预感。果然，他和我说想要离职。我感觉天要塌下来了......”

成为管理者后，需要面对有一天团队成员跟你说：我想跟你聊一聊。这时候心里会凉一下，他想跟我聊什么？能给他加薪吗？我是不是让他觉得不爽了？他最近遇到了什么事情了？

针对不同的情况，有不同的策略。一种是本来就要优化掉的人，这时候一定也准备好了他的 back up，大家好聚好散，江湖再见。

后面两种情况，需要坐下来好好谈一谈，不是说要一门心思的挽留他，而是站在他的角度跟他一起分析什么才是当下最合适的选择。一起看看手上有哪几个 offer，该去哪家，如果他觉得对团队还有眷恋，我是不是做些什么，他就可以不走了。

我见过很多帮着属下找工作的，我也帮我团队的成员找过工作，或者在这个团队里不会有太多上升的空间帮他转岗，转去业务部门、别的子公司等。帮他做出最合理的选择，这个选择不一定对你有利，但是对他一定是最合适的选择。

还有种特殊的情况就是你自己要走，这时候要想一想团队的兄弟们怎么安排，为什么我要离开这个地方，也许去了下一个地方我需要得力干将，但也许是去了另一个火坑，甚至更坑的地方，拉他们过来真的是最好的选择吗？这是需要考虑的。

“团队大部分的工作都步入正轨了，我终于能稍微安心一些了。不过，少数要和外部配合的项目进度不佳，不知道为啥不配合我们。另外，偶尔会有小伙伴和我吐槽，想做点新东西。我该怎么满足所有人的诉求呢?”

想一想为什么他们不配合。我们有一年做日志标准化，还有很多好的东西加在里面，这时候发现平时活干的好好的架构师好像不怎么积极了，后来老板一句话点破其中的玄妙：那是你的 KPI 不是他们的，他们各自有各自要忙的事，凭什么来帮你？

理解了这一层面，就会知道他们为什么不配合，所以要把整个目标说清楚，这件事情你好、我好、大家好，干成了大家都有好处，对公司也有利，促成双赢的局面。平时隔三差五的表达一下善意，帮别人一下，别人也会帮你。

想让团队承担更多的工作，有几点需要注意：不要什么都想往自己碗里放；别人干得好好的活不要去惦记；如果超过团队现有能力也要掂量一下；最重要的一点是手头的事情要做好，不能说把手头的事情搞砸了，去开拓一块新的领域。

可以去挑那种可能没有太多人管，但是大家都会涉及到，又能做好的事情，跟老板说能不能让我来试一下。我们真的就尝试过，替公司省下了好几百万的服务器的资源，大家都得到了好处。

“今天出了个比较重大的产线故障。虽然大家快速响应了，但还是对业务造成了一些影响。原因搞清楚了之后，明明都有责任，可为什么大家全针对我们呢?”

大家其实都对，都想保护自己的团队，希望故障跟自己的团队没关系，或者你担主要责任，次要责任是我的。发生故障之后不要说什么谁出问题谁查，一定是先恢复系统、先止损，然后再看是谁的责任。这时候谁的责任真的重要吗，我跟你吵得面红耳赤，吵到最后 CEO 会说你们技术又出事了，然后把 CTO 骂一顿，CTO 说技术出问题是我的责任，回来也不会骂你只会骂你的老板。

所以站在老板、CTO 的层面，更关注的不是谁的责任，而是以后怎么避免。有时候说技术上怎么优化真的很难，也许可以找产品看一下，流程这么设计是不是太复杂了，然后产品说没关系这步可以不要了，也许问题就解决了。

如何避免意外，跳出纯技术思维看问题：成本越低的人责任越大。我正好在学经济学，侵权法当中有个汉德公式：避免意外的成本<发生意外的概率 * 意外产生的损失，这个事情就跟你有关系。做交易核心系统，对我来说上游所有的都是交易，我怎么知道你的交易重不重要，你那边觉得它重要，自己该做监控，而且你加个监控简单，我要从 99.9999%~100% 是很困难的，这就是成本，成本是放弃了的最大的代价。

成本当中还有一种沉没成本，沉没成本不是成本。假设我以前花 100 个人日做这件事，现在还要再花 50 个人日才能保证下次出了问题能自动恢复。但对于业务系统，可能只要投入 5 个人日加个监控加个补偿就可以了，这个时候就他们做。

为什么我要讲故障的事情，因为现在你是一线的主管，团队出了问题你要兜着，要去保护你的团队。要想一想，出了问题之后，你不应该冲在第一线去跟别人 PK，有更重要的事在等着你。

最后感谢一下指导我走上正轨的那些前辈，一直支持我的团队成员，那些曾经被我坑过、跟我 PK 过、让我有这些感触的人，还有得到 APP 的几位老师，有的时候你不光要去关注技术的事情，非技术的事情也要学，比如经济学、商学院的课程学一些，有一天他们会成为你管理理念的一部分。