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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

两点之间,直线未必最短

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

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

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

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

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

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

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

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

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

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

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

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

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

附言 1  ·  2018年03月13日

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

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

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

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

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

蒋刚毅 回复

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

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

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

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

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

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