Ask an IT manager to list their technical debt and you’ll get a familiar catalogue. Legacy code. Ageing frameworks. That database schema nobody wants to touch. Missing tests. A build pipeline held together with hope.
Nobody lists Tuesday’s stand-up, the mid-morning sync, the pre-meeting for the afternoon meeting, or the recurring hour that has outlived the project it was created for.
They should. Because when you look at what technical debt actually is, a shortcut in how the work gets done, taken for short-term convenience and paid back with interest, a bloated meeting calendar fits the definition perfectly. At Enduring IT we define technical debt simply: anything that impacts throughput or stability. A calendar that leaves your best engineers barely two clear hours a day impacts both.
Process debt is a real category of technical debt
This isn’t a stretched metaphor. In the widely cited ontology of technical debt by Alves and colleagues, process debt sits alongside code, architecture, design, test, documentation and eight others as one of thirteen distinct types. It’s a recognised category, not a rhetorical device.
Process debt is what accumulates when the way a team works becomes inefficient, outdated, or poorly suited to the work at hand, and nobody fixes it because fixing it isn’t anyone’s job this sprint.
A recurring meeting created for a good reason in March, still running in November after the reason evaporated, is process debt. A decision-making culture that requires six people in a room because nobody is trusted to decide alone is process debt. A stand-up that has become a status report to a manager rather than a coordination mechanism for a team is process debt.
And like every other form of technical debt, it compounds. Nobody cancels a meeting. Meetings only ever get added.
The throughput maths is brutal and obvious
Start with the arithmetic, because it’s the part that’s hardest to argue with.
A developer with four hours of meetings in an eight-hour day has, at best, four hours left for development. That’s a 50% reduction in capacity before you account for anything else. Multiply that across a team of eight and you’ve removed the equivalent of four full-time engineers from your delivery capability, while continuing to pay for all eight.
If you’re tracking DORA metrics, this shows up directly in deployment frequency and change lead time. Less time writing, reviewing and shipping code means fewer changes shipped, and each change taking longer to get from commit to production. The team hasn’t got worse at engineering. They’ve just been given less time to do it.
What makes this insidious is that the cost is invisible on any budget line. The meeting is free. The room is free. Everyone’s salary is already being paid. The four engineer-days you burned last week appear nowhere in a P&L, which is precisely why they keep getting burned.
But the fragmentation is worse than the total
Here’s the part most organisations miss entirely, and it’s the part that matters most.
Four hours of meetings is not the same cost as four hours of meetings. It depends entirely on where they land.
Consider two engineers, both with four hours of meetings on Wednesday:
- Engineer A has meetings from 9am to 1pm, then an uninterrupted afternoon.
- Engineer B has meetings at 9:30, 11:00, 1:30 and 3:00, each lasting an hour.
On a timesheet, these two people are identical. In reality, Engineer A has a four-hour block of genuine focus time and will get real work done. Engineer B has four fragments of roughly 60 to 90 minutes, and will get almost nothing meaningful done at all.
Why? Because software development is not a task you resume. It’s a state you enter.
Non-trivial engineering work requires holding a mental model in your head: the call stack, the data flow, the edge cases, the three files you need to change together, the reason the last person did the strange thing on line 240. Building that model takes time, and research on task resumption and interruption consistently shows that recovering from a significant interruption takes considerably longer than the interruption itself.
Now watch what happens to Engineer B. At 10:30 the meeting ends. They start rebuilding context. By 10:50 they’re beginning to get somewhere. At 10:55 they check the clock, see the 11:00 meeting, and decide it isn’t worth starting anything. So they answer some emails.
They’ve had 30 minutes of nominal work time and produced nothing, and (this is the crucial bit) they’ll do the same thing before the 1:30 and again before the 3:00. Every meeting doesn’t just consume its own hour. It poisons the 30 to 45 minutes ahead of it, because nobody starts hard work they know they’ll be pulled out of.
This is why “the meeting is only 30 minutes” is one of the most expensive sentences in software delivery. A 30-minute meeting at 11am can comfortably cost two hours of engineering capacity. A well-placed one at 9am costs 30 minutes.
Context switching has a cognitive cost you’re already paying
Every switch between contexts imposes a tax. Not a metaphorical one, a measurable degradation in performance as attention is dragged from one mental model and forced into another.
Worse, the residue lingers. Attention doesn’t cleanly detach from the previous task; a portion of it stays behind, chewing on the thing you were just doing. A developer who has just come out of a fraught roadmap discussion carries that discussion into the next 20 minutes of code review, whether they want to or not.
Meetings are the single largest source of scheduled, mandatory, unavoidable context switches in a software organisation. They are switches you have chosen to impose, calendared in advance, and made socially impossible to decline.
Your support processes are hiding debt too
This isn’t only a developer problem, and it’s where IT managers tend to feel it most. Look at how the service desk actually runs.
Weak incident management shows up as the standing bridge call: the war room that reconvenes every time something breaks, because there’s no clean runbook and no clear owner, so the fix is “get everyone on a call and talk until it’s better.” That’s process debt, and the meeting is the interest payment.
Weak problem management is worse, because it compounds into defect debt, another of the thirteen types. Problem management exists to find and kill root causes. When it doesn’t happen, the same incident recurs, and you hold the same post-incident review, month after month, for a defect nobody ever scheduled time to actually fix. The recurring meeting is the symptom; the unfixed root cause is the debt.
Weak change management turns into the bloated Change Advisory Board: a weekly meeting where a large group signs off on changes because the process can’t distinguish a routine, low-risk deploy from a genuinely risky one. So everything gets the full ceremony, and throughput drains away one approval slot at a time. If your CAB exists to compensate for a lack of automated testing and deployment confidence, the meeting is standing in for test debt and process debt at the same time.
And poor ticket management, tickets that are vague, mis-routed, duplicated, or reopened, generates its own tax: triage meetings, hand-off meetings, and status meetings that exist purely because the queue itself can’t be trusted to tell you what’s happening. Fix the queue and most of those meetings have nothing left to do.
We see this pattern constantly in assessments: the meeting isn’t the disease, it’s the fever. Measure the meeting load around your support functions and you’ve found a map straight to the underlying debt.
Ask why the meeting exists, and the debt names itself
Excessive meetings are almost always a symptom rather than a cause. In Westrum’s model of organisational culture, generative organisations show high cooperation and genuine information flow, while pathological and bureaucratic ones default to low cooperation and narrow responsibilities. A calendar clogged with defensive, cover-yourself meetings is a cultural tell. Ask why each meeting exists and you’ll usually surface the real debt:
- Meetings that exist to share information are documentation debt. The information should be written down, once, where people can find it.
- Meetings that exist to make a decision are often people debt. Nobody has been given the authority or the context to decide alone, so a quorum has to be assembled every time.
- Meetings that exist to check on progress are process debt. The work is already visible in the tooling; the meeting exists because the process for surfacing it doesn’t, or isn’t trusted.
- Meetings that exist because a previous meeting overran are just process debt in its purest form.
- Meetings that exist to coordinate between teams are architecture debt wearing a disguise. Tightly coupled systems require tightly coupled humans. Conway’s Law runs in both directions.
That last one is worth sitting with. If two teams need a standing weekly sync to avoid breaking each other, you don’t have a communication problem. You have a coupling problem, and you’re paying for it in calendar entries every single week, forever, until someone fixes the boundary between the services.
How to start paying it down
Process debt responds to the same treatment as any other debt: make it visible, quantify the interest, then schedule the repayment.
- Measure it. Pull the calendar data. Meeting hours per engineer per week, and, more importantly, the size of the largest uninterrupted block each engineer has each day. If the answer is regularly under two hours, you have a problem regardless of the total.
- Consolidate before you cut. Moving meetings is politically cheaper than cancelling them and often delivers more benefit. Cluster meetings into designated windows. Protect the rest. Two meeting-free days a week will do more for throughput than removing 20% of meetings scattered at random.
- Give every recurring meeting an expiry date. No meeting recurs indefinitely. Six months, then it must be re-justified or it dies. This alone kills more process debt than any other single intervention.
- Ask what each meeting is compensating for. Then fix that thing instead. A meeting is very often a workaround for missing documentation, unclear ownership, a weak support process, or a bad architectural boundary. Treating the workaround as permanent is exactly how technical debt becomes permanent everywhere else.
- Give the time back visibly. If you reclaim ten hours a week for the team, say what it’s for. Unallocated time gets colonised by the next thing that wants it.
The uncomfortable conclusion
If a consultant told you that a legacy system was silently consuming 40% of your engineering capacity, you’d escalate it. You’d fund a remediation programme. You’d track progress at board level.
Your calendar is doing exactly that. It just doesn’t have a Jira ticket.
Technical debt isn’t only in the code. It’s in the architecture, the tests, the documentation, the infrastructure, the support processes, and in the accumulated, unexamined, endlessly compounding set of habits that determine how your people spend their day.
Meetings are debt. Start treating them like it.
Enduring IT helps IT leaders find, measure and pay down technical debt across all thirteen of its forms, including the ones that don’t show up in the codebase. If your calendar is quietly eating your delivery capacity, we’ll show you exactly where your throughput and stability are leaking, and what it’s costing. Take a Free Health Check or register your interest in an assessment today