Platform engineering is supposed to increase autonomy.
So why do so many platform teams end up running a backlog full of tickets?
- New environments
- IAM permissions
- CI/CD tweaks
- Database provisioning
- Kubernetes changes
- Developers open tickets
- Platform prioritizes
- Platform reviews
- Platform implements
- Platform deploys
Everyone calls this "platform engineering." It isn't.
It's a ticket factory.
And the more optimized your ticket factory becomes, the further you drift from what platform engineering was meant to solve.
How We Got Here
The "internal customer" narrative didn't come from nowhere.
It came from good intentions:
- Breaking Dev vs Ops silos
- Treating developers with a product mindset
- Improving developer experience
- Reducing friction
- Making infrastructure reusable
Platform-as-a-product made sense. Developers became "customers." Platform teams became "service providers."
But somewhere along the way, enablement quietly turned into centralization.
When every infrastructure change flows through one team, you haven't reduced friction.
You've just moved it.
The Hidden Cost of the Ticket Factory
At first, a centralized platform team feels efficient.
- There's governance
- There's standardization
- There's visibility
But the costs show up elsewhere.
1. The Coordination Tax
Every ticket introduces:
- Queue time
- Context switching
- Prioritization politics
- Cross-team dependency
You're not just shipping infrastructure changes. You're scaling coordination overhead.
And coordination is one of the most expensive things in engineering.
2. Ownership Diffusion
When engineers are treated as internal customers:
- They stop learning how their infrastructure works
- They escalate instead of investigate
- They optimize locally
- They externalize operational responsibility
Platform teams slowly absorb production accountability.
Incidents become "their problem."
You cannot build shared ownership on top of a customer/provider relationship.
3. Platform Burnout
Ticket factories don't just hurt product teams. They burn out platform teams.
Instead of:
- Improving architecture
- Building reusable patterns
- Increasing automation
- Reducing cognitive load
They spend their time:
- Reviewing configs
- Applying small changes
- Managing backlogs
- Fighting fires
They become reactive instead of strategic.
Ticket volume becomes the KPI.
Ticket volume is often a measure of platform failure, not platform success.
A Story of Two Approaches
NOTE: The following scenario is fictional, but it reflects patterns I've seen repeatedly across different organizations.
Two companies, both running microservices on Kubernetes, both with roughly 15 product teams and a 4-person platform squad.
Company A: The Ticket Factory
At Company A, every new service deployment starts with a Jira ticket. Need a new namespace? Ticket. Need a database? Ticket. Need to update your CPU limits? Believe it or not, ticket.
The platform team at Company A closes around 120 tickets per month. Leadership sees this as a sign of a productive, high-performing team. The backlog sits at a steady 45 open tickets. Average resolution time is 3.2 days, but some requests take over two weeks when the platform team is focused on incident response.
One Thursday afternoon, a product team needs to scale a service before a marketing campaign launching on Monday. The ticket sits in the queue over the weekend. The campaign launches with degraded performance. The post-mortem points fingers at the platform team for not prioritizing the request.
The platform team works late nights. Two engineers are close to burnout. They spend roughly 70% of their time on reactive ticket work. Strategic projects like migrating to a new service mesh and improving the CI/CD pipeline keep getting pushed quarter after quarter.
Company B: The Guardrail Approach
Company B started in the same place. Same ticket queue, same bottleneck, same frustration. But instead of optimizing the queue, they decided to eliminate the need for it.
Over six months, the platform team built a set of Terraform modules and Helm chart templates with sane defaults, security policies baked in, and automated compliance checks. They created a self-service portal where teams could spin up new services by filling out a short form that generated a pull request against an infrastructure repository. Policy-as-code tools (OPA and Kyverno) enforced constraints automatically: no privileged containers, mandatory resource limits, required labels, network policies applied by default.
The result? Ticket volume dropped from 120 per month to around 15. The remaining tickets were genuine edge cases that actually needed human judgment. Product teams deployed new services in under an hour instead of waiting days. The platform team reclaimed 60% of their time for strategic work. And when that same marketing campaign scenario came up, the product team handled the scaling themselves through pre-approved autoscaling configurations.
The difference wasn't talent or budget. It was philosophy. Company A measured success by tickets closed. Company B measured success by tickets that no longer needed to exist.
The Real Role of a Platform Team
A platform team should not be an infrastructure service desk: It should be a capability accelerator.
The job of a platform team is not to provision resources.
It is to design systems where provisioning doesn't require them.
That means:
- Paved roads instead of custom paths
- Secure defaults instead of manual reviews
- Automation instead of approvals
- Guardrails instead of gates
If engineers need to ask permission to deploy safely, your platform isn't finished.
Gates vs Guardrails
This distinction matters.
Gates:
- Manual approvals
- Review boards
- Ticket queues
- Centralized control
Gates scale control.
They do not scale autonomy.
Guardrails:
- Policy-as-code
- Pre-approved templates
- Secure-by-default modules
- Automated compliance checks
- Self-service infrastructure
Guardrails scale autonomy safely.
That's the difference between governance by friction and governance by design.
What "Without the Ticket Factory" Actually Looks Like
Platform engineering without the ticket factory looks like this:
- Infrastructure as Code modules that teams can use without review
- Golden CI/CD pipelines that embed security and compliance
- Policy-as-code enforcing constraints automatically
- Self-service environment creation
- Clear production ownership per team
The platform team focuses on:
- Reducing cognitive load
- Eliminating decisions
- Encoding standards into tooling
- Measuring adoption instead of tickets closed
Instead of asking:
"How many tickets did we close?"
Ask instead:
"How many tickets no longer need to exist?"
Shared Ownership Is the Real Goal
The ticket factory model quietly reinforces separation:
- Platform owns infrastructure
- Security owns risk
- Developers own features
But high-performing organizations don't operate that way.
They operate with shared ownership:
- Teams own what they build
- Platform enables safe autonomy
- Security is embedded in defaults
- Incidents are learning opportunities
You cannot call engineers "customers" and expect them to behave like owners.
Ownership requires agency.
Agency requires autonomy.
Autonomy requires trust, and well-designed systems.
When Centralization Is Necessary
There are situations where more centralized control makes sense:
- Highly regulated environments
- Small teams with limited expertise
- Early-stage startups
- High-risk systems with strict compliance constraints
But even in those cases, the long-term direction should be:
- More automation
- More clarity
- Less manual coordination.
Because manual coordination does not scale.
A Simple Diagnostic
If you're unsure whether you have a platform team or a ticket factory, ask:
- Does the platform team measure tickets closed as a primary KPI?
- Do developers need approvals to deploy infrastructure?
- Are security controls enforced manually?
- Does platform get paged for application failures?
- Do product teams understand the infrastructure they run on?
If most answers point to centralization, you're not scaling engineering.
You're scaling coordination cost.
Final Thoughts
Platform engineering is not about building a better internal service desk.
It's about designing an organization where engineers can move fast, safely, and independently.
If your platform team is drowning in tickets, that's not a sign of demand.
It's a sign that the system still depends on manual control.
Real platform engineering makes itself less necessary over time.
That's the paradox.
The most successful platform teams aren't the busiest ones.
They're the ones that quietly eliminate the need for tickets altogether.
Top comments (0)