Question to say "I can!"

从技术转管理的困惑

2016-05-12

很好的一篇文章,谈技术员到管理层的转型,从心态上提升境界。

作者:池建强

具备扎实的技术能力和良好的协作能力的人,在成长的过程中,往往会被推向技术管理的位置,成为一个团队的 Leader。成为 Leader 之后,困惑也会接踵而至:你最引以为豪的技术能力可能不再是团队里最强的了,你没有了那么多时间编写代码,你要处理各种复杂的流程和关系,部门内协作,多部门协作,你会感到恐慌、焦虑,并认为自己不是这块料。

还不如踏踏实实自己编程呢!这是很多技术人员在转变初期和我说的最多的一句话。

进入技术领域,上升通道差不多就两条,成为某个领域的技术专家,或者成为一个「Tech Leader」。如果你选择了后者,就意味着你不仅要面对计算机和代码,还要和人、流程和协作打交道。

我在洪恩写代码的时候,池宇峰常常在各个楼层间溜达,有一次站在我身后说:

小池,你大学毕业的时候编程水平咋样?
菜鸟一枚!
哦……根据我的经验,大学毕业还没成为程序高手的,一辈子也没法抵达编程的最高境界。
这么说我练不成九阴真经了呗?
嗯,最多也就形意八卦拳神马的……

我的人生观崩溃了,和另一个菜鸟抱头痛哭,问,那怎么办?池宇峰诡秘的一笑,我们可以领导他们!

后来我才知道,池宇峰大学时学化学的,对技术和编程一窍不通。

可能是因为性格原因,我在一个团队里干着干着就会被提为 Leader,从2001年开始带团队,差不多有十几年的时间。从技术到管理到产品,什么杂事都干过,我经历的这些阶段,写出来供大家把玩一下。

1、野蛮生长

刚开始带团队,规模都很小,几个人一个小组。我虽然是组长,但 80% 的精力仍旧放在编程上面,代码贡献在团队里数一数二。编程之余,我会帮助其他组员解决问题,并承担一些培训新人、跨部门协作的事务。问题不大,我在掌控一切。

2、分组而治

团队规模慢慢增长到了十几个人,人多了事情也成倍增长,制定计划、协作、Code Review、培训新人占掉了我大部分时间。编程时间越来越少,这时候我采取的措施是分组而治。我把十几个人分成了两组,自己带一组,在另一组内提拔了一个组长。这样我每周的工作就变成了编程、处理本组的事务,定期和第二组的组长交流,确认部门的整体方向没有偏离目标。

3、救火队员

团队规模继续增长,我把团队拆成了几个组,自己仍然带一个组,编程,协作,规划,最终发现自己的时间和精力已经不允许我再独立带一个组,并参与更多的编程工作,那样做我会成为最大的瓶颈。于是我把自己带的组也划了出去,开始直接面对各个组的组长,帮助他们解决问题。在这个阶段,我仍然是对整个部门技术体系最为熟悉的那个人,于是我成了一名救火队员。

每个组出了问题,我就会冲上去帮他们搞定,无论是线上还是线下。经常有人问做了管理还要不要兼顾技术,当然要,否则你会专注崩溃三十年。当一个问题无法解决的时候,当所有眼睛都在看着你的时候,你需要拿出勇气和耐力,抽丝剥茧的把问题解决,而不是不负责任的扔给别人,何况也没别人。

4、无为而治

团队规模继续扩大,这个时候我差不多已经能够接受自己的技术不能 Cover 整个部门的技术体系这个事实了。很多小伙伴在各个领域的技术都突破了我的界线。我则转身离去,开始关注更大的战略、产品和技术的未来。这个阶段我要做的事情就是制定出规则、领域和方向,找到合适的人,让他们尽情发挥自己的聪明才智。

好的领导者,不是大包大揽,也不是让下属去完成领导部署的任务,而是让他们做自己真正想做的工作。好的领导者不应该总是去试图领导别人,他们要及时反思,修正自己的思路和决策,听取别人的意见,并把一些决策权交给他人。

如果你未来成长为公司的领军人物,常常要反思的不是「我是不是做的太少了」,而是「我是不是管的太多了」。让每个人都能充分的去做正确的事情,事情差不多就能做成了。

看了这些普通人的个人经验,如果你觉得不够,再看看 Google 的工程师 Leader Matt Welsh 是怎么说的:

团队中的大部分人都是比我更强的技术人员,我完全要依靠他们的努力工作来开发出强壮、稳定的软件。我的工作是保护团队中的这些工程师不被打扰,在各方面给他们支持,帮助他们能顺利完成任务。

我大概要花50%的时间来写代码。我真的需要每天有一些固定的时间编写代码,这样能让我安静下来,清醒头脑。不像团队中的其他人,我很难有长时间不被打扰的时间段,所以我主要开发一些比较简单的任务,比如写MapReduce代码来分析服务日志,并生成性能报告。我真的非常喜欢做这样的事情,这种任务能让我接触到海量数据,用各种有趣的方式来拆解、汇总它们。因为我不需要通过展示高超的编程技艺来获取晋升机会,所以,那些非常惹眼的新功能都让团队中比我强的人去做。

我在团队软件开发大方向上会输出重要的影响,包括设计和架构方面。很大程度上是因为,相比起团队中的那些小伙伴,我在系统设计方面有更多的经验,当然,在某些我不熟悉的细节问题上,我需要听从那些实际编码人的意见。我的很大一部分工作是设置优先级,当在解决某个特殊问题,需要在几个都不怎么样的解决方案间做选择时,我来拍板(这也意味着,如果决策是错误的,我来承担责任)。

成长的轨迹变化无常,但世界上总会存在一些规则和痕迹可以遵循和参考。这些文字,如果能够让你有一点思考,就算价值。



作者:admin | Categories:技术人生 | Tags:

发表评论

电子邮件地址不会被公开。 必填项已用*标注

*

无觅相关文章插件,快速提升流量