技术经理该不该写代码?

标签: Idea Tech | 发表时间:2014-01-15 14:46 | 作者:Stanley Xu
出处:http://www.xuwenhao.com

今天微博上很多人在转MongoDB的Eliot Horowitz的 Engineering Managers Should Code 30% of Their Time,我也来说说我的观点。

首先不是所有的Senior Tech Member的角色都是Manager,比如Jeff Dean在Google的角色是 Senior Google Fellow(他们终于为Jeff Dean升职而专门发明了“Senior” Google Fellow这个职位!)。Tech Fellow或者Architect的角色和贡献是和Manager完全不同的,Manager需要更多承担放大团队产出的工作。不知道Eliot Horowitz目前实际扮演的是什么角色,但是从文章内容来看,的确他说的更多的是Manager的角色。

同时,一般我们说的Manager都是技术管理两头挑的,而不是专门的People Manager,特别是国内快速发展的互联网公司是没有专门的People Manager的角色的。对于这个技术管理一体的角色,我认为谁听信了Eliot Horowitz对公司和个人都是坏事。我认同 黄易山的观点,就是技术经理不应该去写Production Code,或者至少不为Deadline写Production Code,技术经理的贡献更多在团队中。

Eliot的主要立论,集中在写Code能够更好地为团队做决策上,文中提到的Estimates,Technical Debt以及Continuity of Understanding基本上都是谈这点。但是如果团队主要的技术决策是必须依靠Manager,那么这个团队的整体能力就很可疑了,很有可能是累死Manager但是产出还很少。这种情况下,Manager能写再多的Code,能做再多正确的决定,也会成为整个团队产出的瓶颈。

虽然文中也提到了你不可能做每个决策,他认为你需要为团队负责(Parity with Responsibility),所以要"facilitate all decisions",但是除了写Code还有很多种方式做到这一点,包括Design Review,Code Review,以及花一点时间去写一些工具或者启动一些新项目,但是把30%的时间花在写Code上,或者花大量时间写要短期内Release的Production Code,以我个人经验一定会没有投入足够的时间精力和资源解决团队真正需要解决的问题。最大的困扰会来自,当你需要花时间和精力处理好其他问题的时候,你怎么处理分配给自己的任务?如果延期,那么一方面你反而会丧失团队对你的信任,“Manager自己都不能按期Deliver,我稍微晚一点有什么关系”。如果把团队事务扔在一边,那么团队通常会陷入低满意度和低生产率,因为各种需求,信息,干扰你都不再能够帮他们排除了。更可怕的是,在Deadline逼近,而你又处于这种两难问题的情况下,你会陷入焦虑而无法决策的阶段,进一步降低生产力。

当然,以上都是从对公司和团队产出来说的。多花时间写Code对于Manager个人不一定有坏处。因为技术的市场价值通常在你换工作的时候容易衡量,也容易得到认可,而能够真正赏识到好的Manager的公司并不多。但是,一直处在Manager的角色,而不是一头扎进去写Code有时候,在技术成长上也是有好处的。因为你会站在一个完全不同的外部角度去思考这个问题,这个会帮助更好地去做设计决策。

技术经理的确不应该离开技术第一线,我也赞同应该花点时间写Code,但是更多应该是在写工具,而不是花30%的时间写Code。更多地得依靠爱好和业余时间。而一天到晚在写Code通常是新升职的Manager的常犯错误。

最后,非常重要的一点是,Eliot的公司,有且只有一款产品,就是MongoDB,而且这是一个技术产品,而不是面向消费者,或者面向非技术企业的商业产品。也意味着内部从产品,运营的沟通和需求都更技术化,包括产品用户本身也是技术人员,在不同角色下进行转化的成本很低。这个某种程度上是Eliot作为一个Co-Founder仍然能花很多时间去关心到代码级别问题的前提,而大部分公司的产品形式和他们是完全不同的。即使是这样,Eliot自己在文中也承认了自己写Code的时间也没有30%。

我认为这篇文章基本上是热爱技术的Eliot对自己生活的美好期望,而不是正确的商业和技术抉择。哪个Manager要是把这个当真了,就真跌到坑里去了。

相关 [技术 经理 代码] 推荐:

技术经理该不该写代码?

- - 灰色的灵魂
今天微博上很多人在转MongoDB的Eliot Horowitz的 Engineering Managers Should Code 30% of Their Time,我也来说说我的观点. 首先不是所有的Senior Tech Member的角色都是Manager,比如Jeff Dean在Google的角色是 Senior Google Fellow(他们终于为Jeff Dean升职而专门发明了“Senior” Google Fellow这个职位.

Impala中的代码生成技术

- - CSDN博客云计算推荐文章
Cloudera Impala是一种为Hadoop生态系统打造的开源MPP(massive parallel processing)数据库,它主要为分析型查询负载而设计,而非OLTP. Impala能最大限度地利用现代硬件和高效查询执行的最新技术. LLVM下的运行时代码生成就是用来提升执行性能的技术之一.

技术之于产品经理

- - 极客公园-GeekPark
不爱写代码的软件专业学生 没有产品经历的互联网创业者 永远走在学习道路上的小白. [核心提示]近日关于“产品经理需不需要懂技术”的讨论很火,那么技术之于产品经理到底如何呢. 前言:我不是做产品的,只是对产品设计颇有兴趣,所以个人并不代表产品经理的立场;我是技术出身,但不热衷技术,所以也不能代表研发工程师的立场.

产品经理要懂多少技术

- - 极客公园-GeekPark
个人博客 http://blog.igevin.info. [核心提示]产品经理不需要在技术上登峰造极,但必须要赢得程序猿的尊敬. 产品经理是个辛苦的工作,除了要最热爱产品,练功坐禅研究用户体验外,还要和一大堆人打交道——写代码的,做设计的,搞运营的,做市场的. 前两类人算是艺术家,自然会带点艺术家特有的奇葩气质,第一类人又是和产品经理打交道的人里面最聪明的,一个不小心,没准就被程序猿们划入“白痴”族群,作为茶余饭后鄙视的对象.

PHP分页技术的代码和示例

- xx - 酷壳 - CoolShell.cn
本文来自:10 Helpful PHP Pagination Scripts For Web Developers. 分页是目前在显示大量结果时所采用的最好的方式. 有了下面这些代码的帮助,开发人员可以在多个页面中显示大量的数据. 在互联网上,分​页是一般用于搜索结果或是浏览全部信息(比如:一个论坛主题).

技术管理者应不应该写代码?

- - 灰色的灵魂
我相信所有新晋的技术经理,都做过Team的工期紧张,自己加班动手写Code的事情,这种事情我自己也没少干过,事实上,偶尔我自己仍然会在critical的项目上写一些代码. 相信不少同志们还引以为荣,并且不少技术管理的书上,对于技术管理人员是否应该去写代码也有不同的观点,有些认为不应该写,有些认为一定要写一点避免脱离群众外行指挥内行.

100个惊人的CSS、JS代码技术

- - 设计达人
最近在Codepen看到Top Pens of 2013这个专题,专题内容为2013年上最优秀的前100个CSS、HTML5和Javascript Pens,在惊叹技术人员的创造力同时我们还能学习这些技术,对交互设计师而言还能获取灵感哦. Top Pens of 2013专题地址: http://codepen.io/2013/popular.

King.com产品经理谈HTML5技术发展潜力

- - GamerBoom.com 游戏邦
作者:Joe Osborne. 作为一种用于创造网页游戏的新工具,HTML5已经成为了2012年社交游戏领域的一大热词. King.com最近发布于Facebook的《Pyramid Solitaire Saga》便是一款基于HTML5技术的游戏(游戏邦注:但德国社交游戏开发商Wooga则在最近宣布放弃HTML5),该公司产品经理Levina Nilsson在最近媒体采访中解释了King.com看好HTML5技术的原因.

如何成为一位卓越的技术经理?

- - 互联网分析
管理一支技术团队可能是世界上最难的事情之一. 如果你是一个经理,你需要和很多方面的专家合作,和你的上级协调产品需求,和负责协调产品交付件 的同级合作,和将产品功能转化成技术需求的同级合作,带领直接汇报给你的团队等等. 在某些糟心的时刻,你需要面对的是会把患有自闭症的送报小孩(原文,阿 斯伯格综合症,爱因斯坦曾患有此症)赶走的同事.

我是产品经理我需不需要学技术?

- - 方糖气球
我是产品经理我需不需要学技术. 这个问题我已经听过很多遍了. 作为一个技术出身的产品经理,我的意见是,需要学,但很可能不是你所想的那种学法. 科学技术是第一生产力,而现在这个生产力正在移动互联网、云计算、3D打印和物联网等领域飞速发展. 这意味着谁先将它转化为产品,谁就能突破现有的用户体验,在这个体验至上的产品领域中占领头筹.