Why Every New Service Takes Weeks (And It's Not the Tickets)

I've sat in the same meeting more times than I'd like to admit. A team lead walks the room through a new service they need to ship — clean design, reasonable scope, nothing exotic. Everyone nods. The Architecture Review Board approves it. Security signs off. DevOps has no objections. And then someone asks the question that always lands like a small joke that isn't actually funny: "So when can we start building?"

The honest answer, almost every time, was three to four weeks from now.

Not because anyone was slow. Not because the team lacked skill. Because approval was never the bottleneck. What came after it was.

The part nobody puts in the retro

Here's what actually happens after a design gets approved. The dev team opens a ticket for a new Google Cloud project. Another ticket for the service accounts it needs, plus the Workload Identity Federation bindings so those service accounts can be used safely from GKE without a downloaded key sitting somewhere it shouldn't. Another for IAM — and IAM tickets almost never come back clean on the first pass, because someone always needs to clarify scope, or a reviewer flags a binding that's broader than it should be, so it goes back and forth. A ticket to get the right Google Groups wired into IAM so access follows team membership instead of being granted person-by-person. Separate tickets for a Cloud SQL instance, a GKE namespace with resource quotas, secrets that need to land in Secret Manager rather than a config file, and an Artifact Registry repository to push container images to — each one asking the team to specify compute and storage sizing they're only guessing at this early. Then, once the infrastructure exists, a whole new relationship starts with the DevOps team to get a CI/CD pipeline built, because pipelines aren't self-service either.

Each of those is its own queue, with its own owner, its own turnaround time, and its own Slack thread where someone politely asks "any update on this?" every few days. None of it is hard work. All of it is slow work.

One platform team I worked with actually counted it once, out of curiosity more than anything: more than 10 separate onboarding tickets between the moment a service got architectural sign-off and the moment it reached its first deployment. Project creation, IAM, Workload Identity, Secret Manager access, Artifact Registry permissions, GKE namespace setup, pipeline wiring — each ticket individually reasonable, and the sum of them a multi-week wait before a single line of application code touched production.

Why this keeps happening to good teams

I want to be clear about something, because it's the part that took me longer than it should have to see clearly: this isn't a staffing problem, and it isn't a discipline problem. I've worked with sharp DevOps engineers and diligent security reviewers who were doing exactly what their role asked of them. The system around them just had a gap — there was no opinionated, pre-approved pattern for "here's what a new service on this platform looks like." So every request started from a blank page, and a blank page has to be reviewed, provisioned, and wired up manually, every single time.

That's the chain I've watched repeat itself across more clients than I can name:

That last step is the one that quietly does the most damage, because it turns a one-time delay into a permanent tax. The lack of a paved road doesn't just slow down this service. It guarantees the next one will be just as bespoke, just as manual, and just as slow to review — because there's still nothing standard to point to.

What this actually costs the business

It's tempting to file this under "engineering process" and move on. I'd push back on that. When I've helped leadership teams put a number on it, the real cost shows up in three places.

Lost velocity compounds. Three or four weeks per service doesn't sound catastrophic in isolation. But most growing engineering orgs aren't shipping one new service a year — they're shipping one every month, sometimes more. Multiply that delay across a roadmap and you're looking at months of cumulative lost time annually, time competitors without this bottleneck don't have to spend.

Senior people get pulled off the work that actually needs them. The engineers chasing IAM tickets and pipeline requests are usually the same ones capable of doing the highest-value work on the team. Every hour spent following up on a provisioning ticket is an hour not spent on the product. I've watched this quietly become a retention issue — good engineers don't stay engaged chasing tickets for infrastructure that should already exist.

Launch commitments become unreliable. When provisioning time is unpredictable, so is your ability to promise a date to the business. I've sat across the table from CTOs explaining to their board why a launch slipped, and "we were waiting on IAM approval" is never a sentence anyone wants to say twice.

The fix isn't faster tickets — it's no tickets

The instinct is usually to speed up the queue: add headcount to DevOps, set SLAs on ticket turnaround, run a Kaizen event on the approval process. I've tried versions of all of that, and it helps a little. But it treats the symptom. The actual fix is removing the need for the queue in the first place.

That's what a paved road means in practice: a pre-approved, opinionated pattern for what a new service looks like on your platform — the project structure, the IAM baseline, the network guardrails, the pipeline wiring — defined once, reviewed once, and then reused every time a team needs a new service. The architecture review, the security sign-off, the DevOps setup — all of it still happens, but it happens once, at the platform level, instead of once per service, forever.

The organizations that actually improve delivery speed don't simply hire more platform engineers or push their teams to process tickets faster. They standardize the platform itself. Once onboarding a new service — the Google Cloud project, the IAM and Workload Identity setup, the GKE namespace, the pipeline — becomes a repeatable capability instead of a recurring project, engineering teams spend less time waiting on tickets and more time delivering software.

This is exactly the gap Vertro was built to close for teams running on GCP and GKE. Instead of every new service triggering a fresh round of tickets across four different teams, Vertro gives developers a standardized, guardrail-compliant path to a running service — Google Cloud project, IAM and Workload Identity bindings, Secret Manager, Artifact Registry, GKE namespace, and pipeline all included — without waiting weeks for infrastructure that should have been solved the first time a service was ever provisioned.