The Coordination Tax No One Has Calculated — And Why the Number on Your Team Will Surprise You

I used to think I was good at my job because I could hold an enormous amount of context in my head. Every week, I knew exactly where the numbers were, who hadn't sent their update yet, which team was behind on their Q2 targets, and what the CFO needed before Friday's leadership review. I was fast, thorough, reliable.

The week it crystallized for me, I mapped out everything I had done in six days that wasn't my actual job. There was the Monday standup to prepare for the Tuesday sync. The three Slack threads I had started to gather the inputs that would go into the deck I would spend Thursday building for the Friday meeting. The 90 minutes on Wednesday afternoon pulling sales numbers from Salesforce, pipeline updates from HubSpot, and sprint velocity from Jira into a single spreadsheet that I would immediately email to seven people, who would read it once and file it.

I was not doing work.

I was doing the administration of work.

None of it was what I was hired to do. All of it was what my job had become.

What I was doing had a name. I just didn't know it yet.

What Is Operational Overhead — The Definition Your CFO Is Waiting For

Operational overhead is the time, attention, and cost your organization spends on coordination rather than on the actual work of the business — status updates, reporting cycles, cross-team alignment meetings, data-gathering before reviews, and re-communicating decisions that should have been communicated once. Research consistently places this layer at up to 70% of management time. It is not a cultural problem or a motivation problem. It is a structural one, caused by the gap between where decisions are made and where work actually gets tracked.

This distinction matters. Operational overhead is not what happens when your team is disorganized. It is what happens when your organization's operating model requires humans to manually do what a connected system should do automatically.

When I Realized I Was the Overhead

There is a phrase that the team at Rhythms uses internally that stopped me cold the first time I heard it: the human API. It describes what happens when a person becomes the integration layer between disconnected systems — not because they chose to, but because the organization has no other mechanism for moving information from one place to another.

That was me. Every week, I was manually extracting data from tools that didn't talk to each other, reformatting it for an audience that needed it in a different shape, and distributing it through channels that had no memory of what had been shared before. I was overhead — in every accounting sense of that word.

I don't think I was unusual. I think most senior operators in fast-growing SaaS companies have spent meaningful portions of their week being exactly this. The role of Chief of Staff, VP of Strategy Ops, or COO at a 500-person company is often less about strategy than it is about making sure strategy-adjacent information reaches the right people in the right format at the right time. It is a coordination job masquerading as a leadership job.

The average enterprise now runs on 88 SaaS applications. Each of those applications captures something real about how the business is operating. But none of them talk to each other without a human in the middle. That human — the one who pulls the Salesforce pipeline, cross-references it with the Linear sprint data, layers in the Slack updates from last Tuesday's channel, and synthesizes the whole thing into a slide — that is operational overhead wearing a senior title.

The Math No One Has Run on Your Team

Here is the calculation I wish someone had shown me earlier. It is not complicated, but the output is almost always a surprise.

Take the number of people in your leadership team and extended management layer — the people who attend your weekly syncs, your business reviews, your QBR prep calls. Now estimate the percentage of their week that goes to coordination: gathering updates, reporting on status, attending meetings that exist to prepare for other meetings, chasing inputs across systems. For most teams I have worked with or spoken to, that number is somewhere between 40% and 60%. The Rhythms team's research puts it as high as 70% of management time lost to work about work rather than the work itself.

Then do the arithmetic. If you have 20 people in your management layer, each at $200,000 in fully-loaded annual cost, and half their time is going to coordination, you are spending $2 million every year on the overhead layer alone.

Most finance leaders can tell you their SaaS spend to the dollar. Very few have ever run this calculation. That gap — between the cost visible on a software bill and the cost invisible in burned management hours — is where operational overhead lives.

This is the cost that Rhythms' Playbooks feature was built to eliminate. Not by asking teams to update status in a separate tool, but by pulling it automatically from the tools where work already lives. When your review generates itself from live Salesforce, Jira, and HubSpot data, the 90 minutes I used to spend on Wednesday afternoon building that spreadsheet simply disappears. The information is still there. The labor is not.

Why Tactical Fixes Don't Hold

When operational overhead becomes visible, the instinct is to treat it at the symptom level. No-meeting Wednesdays. Async-first policies. Tighter agendas. Fewer recurring syncs. These interventions are not wrong — they are just not structural. The overhead is still there. You have changed when it happens, not why.

I have seen no-meeting Wednesdays work beautifully for about six weeks. Then Thursday becomes Tuesday, the biweekly sync creeps back to weekly by month two, and by month three you are exactly where you started except now there is a channel called #async-updates that 30% of people actually check.

The reason tactical fixes don't hold is that they treat coordination as a behavior problem when it is actually a systems problem. As long as context lives in 88 different applications with no connective tissue, someone has to manually move it. If that someone is a calendar invite, it is a meeting. If it is a Slack message, it is noise. If it is a person with a senior title, it is overhead. The mechanism changes. The structural requirement does not.

This is exactly why the organizations whose operational overhead meaningfully decreases don't do it through policy — they do it by removing the structural gap that made manual coordination necessary in the first place. We built Rhythms for this: when Reviews generate themselves from live data across every connected system, the overhead doesn't migrate to Thursday. It stops existing as a task anyone needs to perform.

You cannot discipline your way out of a system design problem. A team with better communication habits will always outperform a team without them — but even the most disciplined team, operating in a fragmented tool environment, will produce overhead as a structural byproduct. The discipline returns the same result as long as the system produces the same incentives.

What Reducing Overhead Actually Requires

The fix is architectural, not behavioral. The architecture is simpler to describe than it is to build: you need a layer that handles coordination automatically, so that humans are involved only when a decision needs to be made.

This is different from automation in the task sense. Not macros that send a Slack message when a Jira ticket closes. A system that understands your operating cadence — what reviews happen when, what decisions they require, what data feeds them — and runs that cadence without needing a human to manage it.

When I say "the layer that runs coordination automatically," I mean specifically what Rhythms does: Goals & Alignment updates cascade in real time, so a CEO decision on Tuesday doesn't require 14 Slack messages by Friday. Radar surfaces off-track initiatives on day three rather than day thirty, so the Chief of Staff is not the last person to know about a slipping initiative. The operational machinery runs on the system, not on the person who used to hold it together.

The output of that architecture is not just fewer meetings. It is a fundamentally different kind of leadership job. When the coordination layer runs itself, the senior operators in your organization can spend their time on the decisions and relationships that require human judgment — which is, presumably, what you hired them for.

Most organizations are one architectural conversation away from recovering 20 to 30 hours per week across their leadership team. The calculation is sitting in your payroll data, waiting to be run.

The Part I Still Think About

I am better at my job now than I was when I was holding all the threads. That sounds obvious written down. It was not obvious to live through. For a long time, I thought the holding of the threads was the job — that being the person who knew where everything was, who had read every update, who could answer any question in the Monday morning meeting, was the definition of operational excellence.

It is not. It is a symptom of an operating model that has not been designed for the scale it is trying to run at. The goal is not to become very efficient at moving information between disconnected systems.

The goal is to not be that person at all.

There is a version of this job where Sunday is not about building Monday's deck. If you are still the one your organization routes information through because there is no other path, I am not going to tell you there is an easy answer. But I will tell you that the first time the coordination layer runs itself, something shifts in how you understand what your role is actually supposed to be — and what you could be doing instead.

If you're still the human API for your organization, try Rhythms for free at rhythms.ai.

Frequently Asked Questions About Operational Overhead

What is operational overhead in business?

Operational overhead is the time, cost, and attention an organization spends on coordination rather than on the work of the business itself — status update collection, reporting cycles, cross-team alignment meetings, and re-communicating decisions. Research consistently places this layer at up to 70% of management time in most organizations. It is a structural cost, not a cultural one: it scales with organizational complexity and tool fragmentation, and it does not decrease because people try harder or meet less often.

How do you calculate what operational overhead is costing your team?

The straightforward version: multiply the number of people in your management layer by their average fully-loaded annual cost, then multiply by the percentage of their time that goes to coordination rather than direct execution. For a 20-person leadership team at $200,000 average fully-loaded cost, with 50% of time going to coordination, the annual overhead cost is $2 million. Most organizations have never run this number. Running it is often the thing that moves operational overhead from a vague problem to a budget conversation.

What's the difference between operational overhead and just having a lot of meetings?

Meetings are one symptom of operational overhead, but the definition is broader. Operational overhead includes everything your organization spends on coordination — meetings, yes, but also the asynchronous data-gathering that precedes meetings, the status messages that substitute for meetings, the deck-building that prepares for meetings, and the re-communication that follows them. You can eliminate every recurring meeting and still carry enormous operational overhead if the underlying structural problem — fragmented context, no automated information flow — remains.

How do companies reduce operational overhead without losing visibility?

The key distinction is between visibility and the labor of producing visibility. Most organizations generate visibility by having humans manually aggregate, format, and distribute information from multiple systems. That labor is overhead. The alternative is a coordination layer that produces visibility automatically — pulling live data from connected tools, surfacing what needs a decision, and distributing status without requiring anyone to compile it. Visibility goes up. The cost of producing it goes down. These are not in tension; they just require a different operating architecture.