The biggest drag on enterprise engineering velocity I keep running into is the provisioning tax: the calendar time between an engineer asking for an environment and deploying the first code into it, plus everything engineers do to cope with that wait.
In enterprise cloud teams the tax is large and almost never on a dashboard. At Allianz, standing up new infrastructure could take over a year at its worst, across manual approvals, custom networking, security reviews, and a ticket queue.
The direct cost is wait time. The indirect costs are larger, and they hide better.
Engineers who are waiting for environments don't stop working. They context-switch to other tasks and carry the cognitive overhead of each switch. They build parallel setups to keep moving, and every one of those becomes something to maintain, migrate, or explain to an auditor later.
None of it appears on a single report. It is spread across ticket queues, Slack threads, and calendar holds, so leadership sees "slow delivery" and concludes the engineering team needs more people. What the team needs is fewer hours waiting for infrastructure.
Provisioning persists as a tax because it is run as a ticket queue. A ticket queue has an SLA and gets more staff when the backlog grows. A product has adoption metrics and a roadmap, and gets investment when the experience is bad. Most enterprises run provisioning the first way and wonder why it never improves.
Treating provisioning as a product, with self-service interfaces, Infrastructure-as-Code templates, and compliance checks in the pipeline, brought the wait at Allianz down to days for standard environments.
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. Put that number next to the platform team's budget request.
It is usually large enough to end the argument about whether provisioning deserves a product owner.