大多数程序员纠结的事:我要不要转回去做技术

举报
橘座 发表于 2019/09/05 21:53:55 2019/09/05
【摘要】 由于工作关系,我经常有机会和转管理前后的准经理或新经理聊天,并经常会问他们这样一个问题:“经历从工程师到团队领导这个转变,你最大的感受是什么?”我得到的回答往往是下面这样的。有人会一脸无奈地对我说:“管理的事儿太杂,都没时间写代码了,越来越心虚……”有人语重心长地告诉我:“做管理最大的挑战是,要舍弃技术,特别难。”有人会抬头反问我:“管理和技术到底该怎么平衡?”有人会故作轻松地笑道:“突然不...

由于工作关系,我经常有机会和转管理前后的准经理或新经理聊天,并经常会问他们这样一个问题:“经历从工程师到团队领导这个转变,你最大的感受是什么?”我得到的回答往往是下面这样的。

  • 有人会一脸无奈地对我说:“管理的事儿太杂,都没时间写代码了,越来越心虚……”

  • 有人语重心长地告诉我:“做管理最大的挑战是,要舍弃技术,特别难。”

  • 有人会抬头反问我:“管理和技术到底该怎么平衡?”

  • 有人会故作轻松地笑道:“突然不写代码了,感觉吃饭的家伙没了,哈哈。”

  • 有人则会满心忧虑:“管理工作太琐碎,感觉离技术越来越远,现在特别担心个人发展。”

  • 甚至还有人忿忿地跟我说:“管理是一个有违人性的事情,自己的技术越来越差,但是却要带领整个技术团队。”

诸如上面种种说法,如果我告诉你,我访谈过的上百位技术新经理中,大约三分之二的人都有类似的担忧和反馈,你会作何感想?如果你恰好正在经历这个阶段,你对于这个角色转变的最大感受又是什么?你又如何看待技术和管理间的“冲突”呢?会不会也像上述说法或忧虑,或愤慨?最后只能无奈地说:“反正也想不明白,就多投入一些时间来兼顾技术和管理吧!”

然而,“两者兼顾”并不能真正解决问题。要解决这些问题,需要先来看看问题的真正根源在哪里,然后才能对症下药。回想一下上面列举的那些烦恼,它们有哪些共同点呢?

大致可以归类为以下三种情况。

  1. 转管理之前没有仔细了解过管理。技术人员常常会沉浸在代码或某些技术细节当中,对于职业发展方向的思考整体偏被动。大多数的技术管理者是被领导“推到”管理岗位上去的,而在此之前对于怎么做管理并没有深入了解。不夸张地说,对很多技术新经理来说,管理几乎是一个全新事物。在全新事物面前,因为无法掌控而感到惶恐或焦虑就在所难免了。所以才会时不时冒出一个念头:万一做不好怎么办?退路在哪里?

  2. 刚开始做管理,还无法靠管理“安身立命”。在技术新经理的心目中,管理能力并不能让自己安心,更不能让自己依靠,心的家园依然是过去这些年积累的技术能力。而管理就好像是还没有驯服的野马,虽然有时觉得挺新鲜挺刺激,但终究不确信能够骑好,所以不可依赖。在一个未掌控的新事物面前,想来这种心理也是人之常情。

  3. 认为技术才是自己的“大本营”。技术作为自己生存的资本,在过去的工作中已经得到了很好的证明,因此非常值得信赖。这就是所谓的“成功路径依赖”,每个人都大抵如此。对于凡事讲究精确与可靠的技术人来说,尤其如此。所以,一遇到令人不爽的问题,还是希望回到自己的“大本营”——回去做技术工作。

把上面这三点放到一起看,恰好生动地反映出新经理此时的心态:“患得”“患失”。当然,这里没有贬义和批评的意思,只是描述一种纠结的心情。

“患得患失”出自《论语》,原文是“其未得之也,患不得之;既得之,患失之”,翻译成白话就是“还没有得到的时候,担心得不到;而得到了之后,又担心失去”。新经理的状态,从对自己安身立命的安全感角度来看,可谓正处在一种“青黄不接”的状态。

  • 做管理还没有摸到门道,很多事不知道该怎么着手,经常会出现一些让自己不知所措的状况,倍感焦虑;

  • 之前已经熟练掌握的技术能力,由于在上面花的时间越来越少,感觉正在离自己而去,倍感失落。

如此,“患得”的焦虑和“患失”的失落交织在一起,怎不令人烦恼呢!

好在,既然已经知道了“病根”,我们就有办法祛除烦恼。这里有三个药方,每一个都会缓解烦恼,三管齐下的话,应该会神清气爽了吧!

第一个药方专门针对“患失”来开。

作为一个做了十年技术管理,并创过业做过技术VP和CTO的所谓“过来人”,我可以负责任地说,做技术管理,并不会放弃技术,而且也不能放弃技术,放弃了技术是做不好技术管理的。你只是在一定程度上,放弃了编码而已。

那么,没时间编码,怎样才能做到不放弃技术呢?我们会在下一节详细讨论技术管理者如何保持技术能力这个话题。现在先做一个大概的探讨。

首先,把技术提到更高视角来看待。

做技术的时候,把技术做好就是最大的目标。而做了管理之后,需要把技术作为一个手段来看待,看它究竟能为目标带来什么。显然这不意味着你就不需要再关心技术,只是关心的层次不同了:从研究怎么实现到研究怎么应用了,而且,你开始需要借助每个人的技术能力去做更大的事情了。

这很像在组装计算机,我们现在DIY一台计算机,已经不需要关心主板、内存、CPU的内部运行逻辑了,但还是要很清楚它们的功能是什么,接口什么样,以及从哪些维度、用哪些指标去衡量每个组件的优劣,也得清楚在整台计算机中,哪个组件可能会是性能瓶颈等等。所以,技术转管理并不意味着不关心技术,只是从关心技术实现,到关心更大的目标和整体结果了。

其次,换一种学习方式来掌握技术。

亲自写代码固然是很好的学习技术的方式,但是作为管理者,你需要快速掌握更多的技术,并快速判断该如何搭配使用,所以你一定得有更高效的学习方式才行。这里我们介绍三个行之有效的做法。

  1. 建立你的学习机制。你可以想想在团队内建立什么样的学习机制,可以帮助你借助团队的力量来提升技术判断力,并结合自己的情况来创建。

  2. 请教专家。在了解某一个领域的情况时,借助你的平台,找你能找到的最厉害的专家高手进行请教。他们之所以能成为某个领域的高手,都是有着深厚的积累,并且能够用简单精准的语言给出高屋建瓴的关键意见,几句话就会令你有醍醐灌顶的感觉。

  3. 共创。对于知识型工作者来说,和大家共创所收获的成功,往往比自己埋头思考要高效得多。你可以看看在团队中如何建立共创机制。

对于要快速提升技术视野来说,以上三个方式,比看书或写代码都更加高效,你可以选择适合自己的方式。具体的做法和建议,我们在后面对应的章节中介绍。

最后,关于“患失”还有一个做法:如果你是真心热爱技术,擅长用技术的思路和方案解决问题,你可以考虑做“技术型”管理者,让“技术范儿”成为你的管理风格。

做管理主要看结果和成效,对于手段并没有一定之规,有的管理者擅长带人,有的管理者则执行力特别强,有的管理者资源整合能力特别强等,不尽相同,你完全可以有自己的独特风格。身边是有这样的成功案例的,有的技术管理者已经带几百人的团队了,都做到技术VP了,还是一副“技术极客范儿”,这并不会成为他做好管理的障碍。总之,如果技术本身就是你的优势,你也可以结合自己的兴趣和优势,把它打造成自己的管理风格。

以上,就是我们开出的第一个药方:无论从哪个方面讲,你都并没有放弃技术,只是换了一种方式去学习和运用技术。所以,你不会失去什么,也不需要“患失”。

第二个药方专门针对“患得”开出。

这里的“患得”其实是“患不得”——唯恐得不到。那么怎样才能不再担心做不好管理呢?

首先,做管理对个人成长和个人发展来说,不会失败。

因为管理总体上是一项修炼,只要你持续不断地实践、练习,你的造诣就会越来越高,最后你一定可以胜任某个规模或某个职能的团队。我们通常所谓的“不胜任”,只是说不匹配,而不是说你完全做不了管理。而且,管理是很个性化的工作,你完全可以使用自己擅长的方式,去达成管理目标。

其次,对于技术新经理来说,即便“做不好”也并非没有“回头路”。

刚刚从工程师岗位转到管理者岗位时,离技术很近,如果尝试下来,认为管理工作确实不是自己想要的,那么,回过头来继续做工程师,几乎是没有门槛的。所以,如果当下不知道自己适不适合做管理,不如全力以赴去尝试一段时间,你其实还有充足的时间来慢慢做这个决定,不需要有后顾之忧。

最后,做管理所积累的能力完全可以迁移到做“技术带头人”这个角色上。

你不用担心管理者的经历会白费,或者担心本来可以做技术的时间被耽误了。因为,即便你再回头去做工程师,也需要练习去做高级工程师或架构师,需要尝试去负责一个完整的技术方向,此时,你做管理时锻炼的全局视野、规划能力、结果导向意识、项目管理方法、沟通协调能力等,都会派上用场。

所以,我们开出的第二个药方就是:你一定会有所得,会在做管理过程中有巨大的收获。既然一定能“得到”,就不需要去“患得”。

第三个药方有点猛,叫作“认清现实”。

如果你把“编码时间减少”叫作放弃技术,那我不得不告诉你一个残酷的事实:无论你做不做管理,这事都不可避免——做技术管理,需要用更高的视角来看待技术;继续做工程师,也需要用更高的视角去看待技术。因此,对于大部分技术人来说,编码时间会越来越被其他工作所挤占,很难避免。

俗话说:“人穷则反本”,当人们遇到困难和挫折的时候,就想回到老路上去,这是人之常情。但是,技术管理者不得不面对的一个现实是,即便回头去继续做技术,也不再是原来那个做法了——你不再是那个听指挥听安排就可以,做好执行就万事大吉的一线工程师了,工作“升维”已不可避免。一方面,每个人的内心都有成长的诉求;另外一方面,公司和团队也需要你承担更复杂、更具挑战性的任务,你不能缩在一线工程师自己的小天地了。

所以,无论是做技术管理,还是做技术架构师,开启一条“技术升维”之路,都在所难免。即便不做技术管理者,要做好一位技术带头人或架构师,工作视角也要做如下的升级。

  • 从目标出发去看待技术。只有目标明确,才能选择最佳的技术方案,做出最合理的技术决策。

  • 从评估的角度去看待技术。做工程师的时候,把一个技术方案设计好、实现出来就好了,而做了架构师之后,你需要非常清楚一个技术方案是通过哪些维度来评估其好坏优劣的。并且,当一个技术问题暴露出来之后,得迅速判断会造成什么影响,损失的边界在哪里,有多紧急,以决定要不要放下手头的工作去新建一个紧急项目。

  • 从依靠自己的技术到借助大家的技术。做技术的时候,了解自己能做什么就可以了。但无论是做管理者还是架构师,你都需要带人做事了,这个时候就需要熟悉团队里每个人的技术情况,知道谁能胜任做什么事情,适合做什么事,然后借助大家的技术去做事。

综上你可以看到,即使是放弃管理回去做技术,也需要从工程师进阶到架构师,也一样有很多的视角需要转换,有很多的能力需要锻炼。

所以,第三个药方就是:既然避无可避,不如奋力向前。掌握一项新事物不会是一帆风顺的,前进过程中更是充满了挑战,但是我们并没有“退回去”这个选项。你要做的并不是想一些办法去免除“后顾之忧”,而是需要意识到,你已经没有机会“后顾”了。

总之,技术转管理的纠结,归根结底是“对管理的患得和对技术的患失”。既然你已经看到,做管理不会让你“患得”,也不会让你“患失”,那么你是不是可以安心了呢?

本文摘自刚刚上架新书《知行 技术人的管理之路》,作者:刘建国。


  • 极客时间专栏《技术管理实战36讲》增补版图书

  • 互联网技术管理教科书,互联网管理理论与实践总结

  • 每一本书都需要明确回答一个问题——要对谁讲述一件什么事?本书也不例外。

作为一本探讨技术人如何做管理的书,本书适合所有的技术人阅读,因为技术人都不可避免地要和管理者打交道,而且很多技术人或早或晚会成为管理者;本书也适合所有的管理者阅读,因为各种场景的管理逻辑都有共通之处。事实上,本书内容已经得到很多非技术背景的创业者、产品经理、销售经理、HR、管理顾问和培训师的好评。当然,如果你兼具“技术”和“管理”这两个属性,而且恰好处于以下某个状态,本书探讨的内容会更让你感同身受:

★你是一位想做管理的“有志”工程师,却不清楚如何去努力; ★你是一位被要求带团队的架构师,却一时不知道该从哪里下手; ★你是一位新上任的管理者,希望快速掌握管理要领; ★你做了多年管理,希望提炼和梳理系统的管理方法论; ★你希望助力技术管理者的成长和发展。 总之,无论你是想做管理的技术人,还是技术团队的管理者,本书都将为你打开一扇新的窗口。



文章转自异步社区

原文链接 https://www.epubit.com/articleDetails?id=Nda23332f-5e8b-4f7a-9d1f-5334a313a898


【版权声明】本文为华为云社区用户转载文章,如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

举报
请填写举报理由
0/200