技术管理案例课_05_04_避坑指南从技术骨干到一线经理你会遇到哪些坑
你好，我是徐建。
今天我们来聊聊技术骨干转型经理那些坑技术骨干在转型经理之前啊，一般都是部门里专业能力很强的那一类人。
他转型经理之后呢，我们的思维就不能只关注于事了，我下时开始关注事和人。
而这里面更关键的，其实是人，因为所有的事都需要人来完成。
而作为经理呢，更多的是通过培养人和激励人，从而提升团队做事的效果。
那到底什么叫关注事？什么叫关注人呢？我下面给你举几个例子，你一看就能明白了。
首先我来看这样一个例子，因为我们关注事，我们就会想，这件事我怎么干呢？那如果从关注人的角度来看，我们就会想这件事让谁来干更合适呢？因为我给你说另外一个例子，如果我们关注事，我就会想小王，你这个方案不够好，应该用方案b相应的。
如果关注人我就会想小王能够主动提方案，a很好在承受范围之内呢，哪怕a有些瑕疵，我也应该让他尝试，因为我要培养他的记忆信啊，接下来继续这么思考。
如果我们关注事想的就是我们要交付业务价值。
那如果我们转换到关注人我就会想到我们要提高团队成员的能力。
我把刚才说的例子总结成了一张图，给你放在文稿里了。
你可以想一想。
好了，我们回到正题，说到这里，不知道你有什么感受。
我的感受就是从关注事到关注人这两个角度真的完全不一样的。
刚刚我给你讲了，关注事和关注人的不同。
因此在这个转型境理的过程中，我们很容易出现一些问题。
那都有什么问题呢？我根据过往的经验，把这些问题按照难度递增，整理成了六大类。
这些问题分别是管的太细、大包大揽、迷信流程、刷存在感，不能聚焦和不会说。
你可以想想，你是不是也遇到过这些问题呢？接下来我给你逐一做讲解。
第一个坑就是管的太细。
我估计很多人见过这样的情况的管的太细。
典型的做法是，要么给部下制定出非常详细的解决问题细则，而不是给部下提出问题，让他自己拿方案，要么就是不停的去盯部下的进度和要求。
部下汇报工作，不等部下自己去思考和做事。
你就先给一堆意见，请你注意啊，这样做的坏处很明显，部下会觉得自己没有自由度，没有发挥空间。
而且呢这样做最大的问题是有些部下会觉得领导你不够信任我，觉得我没有能力自己解决问题。
我这里拿我给部下交代任务的故事给你。
举个例子，你可以体会一下下面两种沟通方式的区别。
我们先来看方式一小王，你能把性能测试和时效性分析做一下吗？准备三个客户端，给我加十倍流量，另外给我挨个给每台机器断网，再给我做网络延迟模拟。
我每天都要季度报告方式。
二老王啊，最近我们上线的模块性能发现问题，而且发现在网络不稳定的情况下，行为异常。
你觉得我们应该采取哪些举措来解决当前的问题呢？另外我还需要你帮我给一下他的。
所以我可以系统性的避免类似情况的发生。
怎么样？你发现这两种沟通方式的区别了吗？人的本性都是要自由，要我的地盘我做主。
因此，我们要注意他们对自己话语权威性的追求，人对自己是一个靠得住的人的自我认可。
其实说到底啊，这个核心就是要从只关注交付结果，转变成关注交付结果的同时，也要满足人的需求。
我就踩过一次这样的坑，一次我的一个部下b跟我说，他想做一套系统一动。
排查搜索集群机器的健康状况。
因为他觉得这样能大幅提高排查效率，提高可用机器的数量。
当时呢我是这么回复他的，我说你知道g在通用集群上也在做同样的事情吗？我觉得你可以先去看看g是怎么做的，然后给我看一下你的设计，再开始执行。
我后来才知道啊，咪在跟我谈后有点受打击，他觉得他自己是有自己做事的方式的。
我让他去跟技学，好像是在表达他不如技，而且我一定要先看他的设计，然后他才可以执行，就信不过他的微观能力。
你可以想一想自己是否陷入微观管理呢？如果是的话，你就要考虑自己为什么会微观管理呢？是因为你太关注部下做事方式是不是符合你的要求，还是因为你享受那种指挥人干这干那的感觉。
我想和你说的是，只有挖掘到你做微观管理的原因，才能从根本上解决问题。
而为你不再是掌握了一些技巧，而是从更深的层面把自己给分析透了。
第二个坑是大包大揽，这一点很容易理解，与其等他来做我自己，早就做完了。
这句话听起来是不是很熟悉啊，会说这种话的经历呢都有一个共同的特点，那就是这个经理的个人能力很强。
才你以外人的角度看，他的团队是只看得到他，看不到他的成员的。
一旦他休假，他的团队就不知道干什么了。
我给你举个现实中的例子吗？老徐是一位经理，他的下属小熊说自己对下一代流量管理项目感兴趣，所以想参与总部领导的这个项目。
但是流量管理是个高风险项目，弄不好就会影响业务可用性。
而小熊说这件事，两个礼拜就能搞完了。
于徐一直很担心会出线上事故，于是就去跟总部的经理打招性，说小熊太乐观了，我建议老徐就让小熊自己去处理。
他说两周就两周，老徐还是担心说你只能出生产事故吧。
如果你遇到类似似情况，应该怎么做呢？我的建议就是要不你不要把这件事情交给下属周，要么你就跟他说清楚他的责任，然后让他全权负责。
其实啊对于我们做经理来说，下属不吃点亏长大的。
我们要注意的是，这个亏必须是我们这个部门所能承受的。
我们公司在做一线经理培训的时候，搞过一个模拟经理员工对话，目的是暴露一线经理日常工作中的常犯的错误。
洪峰各个总监那里啊收集他们部门经历过的一些棘手的问题，作为素材，把事件中敏感信息改造好，写成案例。
首先呢我们会给一线经理十分钟阅读案例，然后由总监扮演一个刺头员工，该经理扮演该刺头员工的经历，模拟他们俩单独谈工作来解决这个案例里面的问题。
这时候呢刺头员工会找各种理由说，这个案例里的事情很难很棘手。
我们发现现不经经理在这个程程都会犯大包大大的错误，在模拟对话完成后，自己领了一大堆任务。
你要知道，这是对对例作为经理，你一定要提升自己的感感强度度，这名员工需需要完成的工作安排下去。
不然的话，你就在剥夺夺员工工长锻炼机会。
第三个坑呢就是迷信流程。
很多老板对组织效率不满意的时候啊，就引引敏敏捷发模式、OKK模模式者、阿阿巴模式等各各模式。
我一直认为啊你希望通过引入一一个程程能能大幅提升组织效率的想法是不可的的，如果流程就能解决问题，那还需要经理干什么呢？我们要想提高组织矛盾，不脱两层皮，付出点代价是不可能的。
我们真正的难点在怎么原因怎么拿捏流程，不能处理的的根本情况。
如果想想把人用好，首先就要了解这个人。
你知道你的每个部下擅长做什么，不擅长做什么吗？他在乎什么又反感什么吗？谁和谁搭配能够形成互补呢？这都是需要你长期进行积累和挖掘的。
我给你举个常见的例子吧，但些侧人员工技术水平很高的，但是跟人相处老容易产生矛盾。
你能靠流程解决这个问题吗？我们能做的就是去挖掘他容易跟人产生矛盾的根本原因。
但是呢即使你能挖出原因，这个侧头不经过阵痛，不能够改正的机会不大的。
即使能够成长到很高很高的人大多都三十出头了，你能指望一两次对话就能彻底改变一个人前三十年的行为模式吗？我不是说改不了，但是我想提醒你，想做到这一点，你要付出的成本很大。
作为一个经理，你与其花大力气去把这个人熬成你希望的样子，他不是专注在怎么用好他的长处，他不是技术很好吗？但是跟人相处不行吗？那么你就可以安排那种技术难度很大，但是又不需要很多沟通交流的工作给他。
我们再来说说这第四个坑就是刷存在感。
请你注意哦，刷存在感和大包大脑里面提到的，你别的团队只看到经理是不一样的。
你能明显感受到大包大揽的经理对团队提供额外的价值，他对团队是有推动感的，但是刷存在感的经历却不一样。
你会发现他们在邮件和会议里频繁出现，可是却没有什么有价值的意见。
他们的邮件忘了，是这样的，他王你做的不错，great job,我来做一个会议。
总结上级领导安排任务以后，他做任务在团队里的转发啊，很少发表对项目和人员安排的独立见解。
这样的经理，其实每天也挺忙的，他分配工作也鼓励团队成员，但是他不能促进团队达到更高阶段。
你作为上级经理，很少看到他有真知灼见，很少看到他做关键性决策。
我认为啊这样的经历每天的工作就是刷存在感。
虽然他不是有意刷存在感，但事情的本质就是这个样子的。
其实随便找一个情商不低的人来做经理，也可以达到他的水平。
当然不是说你刚从技术骨干转岗到经理，就要马上要有进之卓见，能做关键决策，这也不现实的。
我是建议啊，你可以在开始的时候先韬光养晦一段时间。
但是你必须问自己，为什么团队需要你来做经理，你能给团队提供什么额外的价值？你对于你所管理的团队有推动感吗？请你注意啊。
还有一种更高层次的刷存在感。
这样的经理对日常工作中的事情是有独立见解的，也能做关键决策，促进一些事情的解决。
但是他们没有长期目标，更不要说制定为了达到长期目标的阶段性举措了。
我给你举个例子吧，我就看到我们有团队，每个季度都要花很多时间来制定季度目标。
那他们为什么每一个季度都要花这么多时间来做目标呢？就是因为没有坚定的长期目标，每次都只往前看一个季度，就就会有种看上去去很，但是是天刷刷存在感的感觉。
如果你有长期目标，这目标不应该轻易改变的，需要每个季度都花这么多时间做计划吗？我多数情况是根本就没有明确的长期目标。
说的难听点就是用战术上的勤奋掩盖战略上的难度。
第五个坑就是不能聚焦。
我自己在转岗经历一段时间之后啊，就犯过不能聚焦的错误。
我管理了一个有三个项目的团队，而且我把时间平均分配到这三个项目上，结果就是我在这三个项目上起的作用，就是前面说的刷存在感。
当时的我没有主建和启动项目的能力。
于是呢每一个项目做完以后，我都会跟美国的主管谈下一个项目是什么呢？现在想起来，我当时就跟一个包工头差不多，一旦我手下有空余的工人，简想着很快把这个工人派到新的工地上去干活，直到我成长了一些。
而于有了一些个人的主见，要做云计算的可靠性，并且想到了要自己来主导做这个项目，但却发现自己手上的人都已经派到别的工地去了。
别看我管了十几号人，其实我能分配到可靠性项目项的人只有两个。
既然是让我知道了，要做成一件事情，你就必须聚焦。
那怎么判断你现在有没有真的做到聚焦呢？简单说，就是你得有一个且只有一个目标。
你可以想想看，你有没有每天都在想怎么把这件事情做好，是不是你每天起床就在想怎么做，每天睡觉前也在想怎么做呢？其实啊人的精力是有限的，你同时搞几件事情，基本上你就只能做到平常的水平，很难做出精品呢。
而做一个精品的效果要远好于你去做一堆品用的产品。
我这里说有且只有一个目标，那么你可能会问了，如果我负责部门有好几个项目怎么办呢？那么我要告诉你的是，如果你作为主管经理，你同一个时间也有好几个项目，你的主要精力只能放在其中一个项目上，绝对不要平均分配时间。
我是最终通过云计算可靠性这个契机，把自己团队全部集中在可靠性这个方向上面的。
若干年后的今天，我们已经正式成立了云计算的seattle liability engineering团队。
为了方便我下面都简称cloud SRE团队。
当时我是这么想的，我们cloud SRE团队在第三季度最重要的目标是什么呢？如果说是改进云计算的监控效果，那我们cloud SRE的绝大多数上面是投入在改善监控效果上吗？我觉得不是，那既然不是我真的不觉得我们能做好。
如果我们在第三季度的目标不是改善监控，那么要谈在在云一项目目标是我要求。
无论论什么目标，标oud SSE最主要的执行力必须在这个目标上。
如果不能聚焦，就是有具体的困难，有困难就一定要提出来。
现实中啊有些困难是一线经理要去克服的，有些困难是需要更高一级的经理要去处理的。
如果你只会跟部下提要求，又不处理部下的要求，那么你跟我前文所说的那个缺乏存在感的经理又有什么区别呢？第六个常见的坑就是不会说部最典型的不会说部的经理就是只会家里恨，碰到别的部门领导，或者碰到自己的直属领导都认怂。
结果就是你的部下对你很失望，你在有能力的领导心目当中，位置也不会高到哪里去的。
下面我就用两个例子给你讲讲。
我为什么这么说？这里呢我先给你设置一个情景，假设你有个兄弟部门的服务，构建在你部门的服务之上。
有一天啊，兄弟部门的服务出问题了，客户投诉到兄弟部门。
但实际情况往往是这样的，两个部门的服务都有一些问题。
这时候呢兄弟部门咬死的是你部门的责题，作为经理的，你就要去跟兄弟部门来交涉。
你如果一味的说都是自己部门的责任，你的部下自然会对你非常失望。
我和你说啊，要解决这个情景还是比较简单的，你只要有理有据，采用不夸大不缩小的策略就可以了。
接下来我再给你讲一个难一点的情景的两个兄弟部门都来找你支持他们。
都说他们的要求很低，对业务很重要，并且要求你给出具体的交付时间。
然后呢，你给了时间以后呢，他们都不满意，还质问你为什么要这么久啊？某部门甚至会要求你把打算分配给他们部门做支持的工程师呢，直接交给他们管理，这样他就可以在规定时间内完成任务了。
这时候你会怎么做呢？如果你不会说，不就只能迫使自己的工程师加班，才能满足两个兄弟部门的要求。
对于这种情况，我建议你要做好基于数据的分析，拿着具体的数据去跟两个部门谈交付时间。
请你注意，对于把人交给其他部门的这种要求，我不认为这是有利于部门合作的做法，但是你可以要求兄弟部门把他们准备怎么在不降低交付质量前提下压缩交付时间的细节给自己讲一下。
如果两个兄弟部门因为竞争资源不可调和，那你就应该到更高级的老板了。
你一起定一下到底哪个优先级更高。
不仅是同事对于老板的要求啊，你也不能像奴才一样，什么都点头。
如果你不是很赞同老板交代的任务，你不要马上说我就去干，也不能直接说我不干。
我的建议是你要问老板问题来获取更多的信息。
比如说你可以问老板，我们为什么要做这件事？你的具体期待是什么样的？我现在碰到的具体的困难是这样的，如果你一定要做a在不增加人手的情况下，我现在手头的b项目可能会受影响的。
你要让老板感受到，你需要独立思考的人，不是一个奴才部下，同时还要表明你正在积极寻找解决问题的方法。
好了，今天的内容讲完了，我给你做个总结吧。
首先，微观管理和大包大揽是技术骨干转型经理后最常见的问题。
其本质啊都是太关注于事情的交付，而忽略人的发展。
你要记住的是，经理是通过提高部下的能力来更好的完成任务的。
很多人做了经理以后，一般都希望很快发现组织问题，并且采取措施来解决这些问题。
他采取的措施往老师引入一些流程，但你千万不要迷信这些流程，哪有那么简单的事情呢？你还是要关注人本身，所有的问题，最终都是人的问题。
多琢磨琢磨，你的团队成员本身不要傲姿势，而应该因材施教。
接下来呢你就要开始审视自己，看看自己有没有对自己的团队有推动感，自己有没有用战术上的勤奋掩盖战略上的懒惰。
就算你想清楚了自己团队的价值和目标，你真的聚焦了吗？伤其实指不如断其一指的道理你懂吗？最后兵熊熊一个将熊熊一窝不单单对于兄弟部门，对于老板，你也不能唯唯诺诺的做奴才不下话要说的客气。
但是你的原则不能动摇，逻辑必须清晰。
在本节的最后呢，我给你留一个思考题。
我们公司领导说高度重视开发效率，有个专门的部门负责开发效率，他们制定了完善的开发流程，甚至把流程中的关键点，比如云内test、 coverage、测试、approval流程、CICD等等，都做了开发流程，还制作了十五强发布每一个组织的bug数量。
但是我们公司的业务部门仍然不断抱怨，开发效率不高，你怎么看部门的这些流程呢？如果是你来负责开发效率这件事情，你准备怎么处理呢？另外，请你思考这一节中说的六类问题，另系自己日常的工作。
就每一个主题自己找一个例子，并且描述一下出现这个问题的根本原因是什么。
欢迎在留言区晒出你在管理路上遇到的各种坑。
如果你的朋友也遇到类似文章中提到的这些问题，也欢迎你把文章分享给他，也e就能帮他解决这样的问题了。