gitbook/技术管理案例课/docs/286095.md
2022-09-03 22:05:03 +08:00

200 lines
21 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 12 | 进阶心路:不要轻易跨过一线经理,给员工安排工作!
你好,我是许健。从今天开始我们进入了一个全新的模块——二线经理。
二线经理顾名思义就是管理一线经理的经理,也就是手下管的是经理而不是一线员工。今天我就和你聊一聊进阶二线经理的心路历程。
那二线经理和一线经理到底有什么区别呢?这里有一个很大区别就是我们的能力要全面提高。在事务管理上二线经理需要有自己的**愿景**,并具备**在更大量的信息中抓住重点和深入分析**的能力;在人员管理方面,因为下属是一线经理,他们的成熟度和处理问题的能力相比一线员工要更好,所以留给二线经理处理的问题基本上都是**棘手难办**的问题了。
我们公司是有健全的一线经理培训体系的,但是却没有相应的二线经理培训体系,基本上晋升到二线经理就是直接扔到战场上,通过实战慢慢积累经验。
我自己在这条路上就出了问题,而且据我了解,这些问题都是我们进阶到二线经理后,高频发生的共性问题。解决一线经理不能搞定的问题,这样才能体现二线经理的价值。这句话听上去有点虚,所以接下来我分别从把事管好和把人理顺两个方面来跟你解释,二线经理相对于一线经理有什么不同。
## 把事管好
我们进阶二线经理,其实首先要转变的就是管事情的思路。把事管好,是二线经理的首要特质。
刚刚做二线经理,很容易出现越级指挥,跟进项目时流于表面,以及布置任务急于“亲自作战”的问题。
那我们应该怎样做才能把事情管好呢?**我们不仅要学会集权,更要学会授权;我们不仅要向上管理,更要下沉管理;我们不仅要处理任务,更要学会更好地布置任务。**
### **处理好授权和集权的关系**
作为一个二线经理,我们下面还有一线经理,这里要注意一个升为二线经理后的重大转变:你是通过管理一线经理来管理一线的员工,而不是直接管理一线员工。
如果我们总是越过一线经理,直接给员工安排工作,这就是大忌,为什么这样说呢?下面我给你分析一下。为了方便你理解,这里我们假设王总是直接给一线员工安排工作的二线经理。
**一线经理心里会怎么想?**
王总经常跨过我,给我的部下安排任务,那他要我干什么呢?他是不是觉得我跟他思路不一致?他是不是信不过我?
**一线员工心里会怎么想?**
奇怪,王总老是越过我的上级直接给我安排任务,那我的上级是不是在王总那里出了什么问题,如果王总跟我的上级给我分配的工作有冲突,那我到底该听谁的呢?这不是让我难做人嘛。
**上级领导心里会怎么想?**
我付你二线经理的钱,你却去干一线经理的活?你当二线经理,应该把一线经理培养起来,这样才能更好地提升整体团队效率。总之,你要去解决你的一线经理干不了、或者干起来效率不高的工作,比如有些跨团队的协作问题。
通过前面的分析,我们会发现作为二线经理的王总,越过一线经理直接安排一线员工的工作,会导致一线经理、一线员工和上级领导三个角色都心有不满。
我们去发掘这个误区的本质,其实是没有认清二线经理的定位,这个定位就是二线经理是通过一线经理管理团队,而不是直接管理团队,**我们必须让手下的一线经理有存在感并且受到鼓舞**。一线经理是有决策权的,而且他面对的问题的难度往往需要他带领团队才能解决,作为二线经理要支持和鼓励。
那我们认识到这个定位以后,还容易出现什么问题呢?没错,就是矫枉过正,一味去给一线经理授权,对一线团队的管理细节完全不关注。
二线经理千万不能觉得授权一线经理以后就可以放手不管了。这么做的风险是割裂了自己和一线员工还有一线技术骨干的关系,脱离一线业务,慢慢地把自己变成了一个人事经理,自己把自己做空了。
我刚升任二线经理时很迷茫,很不安,光是去参加下面几个一线团队的会议,就已经把时间消耗了大半。那时候被众多邮件“支配”的恐惧,我现在回忆起来还是历历在目。
光是把自己加到所有一线团队的邮件列表之后,邮件数就已经在爆炸式增长了,就算去掉监控报警邮件,每天的新邮件从几十增长到了数百,根本看不过来。面对种种压力,我感觉自己根本找不到着力点。
经历了不少起伏以后,后来我开始反思,得出的结论就是授权一线经理不等于不管不问,而是掌握二线经理的管理方法,原先一线经理的方法明显不适用了。
我最后发现**真正的症结就是我踏上二线管理岗位后管理开始浮于表面,疏于关键细节**。
### 通过下沉两个级别了解情况
我之前在[向上管理](https://time.geekbang.org/column/article/280295?utm_source=pinpaizhuanqu&utm_medium=geektime&utm_campaign=guanwang&utm_term=guanwang&utm_content=0511)中谈到站在高你两级的领导角度去看问题。其实做了二线经理,也要下沉两个汇报级别了解情况,构建和基层的信任关系。
前面我说自己刚做二线经理时,看似参加了很多会,查看数百份一线邮件,但这些都是浮于表面的典型做法,结果就是耗了很多时间还是不了解真实情况。
那到底怎么了解到真实的情况呢?我们可以按照下面这四个方法来操作:
**第一,梳理关键项目**。二线经理不可能对所有的项目都投入力量,所以就要梳理关键项目,只参加关键项目的关键会议。比如季度计划会议,审核会议,而不是每一天的例会。
如果还是觉得会议太多,那就说明我们抓的还不够关键,应该继续精简。极端情况下,在同一个时间就只跟进一个我们认为最需要二线经理去重点关注的项目。
那手头的重点项目到底怎么做一对一交流呢?具体来说就是和技术负责人做沟通,再把设计思考,技术细节,实施计划,潜在风险和应对策略全部一起过一遍,技术负责人的讲述必须让二线经理听懂。
整个过程会花上一两个小时,为了保证重点项目做到位,我会从客户体验是否简单,技术决策是否跟客户价值交付强相关,技术方案实施投入产出比,后续运维成本,还有导致项目失败的风险点等多方面来做考察。
**第二,找一线骨干沟通**。对于一线骨干,应该安排定期做技术上的单独交流,听一线骨干单独讲项目细节。这一点非常重要,我甚至觉得找一线骨干过技术和项目细节的效果,要比前面提到的关键会议更有作用。
为什么这么说呢?因为往往在人多的会议上你只会听到好消息,或者听到不痛不痒的话,而单独针对技术细节的沟通,更能暴露一线的真实情况。作为二线经理,找多个一线骨干了解细节,再配合自己在关键会议上的观察,就更容易全面地了解情况,尽早发现问题以便我们介入解决。
**第三,通过闲谈也能发现问题**。我们可以采用一些轻松的形式找各级骨干和一线经理聊天,比如一对一形式的散步,吃饭。这样做有两个好处,一是在这样的环境下,能够更好地增进你和各级部下的关系,另一个是没有目的性的闲聊很轻松,很多时候也能聊出有效信息来。
我们可以问问部下对团队内一些事情的看法,一般部下都想表现出自己有真知灼见,他们的看法也能帮我们更好地了解情况。
比如跟X聊天说到合作那我就会随口问问你跟Y合作如何你觉得Y怎么样呢X回答我Y很努力也有担当但情商不够潜力有限。
我也会问问X你觉得小组里谁比较有潜力啊X跟我说在日常工作中他觉得S很强他自己很努力了还不一定能跟上S的进度。我还会问问X在能力上部门里哪些人是你的学习榜样X说完我还会问为什么然后再提几个X没有提到的人问问他为什么不是这些人呢。
**第四,跟进客服情况和进行客户访谈。**二线经理想了解本团队产品跟进客服情况是一个很重要的渠道。我们公司设有专门解答客户问题的渠道比如每一个产品的Slack ChannelJIRA Project 。
我觉得组织的一把手应该不定时地到一线答疑摸底。这不但能让我们直接了解一线的真实情况,对整条客服线也是很大的激励,能够推动他们提升服务质量。
还有就是直接找重点客户做访谈,比如我们是基础架构部门,就会直接找到公司的支付和数据部门了解产品反馈。我想了解细节,所以我更喜欢跟一线的工程师坐在一起收集反馈,而不是单单等着看这些客户所在的部门让下属发来的反馈总结。
把这些事完全交给客服团队去做,二线经理只是跟客服团队定期做个审查远远不够。总之,我坚信组织一把手才是那个关键人物,只有他真正参与了,才能最有效地把客户的需求反馈转换成组织执行力。
### 布置任务的技巧
前面我们了解到二线经理跨层级给一线员工布置任务是大忌,那么到底怎么布置任务更好呢?接下来,我给你举个具体案例说明这个问题。
有一次,我手下的监控团队和云计算团队要协作才能完成一个任务,但是拖了很久还是没有进度。而更麻烦的是,我们是双向汇报制度,这个事情还牵涉到美国的监控和云计算团队,上海这边不能单独解决。
于是我在上海召开了会议,在会议上做了提议,要求监控团队和云计算团队必须在三个月内按计划交付,会后我写了一份会议总结抄送给中美相关团队。
当天晚上美国的监控主管就写了信,询问为什么没有跟他商量就做出决定,第二天又跟我说他的部下也质问他为什么这个事情没有在内部先充分讨论就定了。于是这件事逐步演变成消除我那封会议总结邮件产生的影响,而不是解决问题本身。
事后我问自己,难道我应该先找监控的中美团队开会达成监控内部的共识,再找云计算的中美团队开会达成云计算团队共识,最后再召集所有人开会才能解决这个问题吗?那上海的监控和云计算团队还是我们同一个大部门管辖的吗?
这时老江给了一个建议,他说“许健,你是二线经理,你为什么不尝试写一封邮件给上海的监控经理和云计算经理,列举你看到的问题,只列问题不列方案,然后要求上海的两个一线经理给一个方案呢?对于美国那边,你可以把邮件抄送给美国的监控和云计算经理。”
后来我老板也跟我说,有些事欲速则不达。这件事我作为二线经理的初衷不错,强势介入解决。但是在人的问题没有理顺之前,这样强势直接解决问题的方式不一定更高效,事实也是如此。于是我总结了两条经验:
* 要解决问题,前期在梳理人员这方面的准备工作不可忽视,开会定方案只是最后一击。
* 作为二线经理,可以尝试先抛问题,把自己摆在裁判的位置,而不一定要自己直接上场。
## 把人理顺
二线经理除了把事情管好之外,还需要更多地着眼于把人理顺。请注意,我这里说的不是把人管好,而是把人理顺。
那具体怎么把人理顺呢?二线经理和一线经理对人的着眼点到底有何不同?我会从人员诉求,招聘、裁人三个角度带你做个分析。
### 人员诉求
前面我强势解决监控和云计算协作的做法有什么问题呢?其实就是**只关注到解决问题本身,却忽视了人员诉求。**
作为一名二线经理需要处理的更多是跨团队协作。我就拿前面监控和云计算协同的故事为例带你做个梳理,看看经理知道了人员诉求后,再去做协调会有什么不一样:
我应该先想想监控的总部主管是什么样的人,他在乎什么?结合以往的相处经历,我想起这名主管曾多次明确提出他需要在决策圈内,如果不提前通知他,他总会质问是谁在他不知情时做了决定。
再来想想云计算的总部领导是什么人,又在乎什么?云计算主管也有自己的优先级,回忆了和这位主管过去的交流互动,我意识到总部云计算主管很在乎解决方案有没有前瞻性,而不是一味解决眼前问题。
还有一点也很重要云计算部门的Quota实施已经做了一年还没有一个成功案例来证明其价值那这个诉求我有没有办法满足呢。
梳理了这些诉求,再复盘前面的案例,我觉得除了之前说的跟上海的一线经理提出要求,我也可以帮忙在幕后铺一下路,比如:监控总部的领导那边,我应该提前打招呼告知困难,可以把事情的前因后果和他说清楚,再提出希望他给予帮助;云计算那边可以跟总部商量一下,是不是可以把监控当成一个成功案例来做。
总之,**先了解清楚相关人的诉求,看能不能借助别人的思路把自己想办的事情办了。**有兴趣可以在网上搜一下“盖茨的女婿和世界银行副总裁”相关的故事仔细体会这一点。
### 招聘
我在讲[人才招聘](https://time.geekbang.org/column/article/282069?utm_source=pinpaizhuanqu&utm_medium=geektime&utm_campaign=guanwang&utm_term=guanwang&utm_content=0511)时就强调过招聘的重要性,但我们现在作为二线经理,实际是你的一线经理在招聘一线员工,那我们应该怎么做?每一个人的终面必须参加吗?还是说,我们直接把招聘的定夺权完全交给一线经理呢?
作为二线经理下面两种情况的面试我一定会参加一种是高级别的候选人面试另一种是团队转型时期招聘的新人面试比如从传统运维向DevOps转型
二线经理的介入程度要根据具体情况选择,如果我认为招聘经理的要求很高,我介入的就少,如果我认为招聘经理的要求不够高,我介入的就多,甚至要求必须让我参加面试,面试官的安排也必须要有我指定的人。
这样做不是因为一线招聘经理招人的主观要求不高,而是他的能力和思维方式没有办法在短时期内就提升。如果这时候二线经理不参与,就很容易导致这个一线经理招来的人达不到我们的标准。
如果不是大规模招聘实在忙不过来,我还是建议二线经理对每一个进入组织的人都要面试一下。
面试一方面是考察候选人,另一方面也是我们和候选人的第一次接触。我一直觉得面试官和古时候科举考试的主考官一样,如果候选人在面试阶段就见过面,他们加入之后和我们的关系就自然会亲近一些。
### 裁人
除非是要裁掉一线经理,不然我们想裁掉一线经理下面的员工,就必须得到一线经理的配合。那么如果一线经理不愿意裁人,或者裁人的动力不大该怎么办呢?
我们可以要求一线经理持续以高标准招聘,让他不要担心最后没有招聘预算。好的人才可遇不可求,如果这个一线经理经过自己的努力,终于面试到一个他很看好的人才,为了把这个他欣赏的人才纳入麾下,他就会有动力去主动裁掉团队内相对较差的员工。
前面我说了裁人的简单情况,其实如果你一线经理给力,这些事并不需要我们亲自推动。更关键的裁人情况是,怎样完成关键位置的裁人,比如为了组织团队转型而裁人。
有些重要项目想要做好,就要靠**关键位置上的人**。为什么这样说呢,我给你分析一下:
作为二线经理如果我们想落实一件事儿但涉及这件事的关键核心人员跟你不是一条心那事情就很难做成。比如我们想提升团队A的效率但是团队A的经理觉得他的团队已经挺好了那他即使没有当面顶撞你提效这件事上他的贯彻执行力度也会大打折扣。
所以有时候,你不得不下一个痛苦的决定,就是拿掉他。要知道这个人能走到关键岗位,一定有他的道理的,所以这个事情急不来,这里有两个思路供你参考:
* **评估其人脉构成。**这个人手下的人员中对业务至关重要的关键骨干,我们要花时间构建信任关系。注意这里绝对不是说用利益去让他们背叛他们原来的上级,这样就走偏了。而是让他们了解我们是什么样的人,有怎样的价值观,了解我们希望这个组织变成什么样子。
* **获取上级领导的支持。**特别是空降到一个部门做经理,想要拿掉一线经理,就要获得提拔过该经理的老板支持。这个对话不容易,我们要坚定,敢于承担责任。
## 树立不断突破的意识
当然,二线经理除了把事管好,把人理顺之外,还应该有更高的追求,那就是不断突破自己,走向卓越。
对于一个二线经理来说,值得自豪的不是自己多苦多累,而是要带领好几个团队组成的一个大的部门达到新的高度。
以我现在的情况来看,如果部门要取得突破性进展,已经没有简单的事情可以做了,关键的事情都是利益相关的,**如果我不站出来,只顾自己****安稳****得过且过,那是我失职;如果我把关系搞砸了,影响到我们团队的利益,也是我失职**。这就跟历史上的变革一样,团队内部有以前的惯性,团队外部有利益冲突。
所以,二线经理想要把自己负责的团队带到新的高度,特别需要有突破意识,如果每天工作所做的决定都很容易,每天处理的问题都不伤神、不痛苦,那就是在传达一个信号——我们自己的提升有限,我们带领的团队提升也十分有限。
## 总结
今天我们主要谈了进阶二线经理后,在**把事管好**和**把人理顺**两个方面需要做的提高,这个提高是区别于一线经理的。
首先就是把事管好,二线经理要通过下面的一线经理去管理团队,所以要给一线经理授权,不要轻易跨过他们安排一线工作。
同时也不能忘记,我们要下沉两个管理层级去了解一线的细节。具体有四个方法了解情况,**梳理关键项目、找一线骨干沟通、通过闲谈发现问题、跟进客服情况以及进行客户访谈。**
在布置任务的时候,可以抛问题让一线经理协商给方案,然后你按需选择是直接启动方案里的实施步骤,还是根据情况做调整,这样二线经理就能更好地把握进退的空间。
另一方面就是把人理顺,具体分为人员诉求、招人和裁人三个部分。人员诉求上,我们需要清楚相关人的诉求,借人成事。
招聘和裁人上也需要得到一线经理的支持,不是所有情况都要亲力亲为。这里要注意团队招纳重要的候选人时还是要由我们二线经理参与、拍板。在团队转型这类特殊情况下,就算是一线经理,如果影响到了团队发展,也必须从关键位置上拿下来。
二线经理做到把事管好,把人理顺以外,还要**具备突破意识**。除了维持团队正常运行外,二线经理还应该有更高的追求。我们可以想一想,自己有没有做过触及核心利益的艰难决定呢?这能帮我们审视自己,激励我们从合格的二线经理迈向更高的水平。
![](https://static001.geekbang.org/resource/image/db/04/db36a22f0e7af50b2ca1ee6cf497c204.jpeg?wh=3200*1800)
## 思考题
我不喜欢那种“捣糨糊”领导,就是那种碰到跨团队协作问题就跟部下说你们自己协商解决,还教育下级经理要主动扩大自己的影响力,但他作为领导却从不真正出力。
1.二线经理在什么情况下要自己直接到一线解决问题,什么情况下需要让一线经理们自己协商解决呢?
2.如果确定了一线经理自己去协商解决,二线经理又需要做哪些事情,才能避免成为我前面说的这种“捣糨糊不出力”的领导呢?
欢迎在留言区晒出你的经历和疑问。如果有收获,也欢迎你把这篇文章分享给你的朋友。