技术管理案例课
许健
eBay 基础架构工程研发总监
21440 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 28 讲
技术管理案例课
15
15
1.0x
00:00/00:00
登录|注册

04 | 避坑指南:从技术骨干到一线经理,你会遇到哪些坑?

如何处理这些流程?
业务开发部门抱怨开发效率不高
缺乏独立思考和表达原则的能力
遇到困难时不敢提出
需要有一个且只有一个目标
分散精力导致平庸成果
缺乏长期目标和关键决策能力
经理频繁出现但缺乏有价值的意见
需要了解部下的能力和需求
引入流程不能解决所有问题
部下缺乏成长锻炼机会
部下长期无法独立完成任务
部下可能感到缺乏信任和能力自主解决问题
部下缺乏自由度和发挥空间
不会说不
不能聚焦
刷存在感
迷信流程
大包大揽
管得太细
这件事让谁干最合适?
这件事我怎么干?
分享在管理路上遇到的各种“坑”
举例描述每个主题出现的问题根本原因
公司开发效率部门制定的流程
坑6:不会说不
坑5:不能聚焦
坑4:刷存在感
坑3:迷信流程
坑2:大包大揽
坑1:管得太细
关注人
关注事
思考题联系实际
思考题
6大类问题
从“关注事”到“关注人”
从技术骨干到一线经理,你会遇到哪些坑?

该思维导图由 AI 生成,仅供参考

你好,我是许健。今天我们来聊聊技术骨干转型经理那些坑。
技术骨干在转型经理之前,一般都是部门里专业能力很强的那类人。但转型经理后,我们的思维就不能只关注于事,要同时开始关注事和人,而这里面更关键的其实是人。因为所有的事儿都需要人来完成,而经理更多的是通过培养人和激励人,从而提升团队做事儿的效果。那到底什么叫“关注事”,什么叫关注“人”呢?我下面给你举几个例子,你一看就能明白了。
例子 1:
关注事:这件事我怎么干?
关注人:这件事让谁干最合适?
例子 2:
关注事:小王你这个方案 A 不够好,应该用方案 B。
关注人:小王能够主动提方案 A 很好,在承受范围内哪怕 A 有些瑕疵也让他尝试,我要培养他的积极性。
例子 3:
关注事:我们要交付业务价值。
关注人:我们要提高团队成员的能力。
我把刚才说的例子,总结成了一张图给你放在下面了。
从“关注事”到“关注人”,这两个真的是完全不一样的思考角度。因此,在这个转型经理的过程中,我们很容易出现一些问题。都有什么问题呢?我根据过往的经验,把这些问题按照难度递增,整理成了 6 大类,分别是管得太细、大包大揽、迷信流程、刷存在感、不能聚焦和不会说不。
你可以想一想,你是不是也遇到过这些问题呢?接下来,我们来逐一讲解。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

技术骨干转型为一线经理需要关注人员而非事务,这带来挑战,如过度微观管理和刷存在感。建议经理关注部下自由度,给予责任和成长机会。刷存在感的经理缺乏真知灼见,而不能聚焦会导致效率低下。作者强调经理需了解部下,聚焦目标,提供额外价值。文章深入探讨技术骨干转型为一线经理的挑战,并提供实用解决方案。文章中还提到了不会说不的经理,以及对开发效率的讨论。建议经理不要迷信流程,而应该关注团队成员本身,不要拗姿势,而应该因材施教。同时,经理需要审视自己的团队价值和目标,聚焦问题,同时在处理部门的开发效率问题时,需要审视流程并采取合适的措施。整体而言,文章提供了关于技术骨干转型为一线经理的挑战和解决方案,以及对开发效率问题的思考和建议。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《技术管理案例课》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(20)

  • 最新
  • 精选
  • 阿斌
    你好,听了几节课深有感触,我也是去年三月才开始从技术转岗主管职位,目前也不做技术开发了,专做项目分配和协调,进度跟进。当前遇到两个问题需要请教一下老师:1 我今年30就转岗做管理了,而且目前公司技术组就十个人,做微商主营业务,我不知道自己以后的定位是怎么样,假如从这里离职了,我该怎么样找到自身价值,还有就是该找什么岗位去面试,面技术还是面管理呢,目前市场是否有这样的岗位呢。 2 当前公司技术组基本上都是我这边组建起来的,目前也一年了,大家纷纷提议加工资,但是我反馈到老板那边,公司就说需要什么考核来进行是否提薪,但是这个考核目前还是刚实行(试行期),于公司而言,我希望这帮兄弟明年继续在这里(毕竟也为公司付出了很多业务从0到1),于兄弟而言,我也希望他们得到应有的回报,能力在这一年有提升,也应该得到加薪。希望老师能帮我解答解答,万分感谢!

    作者回复: 1. 什么事情关键都是要精进。你经理做了一年挺难找经理位置的,你说的专做项目分配和协调你觉得这一年你有很大的长进吗?你现在只做了一年管理你去外面面技术还可以,但是随着你管理时间变长,如果你不能在管理上精进,你在市场上就尴尬了。 2. 你跟老板关系如何?理解考核的目标吗?如果你赞同考核的方式,就在那个规则下给跟你奋斗的兄弟提薪。老板也要知道,骨干得安抚好。不管哪种方法,那10人里面有核心骨干吗?骨干走了对公司有多大影响,你要在明白老板的思维逻辑之后站在老板的角度给老板算笔账。

    2020-09-12
    3
    12
  • Geek_积木
    为了提升研发效率,从而加入流程优化,出发点是好的。但是,过程方法不正确,应该是通过度量指标来反馈研发流程,看效能瓶颈在哪里,再优化流程,再看反馈结果,而不应该简单的当做考核指标,最终导致本末倒置,既加重工作量压力,也没达到效率提升的目的

    作者回复: 你好,积木 感谢你的回复,我写这个专栏到今天已经过去一年了,我有些新的体会和经验: 现在的我越来越不相信流程了,我觉得流程是用来把一个已经成熟的方案做大规模复制用的。而你上面说的方法很多人也都能想到,只要专注就能解决问题。但是我会想一想更深层次的问题: 1. 我的团队成员关心研发效率吗?如果不关心,为什么我会关心而他不关心呢? 2. 如果他也关心,那是什么阻止他不去做呢? 很多时候这些问题问下来,我发现问题其实是在管理层。管理层很少做减法,甚至根本就没有在真正关键的地方投入。当我说真正关键的地方的时候也有三个问题帮助组织思路: 1. 当前项目的关键点 (可以用你上面回复的思路来解决) 2. 如果我把自己拔高两层汇报级别,再看当前项目可能就变成更大的项目其中一个环节,那更大的项目的关键点真的是我的这个项目吗? 3. 事和人哪个是因,哪个是果?我要长期解决问题,应该着眼于因还是果?各自的优缺点是什么呢? 谢谢

    2021-09-14
    11
  • 此方彼方Francis
    管的太细那个章节里,V的那个例子我不是很认同。 1. V也太玻璃心了吧,让他去了解一下G做的事情,就这么委屈?如果V和G的想法基本一致,那么V是不是可以不用新做一套系统了?至少,了解了G的设计之后,是不是V也可以对自己的设计查漏补缺? 2. 属下要做一个系统,领导要求review设计方案这样不是很正常吗?如果大的设计方案都不做了解,时间长了这领导还怎么把握自己部门的事情,关键决策做的出来吗?

    作者回复: 每一个人的视角不一样的,当我在谈这个问题的时候更加关注的是V 这个人,我通过这个反馈加深了对V 的了解,很多时候人和人之间的交互不是我觉得如何,而是对方感受到的如何。

    2020-08-31
    3
    8
  • IT男_愚人
    老师您好,我刚走上管理岗位不久,性格确实有点老好人,不管是下属,还是上级领导,都不太会拒绝人。但是同时特别别扭的对待自己人(自己带进团队的兄弟),要求又有点苛刻,甚至是说话语气,作息时间,跟客户聊天神情,跟其他领导相处方式,什么都想给他提意见作纠正(没有行动,只是心里很想这么做),请问您当初有没有这么个经历?有什么方法去转变这种莫名其妙的心理呢?

    作者回复: 我有过对部下有意见,但是你跟他说,或者拐弯抹角说,或者在等一个合适的机会再说的经历的。以我自己的情况,我一个是因为自己感情强度不够,从内心就不想发生冲突,对于有点性格的部下直言直语有点犯怵;还有就是其实我和这样的部下信任程度不够。我在文章里说了,后来我还是直接面对了,我觉得我没有什么好损失的,将心比心嘛。甚至我后来发现,只要我说的话有具体的细节支撑,也就是说我不跟你谈原则,我就拿最近的一个具体的事情来跟你说你哪里哪里做的不够好,效果其实挺好的。有些性格强的人你能一针见血指出他的问题,他反而越来越尊重你。 我不知道你的情况跟我有多少相似。我想问你的是你觉得你自己为什么会只是心里想却没有行动呢?一定有原因的,你说的莫名其妙到底是什么? 还有,我见过有些领导是反而对自己带的人要求更严的,这建立在高度信任基础上,为了服众,他只会对自己往日的弟兄更严。

    2020-09-05
    6
  • 难得糊涂
    老师,您好。我是一名RN/Flutter开发人员,因为一些原因(可能是项目管理做的好),我现在是一条业务线的技术负责人,团队有10人(包含App、前端、测试、后端)。 其他业务线的技术负责人都是后端高P(我本人对后端可以说是没有一点基础),现在感觉有些惶恐,原因在于:在后端这一块能力十分欠缺,而且领导也不止一次提到我们需要一个后端高P。我想请教的问题是:关于技术这一块我该何去何从,有必要从0学后端么,即使学,需要学到什么程度呢。

    作者回复: 难得糊涂 你好,抱歉回复的晚了。我很能体会你的感受,你首先要接纳自己,你现在的感觉是正常的,能给自己起昵称叫“难得糊涂”的人一般都是比较有智慧的。你要相信自己身上有比具体的前端后端技术更加本质的竞争力,你也要相信把你放到这个位置的领导的眼光,就他给你说需要一名高P后端来说,你的领导知道你的优缺点,而他仍然相信你可以,你想一想他做了什么?他在成就你,给你平台,告诉你整个团队缺什么… 现在我们来谈要不要学后端的问题,学习后端的目的是什么?我不觉得其他团队的负责人是高P后端是原因,你也觉得不要给自己设定一个目标说要学到跟其他高P 一样的水平,你考虑的首先是为了更好的交付业务价值和更好的成就他人,你需要做什么?如果你需要招一个高P, 那你给了他什么舞台,你很有可能是要跟他搭班子的,既然搭班子那就有分工,对吗?那在这个分工里你对自己的定位是什么?如果你不准备招一个高P 而准备自己培养一个,也不是不可以,自己提拔的人跟你的关系要更牢固一些,那你能为他的成长提供什么? 我的VP 有一次问我,他说许健,我们碰到的内核问题我直接到一线跟大家一起解决,你怎么看?我说,副总,如果我们这么大的部门没有人能解决而要你亲自去一线,那我们这个部门有问题了,但如果你是通过这种方式来激励鼓舞一线的同事的,那就是另一回事了。在这里、你要不要学后端,学到多少程度?如果你觉得这是你更好的跟大家沟通的基础,是你带好这个团队所必须的,你就去做。 最后,我多说一句,我上面说的所有的话都是理性分析,但是现在的我觉得直觉不可轻易否定。如果你的心告诉你说我就是想学,那就去做吧。相信自己的心,follow your heart.

    2021-10-11
    3
  • Focused
    本节课总结: 1、关注事与关注人的不同出发点; 2、前5个坑都是向下管理过程中,会不断遇到的挑战: 1)刚转型经理,还是站在关注事的角度,进入了微观管理,团队成员无法得到锻炼,不利于团队成长; 2)大包大揽的问题,还是没有把自己转换到管理角色,没有意识到去解决人的问题; 3)迷信流程,任何流程都有适用场景,各有利弊,重要的是找到适合自己团队的那一部分,剩下的还是需要自定义; 4)刷存在感,实际上是没有找到自己的定位,不清楚自己的核心价值; 5)不能聚焦,没有找到团队的核心竞争力; 第六个坑,是向上管理和跨部门同级管理中容易出现的问题,需要保持独立思考的能力,明确自己的原则,坚持住自己的原则。 ----------------------------------- 问题1: 在文章“坑2:大包大揽”的最后,“作为经理,你一定要提升自己的感情强度”,这里的“感情强度”不是很理解,具体能再解释下吗? 问题2: 遇到技术问题,团队搞不定,经理也没有相关经验,这种情况下,经理该如何面对? 希望许健老师能释疑,不胜感激!

    作者回复: 你总结的很好的,什么事情只要用心都会有提高的。关于问题,老师我不敢当,分享一下我的看法吧:感情强度就是你是不是能够正视你的部下,特别是性格比较强硬的部下,坚持把工作push 给他去做。比如: “T, 这个问题你去全权处理,你去找安全部门谈,你去研究告诉我你的解决方案,你说要一个月以后才有时间?我等不了那么久,这个方案必须这个月就拿出来,原因是...”, 而不是:“好的,我知道你很忙,那我去找安全部门谈吧,我去研究一下...”。你知道自己本身不喜欢这样强硬的push 工作,但是你现在是经理,你要有这个感情强度top down. 问题2: 短期内很难了,我说的点估计你也早就想到了或者去做了,比如去找公司内外更厉害的人帮忙。我能想到的是 一个你一定要很积极,要么你在积极的去需求外部帮助,再不济你陪在团队成员身边一起努力解决。大家共进退。如果你扛过去了,记得好好审视一下自己的团队,有什么措施可以加快人才培养,是不是需要引进更强的人才。

    2020-08-29
    5
    3
  • Xunqf
    我觉得这个“负责开发效率”部门的思考方向应该改变一下,为了达到提高效率的目的,他们不应该是给其他部门设置条条框框,而是应该了解其他部门遇到的问题,怎么帮其他部门快速的解决这些问题。

    作者回复: 他们其实也去了解的,但是我觉得他们铺的太开,而且并没有把组织里最资深的人投到一线去。资深的人觉得他们可以用最新的技术帮到开发部门,但是他们缺没有花足够时间去一线体验。

    2020-08-28
    3
  • 我能走多远
    总结刚换工作,工作就遇到了小组组长也是刚上任不到三个月。着急把项目做出来,不考虑技术框架(我们是对开源项目进行二次开发)。不使用现有开源的底层库,而总是自己造轮子,导致小组内另一个老员工很大意见。最终老员工和cto聊天,经常说不想在组长项目下做事情,说了很多组长的坏话。最终这个组长也被裁掉。

    作者回复: 我很喜欢黔驴技穷里面那只老虎,站在旁边仔细观察,而不是盲动。真正凶的都不叫的。

    2020-10-19
    2
  • quietwater
    大公司都有很多流程,原因我想应该是通过流程规范一些问题的处理。流程的好处是可以提高处理问题的下限,能力差的人通过流程也可以比较好的处理问题。坏处是限制了处理问题的上线,能力强的人是可以打破流程,以更高效的方式解决问题。流程也是有两面性的,需要考虑公司,团队,人员等多角度来判断采用什么样的流程来更好的规范一些行为,减少沟通成本。没有绝对的标准,但大多数情况下,制定实施流程的人因为能力不足,视野不开阔,认知水平低而推出一些不合适的流程。

    作者回复: Quiet water , 你好。我觉得你这段话里面的辩证思想是非常好的思维模式。很多事情都是要把握度,所谓“中庸”,所谓”恰到好处”大概就是这个道理。这两年,我自己跟写专栏时的自己也有些不同。以这里为例,我去看了章义伍的流程课,正在尝试如何通过流程批量复制必要的能力,我觉得自己祥林嫂般的说教以期望改变的方式没有落实到流程见效好。再以突破流程为例,我觉得本质上突破的是认知。要突破认知首先就要谦卑,能够认可自己的不足,不然很难用自己的逻辑去打破自己的逻辑。很多人说打破自己的认知要碰到高人,现实的高人或者书上的高人,我觉得两条路径都可以走,三人行则必有我师,关键是自己愿不愿意去看。

    2022-04-06
    1
  • 有个道理是,每个组情况都不一样,因为每个组里的人背景是不同的。所以不能去横向比较。弄个bug墙更傻了,这样大家都会很小心,导致开发效率低下。或者大家都努力去消除bug,对项目本身的难点和进度,就会造成或多或少的忽略。因为大家觉得每个组减少了bug变成了绩效指标。本末倒置

    作者回复: 聪,谢谢你的回复。我们公司是这样的,耻辱墙在美国只显示到副总级别,在上海落实到总监级别。其实效果很有限,因为一线的人看的是直属领导的态度,直属领导觉得没有啥不是组织真正的核心问题,那他下面的人也不会重视的。我出这个思考题的意图跟 《实践论》很相似,该部门的人没有深入一线了解各个部门真正的痛点。

    2020-10-05
    3
    1
收起评论
显示
设置
留言
20
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部