The biggest drag on enterprise engineering velocity isn't technical debt or legacy code. It's the provisioning tax — the time engineers spend waiting for, configuring, and working around environment setup.
In enterprise cloud teams, this tax is enormous and almost never measured. At one global insurance company I worked with, cloud infrastructure provisioning took over a year. Not because engineers were slow. Because every environment required manual approvals, custom networking, security reviews, and a ticket queue that nobody owned.
What the tax actually costs
The direct cost is wait time. But the indirect costs are worse.
Engineers who are waiting for environments don't stop working. They context-switch to other tasks, building up cognitive overhead. They create workarounds — local environments that don't match production, shared dev servers that create conflicts, shadow IT deployments that bypass the approval queue entirely.
Each workaround becomes a maintenance burden. Each context-switch reduces quality. The provisioning tax compounds.
And because nobody measures it — because it's distributed across ticket queues, Slack threads, and calendar holds — leadership sees "slow delivery" and concludes the engineering team needs more people. They don't need more people. They need fewer hours waiting for infrastructure.
Why it persists
Provisioning persists as a tax because it's owned as a ticket queue, not as a product.
A ticket queue has an SLA. A product has adoption metrics, user satisfaction, and a roadmap. A ticket queue gets staffed when the backlog grows. A product gets invested in when the experience is bad.
The moment you treat provisioning as a product — with self-service interfaces, Infrastructure-as-Code templates, and automated compliance checks baked into the pipeline — the tax drops dramatically. At Allianz, we cut provisioning from months to days with exactly this approach.
The fix
Measure the tax. Add up the calendar days between "engineer requests environment" and "engineer deploys first code to environment." Multiply by the number of engineers affected. The number will be large enough to justify treating provisioning as a first-class product, not a support function.
The cheapest infrastructure investment you can make is eliminating the time your engineers spend not engineering.