原文链接:The Engineer/Manager Pendulum

翻译如下,有删节。前后分几次拖延很久完成,自己感觉翻译得有些生硬,可以的话建议读原文。


……

世界上最好的一线工程管理者是那些从全职的、实地的一线工作中退下来不超过两三年的人,最好的单个贡献者则是那些有管理经验的人。

而世界上最好的技术领导者常常是那些做过以上两者,如钟摆在其间往复的人。

有很多人两样都做得很好,但是是顺序地,而非同时。— @sarahmei

如何做(技术项目的)管理者

从内部提拔管理者意味着你从刚刚成事的人那得到剃刀般锋利的技能。当他们在一个不同的角色中挣扎于新出现的不足时,这给予他们威信。

这是你能够获得管理者+技术领导者混合的暂时荣光的为数不多的方法之一。这是一种不稳定的组合,因为随着你越做越久,你的工程技能和对环境的敏锐也随之衰退。

你一次只能改进其中的一件事:工程或管理。如果你是管理者,你的工作是更擅长管理,不要试图再去抓着你往日的荣光不放。

管理是常常中断的工作,而好的工程工作 —— 你学习东西 —— 需要阻隔打扰。你不能同时做两件相反的事。作为一名管理者,你的工作是服务于你的团队,被打断。你的工作是选择分配有挑战的任务,让你的工程师们表现更好。

出色的代码和人员都需要同样的东西:专心、持续的关注,没人能两样都做好。

如何做(人员的)技术领导者

反之,世界上最好的技术领导者也总是那些有管理经验的人。不仅仅因为他们通常是最好的程序员或调试者,而是因为他们知道怎么搞定脏活,这意味着他们知道怎样沟通、怎样管理其他人。

技术领导者是管理者……但他们优先考虑的是完成手头的任务,而不是关注和培养进行工作的人。

技术领导者仍然需要全套的管理者技能。他们需要知道如何团结和激励人员和团队,知道如何鉴定和重启一个人人害怕的停滞的项目。技术管理者仍然需要在商业目标和技术目标之间建立联系,把大的目标划分为小的组件。技术管理者需要有能力评估初级工程师的能力并且有技巧地分配有益的任务 —— 推动初级工程师能力的边界又不至于压垮他们……然后在其它团队成员身上如法炮制。从稍作调整的“把某事搞定”而非“关注这些人”的视角,这就是管理工作。

所以这些技术领导者常常花更多的时间开会,而不是创造东西。他们会对此发牢骚,但终归还是会这样做,因为写代码不是对他们的时间的最好用途。技术是简单的部分,照料人员才是困难的部分。

同时拥有技术和管理技能的高级工程师是你创建一个组织或一个公司所需要的技术领导者,他们能搞定脏活累活,他们也很稀有。

几乎所有优秀的技术领导者都在管理上投入了可观的时间。

钟摆

作为管理者教会你业务如何运作,还教会你人员如何工作。你将学会进行让人不快的对话,你将学会让那些懊恼、气愤甚至恨你的人仍能好好完成工作,你甚至将学会如何解决冲突(事实上你会变得渴望冲突,因为简单直接的冲突通常要好于所有其它选项。)每天你会精疲力尽地回家,说不清楚你到底做了什么,但你做成了事情。

你会怀念修复缺陷或解决问题的快感,你会极其怀念它。

关于管理的最后一件事,是有一种神话使人们真的很难停止“管理”,即使这种管理工作使他们和周围的所有人都苦不堪言,这就是把管理工作看作是一种晋升的想法。

管理工作不是一种晋升

成为一名管理者不是一次晋升 —— 而是向平行轨道的一次横向移动,在很多关键技能上你重新回到了新手级别

严肃地说,正是这种潜伏的神话,使很多讨厌管理工作、和管理工作无关的人进入管理领域,而且耗尽了本应成为我们需要的优秀导师和资深专家的高级工程师

管理工作不是一种晋升,管理工作是一次职业改变。你开始管理工作后的很长一段时间你都做不好它。如果你不觉得没做好管理工作,是因为你并没有在做管理工作。

为了满足自尊而去管理是个糟糕的选择,必然导致你的工程师需要向某个痛苦愤恨的管理者汇报,而你真正应该做的是写代码,或是找到其它给大家带来欢乐的事情。

没有比向不情不愿的管理者汇报更糟糕的事了,请不要成为让人们对科技行业心灰意冷的原因之一。

管理工作不是一种晋升,所以你不需要放弃任何地位。只要管理工作能够让你和你周围的人开心,就去做。否则就停手,回去创造东西,等到你再次有想要管理的渴望。

然后把整个过程再重复一遍