|
|
|
|
|
# 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类问题，联系自己日常的工作，就每一个主题自己找一个例子，并且描述一下出现这个问题的根本原因是什么。
|
|
|
|
|
|
|
|
|
|
|
|
欢迎在留言区晒出你在管理路上遇到的各种“坑”。如果你的朋友也遇到了类似文章中提到的这些问题，也欢迎你把这篇文章分享给他，也许就能帮他解决这样的问题了。
|
|
|
|
|
|
|
