What is engineering overhead?
Put simply engineering overhead is "any activity that a developer performs that is not being tracked in the current sprint". Examples include, email, chat, managing issues, meetings, etc. In my experience meetings are the biggest contributor too high engineering overhead.
Setting overhead goals.
How much overhead is the company comfortable with? I've experienced anywhere from 10-40% depending on the situation. In general I will shoot for 20%. That equates too 8 hours a week.
How did I come up with 20%?
If you assume that the average engineer spends 1 hour a day managing e-mail, chat, commenting on issues, etc… that leaves 3 hours a week for everything else (meetings, customer calls, supporting other team members, etc). Considering that the average agile team has the following overhead as part of the process:
| Meeting description | Minutes per week |
|---|---|
| Stand-up (15 minutes/day) | 75 |
| Sprint planning (1 hour/every two weeks) | 30 |
| Retrospective (1 hour/every two weeks) | 30 |
| Total | 135 |
That means our 'planned' overhead is 435 minutes/week. That leaves 45 minutes of un-planned overhead.
In actuality 20% overhead is really hard to hit so if you are near it you are doing great!
How do you track overhead?
Like anything you need to develop metrics. There are a couple of ways you can tackle this issue. Honestly, I recommend both as they are both important metrics for an engineering team.
Engineers need to track time
I know this is an 'un-popular' statement and I intend to write another blog about the importance of time tracking in the future. Put simply, engineers need to track time spent on "planned" engineering work. This is relatively simple to do with most tools available today. Using this information you can calculate your engineering overhead. Basically your overhead = (available work hours) - (tracked time). If your overhead is 20% or less that's probably all you need to know. Of course if this changes over time you need to understand why.
Look at your teams calendars
I believe that the biggest killer too your overhead metrics are meetings. As a manager I have access to all of my direct/in-direct reports calendars (you should too). A weekly or monthly review is another indicator of if there is a problem or not. You could go so far as developing a script which calculates your teams total time spent in meetings (by department) if you like. Honestly this is the most accurate way too determine how much time your team (individually and collectively) is spending with whom.
By reviewing your teams calendars you can step in and manage the situation if your engineers are being invited to poorly planned meetings.
Final thoughts
As a manager it is important to support your employees. I encourage my engineers too use discretion when attending meetings. I tell them "Don't go too a meeting just because you are invited (unless I invited them)". Encourage them too determine if they can contribute and it will be a valuable use of everyone's time. Of course this is difficult/impossible to do if the meeting is not properly managed. You do have meeting standards don't you? I smell another blog post coming.