04 避坑指南：从技术骨干到一线经理，你会遇到哪些坑？
你好，我是许健。今天我们来聊聊技术骨干转型经理那些坑。
技术骨干在转型经理之前，一般都是部门里专业能力很强的那类人。但转型经理后，我们的思维就不能只关注于事，要同时开始关注事和人，而这里面更关键的其实是人。因为所有的事儿都需要人来完成，而经理更多的是通过培养人和激励人，从而提升团队做事儿的效果。那到底什么叫“关注事”，什么叫关注“人”呢？我下面给你举几个例子，你一看就能明白了。
例子1：
- 关注事：这件事我怎么干？
- 关注人：这件事让谁干最合适？
例子2：
- 关注事：小王你这个方案A不够好，应该用方案B。
- 关注人：小王能够主动提方案A很好，在承受范围内哪怕A有些瑕疵也让他尝试，我要培养他的积极性。
例子3：
- 关注事：我们要交付业务价值。
- 关注人：我们要提高团队成员的能力。
我把刚才说的例子，总结成了一张图给你放在下面了。
从“关注事”到“关注人”，这两个真的是完全不一样的思考角度。因此，在这个转型经理的过程中，我们很容易出现一些问题。都有什么问题呢？我根据过往的经验，把这些问题按照难度递增，整理成了6大类，分别是管得太细、大包大揽、迷信流程、刷存在感、不能聚焦和不会说不。
你可以想一想，你是不是也遇到过这些问题呢？接下来，我们来逐一讲解。
坑1：管得太细
管得太细，我估计很多人都见过这样的情况。典型的管得太细的做法一般是：要么给部下制定出特别详细的解决问题细则，而不是给部下提出问题让他自己拿方案，要么就是不停地去盯部下的进度和要求部下汇报工作，不等部下自己去思考和做事就先给一堆意见。
这样做的坏处很明显，部下会觉得自己没有自由度，没有发挥空间。而且，这样做最大的问题是，有些部下会觉得，领导你不够信任我，觉得我没有能力自己解决问题。
我这里拿给部下交待任务的故事给你举个例子，你可以体会一下下面两种沟通方式的区别。
方式一：小王，你能把性能测试和失效性分析做一下吗？准备三个客户端给我加10倍流量，另外给我挨个给每一台机器断网，再给我做网络延迟模拟，我每天都要进度报告。
方式二：老王，最近我们上线的模块性能发现问题，并且发现在网络不稳定的情况下行为异常，你觉得我们应该采取哪些举措来解决当前的问题，我还需要你帮助给一下意见，最好可以系统性地避免类似情况的发生。
怎么样，你发现这两种沟通方式的区别了吗？
人的本性是都要自由，要我的地盘我做主。因此，我们要注意他们对自己话语权威性的追求和对自己是一个靠得住的人的自我认可。说到底，这个核心就是要从只关注交付结果，转变成关注交付结果的同时也要满足人的需求，
我就踩过一次这样的坑。一次我的一个部下V跟我说，他想做一套系统，自动排查搜索集群机器的健康情况，因为他觉得这样能大幅提高排查效率，提高可用机器的数量。
当时，我是这么回复的：“你知道G在通用集群上也在做同样的事情吗？我觉得你可以先去看看G是怎么做的，然后给我看一下你的设计再开始执行。”
我后来才知道，V在跟我谈后有点受打击，他觉得他自己有自己的做事方式，我让他去跟G学，好像是在表达“他不如G”。而且，我一定要看他的设计后，然后他才可以执行，就是信不过他的设计能力。
你可以想一想，自己是否陷进了微观管理？
如果是，你就要考虑自己为什么会微观管理？是因为你太关注部下的做事方式是不是符合你的要求？还是因为你享受那种指挥人干这干那的感觉？只有挖掘到你做微观管理的原因，才能从根本上解决问题。因为你不再是掌握了一些技巧，而是从更深的层面把自己分析透了。
坑2：大包大揽
大包大揽这一点很容易理解。
“与其等他来做，我自己早就做完了”，这句话听起来是不是很熟悉。会说这种话的经理都有一个共同的特点，那就是个人能力很强。当你以外人的角度看他的团队时，只看得到他，看不到他的成员。一旦他休假，他的团队就不知道要干什么了。
我给你举个现实中的例子。老徐是一位经理，他的下属小雄说自己对下一代流量管理项目感兴趣，所以想参与总部领导的该项目。但是流量管理是个高风险项目，弄不好就会影响业务可用性，而小雄说这件事2个礼拜就能做完。老徐一直很担心会出线上事故，于是去跟总部的项目主管打招呼，说小雄太乐观了。我建议老徐就让小雄自己去处理，他说2周就2周。老徐还是担心，你等着出上线事故吧。
如果你遇到了类似的情况，我的建议就是：要么你不要把这件事交给下属做，要么你就跟他说清楚他的责任，然后让他全权负责。对于我们做经理的来说，下属不吃点亏是长不大的。我们要注意的是，这个“亏”必须是我们这个部门能承受的。
我们公司在做一线经理培训的时候搞过一个模拟经理员工对话，目的是暴露一线经理日常工作中常犯的错误。
我们从各个总监那里收集他们部门经历过的一些棘手的问题作为素材，把事情中的敏感信息改造后写成案例。给一线经理10分钟阅读案例，然后由总监扮演一个刺头员工，该经理扮演该刺头员工的经理，模拟他们俩单独谈工作，来解决这个案例里面的问题。刺头员工会找各种理由说这个案例里的事情很难、很棘手。
不少经理在这个过程中都会犯“大包大揽”的错误，在模拟对话完成后自己领了一大堆任务。这是不对的，作为经理，你一定要提升自己的感情强度，把该员工需要完成的工作安排下去。不然你就是在剥夺该员工的成长锻炼机会。
坑3：迷信流程
很多老板对组织效率不满意的时候，会引入敏捷开发模式、OKR模式，或者阿米巴模式等各种模式。我一直认为，希望通过引入一个流程，就大幅提升组织效率的想法是不现实的。如果流程就能解决问题，那还需要经理干什么呢？
要提高组织效率，不脱两层皮付出点代价是不可能的。我们真正的难点在于怎么用人，怎么拿捏流程不能处理的意外情况。
如果你想把人用好，首先就要了解这个人。你知道你的每个部下擅长做什么，不擅长做什么吗？他在乎什么，反感什么？谁和谁搭配能够形成互补？这都是需要你去进行长期积累和挖掘。
举个常见的例子吧，有些刺头技术水平很高，跟人相处很容易产生矛盾，你能靠流程解决这个问题吗？我们能做的，是去挖掘他容易跟人产生矛盾的原因。但即使你能挖出原因，这个刺头不经过“阵痛”就能够改正的机会不大。技术水平能够成长到很高的人，大多都30出头了，你能指望一两次对话就能彻底改变一个人前30年的行为模式吗？我不是说改不了，但是想做到这点，你要付出的成本很大。
作为一个经理，你与其花大力气去把这个人拗成你希望的样子，还不如专注在怎么用好他的长处。他不是技术很好，但是跟人相处不行吗？那就安排那种技术难度很大，但是又不需要很多沟通交流的工作给他。
坑4：刷存在感
刷存在感和大包大揽里面提到的“让别的团队只看到经理”是不一样的。你能明显感受到大包大揽的经理对团队提供的额外价值，他对团队是有推动感的。
但是刷存在感的经理不一样，你会发现他们在邮件和会议里频繁出现，但是却没有什么有价值的意见。他们的邮件往往是这样的：
- 小王你做得不错，Great Job；
- 我来做一个会议总结；
- 上级领导安排了任务以后，他做任务在团队内的转发；
- 很少发表对项目和人员安排的独立见解。
这样的经理其实每天也挺忙的，他分配工作，也鼓励团队成员，但是他不能促进团队达到更高阶段，你作为上级经理很少看到他有真知灼见，很少看到他做关键决策。我认为这样的经理，每天的工作是在“刷存在感”，虽然他不是有意在刷存在感，但是事情的本质就是这样，其实随便找一个情商不低的人来做经理，也可以达到他的水平。
当然，我不是说你刚从技术骨干转岗到经理就要马上有真知灼见，能做关键决策，这不现实。我建议，你可以在开始的时候先韬光养晦一段时间，但是你必须问自己，为什么团队需要你来做经理，你给团队提供什么额外的价值，你对于你所管理的团队有推动感吗？
还有一种更高层次的“刷存在感”，这样的经理对日常工作中的事情是有独立见解的，也能做关键决策促进一些事情的解决，但是他们没有长期目标，更不要说制定为了达到长期目标的阶段性举措。
举个例子，我就看到我们有团队每一个季度都要花很多时间制定季度目标，他们为什么每一个季度都要花很多时间来做目标呢？就是因为没有坚定的长期目标，每次都只往前看一个季度。这就会有一种看上去很忙，但是在天天刷存在感的感觉。
如果你有长期目标，这样目标应该不会轻易改变的，需要每一个季度都花这么多时间做计划吗？大多数情况是根本就没有明确的长期目标，说得难听点，就是用战术上的勤奋掩盖战略上的懒惰。
坑5：不能聚焦
我自己在转岗经理一段时间之后，就犯过“不能聚焦”的错误。我管理了一个有3个项目（云计算的计算、存储和网络）的团队，而且我把时间平均分配在这三个项目上。结果就是，我在这三个项目上起的作用就是前面说的“刷存在感”。当时的我没有主见和能力启动项目，于是每一个项目做完以后就会去跟美国的主管谈，下一个项目是什么呢？
现在想起来，我当时就跟一个包工头差不多，一旦我手下有空余的“工人”，就想着很快把这个“工人”派到新工地上去干活。直到我成长了一些，终于有了个人主见，要做云计算的可靠性，并且也想到了要自己主导来做这个项目，但却发现自己手上的人都已经“派到别的工地”去了。别看我管了十几号人，其实能分配到可靠性项目上的人手只有两个。
这件事让我知道了要做成一件事，你就必须聚焦。
那怎么判断你现在有没有真的做到聚焦呢？简单地说，就是你得有一个且只有一个目标，你可以想想，你有没有每天都在想怎么把这件事做好，是不是每天起床就在想怎么做，每天睡觉前也在想怎么做？
人的精力是有限的，你同时搞几件事，基本上也就只能做到平常的水平，很难做出精品。而做一个精品的效果要远好于做一堆平庸的产品。
我这里说有且只有一个目标，你很有可能会问：如果我负责的部门有好几个项目怎么办？那么我要告诉你的是：如果作为主管经理的你，在同一时间有好几个项目，你的主要精力只能放在其中一个项目上，绝对不要平均分配时间。
我是最终通过“云计算可靠性”这个契机把自己团队全部集中到可靠性这个方向上，若干年后的今天，我们已经正式成立了云计算的SRE团队。当时我是这么想的：
我们Cloud SRE（Site Reliability Engineering）团队在第三季度的最重要的目标是什么？如果说是改进云计算监控效果，那我们Cloud SRE的绝大多数力量是投入在改善监控效果上吗？
我觉得不是，当时我们最多只有40%的人力投入到这里。既然不是，我真的不觉得我们能做好。如果我们在第三季度的目标不是改善监控，那我们要定一个别的目标，但是我要求无论是什么目标，Cloud SRE的最主要的执行力必须在这个目标上。
如果不能聚焦，就是有具体的困难，有困难就要提出来。现实中，有些困难是一线经理要去克服的，有些困难是更高一级经理要去处理的。如果你只会跟部下提要求，又不处理部下的要求，那你和前文说的那个“刷存在感”的经理又有什么区别呢？
坑6：不会说不
最典型的不会说不的经理就是只会家里横，碰到别的部门领导，或者碰到自己的直属领导都认怂。结果就是你的部下对你很失望，你在有能力的领导心目中的位置也不会高到哪里去。
下面我用两个例子来给你讲讲我为什么这么说。这里，我给你设置一个情景，假设你有个兄弟部门的服务构建在你部门的服务之上。有一天，兄弟部门的服务出问题了，客户投诉到兄弟部门，但实际情况是，两个部门的服务都有一些问题。这时兄弟部门咬死了是你部门的问题，作为经理的你就要去跟兄弟部门交涉。你如果一味地说都是自己部门的责任，你的部下自然会对你非常失望。
要解决这个情景还是比较简单的，你只要有理有据，采用“不夸大，不缩小”的策略就可以了。接下来，我再讲个难一点的情景。
两个兄弟部门都来找你支持，他们都说他们的要求很急，对业务很重要，并且要求你给具体的交付时间，你给了时间以后，他们都不满意，质问你为什么要这么久。某部门甚至会要求你把打算分配给他们部门做支持的工程师直接交给他们管理，这样他就可以在他规定的时间完成业务。
这时候你怎么做？如果你不会说不，就只能迫使自己的工程师加班来满足两个兄弟部门的要求。
对于这种情况，我建议你做好基于数据的分析，拿着具体的数据去跟两个部门谈交付时间。对于把人交给其他部门的要求，我不认为这是有利于部门合作的做法。但是，你可以要求兄弟部门把他们准备“怎么在不降低交付质量的前提下，压缩交付时间”的细节给自己讲一下。如果两个兄弟部门因为争夺资源不可调和，那你就到更高一级老板那里，一起定一下到底哪个优先级更高。
不仅是同事，对于老板的要求，你也不能像奴才一样什么都点头。如果你不是很赞同老板交待的任务，你不要马上说我去干，也不能直接说我不干，我的建议是你要问老板问题以获取更多信息。比如，你可以问老板：我们为什么要做这件事？你的具体期待是什么样的？我现在碰到的具体困难是这样的，如果你一定要做A，在不增加人手的情况下，我现在手头的B项目会受影响。
你要让老板感受到你是有独立思考的人，不是一个奴才部下，同时还要表明你正在积极寻找解决问题的方法。
总结
微观管理和大包大揽是技术骨干转经理后最常见的问题，其本质都是太关注于事情的交付而忽略人的发展，你要记住的是经理是通过提高部下的能力，来更好地完成任务。
很多人做了经理以后，一般都希望很快发现组织问题，并且采取措施来解决这些问题，而采取的措施往往是引入一些流程。但你千万不要迷信这些流程，哪有这么简单的事情？还是要关注人本身，所有的问题最终都是人的问题，多琢磨琢磨你的团队成员本身，不要拗姿势，而应该因材施教。
接下来，你就要审视自己，看看自己有没有对自己的团队有推动感，自己有没有用战术上的勤奋掩盖战略上的懒惰？就算你想清楚了自己团队的价值和目标，你真的聚焦了吗？伤其十指不如断其一指的道理你懂吗？
最后，“兵熊熊一个，将熊熊一窝”，不单单对于兄弟部门，对于老板你也不能唯唯诺诺地做奴才部下。话要说得客气，但是你的原则不能动摇，逻辑必须清晰。
思考题
我们公司领导说高度重视开发效率，有一个专门的部门负责开发效率，他们制定了完善的开发流程，甚至把流程中的关键点比如Unit test Coverage、测试Approval流程、CICD等都做进了开发流程，还制作了耻辱墙发布每一个组织的BUG数量。
但是我们公司的业务开发部门仍然不停抱怨开发效率不高，你怎么看部门的这些流程？如果是你来负责开发效率这个事情，你准备怎么处理？
请你思考这一节课中说的6类问题，联系自己日常的工作，就每一个主题自己找一个例子，并且描述一下出现这个问题的根本原因是什么。
欢迎在留言区晒出你在管理路上遇到的各种“坑”。如果你的朋友也遇到了类似文章中提到的这些问题，也欢迎你把这篇文章分享给他，也许就能帮他解决这样的问题了。
- 阿斌 👍（15） 💬（3）
你好，听了几节课深有感触，我也是去年三月才开始从技术转岗主管职位，目前也不做技术开发了，专做项目分配和协调，进度跟进。当前遇到两个问题需要请教一下老师：1 我今年30就转岗做管理了，而且目前公司技术组就十个人，做微商主营业务，我不知道自己以后的定位是怎么样，假如从这里离职了，我该怎么样找到自身价值，还有就是该找什么岗位去面试，面技术还是面管理呢，目前市场是否有这样的岗位呢。 2 当前公司技术组基本上都是我这边组建起来的，目前也一年了，大家纷纷提议加工资，但是我反馈到老板那边，公司就说需要什么考核来进行是否提薪，但是这个考核目前还是刚实行（试行期），于公司而言，我希望这帮兄弟明年继续在这里（毕竟也为公司付出了很多业务从0到1），于兄弟而言，我也希望他们得到应有的回报，能力在这一年有提升，也应该得到加薪。希望老师能帮我解答解答，万分感谢！
2020-09-12 - Geek_积木 👍（13） 💬（1）
为了提升研发效率，从而加入流程优化，出发点是好的。但是，过程方法不正确，应该是通过度量指标来反馈研发流程，看效能瓶颈在哪里，再优化流程，再看反馈结果，而不应该简单的当做考核指标，最终导致本末倒置，既加重工作量压力，也没达到效率提升的目的
2021-09-14 - 此方彼方Francis 👍（10） 💬（3）
管的太细那个章节里，V的那个例子我不是很认同。 1. V也太玻璃心了吧，让他去了解一下G做的事情，就这么委屈？如果V和G的想法基本一致，那么V是不是可以不用新做一套系统了？至少，了解了G的设计之后，是不是V也可以对自己的设计查漏补缺？ 2. 属下要做一个系统，领导要求review设计方案这样不是很正常吗？如果大的设计方案都不做了解，时间长了这领导还怎么把握自己部门的事情，关键决策做的出来吗？
2020-08-31 - IT男_愚人 👍（6） 💬（1）
老师您好，我刚走上管理岗位不久，性格确实有点老好人，不管是下属，还是上级领导，都不太会拒绝人。但是同时特别别扭的对待自己人(自己带进团队的兄弟)，要求又有点苛刻，甚至是说话语气，作息时间，跟客户聊天神情，跟其他领导相处方式，什么都想给他提意见作纠正(没有行动，只是心里很想这么做），请问您当初有没有这么个经历？有什么方法去转变这种莫名其妙的心理呢？
2020-09-05 - 难得糊涂 👍（3） 💬（0）
老师，您好。我是一名RN/Flutter开发人员，因为一些原因(可能是项目管理做的好)，我现在是一条业务线的技术负责人，团队有10人(包含App、前端、测试、后端)。 其他业务线的技术负责人都是后端高P(我本人对后端可以说是没有一点基础)，现在感觉有些惶恐，原因在于：在后端这一块能力十分欠缺，而且领导也不止一次提到我们需要一个后端高P。我想请教的问题是：关于技术这一块我该何去何从，有必要从0学后端么，即使学，需要学到什么程度呢。
2021-10-11 - Focused 👍（3） 💬（5）
本节课总结： 1、关注事与关注人的不同出发点； 2、前5个坑都是向下管理过程中，会不断遇到的挑战： 1）刚转型经理，还是站在关注事的角度，进入了微观管理，团队成员无法得到锻炼，不利于团队成长； 2）大包大揽的问题，还是没有把自己转换到管理角色，没有意识到去解决人的问题； 3）迷信流程，任何流程都有适用场景，各有利弊，重要的是找到适合自己团队的那一部分，剩下的还是需要自定义； 4）刷存在感，实际上是没有找到自己的定位，不清楚自己的核心价值； 5）不能聚焦，没有找到团队的核心竞争力； 第六个坑，是向上管理和跨部门同级管理中容易出现的问题，需要保持独立思考的能力，明确自己的原则，坚持住自己的原则。 ----------------------------------- 问题1： 在文章“坑2：大包大揽”的最后，“作为经理，你一定要提升自己的感情强度”，这里的“感情强度”不是很理解，具体能再解释下吗？ 问题2： 遇到技术问题，团队搞不定，经理也没有相关经验，这种情况下，经理该如何面对？ 希望许健老师能释疑，不胜感激！
2020-08-29 - Xunqf 👍（3） 💬（1）
我觉得这个“负责开发效率”部门的思考方向应该改变一下，为了达到提高效率的目的，他们不应该是给其他部门设置条条框框，而是应该了解其他部门遇到的问题，怎么帮其他部门快速的解决这些问题。
2020-08-28 - 我能走多远 👍（2） 💬（1）
总结刚换工作，工作就遇到了小组组长也是刚上任不到三个月。着急把项目做出来，不考虑技术框架（我们是对开源项目进行二次开发）。不使用现有开源的底层库，而总是自己造轮子，导致小组内另一个老员工很大意见。最终老员工和cto聊天，经常说不想在组长项目下做事情，说了很多组长的坏话。最终这个组长也被裁掉。
2020-10-19 - 小柒 👍（1） 💬（1）
> 技术骨干在转型经理之前，一般都是部门里专业能力很强的那类人。但转型经理后，我们的思维就不能只关注于事，要**同时开始关注事和人**，而**这里面更关键的其实是人**。 误区： - 管得太细：安排任务事无巨细，会影响别人的自由度和发挥空间。 - 大包大揽：因为自己能比别人做得好或者做得快而包揽了一大堆任务，压缩了别人的试错机会、锻炼机会和成长空间。**经理是通过提高部下的能力，来更好地完成任务。** - 迷信流程：敏捷开发、OKR等流程是辅助工作的工具，不是解决问题的手段。最关键的人的问题大都要通过人与人之间的真诚沟通来解决。所有的问题最终都是人的问题，**因材施教**，学会**通过培养人来做成事**。 - 刷存在感：减少无意义的频繁露面，多做**长期规划**和**关键决策**。 - 不能聚焦：同一时间内**有且只有一个目标**，聚焦精力做成一件事。伤其十指不如断其一指。 - 不会说不：敢于拒绝上级或者合作部门的无理要求，为同事争取合理权益。“兵熊熊一个，将熊熊一窝”。
2022-07-02 - quietwater 👍（1） 💬（1）
大公司都有很多流程，原因我想应该是通过流程规范一些问题的处理。流程的好处是可以提高处理问题的下限，能力差的人通过流程也可以比较好的处理问题。坏处是限制了处理问题的上线，能力强的人是可以打破流程，以更高效的方式解决问题。流程也是有两面性的，需要考虑公司，团队，人员等多角度来判断采用什么样的流程来更好的规范一些行为，减少沟通成本。没有绝对的标准，但大多数情况下，制定实施流程的人因为能力不足，视野不开阔，认知水平低而推出一些不合适的流程。
2022-04-06 - 聪 👍（1） 💬（3）
有个道理是，每个组情况都不一样，因为每个组里的人背景是不同的。所以不能去横向比较。弄个bug墙更傻了，这样大家都会很小心，导致开发效率低下。或者大家都努力去消除bug，对项目本身的难点和进度，就会造成或多或少的忽略。因为大家觉得每个组减少了bug变成了绩效指标。本末倒置
2020-10-05 - 青苹果 👍（1） 💬（1）
迷信流程这一块真得说到我心上去了。公司之前推Agile，落到具体之处就是，一大堆的线上表格要填，每次改动上线要过一大堆评审会，需要很多不同的人sign off，结果就是团队走流程的时间比做事的时间还多，大家不愿意及时快速上小的change，都堆在一起过会，实际审批的人其实也也不想看，也看不懂你们做了啥…一切流于形式。流程是辅助你更好管理的工具，而经理是主观能动性，没有主观能动性的流程就是自我欺骗…这也是管理者不可或缺的原因吧。否则流程很容易抄，为啥还有管得好，管的不好的区别呢？
2020-09-04 - 邱帅 👍（1） 💬（2）
老师您好，目前我就是刚从技术转到项目经理职位，听了您的课程，我总结了一下目前我遇到的问题，请问我如何面对周围环境氛围不好，工作任务重压力大，加班严重等相关问题
2020-08-29 - 伊诺 👍（0） 💬（1）
你有没有每天都在想怎么把这件事做好，是不是每天起床就在想怎么做，每天睡觉前也在想怎么做？ 整天晚上想的就是怎么赚钱
2023-03-22 - nero 👍（0） 💬（1）
首先，感谢老师的精彩分享，针对课后思考题，做以下阐述 1.在引入流程之前，是否有进行过根因分析和实际调查很重要，是真的有效能问题，还是领导视角的单方面意见，有待考察。 2.任何流程的引入都会增加成本去维护相应的数据和拖慢事宜交付，在上有流程政策的情况下，是否会发生“下有对策”。甚至激发各个业务研发小组不满的声音。 3.流程维护增加了时间成本支出，那么是否意味着要计划中给相关产研同学做相应减负。占用的工时可以减少其他产出吗？不满的小组经理是否有勇气对领导说不？ 最后，个人认为，效能问题与市场问题相同。是否引入流程不重要，快速反馈快速做出调整才是最关键的,引入流程只是可能的方案之一。 感谢老师批评指正！
2022-08-27