A developer needs a test environment. They open a ticket.

Another team needs a secret rotated. They open a ticket. A third needs a database, a DNS record and access to production logs. Four more tickets.

By Wednesday, the DevOps team is processing requests faster than it can improve the system that creates them.

Nothing is technically broken. The cloud is available, the cluster is healthy and the engineers are busy. Yet delivery slows because every product team must pass through the same small group of people.

This is not a staffing problem first. It is an operating-model problem: DevOps has become a service desk for infrastructure.

The ticket queue is a dependency graph

A ticket looks like a unit of work. For the product team, it is usually a dependency.

The feature cannot be tested until the environment exists. The migration cannot start until the database is provisioned. The incident cannot be diagnosed until somebody grants access. One fifteen-minute infrastructure task can hold several days of product work behind it.

The visible queue also understates the real cost:

• developers stop, switch tasks and later reconstruct their context;
• DevOps engineers are interrupted before they can finish automation work;
• urgent requests bypass the queue through direct messages;
• the same request is described differently by each team;
• approvals prove that somebody clicked a button, not that the result is safe;
• knowledge accumulates in the heads of the people handling the tickets.

Adding another engineer may reduce the queue for a while. It also increases the number of people manually translating requests into cloud changes. If demand grows with the number of product teams, the operating model still scales linearly with headcount.

Google SRE describes this class of work as toil when it is manual, repetitive, automatable and provides no enduring improvement to the service. Excessive toil slows engineering progress and encourages other teams to send even more operational work toward the same group: Eliminating Toil.

How to tell whether DevOps has become the bottleneck

Do not start by counting the total number of tickets. A queue can be small and still block the most important work.

Choose twenty recent infrastructure requests and record:

Signal	What it reveals
Time waiting before work starts	Whether capacity or prioritisation is the constraint
Active handling time	How difficult the technical change really is
Number of messages needed for clarification	Whether the request has an usable contract
Percentage completed through a standard procedure	How much work is already predictable
Number of product tasks blocked by the request	The business impact of the queue
Requests repeated in the same month	The strongest self-service candidates

The most useful comparison is waiting time versus handling time.

If a request waits two days and takes twelve minutes to fulfil, optimising the twelve minutes will not materially improve delivery. The opportunity is to remove the handoff.

Also trace the unofficial path. If senior engineers receive requests in chat because the ticket queue is too slow, the dashboard is reporting only the work that followed the process. The interruption load is somewhere else.

Not every request should become self-service

The objective is not to let anybody create anything in production.

Separate requests into three groups.

Standard and frequent

These should become the first self-service paths:

• creating a development or preview environment;
• provisioning an approved database size;
• generating a repository from a service template;
• requesting a DNS record in an owned namespace;
• rotating an application secret;
• granting time-limited read access to logs;
• deploying an already verified artifact.

The inputs, policy and expected result are known. A human adds waiting, but little judgment.

Standard but sensitive

These can still be automated while retaining a specific approval:

• production access;
• a high-cost resource class;
• public network exposure;
• destructive data operations;
• changes inside a regulated environment.

The system should prepare and validate the change. The reviewer should approve a named risk with the evidence beside it.

Exceptional

Unusual architecture, incident investigation and novel security decisions need engineers. Keep a path for consulting work instead of forcing every situation through a rigid form.

Self-service should absorb the routine so the DevOps team has time for the exceptional.

Do not automate the ticket form

A portal that creates a better-formatted ticket is not a platform.

Neither is a catalogue of scripts that only the DevOps team can run. Both improve intake while preserving the dependency: the product team still waits for another team to execute the change.

A useful self-service path includes the whole result:

1. A clear input contract. The user selects the service, environment, ownership, data class and approved size.
2. Policy before execution. Invalid, unsafe or unexpectedly expensive choices fail before resources are created.
3. A repeatable implementation. Infrastructure as code, an API or a controlled workflow performs the change.
4. Identity and audit. The system records who requested the change, which policy allowed it and what was created.
5. Useful feedback. The requester can see progress, failure details and the next action without asking in chat.
6. Lifecycle ownership. Expiry, upgrades, cost allocation and deletion are part of the path rather than later cleanup tickets.

DORA describes effective platform engineering as a product discipline built around automation, repeatability and self-service “golden paths.” It also warns against “ticket-ops,” where a platform team remains a reactive infrastructure vending machine instead of enabling teams to work independently: Platform engineering capability.

Build one paved path, not a universal platform

Teams often respond to ticket overload by starting an internal developer platform programme. Six months later, the queue still exists and a new platform also needs support.

Start with one journey that is frequent, costly and sufficiently consistent.

Suppose the repeated request is “create a test environment.” The first useful version might:

• accept an application repository and owner;
• create an isolated namespace from a reviewed template;
• apply default CPU, memory and network limits;
• attach standard observability;
• issue environment-scoped credentials;
• expose an expiry date and estimated cost;
• return the URL and health state to the requester.

It does not need to support every database, network topology and deployment model on day one.

The escape hatch matters. A team with a legitimate exception should be able to extend the template or request engineering help. A golden path is successful when it is the easiest safe option, not when every alternative is prohibited.

The CNCF Platform Engineering Technical Community Group frames internal platforms around self-service infrastructure with consistency, security and governance. That balance matters: autonomy without guardrails creates cleanup and risk; guardrails without autonomy recreate the ticket queue. See the CNCF Platform Engineering TCG.

Change ownership with the interface

Self-service fails when the new button appears but responsibilities remain unchanged.

Define ownership explicitly:

Platform team owns	Product team owns
Templates, APIs and policy controls	Application configuration and declared dependencies
Reliability of the self-service path	The resources created for its service
Default observability and access patterns	Responding to application-level alerts
Upgrade and deprecation mechanisms	Adopting supported versions within the window
Documentation and actionable error messages	Supplying feedback and reproducible failures

This is not “throwing infrastructure over the wall.” The platform team owns the common capability as a product. The product team owns its use of that capability.

If only the platform team can understand an error, the interface is incomplete. If product teams can change every policy, the guardrails are incomplete.

A four-week way out of the queue

Week 1: map demand

Export the previous month of requests. Group them by outcome, not by the wording in the ticket.

“Need Redis,” “cache for staging” and “please provision managed memory store” may all be the same journey.

For each group, calculate volume, waiting time, handling time, clarification steps and how many people are blocked. Pick one candidate with high repetition and low decision complexity.

Week 2: write the contract

Before building a portal, define:

• required inputs;
• allowed values;
• policy checks;
• created resources;
• ownership metadata;
• success and failure states;
• expiry and deletion behaviour;
• the exceptional path.

Run the contract manually for three real requests. If engineers still need an unrecorded conversation to complete the work, the interface is missing information.

Week 3: automate end to end

Encode the change in version-controlled infrastructure and expose it through the narrowest useful interface: a repository template, pull request workflow, CLI command, API or portal.

Use the interface with an application team while the platform engineer observes. Do not take the keyboard at the first confusing error. The confusion is product feedback.

Week 4: remove the old route

Publish the supported path, response expectations and exception process.

Stop accepting routine requests through private messages. Redirect matching tickets to self-service and record why users abandon the path. Every workaround is either a missing capability, a documentation problem or a legitimate exception.

Reserve explicit platform capacity for improving the path. If all capacity remains available for ticket handling, urgent manual work will consume the time intended to eliminate it.

Measure independence, not portal activity

The number of portal clicks is not an outcome.

Track:

• percentage of eligible requests completed without platform-team intervention;
• median time from request to usable resource;
• clarification messages per request;
• failed self-service attempts that become tickets;
• platform-team time spent on repetitive operational work;
• adoption and repeat use by product teams;
• policy violations prevented before execution;
• developer satisfaction with the specific journey.

DORA defines developer independence as the ability to perform tasks across the application lifecycle without relying on an enabling team. That is a better target than “all requests go through the platform”: 2024 DORA research errata.

Keep delivery and reliability measures beside the experience metrics. A path that is fast but frequently creates broken environments is not successful. A path that is safe but requires a week of training is not self-service.

Some tickets should remain

A healthy DevOps operating model still has requests.

Teams will need architecture advice, incident help, new capabilities and exceptions. Those are valuable interactions because they contain judgment and generate learning.

What should disappear is the ticket whose resolution is already known.

If the same request arrives every week, the DevOps team should not become faster at clicking through it. The team should turn its knowledge into a safe, repeatable capability that other engineers can use.

That is the difference between operating infrastructure for people and building an engineering system that lets people operate safely.

The outcome to aim for

The DevOps team should be a multiplier, not a queue.

Product teams should be able to complete common infrastructure tasks through a supported path, understand the result and own what they create. DevOps engineers should spend their time improving those paths, solving hard operational problems and reducing the next source of toil.

When every team is waiting for DevOps, hiring another ticket handler buys time.

Removing the handoff buys scale.