The author of this article, Eliot Horowitz , is the founder and technical director of MongoDB .
In a tech company, software technical managers should spend no less than 30% of their total working time on programming. Whether managing a team, a division, or an entire company, when a technical manager spends less than 30% of his time programming, his ability to perform his duties is severely degraded.
This assertion of mine is probably the exact opposite of what I've seen from software programmers who want to be team leaders. With each promotion, programmers expect a significant reduction in the amount of time spent coding, and when climbing from "leader" to "manager" positions, they should be completely out of coding activities. Also, they expect to maintain familiarity with the codebase in a "mouth/eye" way. The higher-level leadership has absolutely nothing to do with coding (if there is one).
About a year ago, when my time was occupied by more and more other things, such as recruitment, management, meetings, etc.; I found that as a technical leader, when the time spent on programming fell below a certain percentage, There will be problems with management effectiveness and work efficiency. I wrote a short blog about this experience and point of view before, but did not expand on the specific description. Here, I will discuss this point in more detail.
Why stick to programming activities
Many people believe that as a manager, you should step back from the front line of battle and focus on grand strategy and management. Of course, managers should spend most of their time on this sort of thing. But, in an industry like ours, where we allow or require managers to almost stop programming, reality costs us dearly. Once a person stops coding, the important connection between him and the things programmers care about degenerates. When this happens, decision-making, planning, and cadre relationships go awry, undermining the foundation of a good desire to elevate technicians to management positions.
Project Development Evaluation Capability
One of the most important tricks in a programmer's treasure chest is estimating construction time. Without the ability to accurately estimate, the overall plan cannot be correctly introduced. As we all know, as a group, programmers are notorious for estimating duration. It couldn't be worse, in fact, when getting an estimated number from a programmer's mouth, the accepted method is to multiply it by two. Usually, programmers have a very optimistic view of development work, but if we use the "estimate traction" theory, we find that programming activities exhibit particularly volatile characteristics. Because I can implement a function in many ways, our estimates are unreliable until we get into the details.
technical debt
Another thing is that the technical manager must have first-hand knowledge of the impact of technical debt on the project. The term technical debt is very popular these days and is often used as ammunition for debating whether to prioritize developing new features or refactoring old code first. People familiar with the connotations of the term "technical debt" are usually the easiest to start a debate. As a technical manager, you don't just have to be familiar with the concepts, they play a direct role in your decisions about when to pay off your technical debt. Managers who code frequently have more and more valuable information to judge when/how to make such decisions.
informed continuity
I didn't choose the 30% ratio at random. I'm based on my own experience, spend enough time in development activities that you can easily stay on top of any changes to the codebase. If you have too little time, your grasp of the dynamics of development will be choppy and unconnected. Once the line is disconnected, I need to rewire the context, and the penalty for this is wasting extra time.
shared responsibility
As the person in charge, you cannot have all decisions made or approved by you. But you need to understand the context and context of all decisions to aid those decisions. Ultimately, you are responsible for the consequences of these decisions, and your control over the project situation should match your responsibility.
Actively participate in programming to earn the respect of the team
Everyone needs to understand: To be a successful manager, you need to serve your team members, facilitate development, and make sure they get things done. I wrote in a blog post how to diagnose and fix problematic cadre relationships for managers. But for management programmers, you need to love programming. Because your team is programming, and if you set an example in programming, they will all hold you in awe.
Reach 30% Barrier
尽管付出了最大努力，我仍然在保持30%的编码时间上遇到了很多的阻碍。包括下面这些：
工作繁多：在一个创业公司里，你总有忙不完的工作需要去做，即使在公司有规模、壮大后，如何对众多都很重要的事情排优先级也是一种考验。技术经理有很多职责，完全会占满他的70%的时间。下面就是一些：
- 领导和照顾团队：这是一个技术经理的第一要务。你已经不能够只为自己的工作负责，你要为你的团队能保持最好的工作状态负责。指导团队任务，解决纷争，思考如何优化工作条件来提高工作效率和舒适度，这都需要时间。
- 做决策：随着职权的增加，技术经理需要花更多的时间放在各种各样战略上的统筹和计划等事务上。起初，也许只是一些技术方面的决策，但之后，产品开发和竞争策略方面的事务将会占去很大一部分。
- 招聘：经理，总监，副总们，CTO都需要组建自己的团队，有时需要迅速组建。一个好的招聘高手能带来很大帮助，技术经理在这样的事情上的作用是无可替代的。好的技术经理会活跃的跟上级保持沟通，不断的将自己团队中的优秀人士推荐出去。
- 客户：随着技术经理职权的增加，他们经常会对外抛头露面。他们会被带去参加“推销会”，期望他能带去一些有深度的话语。或当重要客户不高兴时被叫去灭火。
- 公关：资深技术经理会把一部分时间奉献给公开演讲，写博客，或者报刊上发表文章。不论你在这些活动中出了多少力，这些写作、编辑、排练、差旅、出席活动等都是花费时间的。
夺回时间：上面我说的这些活动都是一个技术经理应该投入时间的事情。下面要说的是我从经验中发现的一些陷阱，是它们在阻挡我努力保持20%最低限度的编码时间，至今仍站在我面前，妨碍我重回30%的目标。
- 不勇于说不：高成就意味着要努力工作；然而，做事要稳妥，一个技术经理最重要的职责就是，当你的团队负担过重或接近这种状态时要勇于说不。如果你这个时候不说不，其他人就会开始对你的计划和工期承诺指手划脚。
- 开会：有一个巨大的家庭手工业行业都在为如何高效的开会出谋划策，这是有其自身原因的。我的职业生涯中浪费在会议中的时间算是最多的了。尤其是不断的面试或出席必须由团队首领出席的会议。
失败的策略
当在探索如何夺回我的编码时间时，有很多的方法并不奏效。
- 少睡：这种方式虽然对我有巨大的诱惑，但其实牺牲睡眠时间没有一点效果。你的大脑需要休息，缺少睡眠会影响情绪并降低工作效率。
- 只看头文件：我以为这种方法可行，但实践中，只看提交的C++代码的头文件对你的管理工作的帮助甚少。
- 专一：作为团队首领，你只关注代码库里的一个项目也许是可以的，但对于总监或更高级别的人来说，你应该对负责的所有东西都要熟悉、了解。
- 委托：有时候为了多做工作，会将一些事情随意的交给他人做，但实际上一些像写报告这样的事情你一定要认真嘱咐才行。
成功的策略
尽管走了很多死胡同，我还是发现了一些成功的方法：
- 时间分段：我的日程表上没有被预先分配的时间是非常少的。想起来这也是很显然的。于是我专门为编程特地分出一些时间段。实践中，这些时间段经常会被重新调整，虽然每周只挤出8小时，效果是完全不一样的。
- 委派：委派要有技巧，尤其是在你对如何执行抱有强烈想法并有能力去做时。有很多原因导致一个经理反对将任务委托他人，但事实上每个原因都应该被当作一个现存的需要解决的问题，而不是一个不可逾越的障碍。没有什么比放手让一个你信赖的人替你主持一个会议能释放你更多的编码时间了。
- 工作时间：将时间分段，工作时间里尽量避免打扰。在这些时间段之间的时间里，我会干一些不重要或不需求注意力长期集中的事情。
最后几招
下面是一些经验建议，送给那些发现自己试图达到30%但无法接近的技术经理们：
- 学习如何读代码。跟写代码比起来，这是一种完全不同的技巧。
- 指定会议流程，对会议进程保持控制。不参加任何没有计划的会议。
- 用一台好用的电脑。你喜欢MacBook Air？不，别用它。
- 清楚如何访问一个开发环境，这样当有修改时可以快速测试。
- 记住你是把一小时分成5个时间段使用的人。如果有事情需要一小时，在日程表上标明。
- 20–30%是我自己的发现。你的也许跟我不同。评估你自己的(你修复一个紧急bug需要多少时间？你知道代码库中麻烦最多的程序是哪一块吗？随机找一段程序，看看你是否知道是做什么的。如果不能，说明你需要更多的时间)。
- 分类列出哪些事情什么时候做，哪些事情应该完成。(知道Getting Things Done (GTD)的人会看出这是提高工作效率的基本技巧。)
- 最后，我最近越来越喜欢把东西写到纸上。跟感觉上相反，打印出来的说明，把一些需要排优先级的任务列在纸上，或者是一段代码，经常的，它会成为把大量时间盯着屏幕的一种平衡。
我希望这些方法对你们有用。如果你有其它更好的技巧，请在评论里告诉我。谢谢。
原文地址：http://www.vaikan.com/engineering-managers-should-code-30-of-their-time/