职业经验 [转] 转型技术管理后,应该避踩哪些坑?

槽神 · 2018年03月13日 · 最后由 yangbin 回复于 2022年01月25日 · 2000 次阅读

很多大兄弟面临转管理之后不知所措的情况,经常跑过来发匿名求助,转个文章给大家看看。

  “程序员是个年轻职业,到 30 岁还不能转管理就没戏了。“十多年前我刚入行的时候,这歌(别字,应为个)「魔咒」特别流行,虽然没有去深究背后的道理,但总觉得它还是概括了某种一般规律。

  那时候想着:距离 30 岁还有很长时间,所以随他去吧,也没太把它当回事。到如今,似乎也没有人再提 “ 30 岁不能转管理就没戏” 这回事了。

  最近几年,因为工作的原因,我面试了不少技术人员,才发现现在还是有很多 30 岁上下的技术人员希望转型管理。但是他们中的不少人,要么不明就里、踟蹰不前,要么不得要领、行路蹒跚。看来,转型技术管理这条路也并不好走。

  身为技术人员,遇到问题我们一般都会思考一般规律,以方法论来解决。在我看来,转型管理其实也是有一定之规的。其中不少与性格和能力都没有关系,而是若干习惯和思维方式的改变。所以,下面我尝试总结初入管理岗需要特别注意的几点,供各位参考。

「我搞得定」不一定是好事

  做技术的人,大多很享受「搞得定」的快感。毕竟,技术既是我们安身立命的本钱,也是我们的价值来源 —— 能用技术去搞定各种事情,既让我们开心,也给我们经济回报。看看我们身边,如果有这样一个人,无论出了什么难题,他都可以搞得定,那么他就是牛人,当然应当受到大家的敬仰,成为学习的楷模。我们很多人,内心里都希望成为这样的人。

  但是,如果你希望从技术转向管理,强调「我搞得定」却不一定是好事。因为「管理」从某种意义上来说,就不再是自己单干,而是要驱动一群人,借助团队创造更大的优势和能量。如果团队每次遇到问题,技术管理者热衷于高喊「我搞得定」,冲锋在第一线,单从事情来说或许很好,但从团队来说未必很好。

  我们要认识清楚,高喊「我搞得定」的时候,他的身份是个人贡献者,而不是团队的管理者。长此以往,技术管理者很可能越发相信「只有我才搞得定(才能放心)」,失去了对团队成员的信任,忽略了团队能力的培养;另一方面,团队也越来越依赖管理者出头解决疑难问题,缺乏主动挑头的勇气。如此往复下去,进入恶性循环。管理者精力透支,团队却在原地踏步。

  要解决这个问题,技术管理者一定要克制「我搞得定」的冲动。比较好的办法是,把「我搞得定」当成不轻易亮相的法宝。即便你知道自己能搞得定,也应当忍一忍,等待团队里有人出头来搞定。如果有人确实搞定了,要多加肯定。如果不得已必须自己出手,完事之后应当仔细想想,这个问题有没有必要自己出手,是不是应该培养人来搞定这些事,如何培养这样的人。

「我搞不定」不一定是坏事

  如果说「我搞得定」对技术人员来说是信心的来源,那么「我搞不定」就是丢脸的象征。我知道很多技术人员都羞于承认「我搞不定」,宁愿翻阅书籍、上网搜索,也不愿意问问同事,更不用说承认「我搞不定」了。因为,这就等于说「我水平不行」嘛。

  很多技术人员转型管理之后,仍然带有这种思维惯性。不论管理什么团队,做什么业务,都希望百分百杜绝「我搞不定」,避免 “「我水平不行」的尴尬。

  可惜他们没有意识到,角色不同,定义也不同,此「水平」非彼「水平」。对专业技术人员来说,「水平」基本等同于「专业技术能力」,而对于管理者来说,「水平」基本等同于「动用资源解决问题的能力」。也就是说,不怕你自己个人搞不定,就怕你找不到资源搞定。

  可以想象,承认「我搞不定」的管理者,一定会更迫切地为团队补充高水平的人才,壮大团队的力量。对团队成员来说,如果自己动手搞定了管理者自己承认「搞不定」(谁知道真假呢)的问题,也更容易获得成就感,积累继续成长的动力。

两点之间,直线未必最短

  技术的世界是单纯、简单、直来直去的。许多语言、框架、工具,更是在努力塑造「凡事有且只有一种最优解法」的思维。所以,在技术人员看来,很多问题本身没有那么复杂,两点之间,直线就是最短,这是毫无疑问的。

  但是身为管理者,要应对的局面、考虑的问题都要复杂很多,直截了当地解决问题,很多时候并不是最可取的方式。因为,管理者不是一个人在战斗,往往需要借助其他人的力量去达成目标,并且在这之后,还需要持续与其他人保持良好的合作关系。这时候,你认为的「最短路径」和「最优解」,未必是其他人认同的「最短路径」和「最优解」。

  假设有个任务,你觉得用 Python 写一点代码就能完成,这是最好的办法,天经地义的,其他人却认为用 Java 或者 Ruby 才更好。这时候,你可以动用权威,直接命令他用 Python 来写,甚至他不会也可以命令他从头学起,但你也要考虑:如果不能让对方心服口服,很可能即便本次按照你的意愿完成了任务,心里却埋下了别扭甚至埋怨的种子,日后不知何时会出土,在想不到的地方给团队添乱。

  如果能多点耐心,让他按照自己的意愿去解决,同时给他看看你认为更好的办法,比较讨论之后得到一致,也许花的时间长一点,日后的收效却大不相同。而这种耐心的培养和启发,正是很多优秀管理者的做事方式,因为他们知道,两点之间并不是只有直线可以连接,下跳棋同样可以达到目标,而且难度一点也不低。

理论是灰色的,而生活之树常青

  很多人都知道歌德《浮士德》中的名句 —— 理论是灰色的,而生活之树常青。但是,真正能参透其中道理,并且运用到自己工作中来的技术人员,却是少之又少。

  我见过很多技术团队相当喜欢干的一件事,就是抱怨业务团队的愚蠢:连这么简单的都不会,还怎么混?怎么根本没有逻辑?这也不懂那也不懂,整天不知道在干嘛…… 越抱怨,越有共同语言,越觉得自己人有共识,怎么做人、怎么做事,这些问题本没有那么复杂,本来有公认的答案。

  在我看来,技术人员之所以有这样的认知,很多时候是过于相信技术的力量了,忘记了「理论是灰色的」。技术当然很强大,很有力量,但也有很多问题是技术解决不了的 —— 从去年的月饼事件,到前不久的搜题风波,说起来都是技术问题,但哪一件是单凭技术就能解决,甚至能像技术问题那样容易达成共识的呢?

  如果承认「生活之树常青」,就会发现不一样的世界。尤其是身为技术团队的管理者,多半需要和不同职能的团队打交道,在这种时候,技术不再像以前那样是唯一的标准和讨论的基础。

  你知道产品团队的目标是什么吗?你知道运营团队整天在考虑什么吗?你知道客服最近忙于解决什么问题吗?你知道商务遇到了什么困难吗?如果你愿意放下「技术主导一切」的观念,把自己当作不懂技术的人,设身处地理解其他人的处境和工作,技术的价值往往才能得到更大程度的实现。

  前几周谷歌出现了沸沸扬扬的「性别歧视事件」。我总觉得,大家太容易形成刻板印象,比如男人适合干什么,女人适合干什么,并脑补出一些所谓的理由。全然不顾无数科学研究早已经证明,女性在科学方面表现不如男性,更多不是生理原因,而是社会观念和习俗作用的后果。

  对于技术人员转管理,很多人更喜欢从性格上找原因,于是管理岗就变成了一个「天注定」的选择。但是在我看来,转管理并没有那么玄乎,即便「管理能力」,培养起来也是有章可循的。如果你相信我的观点,如果你正在考虑转行管理或者刚转管理觉得手足无措,希望上面说的几条可以帮助你。

原文地址:https://news.cnblogs.com/n/591647/
博客园的文章转载自微信公众号「 100offer 」
作者:余晟

附言 1  ·  2018年03月13日

很有参考价值,谢绝技术喷开火,如果有人喷,我会立刻关闭回复~

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 7 条回复 时间 点赞

我竟然看完了,正好最近处于转型的思想阶段,做点笔记
1.克制住 我能 因为管理者最重要不是 我能 而是 我和我的团队能
2.我不会 术业有专攻 管理者更多的是资源协调者 而不是执行者
3.最优选择 不是硬性逼迫你去做 而是有理有据 影响思维 而不是 影响行为
4.理论 只是某些基础的总结 应该结合实际场景 换位分析
5.(我最喜欢) 管理者并不是与生俱来 后天培养也是有章可循

挺有意思的。希望继续介绍一下做管理可能会遇到的问题:如何让团队拧成一股绳来前进?如何面对团队里的 “刺头”?因为做管理和做技术出发点不同,有的技术人员可能会因倚仗技术能力从而 “轻视” 管理者,如何 “以德服人”?

有些观点不敢苟同,对大多数技术管理者来说,任何时候都要有追求技术,用技术搞定问题的心(至于是自己搞定还是培养其他人搞定另论)。见过太多优秀的工程师因为进入管理岗位,就开始正儿八经把多数精力放到管理学那些套路里,慢慢沦落为眼高手低的普通管理者。个人观点。

蒋刚毅 回复

会 和 包揽的差异,这是两码事,原文是说不要总以个体贡献者的思维做团队建设

另外,对技术的追求,你这个说法很好的回答了你楼上的问题。

我应该不算专业管理岗吧, 我们有专门的测试总监做人员管理。 我只是个管技术的,属于带着大家攻坚的。我比较同意克制自己的表现欲,即便自己搞的定,也要让自己的战友来搞的观点,要发挥团队的作用,就算个人能力再强也只有一个人。 但是如果是属于基层管理者,比如 leader,测试经理或者测试架构师 (好吧这里有好多个叫法), 还是要尽量避免【搞不定】这种事。 因为这时候 level 不够高,还是属于带着大家奋斗在一线的,那么这时候身为管理者的指导作用还是很重要的。 尤其是在测试行业这种大部分人技术水平不高的环境下,在大家还不是很强的时候,指导战友做事情还是比较重要的。 在相信战友能力的同时,也要给予一定的指导。

一字一句看完,深受启发;刚转管理半年,对于一个小公司而言,11 人团队确实不算小的测试团队,如何更高效的发挥出团队的测试效率?这几个月一直在研究这个问题。谢谢楼主的总结:搞得定,未必是好事,搞不定,未必是不好的事。谢谢楼主分享~

文章看后收益颇多,我认为这个要根据实际的情况去决定管理者需要'搞得定'还是'搞不定';
我举个栗子吧:假如你的测试团队也就十来人甚至更少的样子,你作为测试经理遇到技术问题总是给团队成员的印象是你'搞不定',你要你的团队成员怎么看你,水货一个嘛... 当然给别人 ‘搞得定’ 的印象不一定是要你自己大包大揽 而是能引导团队成员朝着正确的方向前行(注意关键词'引导',这个度自己要把握好,所以如果你这个测试经理对于这个技术问题完全是一副'搞不定'的姿态,你要如何'引导'呢);当然对于团队规模比较大的情况下 我觉得楼主的说法还是很适用的;总结一下:小团队需要管理者有过硬的专业技能 + 不要太张扬,'肉'留给团队 不要只顾自己吃.,;大团队就像楼主说的这样吧(没带领过大团队 不敢妄言)

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册