转型技术管理后,应该避踩哪些坑?

程序员转型技术管理一直是圈内讨论不休的一个话题。特别是那些年近30岁的程序员们,对于是否应该转型管理往往思前想后、犹豫不决。

所以这一期「100offer 大咖说」,我们请到了目前在沪江网做架构和管理工作的余晟,作为一名技术团队的管理者,他有一些技术管理方面的心得,跟大家分享,也许能给那些举棋不定的程序员们一些帮助。

转型技术管理后,应该避踩哪些坑?_第1张图片

作者介绍:余晟,在IT行业混迹十余年,热衷编程,早年翻译并写作过若干技术书籍。曾担任若干公司主程,现在沪江做架构和研发管理方面的工作。业余写作公众号「余晟以为」(yurii-says),分享关于阅读和生活的观点。

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

两点之间,直线未必最短

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

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

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

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

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

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

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

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

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

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

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

对于技术人员转管理,很多人更喜欢从性格上找原因,于是管理岗就变成了一个「天注定」的选择。但是在我看来,转管理并没有那么玄乎,即便「管理能力」,培养起来也是有章可循的。

如果你相信我的观点,如果你正在考虑转行管理或者刚转管理觉得手足无措,希望上面说的几条可以帮助你。

100offer说:

你还有哪些职场困惑?想向哪位大咖请教?

欢迎留言告诉我们。一旦你的问题被我们的内容团队采用,将有 100offer 周边礼品相送。

你可能感兴趣的:(转型技术管理后,应该避踩哪些坑?)