技术经理应该把30%的时间用在编程上

英文原文：Engineering Managers Should Code 30% of Their Time

　　在一个科技公司里，软件技术经理用在编程上的时间应该不低于总工做时间的30%。不管是管理一个团队，仍是一个分部，仍是整个公司，当技术经理用在编程上的时间低于30%时，他执行职责的能力就会发生严重退化。

　　个人这个断言可能跟那些我看到的想成为团队首领的软件程序员们指望的状况彻底相反。每次晋升，程序员们都期待花在编码上的时间会大幅度减小，当从“leader”爬到“经理”职位时，就应该完全脱离编码活动。并且，他们指望以一种“动口动眼不动手”的方式来保持对代码库的熟悉。再上级的领导就跟编码彻底不要紧了(若是有的话)。

　　大概一年前，当时个人时间被愈来愈多的其它事情占用，例如招聘，管理，开会等。我就发现，做为一个技术首领，当花在编程上的时间低于某个比例后，管理效果和工做效率就会出现问题。以前我写过一篇短博客阐述过这种体验和观点，但没有展开具体的描述。这里，我将会对这个观点展开更详细的论述。

　　为何要坚持编程活动

　　不少人认为，做为管理者，应该退出战斗第一线，专一于大战略和管理工做。固然，管理者把大部分的时间用在这种事情上是应该的。可是，在咱们这样一个行业里，由于咱们容许或要求管理者几乎再也不去编程，现实让咱们付出了沉重的代价。一旦一我的中止编码，他和程序员们关心的事物之间的重要联系就会退化。当这种状况发生时，决策、计划和干群关系就会出问题，从而瓦解了将技术人员提高到管理职位的良好愿望基础。

　　项目开发评估能力

　　程序员的百宝箱中最重要的一个绝活就是估计工期。若是没有准确预估的能力，总体计划是不可能正确的出台的。你们也知道，作为一个族群，程序员们对工期的估计是臭名昭著的——糟糕的不能再糟，事实上，当从程序员口中获得一个预估的数字后，公认的方法是将它乘以二。一般，程序员都会对开发工做抱有很是乐观的态度，但若是咱们使用“estimate traction”理论，就会发现，编程活动表现出特别易变的特征。由于我能够用不少方法实现一个功能，当咱们在尚未深刻细节以前，咱们的估计就是不可靠的。

　　技术债务

　　另一个事情是，对于技术债务给项目形成的影响，技术经理必须掌握第一手的资料。现在，技术债务这个术语很是流行，常被用来看成争论的弹药——优先开发新功能仍是先重构老代码。对“技术债务”这个词的内涵熟悉的人一般最容易发起论战。做为技术经理，你不只仅要熟悉这个概念，并且它们会在你判断什么时候偿还技术债务的决策中起直接做用。常常写代码的经理拥有更多更有价值的信息来判断什么时候/如何作出这样的决策。

　　知情的连续性

　　我并非随意选择30%的比率的。我是基于本身的经验，将足够的时间参与到开发活动中，你很容易就能时刻掌握代码库的任何变化。若是时间太少，你对开发动态的掌握就是断断续续，没法连成线。一旦断了线，我就须要从新理顺脉络，由此获得的惩罚就是浪费了额外的时间。

　　分担责任

　　做为负责人，你不可能让全部决策都由你制定或由你批准。但你须要了解全部决策的来龙去脉和背景知识，来辅助这些决策。最终，你要为这些决策的后果负责，你对项目状况的掌控能力要能匹配你的这份责任。

　　积极参与编程赢得团队尊敬

　　你们须要明白：要想成为一个成功的经理，你须要为团队成员提供服务，促进开发，确保他们完成任务。我曾在一篇博客里写过如何诊断和修复经理们有问题的干群关系。可是对于的管理程序员来讲，你须要热爱编程。由于你的团队在编程，若是你在编程上作榜样，他们都会对你肃然起敬。

　　达到30%的障碍

　　尽管付出了最大努力，我仍然在保持30%的编码时间上遇到了不少的阻碍。包括下面这些：

　　工做繁多：在一个创业公司里，你总有忙不完的工做须要去作，即便在公司有规模、壮大后，如何对众多都很重要的事情排优先级也是一种考验。技术经理有不少职责，彻底会占满他的70%的时间。下面就是一些：

• 领导和照顾团队：这是一个技术经理的第一要务。你已经不能只为本身的工做负责，你要为你的团队能保持最好的工做状态负责。指导团队任务，解决纷争，思考如何优化工做条件来提升工做效率和温馨度，这都须要时间。
• 作决策：随着职权的增长，技术经理须要花更多的时间放在各类各样战略上的统筹和计划等事务上。起初，也许只是一些技术方面的决策，但以后，产品开发和竞争策略方面的事务将会占去很大一部分。
• 招聘：经理，总监，副总们，CTO都须要组建本身的团队，有时须要迅速组建。一个好的招聘高手能带来很大帮助，技术经理在这样的事情上的做用是无可替代的。好的技术经理会活跃的跟上级保持沟通，不断的将本身团队中的优秀人士推荐出去。
• 客户：随着技术经理职权的增长，他们常常会对外抛头露面。他们会被带去参加“推销会”，指望他能带去一些有深度的话语。或当重要客户不高兴时被叫去灭火。
• 公关：资深技术经理会把一部分时间奉献给公开演讲，写博客，或者报刊上发表文章。不论你在这些活动中出了多少力，这些写做、编辑、排练、差旅、出席活动等都是花费时间的。

　　夺回时间：上面我说的这些活动都是一个技术经理应该投入时间的事情。下面要说的是我从经验中发现的一些陷阱，是它们在阻挡我努力保持20%最低限度的编码时间，至今仍站在我面前，妨碍我重回30%的目标。

• 敢于说不：高成就意味着要努力工做。然而，作事要稳妥，一个技术经理最重要的职责就是，当你的团队负担太重或接近这种状态时要敢于说不。若是你这个时候不说不，其余人就会开始对你的计划和工期承诺指手划脚。
• 开会：为如何高效的开会出谋划策已经成为了一帮人的职业，这是有其自身缘由的。个人职业生涯中浪费在会议中的时间算是最多的了。尤为是不断的面试或出席必须由团队首领出席的会议。

　　失败的策略

　　当在探索如何夺回个人编码时间时，有不少的方法并不奏效。

• 少睡：这种方式虽然对我有巨大的诱惑，但其实牺牲睡眠时间没有一点效果。你的大脑须要休息，缺乏睡眠会影响情绪并下降工做效率。
• 只看头文件：我觉得这种方法可行，但实践中，只看提交的C++代码的头文件对你的管理工做的帮助甚少。
• 专注：做为团队首领，你只关注代码库里的一个项目也许是能够的，但对于总监或更高级别的人来讲，你应该对负责的全部东西都要熟悉、了解。
• 委托：有时候为了多作工做，会将一些事情随意的交给他人作，但实际上一些像写报告这样的事情你必定要认真嘱咐才行。

　　成功的策略

　　尽管走了不少死胡同，我仍是发现了一些成功的方法：

• 时间分段：个人日程表上没有被预先分配的时间是很是少的。想起来这也是很显然的。因而我专门为编程特意分出一些时间段。实践中，这些时间段常常会被从新调整，虽然每周只挤出8小时，效果是彻底不同的。
• 委派：委派要有技巧，尤为是在你对如何执行抱有强烈想法并有能力去作时。有不少缘由致使一个经理反对将任务委托他人，但事实上每一个缘由都应该被看成一个现存的须要解决的问题，而不是一个不可逾越的障碍。没有什么比放手让一个你信赖的人替你主持一个会议能释放你更多的编码时间了。
• 工做时间：将时间分段，工做时间里尽可能避免打扰。在这些时间段之间的时间里，我会干一些不重要或不需求注意力长期集中的事情。

　　最后几招

　　下面是一些经验建议，送给那些发现本身试图达到30%但没法接近的技术经理们：

• 学习如何读代码。跟写代码比起来，这是一种彻底不一样的技巧。
• 指定会议流程，对会议进程保持控制。不参加任何没有计划的会议。
• 用一台好用的电脑。你喜欢MacBook Air？不，别用它。
• 清楚如何访问一个开发环境，这样当有修改时能够快速测试。
• 记住你是把一小时分红5个时间段使用的人。若是有事情须要一小时，在日程表上标明。
• 20–30%是我本身的发现。你的也许跟我不一样。评估你本身的(你修复一个紧急bug须要多少时间？你知道代码库中麻烦最多的程序是哪一块吗？随机找一段程序，看看你是否知道是作什么的。若是不能，说明你须要更多的时间)。
• 分类列出哪些事情何时作，哪些事情应该完成。(知道Getting Things Done (GTD)的人会看出这是提升工做效率的基本技巧。)
• 最后，我最近愈来愈喜欢在纸上看一些东西。看上去好像是一种倒退，好比把需求规范、须要优先实现的功能列表、甚至一段代码打印出来看，但相对于长时间盯着屏幕，这是一种平衡。

　　我但愿这些方法对大家有用。若是你有其它更好的技巧，请在评论里告诉我。谢谢。