今天微博上很多人在转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要是把这个当真了，就真跌到坑里去了。