How I Would Remove a Platform Bottleneck

This is a Platform Engineering problem that looks deceptively simple at first glance.

Developers need infrastructure. The platform team provides it. Then the organisation grows, more teams start asking for environments, pipelines, databases, permissions, deployment changes, and the platform team automates some of it, but the requests just keep piling up anyway. Eventually senior platform engineers end up spending a big chunk of their week answering Jira tickets and Slack messages instead of doing actual engineering.

At that point, hiring another engineer might help a bit. It won't fix the underlying problem though.

So the first thing I'd actually do isn't redesigning the platform or bringing in another tool. It's mapping where developers are stuck waiting.

Step 1: Map the current delivery workflow

Take one normal application team and follow a single change from repository creation all the way to production. A simple workshop in Miro, FigJam, or honestly even a whiteboard is enough to get this done.

The workflow usually looks something like this:

                Developer
   ↓
Create Jira request
   ↓
Platform engineer reviews request
   ↓
Terraform changed manually
   ↓
Infrastructure provisioned
   ↓
Security approval
   ↓
CI/CD configured
   ↓
Application deployed
   ↓
Observability configured
   ↓
Production
              

Now add waiting time on top of that, and things tend to look a lot worse than expected:

The technical work itself usually isn't slow. It's the handoffs between people and teams that eat all the time. That distinction matters more than it seems.

Step 2: Find the repetitive decisions

Next, I'd go through the last 50 to 100 platform tickets, Jira data is usually more than enough for this, and group them into categories like:

• environment provisioning
• Kubernetes namespaces
• IAM permissions
• databases
• CI/CD pipelines
• secrets
• observability
• networking
• deployment troubleshooting

The question worth asking here is simple: which of these requests actually need real engineering judgement, and which ones are just repeating a decision the team already made months ago?

If 40 teams keep requesting the exact same Kubernetes namespace configuration, that shouldn't still be a ticket. If every service needs the same Prometheus setup, developers shouldn't be rebuilding it by hand each time. And if Terraform modules already exist but only platform engineers are allowed to run them, that's a sign automation exists but self-service doesn't. This is usually where the bottleneck actually becomes visible.

Step 3: Turn the common path into a product

At this point, the goal is to build one supported path, not twenty different ones.

Say a team needs a new backend service. Instead of the old route:

                Jira → Platform Team → Terraform → CI/CD → Security → Observability
              

the target workflow looks more like this:

                Developer
   ↓
Developer Portal / Template
   ↓
Repository created
   ↓
Terraform module executed
   ↓
CI/CD pipeline created
   ↓
Security policies applied
   ↓
Observability enabled
   ↓
Deployment
              

The tools that could support this include:

• Backstage for the developer portal and software templates
• Terraform for infrastructure provisioning
• GitHub Actions, GitLab CI, or Azure DevOps for CI/CD
• Argo CD for GitOps-based Kubernetes delivery
• Open Policy Agent / Gatekeeper for policy enforcement
• OpenTelemetry, Prometheus, and Grafana for observability

Honestly, the specific tools matter less than the operating model behind them. The developer asks for a capability, and the platform hands back a controlled product, not a queue.

Step 4: Put guardrails into the workflow

Self-service without any controls just moves the risk somewhere else, it doesn't remove it. So the platform needs to bake the organisation's standards directly into the workflow.

A service template might automatically include something like:

                
                  service
                  :
                  owner
                  :
                  payments-team
                  environment
                  :
                  production
                  security
                  :
                  encryption
                  :
                  enabled
                  secrets
                  :
                  external
                  observability
                  :
                  metrics
                  :
                  enabled
                  logs
                  :
                  enabled
                  tracing
                  :
                  enabled
                  deployment
                  :
                  rollback
                  :
                  automatic
                  health_checks
                  :
                  required
                
              

That way the developer doesn't have to memorise every requirement, and the platform engineer doesn't have to review the same configuration over and over. This is really where Platform Engineering starts cutting cognitive load, rather than just automating infrastructure underneath.

Step 5: Measure whether it actually worked

I wouldn't lead with platform adoption as the main KPI here. What matters more is comparing the workflow before and after the change.

Something like this, for example:

These numbers are just illustrative, obviously. What matters is what you choose to measure. Not "how many teams use Backstage", but "how much waiting and manual work did the platform actually remove".

Step 6: Keep the exceptions outside the golden path

Not every workload needs to fit the standard path, and that's completely normal. The real mistake is trying to make the platform support every possible architecture from day one.

A rough target might look like this:

                80% common workloads
        ↓
Golden path / self-service

20% complex workloads
        ↓
Platform engineering engagement
              

This keeps senior engineering capacity free for the problems that genuinely need senior engineers, instead of burning it on provisioning the same resource for the hundredth time.

The outcome

The goal here was never to remove the platform team from the process entirely. It's to remove them from the repetitive parts of it.

That shifts the role of Platform Engineering from "send us a request and we'll build it" to something closer to "here's a safe, supported way to build it yourself." And that's usually the point where platform capacity finally starts scaling alongside engineering demand, instead of becoming the next thing everyone's waiting on.

If your platform team disappeared from the workflow for a single day, which developer requests would immediately grind to a halt? Those are probably the first ones worth turning into actual platform capabilities.