Productivity Dependency Outpacing Governance

I maxed out my weekly Claude credits in four days. On a 20x Max plan. Claude said we did four months of work in 5 days. It makes sense how they got maxed out. I was on a burner idea. Claudemaxing, if you will.

Then the wall appeared.
Project paused.
Hands off the keyboard.
Forty-eight hours waiting for the weekly counter to reset.

What popped me right in the mouth was something even more uncomfortable. I had restructured my work around this tool. The workflows, the throughput, the output I expected from myself… all of it was predicated on the resource being infinitely available. I mean, I signed up for the biggest, baddest 20x plan, right? But when the resource disappeared, it wasn’t inconvenient. It was an availability event.

A light bulb went off in my head. It felt extremely familiar because I’ve seen these kinds of availability events before. A few times, actually.

Every generation of enterprise infrastructure has had its version of this story.

A powerful new resource arrives.
It is genuinely transformative, not just faster.
Somebody important issues a mandate.
Adoption accelerates.
Workflows get restructured around the new capability.
Output expectations quietly reset against it.

And then the bill arrives. Sound familiar? But wait…

Big picture, here. The workers who built their entire workflow around the abundance are now running at a pace the organization can no longer sustain. The resource that felt unlimited isn’t. And nobody can go back to the old way because the old way no longer has the headcount, the process, or the institutional memory to support it.

What happens in an organization when what happened to me happens to thousands of employees in a large company?

There is a name for this pattern.

Productivity dependency outpacing governance.

And enterprise IT has lived through it at least three times before we got here. Grab a snack and let’s go on a stroll down memory lane here, because it’s important if we want to be prepared for what’s about to impact all of us.

---

We Have Been Here Before

It all started with client/server.

Before the late eighties, compute lived in the data center and nowhere else. IT controlled the hardware, IT controlled the access, and if your department needed something, you put in a request and waited. Then distributed computing arrived and everything changed. Suddenly a business unit could buy its own server, stick it under a desk or in a supply closet, and have compute on demand without filing a single ticket. Finance had one. Marketing had one. Operations had one. Facilities probably had one, though nobody could say for certain. The promise was departmental autonomy and faster time to value, and for a while it genuinely delivered. Teams moved faster. Projects got done.

Everyone was really happy about it… until IT was asked to actually account for what was running across the organization.

What followed was years of data center consolidation work that most infrastructure veterans would rather forget. Servers pulled out of closets that hadn’t been opened since the previous administration. Asset inventories built from scratch because nobody had maintained one. Applications that couldn’t be migrated because the person who built them had left the company and taken the documentation with them and the implementation details were in their head. Hardware that might have been doing something critical or might have been running a screensaver for eighteen months, and nobody was willing to find out the hard way. The repatriation was messy, expensive, and entirely avoidable. I know this first-hand because I did a truckload of contract work doing this very thing.

The root problem? Well, it’s a trend you’re going to see play out…

Resources had escaped governance on the way in. Getting it back cost three times what the autonomy had saved. But the organization survived, dusted itself off, and promptly did the whole thing over again with a different technology.

Virtualization arrived in the mid-2000s and handed every developer, admin, and project manager the most dangerous sentence in enterprise IT history:

“It’s just a VM.”

And technically, they were right. Provisioning a virtual machine dropped from a multi-week capital request involving procurement, facilities, and a purchase order to a fifteen-minute task any sysadmin could knock out before lunch. The friction that had naturally constrained consumption essentially disappeared overnight. Developers spun up VMs for feature branches, performance tests, proof-of-concept builds, and one-time migrations. Project managers requested them for initiatives that lasted a quarter and then quietly died. Business units who had waited weeks for compute now had it in an afternoon, and they used that abundance with the enthusiasm of people who had been rationed for years.

What nobody tracked was the other end of the lifecycle.

VMs accumulated faster than anyone decommissioned them. Projects ended. The VMs did not. They sat there consuming memory, storage, and VMware per-socket licensing, running workloads nobody could identify anymore, owned by teams that no longer existed, tied to projects that had been cancelled two fiscal years ago. Zombie VMs. The term entered the IT lexicon because the problem was widespread enough to need a name, and the name stuck because every infrastructure engineer who heard it immediately thought of three specific examples from their own environment.

The real damage was not the wasted resources, though those were significant. It was the paralysis the sprawl created. Nobody wanted to be the person who turned something off and broke something important. Decommission requests stalled in queues for months because every review cycle surfaced the same unanswerable question…

“What is this actually doing, and does anything depend on it? “

VM audit projects became their own category of infrastructure work, consuming engineering time that should have been going toward new builds. Some organizations are still running those audits today. The cleanup cost exceeded the efficiency gains by a margin that would have been embarrassing to document, and most organizations quietly chose not to document it. Entire companies were spun up to offer tools to solve for this, to the point that it became an unspoken pre-requisite to implement them alongside any future VM project.

The lesson was clear enough, or should have been…

When the friction of provisioning drops to near zero and governance does not keep pace, you do not get efficiency. You get sprawl. And sprawl has a compounding cost that makes the original convenience look like a very bad trade in retrospect.

Cloud was supposed to be the version where we got it right. The pitch was elegant… unlimited scale, pay only for what you use, no more capacity planning, no more overprovisioned hardware sitting idle at three percent utilization. The early days felt genuinely abundant in a way that client/server and virtualization never did. Spin up whatever you need. Experiment freely. Fail fast. The bill is a future problem, and future problems are someone else’s budget cycle.

And then the invoice landed. Finance walked into the room with a spreadsheet that looked like a ransom note.

What followed was a decade of FinOps, an entire discipline and job category that did not exist before cloud, built entirely around one question…

“How do we govern a resource our organization became completely dependent on before we built a governance model for it?

Cloud cost optimization became a product category with dozens of vendors, similar to what happened with virtualization. Rightsizing reports became a quarterly ritual at every enterprise running meaningful workloads in AWS, Azure, or GCP. Reserved instance negotiations became a competitive advantage and an entire kind of grey market for bidding on them felt like a secret hack few people understood. Tagging strategies became religious debates. Showback and chargeback models were implemented, torn down, and reimplemented in cycles that consumed more engineering time than the savings justified, because the alternative was worse.

For the organizations where governance arrived too late or cost controls landed too bluntly, the answer was repatriation. 37signals, the company behind Basecamp and Hey, made their exit from cloud public and put numbers on it, citing millions in annual savings after moving workloads back on-prem. They were not alone. Repatriation programs ran at enterprises across every industry, quietly and without press releases, as organizations absorbed the migration cost because the alternative was a cloud bill that had no ceiling in sight.

It worked. Painful, multi-year programs that consumed engineering bandwidth and tested organizational patience. But it worked. Because the workloads could move. The knowledge of how to run infrastructure had not disappeared from the organization. The people who knew how to rack servers and configure storage were still in the building, even if their titles had changed. The old way was still available as a fallback, even if it required dusting off skills and rebuilding muscle memory that had gone soft during the cloud years.

That fallback does not exist for AI tooling, folks. And that is what makes this moment categorically different from everything that came before it.

---

The AI Era

In the client/server era, departmental adoption was organic and bottoms-up, shadow IT finding its own way in through Blackberry’s and iPad’s. VM sprawl was similar, developers and admins making pragmatic local decisions. Cloud had a mix of both flavors.

But the difference is that AI tooling is increasingly arriving top-down. The C-suite issues the mandate via some semblence of…

“We will use AI to drive 10x productivity to remain competitive.”

The board backs it. Budgets get allocated. Tool adoption becomes a performance expectation, not an experiment. This changes the dynamic in a way that makes the governance failure faster and harder.

When adoption is organic, at least there is a discovery phase. Teams figure out the constraints through normal friction. Governance has some time to catch up. When adoption is mandated from above, that discovery phase collapses. The entire organization restructures around the tool simultaneously, on a schedule set by the people least likely to understand the operational constraints on the ground.

And those same people, the ones who issued the mandate, are the ones who will restrict the spend when the quarterly AI bill hits the board deck. The accountability whiplash is going to be brutal…

“thou shalt use AI to 10x productivity” followed six months later by “why is the AI spend this high?”

The workforce caught in the middle cannot win that argument. They did exactly what they were told. When cloud repatriation happened, the workload moved. The app went back on-prem. The data followed. The engineers who knew how to run it were still in the building.

What is happening right now with AI tooling is not that kind of dependency. It is a cognitive one.

Workers are not just using these tools to go faster. They are using them to do things they could not do before, or to do things at a scale that would have required two or three additional headcount at the previous capability level. Organizations are, quietly and without announcing it, resizing their output expectations around that new baseline. And to be fair, the math works as long as the resource holds.

But when the credits get expensive and leadership starts rationing, the workforce cannot revert. You cannot un-train the muscle memory. You cannot put three people back in roles that were quietly eliminated because the throughput numbers no longer required them. The org chart does not magically reconstitute itself.

This is not a billing problem, it’s an availability problem. And the organizations that discover it reactively are going to find themselves with an availability hole, a workforce that cannot go back, and a C-suite wondering why the productivity gains evaporated when they trimmed the AI budget.

---

What Good Governance Looks Like

The organizations that navigated cloud best were the ones that built the governance model before the chaos. FinOps practitioners embedded in engineering teams, not parachuted in from finance in the 13th hour. Chargeback models that made consumption visible at the team level. Quota strategies that separated critical workloads from exploratory ones.

The same framework applies to AI tooling right now, before we get to the crisis.

Treat AI credits like infrastructure capacity. Not a SaaS subscription. Not an experiment budget. Capacity. The same questions you would ask about compute, storage, and network apply here…

What is the peak demand?
What is on the critical path?
What can tolerate being queued?
What absolutely cannot?

Audit your AI subscriptions the way you should have audited your VMs. Find the zombie licenses. Find the overlapping tools. Find the department that is paying for something the enterprise agreement already covers. Do this now, before the mandate to cut costs makes it a panic exercise instead of a planning one.

Identify which workflows are now load-bearing. If a team’s output depends on an AI tool being available, that tool is load-bearing infrastructure. It belongs in the same conversation as server uptime and storage availability, not in the discretionary software budget.

And build the workforce conversation into the governance model from the start. The output expectations that were set during the abundance phase need to be pressure-tested against what happens during a rationing phase. Leadership needs to understand the dependency before they make decisions that assume it does not exist.

---

The Pattern Is Predictable.
The Outcome Does Not Have To Be.

Client/server. VMs. Cloud. AI.

Four generations.
Same immune response.
Resource enables productivity leap.
Adoption outpaces governance.
Bill shows up, triggering whiplash.
Restriction begins.
Workforce cannot revert.
Leadership overcorrects.

The difference this time is not the technology. It is the fallback. Every previous generation had one. The server could go back in the data center. The VM could be migrated or decommissioned. The workload could be repatriated.

You cannot repatriate muscle memory.

The organizations that figure this out first are the ones that still have people who remember all four rounds. People who ran VM audits. People who built FinOps practices. People who know that when a resource becomes critical infrastructure, you govern it like critical infrastructure.

That institutional knowledge is sitting in your organization right now, probably in someone with more tenure than their title suggests.

Find them. Listen to them. Because they’ve got some horror stories to tell you.

/Nick

---

Frequently Asked Questions

What is productivity dependency outpacing governance?

It describes the recurring enterprise pattern where organizational workflows become structurally dependent on a resource before any governance model exists to manage that resource’s cost, availability, or access. The dependency forms faster than the oversight. When restrictions eventually arrive, the gap between productivity expectations and available capacity creates an operational crisis that is expensive and sometimes impossible to reverse.

How does VM sprawl relate to AI tool governance?

VM sprawl is the closest historical parallel to the AI credits problem. In both cases, provisioning friction drops to near zero, adoption accelerates beyond what governance can track, and the cleanup cost exceeds the efficiency gains. The key difference is that VM sprawl left zombie compute you could eventually audit and decommission. AI dependency leaves cognitive workflows you cannot inventory or roll back.

Why is top-down AI mandate adoption more dangerous than organic adoption?

Organic adoption includes a discovery phase where teams encounter constraints naturally and governance has time to respond. Top-down mandates compress that phase entirely. The entire organization restructures around the tool simultaneously, on an executive timeline. When the bill arrives and restrictions follow, the same leadership who issued the mandate is now restricting the resource, leaving the workforce that complied with the original directive with no fallback and no cover.

What happened during cloud repatriation and why can’t AI follow the same path?

Cloud repatriation was expensive but viable because the underlying capability of running infrastructure on-prem had not disappeared. Engineers still knew how to do it. Workloads could physically move. AI tooling creates a cognitive dependency rather than a workload dependency. When teams rebuild their work processes around AI capabilities, the knowledge of how to do that work without the tool atrophies. There is no repatriation path for that.

What should enterprise IT do right now about AI tool governance?

Audit AI subscriptions immediately, the same way a healthy VM hygiene program would inventory running machines. Build chargeback models before finance does it reactively. Classify AI tools by whether they are load-bearing for team output or exploratory, and apply differentiated governance policies. Most importantly, have the workforce conversation now, before a cost-cutting mandate forces it, so leadership understands the dependency before making decisions that assume it does not exist.