Overhead isn't the enemy. Hiding it is.

A thing to think about as you read this: Overhead likely accounts for a double-digit percentage of your ROI, and most of it is invisible to you.

Every company I've worked with has had an unspoken rule: keep the overhead off the books. Meetings, syncs, context-switches, those hours you ironically spent tracking time ... some of it gets tracked, most of it gets baked into the broader context, and nearly all of it vanishes into the ether when it comes to calculating capacity, your ability to build towards the organization's goals.

I've witnessed firsthand how unaccounted-for overhead can cripple projects. Progress slows, meetings ramp up, debates spiral over rework, scope creep and lack of available capacity. When velocity dips into the danger zone everybody feels it ... but nobody sees it as chart or signal.

Overhead deserves both signal and context, because every bit of it costs.

Unaccounted Effort

In the pivotal DevOps-for-the-masses work The Phoenix Project, authors Kim, Behr and Spafford walk us through the life of Bill, a recently-promoted VP who must untangle the complex mess of large IT infrastructure that is choking the company's progress.

Central among the ideas put forth is the naming of 4 types of work (drawn from the earlier work of Taiichi Ohno and others).

In the book, mentor Erik guides our protagonist through the classifications, naming each and underlining how one affects the other. It is a stark irony, however, that the authors, much less hero Bill, never name the 'meta' that our protagonist is operating within. Endless hours in meetings, sketching out adhoc Kanban, travelling to and from the Manufacturing building, all of it unrecognized as a 5th type of work: Overhead.

Overhead is free-form, meta, the breathed everyday, so pervasive we ignore it like we ignore oxygen. Without it the organization could suffocate, and yet its existence is all but unaccounted for.

The Category of Work

I realized early in the development of AbleTime that one of my core objectives was failing to materialize. I had written a scenario that I wanted addressed by the software: "Angela" the lead designer wanting to attend more meetings, and lead developer "Casey" who wanted to attend less. Careful time tracking would prove it out, right?

Wrong. Time entries provide the when and how long. The description might mention the decisions, but the outcomes would all come afterward, unlinked and without context. If Angela attended developer standups, would her input complicate progress or increase understanding? Would Casey skipping meetings add uncertainty to the design?

The thing missing was context. You need to see the overhead in context to the tasks. Where it appears on the timeline, how it affects that day's output, whether the task durations quicken or drag forward. It was an evolutionary moment, where AbleTime graduated from "time tracking plus tasks, to time tracking against tasks".

What I ended up with was a distinct visual at the top of the timeline that measures overhead, the EQ shouting when the imbalance is loudest. Click in and it tells the story; every user, every hour. Sitting above the tasks and along the timeline, it tells the story of what paid the price on bad days, what got to breathe on the good ones. Green is the goal, yellow the signal, red the pain.

The best part? No extra work. Just record the time as usual, like you already do.

Visible Capacity

This hints at one more facet that I want to highlight, beyond accounting and capacity. A more pointed question is, whose capacity is being used? Angela and Casey are both leads, so if they are the ones who are always away, who's left doing the work?

When I worked at a digital services agency, I was constantly pulled into client meetings, specification reviews, design standups ... pretty much anything where a stakeholder wanted a "senior dev opinion". Then the PM would ask "why haven't we closed this feature yet?" Meetings were "goes with the job" expectations, but the capacity they consumed was unaccounted for in the project manager's mental ledger.

Overhead was the unseen bottleneck to our capacity. Identifying that, quantifying how significantly it impacted our delivery, was all based on opinion and estimate. The balance never improved.

So I made a thing that could prove it.