Channels ▼
RSS

Design

Engineering Managers Should Code 30% of Their Time


No software engineering manager at a tech company should spend less than 30% of his or her time coding. Whether managing a team, a division, or all of engineering, when managers spend less than 30% of their time coding, they encounter a significant degradation in their ability to execute their responsibilities.

My claim stands in stark contrast to what I see as the expected path for software engineers who become team leaders. At each promotion, the engineer is expected to spend drastically less time coding, with a particularly steep drop-off when they go from a "lead" to a "manager" title. At that point, they're expected to maintain passing familiarity with their codebase. A director's coding is done, if at all, as a hobby.

This happened to me about a year ago as more of my time became absorbed in other things, such as recruiting, managing, and strategizing; I found then that I had crossed a threshold where my effectiveness as a technology leader suffered out of proportion to the amount of coding time lost. I wrote a short post on my blog that presented my thoughts following that experience, but without much concrete detail. Here, I'd like to expand that into a more developed thesis.

Why You Should Keep Coding

Many people believe that managers should step back and concentrate entirely on strategy and management. It makes sense that managers are expected to spend the majority of their time on these things. But as an industry, we pay too high a price for our managers when we allow or demand that they barely spend time coding. Once a person stops coding for a significant portion of time, critical connections to the concerns of developers atrophy. When that happens, decision-making, planning, and leadership suffer, undermining the entire basis for promoting engineers to management positions.

Estimates

One of the most important skills in an engineer's toolkit is estimation. Strategic planning is quite simply not possible without the ability to accurately estimate. And yet we engineers are, as a class, notoriously bad at it. So bad, in fact, that we are advised to just double whatever number we come up with when asked to estimate something. In general, it's easy to fool oneself into thinking that things will go optimally, but if we use the concept of "estimate traction," code appears to have a particularly slippery surface. Because there are so many ways to implement features, when you lose familiarity with the details, your estimates become even more unreliable.

Technical Debt

Another thing that engineering managers need first-hand exposure to is the impact of technical debt. These days, that term has been popularized enough that when you have to debate the priority of a new feature versus. refactoring, you have a good chance of having that debate with people familiar with the concept. Engineering managers need to be more than familiar with the concept — they are the ones directly responsible for making the judgment call as to when technical debt needs to be paid down. A manager who codes regularly will have much better information on when and how to make that decision.

Continuity of Understanding

I haven't chosen the number 30% arbitrarily. I chose it based on my experience because it is a simple heuristic for enough time to keep up with the changes that happen in a codebase under active development. With less time, it's easy to lose the thread of development; and once that thread is dropped, I will need to ramp up all over again to retrieve it, thereby incurring an extra time penalty.

Parity with Responsibility

As a leader, you definitely should not be making all the decisions for your team, or approving all the decisions, but you need the context and the knowledge to facilitate all decisions. In the end, you are responsible for the outcome, and your ability to sensibly make choices should match that responsibility.

Your Team Respects You For Loving Code

Let's be clear: To be successful as a manager, you must facilitate your team members' efforts, foster their development, and ensure they are fulfilled by their work. I've been writing about how to diagnose and repair issues with poor managers on my blog in a series called Debugging the Boss. But to truly excel at managing software engineers, you had better love code. Because your team does, and they will respect you all the more if you lead by example.

Obstacles to Reaching 30%

Despite of my best efforts, I have run into many obstacles trying to maintain my coding time at 30%. These include the following.

Actual Responsibilities: At a startup, there is always more work to do than there is time to do it, and even as a company scales and matures, being as effective as possible is always an exercise in managing competing priorities. An engineering manager has many responsibilities, which should take up 70% of their time. Here are a few:

  • Leadership and Team Tending: This responsibility is the first to appear in an engineering manager's career. You are no longer just responsible for your work, you are responsible for enabling your team to produce their best work. It takes time to mentor your team, resolve disputes, and think about how to optimize their environment for happiness and productivity.
  • Strategy: As the level of responsibility grows, an engineering manager is required to spend more time contributing to strategic planning at various levels. Initially, this will be limited to tech strategy, but later, both product development and competitive strategy will play a large part.
  • Recruiting: Managers, directors, VPs, and CTOs need to build their teams, sometimes quite rapidly. While a good recruiting staff is a help, there is no substitute for a strong leader who actively seeks out new connections and sells every good engineer they meet on how great it is to work on their team.
  • Customers: As engineering managers gain responsibility, they will often become more external-facing. This means they're brought in "pitch meetings" with high-value prospects and called on for firefighting when important customers are unhappy.
  • PR: Senior tech managers devote time to public speaking engagements, writing blog posts, and (of course) articles in prestigious tech journals. No matter how much help you have with these tasks, it takes time to write, edit, rehearse, travel, and present.

Avoidable Time Losses: The responsibilities I just discussed are what an engineering manager should be spending time on. These next areas are pitfalls I've experienced that have been my undoing when trying to maintain a bare minimum of 20% of my time spent coding, and which still stand between me and the 30% I am fighting to return to.

  • Not Saying No Enough: Achieving great things means working hard; however, growth has to be sustainable, and one of the most crucial responsibilities of an engineering manager is to say "no" when their team is over-committed or on the verge of becoming so. When you don't say no, other people begin to dictate your schedule and time commitments.
  • Meetings: An entire cottage industry exists to give advice on how to meet effectively, and justifiably so. I have wasted more time in meetings than any other single activity in my career. This is especially debilitating when you have fallen behind in hiring, and are attending meetings that really should be run by team leaders.

Failing Strategies

In my quest to regain my coding time, I have tried a number of things that have not worked.

  • Sleep Less: While surprisingly alluring for me, sacrificing sleep doesn't work. Your brain stops working and you become unpleasant to be around and much less effective.
  • Read Headers Only: I thought this was promising, but in practice, reading only the headers of C++ code commits gets you very little of the benefit you need for management.
  • Overspecialization: Knowledge of only one project in your overall codebase is appropriate for a team lead, but not a director or above — you need familiarity with everything you are responsible for.
  • Delegating Too Much Too Early: It's easy to make more work for yourself by delegating recklessly when your reports actually need careful mentoring.

Successful Strategies

In spite of numerous dead-ends, I have managed to uncover some successful strategies:

  • Time Blocking: The percentage of time on my calendar that is not allocated weeks in advance is minuscule. It seems obvious in hindsight, but I needed to allocate blocks of time specifically for coding. In practice, these blocks are frequently rebooked, but having even 8 hours blocked out per week makes an enormous difference.
  • Delegating: Delegating is tricky, especially when you have very strong opinions about how tasks should be done and the ability to do them if you had the time. There are many reasons why managers resist delegating, but every reason has to be viewed as a problem to be solved, rather than an insurmountable barrier. Nothing frees up your time for coding like handing off running a meeting to someone you trust.
  • Office Hours: Something I'm planning on instituting in the near future is office hours. This technique should help a lot with the random interruptions by consolidating them into discrete time windows, during which I can work on the many tasks I have that do not require committed, long-term focus.

Final Tips

Here are a few points of practical advice for managers finding themselves approaching, but not getting across, the 30% threshold:

  • Learn how to read code. It's a different skill than writing it.
  • Commit to a meeting structure and hold your organization to it. Do not attend a single meeting that does not have a defined agenda.
  • Get a real machine to work on. That MacBook Air you love for meeting hopping? Not it.
  • Know how to access a dev environment and test a change fast.
  • Understand if you're the kind of person who can use five 20-minute blocks. If you need an hour, then put it on your calendar.
  • Remember, 20–30% is a heuristic I've come up with for myself. Your mileage may vary. So measure yourself (Estimate how long it would take you to try out a hot fix; Can you list the most indebted areas of your codebase? Pick a random code review and see if you understand the conversation and the choices. If you don't, you need to dig in more).
  • Categorize your work by when you can work on it and what you need to accomplish it, rather than by topic. (Advocates of Getting Things Done (GTD) will recognize this as the essential basis of their productivity technique.)
  • Finally, I've lately become fond of getting paper homework. As backwards as it seems, printing out a spec, a list of features to prioritize, or even a block of code is often a nice balance to spending large amounts of time looking at a screen.

I hope these tips are useful. If you have other techniques that have worked for you, please leave them in the comments area.


Eliot Horowitz is the cofounder and CTO of MongoDB.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Comments:

ubm_techweb_disqus_sso_-b04288990863dd71baa6656dc9b4a102
2014-03-15T20:32:21

Fantastic article. I will absolutely carry your ideas into my next management role.

Here's another time sink: email. After becoming a Software Director, I found myself swamped with it. Here's the solution I saw my boss use: Create a "CC" folder and send all the mail there automatically when you are "CC'd". Then tell everyone that if they want you to take action on something or if the info is critical, to make sure that you are on the "To" list. But tell everyone to "CC" you about everything anyway. Once in a while I would go through the "CC" list and I found that 95% of the time I knew what was discussed there anyway, and didn't need to respond or even keep up with it. Reduced my email inbox by 60%.
Also - I found that I was getting customer support emails from 8 different business areas for which my group was responsible. Was there no other system to track them? I created a system using a web-based ticket tool (like bugzilla but better) and required all of the interested parties to fill out tickets. Then I delegated managing to the tickets and no more support email!

BUT REALLY, staying in the code is critical. At the line manager level, I think 30% should be required, but as a Director, even 15%-20% makes a huge difference. I made the same mistakes OP did, but not again!


Permalink
ubm_techweb_disqus_sso_-9323c3011892751b33193b386c38021f
2014-01-28T22:15:12

Agree with that, a non coding and architect does not have the knowledge to make decisions that will guide the development teams.


Permalink
ubm_techweb_disqus_sso_-9323c3011892751b33193b386c38021f
2014-01-28T22:14:31

This article seems to assume you are working for a startup or at least a product centred organisation. the vast majority of programmers and their managers work in corporate environments and a project managers role in a major project is far too time consuming to get back into coding,

My own experience of this was when I was a programmer on a large project and the project manager did some coding. But the project team was approx 50 strong and it was a complex and demanding customer. It took me longer to unpick the mess he made than it would have done to code the thing myself.

Project management is a skill in its own right, especially in the large corporate world, and the best PM runs interference for his team and facilitates them to do of their best. MOst programmers of my experience are quite happy with a non coding manager provided he keeps them effective and stops other management from interfering and making stupid decisions. When you are a non coding manager though you had better be very good at the management role...


Permalink
ubm_techweb_disqus_sso_-a63f4d2f350918700b569e3f33055eb5
2014-01-23T15:34:48

I have tried different types of coding. One that doesn't work for sure is side projects. While fun and good at keeping up with languages and libraries, it doesn't help with the code base.

I do agree that fixing bugs is probably better than adding features. Currently a lot of my coding time is going towards refactoring some of the oldest code and fixing bugs while doing so.


Permalink
ubm_techweb_disqus_sso_-a63f4d2f350918700b569e3f33055eb5
2014-01-23T15:32:47

Colin,

100% agree that the manager's main job is to make their engineers more productive and make sure the products are delivered. The thing I'm unsure of is that goal is possible without working on the production code.

Being active on your team's codebase does not necessarily make you a bottleneck, though. You need to approve every commit, or keep your team away from the hard problems. If you've done the other part of your job well, you've hired engineers you respect and trust, and give them real ownership of the projects they work on.


Permalink
ubm_techweb_disqus_sso_-6101f2cb1dd5ff7ac03be1528c04bf46
2014-01-15T17:12:46

Good article Eliot. I was a manager and/or director of software for several of the companies that I worked for. Thinking back, i would say that I was the happiest and most effective at this in the jobs where I had at least 25% involvement in coding. I would like to list here some tips/techniques that worked for me.
1. As a manager new to a company or group, it is very important to quickly assess each of your direct reports for both technical ability and psychological balance. By the latter what I mean is to assess whether the employee is a psychologically balanced individual who is self-motivated, or whether he/she will require more of your time. Looking at prior performance reviews may help. After having made this assessment, the manager needs to also find out the strengths, including technical likes/dislikes of each employee. Spending time early on in this type of assessment goes a long way in building an effective team where you can assign to each employee tasks that they are good at and like, making them more effective.
2. Maintain a good work/personal life balance which of course does vary with the individual. When you find your balance stick with it, and also be an example to your employees, encouraging them to find their balance as well. This leads to happier employees who are more satisfied with their work and workplace.


Permalink
ubm_techweb_disqus_sso_-348efa56fd1b73126357f3de2bf139f7
2014-01-15T10:39:05

Totally agree with the concept. Not sure about the right amount of %.

In my current company we have a different products(iOS,Android, Server etc), what I'm trying to do is to take a part (even a very small one) as a coder in each and every one of this projects. One thing to remember, tasks that are taken by a manger should never ever be in the project critical path.


Permalink

2014-01-15T10:28:04

Totally agree with the concept. Not sure about the right amount of %.
In my current company we have a different products(iOS,Android, Server etc), what I'm trying to do is to take a part (even a very small one) as a coder in each and every one of this projects. One thing to remember, tasks that are taken by a manger should never ever be in the project critical path.


Permalink
ubm_techweb_disqus_sso_-93406c21fed826554d39726f5219d6bd
2014-01-14T23:55:32

Have you tried different types of coding to see if they are better or worse at addressing the reasons you list for why managers should code? I'm curious if fixing bugs would work well, particularly if one chooses bugs in different code bases and feature sets. I think fixing bugs would be a good way to ensure one has a good understanding of the impact (and level) of technical debt, ensure continuity of understanding and earn respect (and gratitude) from the team.


Permalink
ubm_techweb_disqus_sso_-3d5c2f8c937c79a8938fe1aa213eb1c6
2014-01-14T23:06:22

I think this is a very slippery slope. I have seen far too many dev managers / directors / vpe / cto's who code cause more problems than they contribute. Chiefly among the problems are:

-managers quickly become bottle necks
-engineers never become empowered to solve their own problems when someone 'more senior' can come to the rescue
-engineers are afraid to point out problems in the code for people who are 'more senior'

A manager's job is to make the engineers more productive and make sure the projects are delivered. This requires them to be extremely technical and keep up with the systems, but contributing production code is quite another horse.


Permalink
ubm_techweb_disqus_sso_-09a9d031ab1ec9d0e017141b26dbb45e
2014-01-07T23:22:10

The headline for this article grabbed me!

I was a USAF officer and an EE. I loved the requirement that the USAF had, that the commander of any flying unit MUST have wings and keep them up to date - on aircraft that his unit currently used (not the Wright Flyer, or whatever the commander flew back when he was a line pilot).

I've believed that this is absolutely a good requirement for technical managers. I think 30% is a bit much, however, for top level management, but for first level managers, this might be appropriate. The boss needs to understand what that boss' team is developing. And, particularly, the boss needs to realize how much time it really takes to develop quality code. Managers I've encountered typically try to get developers to cut their estimates and shorten their schedules. (When I finally became a Director, I ensured that my managers DID NOT reduce their engineer's estimates.)


Permalink
ubm_techweb_disqus_sso_-820e2fd56579310beaab2f624b3f0088
2014-01-07T21:52:31

Agree 100%
It is even more important for architects


Permalink
hackworks
2014-01-07T21:27:30

This is a very nice article. I wish I was allowed to spend my 30% time coding when I was a manager, I would have continued a career in the management. Since I did not get enough time to write code, I moved back to an individual contributor - engineer/programmer role.
Hope the industry matures and realizes the need to allow managers stay close to the trenches (coding)


Permalink

Video