We built an internal developer platform so developers would stop opening tickets. They now open tickets about the platform.
This is not an unusual outcome. It is merely an awkward one, especially after the organisation has spent eighteen months, several consulting invoices, and enough Kubernetes expertise to operate a small space programme.
Platform engineering is usually introduced as the answer to slow delivery, fragmented tooling, and the cognitive burden of modern cloud infrastructure. The promise is sensible. Give development teams a supported way to create services, provision environments, deploy software, and observe production without requiring every engineer to become a part-time network specialist, IAM archaeologist, and Terraform state therapist.
Then reality arrives.
The company launches a polished portal. It contains a service catalogue, a collection of templates, and a reassuring amount of corporate branding. A developer selects “Create database”, completes a form, and clicks a large blue button.
Somewhere behind that button, a Jira ticket is born.
Three days later, a platform engineer asks which subnet the database should use.
The interface changed. The bottleneck survived.
The portal is not the platform
An internal developer portal can be useful. It can bring documentation, service ownership, software templates, pipeline links, and operational information into one place. In a sufficiently large organisation, simply discovering which team owns a service can feel like a meaningful product feature.
But a portal and a platform are not the same thing.
A portal helps developers find the door. A platform should let them walk through it.
A genuine internal developer platform provides reliable, reusable capabilities that teams can consume with minimal negotiation. Those capabilities may include creating a service, provisioning a development environment, obtaining a workload identity, exposing an endpoint, attaching a managed database, or promoting a release. The important part is not where the button lives. The important part is what happens after somebody presses it.
If the result depends on another team reading the request, interpreting it, arranging a meeting, and manually running the same commands they ran last week, the organisation has not created self-service. It has created a more attractive reception desk.
Reception desks have value. They can organise demand and stop people wandering into the server room. They should not be confused with an operating model.
The help desk with better branding
The modern version of the old infrastructure request process often looks like this:
- A developer opens the internal portal.
- They choose a service template.
- They complete a form.
- The form creates a ticket.
- The platform team reviews the ticket.
- Several meetings take place because the form did not capture the important part.
- Somebody manually provisions the resources.
This workflow may include Kubernetes, Terraform, GitOps, and an icon set with rounded corners. None of those things changes the fact that a human queue remains the API.
The platform team gradually becomes a central operations team with more YAML and a more ambitious job title. Its engineers spend their days processing access requests, repairing template failures, explaining undocumented conventions, and performing routine changes on behalf of other teams. Because the platform is now the approved route to production, every delivery dependency eventually lands in their queue.
This arrangement is expensive in two directions. Developers wait, so product delivery slows down. Platform engineers handle repetitive work, so the platform itself barely improves. Demand increases, headcount follows, and the organisation concludes that platform engineering requires a surprisingly large team.
Sometimes it does. Sometimes the company has simply built the world’s most technically sophisticated help desk.
Golden paths and golden cages
Golden paths are one of the better ideas in platform engineering. A golden path is a recommended, well-supported route through a common delivery scenario. It should make the safe option the easy option, provide sensible defaults, and remove decisions that most teams should not need to make repeatedly.
For example, a team creating an ordinary internal API probably does not need a week-long debate about repository layout, health endpoints, log format, workload identity, or basic deployment policy. A good platform can make those choices once, encode them well, and allow the team to concentrate on the application.
The trouble begins when the path acquires walls.
A golden path becomes a golden cage when every workload must use the same runtime, every repository must have the same structure, and every exception requires a visit to an architecture board. Requirements that the platform does not support are reclassified as developer mistakes. Application teams learn that “opinionated” means the platform team has opinions and everyone else has forms.
Standards matter. Security, reliability, and operational consistency are not optional decorations. But uniformity is not the same as standardisation. A batch workload, a latency-sensitive API, and a data science environment may share governance principles without pretending to be the same system.
The path should guide teams, not trap them. Mature platforms provide documented escape hatches with clear responsibilities and controls. If too many teams take the escape hatch, that is not automatically evidence of widespread indiscipline. It may be evidence that the road goes to the wrong place.
Self-service that still requires permission
The phrase self-service has suffered badly from corporate enthusiasm.
A capability is not meaningfully self-service if a developer must request access before every action, wait for a manual approval, contact an administrator for routine configuration, or summon the platform team whenever the automation produces an error message.
Approvals are sometimes necessary. Deleting a production database should involve more friction than creating a temporary development namespace. Giving both actions the same governance process is not security maturity. It is the administrative equivalent of making everyone pass through airport immigration to visit the office kitchen.
Good platforms apply controls according to risk. Low-risk, repeatable actions should be automated and auditable. Higher-risk actions may require separation of duties, policy checks, or explicit approval. The controls should be designed into the capability instead of being added as a human checkpoint after the automation has finished pretending to be autonomous.
The goal is not to eliminate governance. It is to stop using human availability as the primary enforcement mechanism.
Abstraction is useful until it hides the wrong things
Cloud platforms exist partly to reduce cognitive load. Developers should not need to understand every detail of network routing, certificate automation, Kubernetes controllers, cloud account topology, Terraform state management, and IAM implementation before deploying an application.
This is a reasonable abstraction boundary. Nobody becomes a better product engineer by memorising the organisation’s subnet naming convention.
But abstraction can become concealment.
Developers still need to know what resources were created, where their logs live, how the service scales, what it costs, and why a deployment failed. They need enough visibility to diagnose ordinary problems without opening a support case. They also need to know who owns the next layer when the problem is not ordinary.
A good abstraction hides unnecessary mechanisms while preserving useful feedback. A bad abstraction takes a precise cloud error, removes all context, and returns PLATFORM_REQUEST_FAILED. This is technically simpler in the same way that replacing an aircraft dashboard with a single red light is technically simpler.
Platform APIs should expose status, events, ownership, and actionable errors. The underlying system can remain complex. Its behaviour should not remain mysterious.
Backstage is not a platform strategy
Backstage is a useful project. It can improve service discovery, documentation, ownership, software templates, plugin integration, and developer navigation. In many organisations, it provides an effective front door to the engineering estate.
Installing it does not create a platform organisation.
Backstage does not automatically repair slow approval processes, unreliable automation, poorly designed APIs, or organisational silos. It does not appoint a product owner, interview developers or decide which recurring problems deserve to be solved. It cannot make an infrastructure workflow self-service when every action behind the interface still depends on a person.
An organisation can deploy Backstage and continue requiring tickets for everything behind it. In that case, the portal is doing its job. The operating model is not.
The tool is not the strategy, just as buying a very good oven does not establish a restaurant. Somebody still needs to decide what the kitchen is for.
When the platform team builds for itself
Platform teams are full of infrastructure engineers, and infrastructure engineers enjoy infrastructure. This is both useful and dangerous.
The team may celebrate a sophisticated Kubernetes architecture, reusable Terraform modules, policy enforcement, multi-region control planes, elegant GitOps reconciliation, and a plugin ecosystem large enough to require its own governance committee.
Developers may still experience slow environments, confusing documentation, long onboarding, limited debugging access and no obvious owner when something fails.
Both views can be true. The architecture can be excellent while the product is poor.
This usually happens when the team optimises for technical completeness rather than developer outcomes. Developers are treated as consumers of infrastructure instead of customers of a product. Requirements arrive as requests to fulfil, not problems to understand. The roadmap becomes a list of technologies that the platform team would like to operate.
Product thinking does not mean developers are always right. A platform team must balance autonomy with security, compliance, cost, reliability, and organisational standards. It should not accept every request or support every possible runtime.
It should, however, look for patterns.
If ten teams request the same change, the answer is probably not eleven tickets. The answer may be a new capability. Tickets should become product discovery input, not the permanent delivery mechanism.
The metrics that reveal the truth
Infrastructure availability matters. Deployment success rates matter. Neither tells you whether developers are losing two days each month navigating the platform.
The uncomfortable metrics tend to be closer to the user.
Lead time
Measure the time between a developer needing a capability and being able to use it. This might include creating a service, obtaining a development environment, provisioning a database, exposing an endpoint, or receiving production access.
If the Terraform runs in six minutes but the complete process takes four days, the bottleneck is not Terraform.
Adoption
Measure whether teams choose the platform when alternatives exist. Mandatory adoption proves that management can send an email. It does not prove that the product is valuable.
Look at whether teams recommend the platform, whether new services onboard faster, and whether developers use supported paths or quietly build alternatives behind a different AWS account.
Cognitive load
Count the platform-specific knowledge required to complete ordinary work. A platform has not reduced complexity if developers must learn several internal YAML schemas, custom pipeline syntax, hidden approval rules, and a naming convention apparently derived from a lost branch of medieval accounting.
The platform should remove decisions, not replace cloud complexity with company-specific complexity.
Escape rate
Track the teams that bypass the platform or request exceptions. A high escape rate may indicate missing capabilities, excessive restrictions, poor performance, weak documentation or a platform designed around the wrong workloads.
Exceptions are data. Treating every exception as misconduct is a convenient way to avoid learning from it.
Support demand
Measure tickets, messages, and meetings per platform user or service. If adoption and support demand rise at the same rate, the platform is not scaling. It is hiring.
A healthy platform allows usage to grow faster than the number of people required to support it. The exact number will vary, but the direction should not.
What a platform product team does differently
A product-oriented platform team interviews developers and observes real delivery workflows. It prioritises recurring friction, maintains a clear roadmap, publishes service expectations, and measures user outcomes. It deprecates capabilities nobody uses and treats documentation as part of the product rather than the place where unfinished automation goes to retire.
Most importantly, it designs capabilities and APIs before designing screens.
A reliable API can support a portal, a command-line tool, a pipeline, and future integrations. A portal placed over manual processes merely conceals the queue. This is why the smallest valuable platform is often not a grand catalogue. It is one complete workflow that works from beginning to end.
Consider a developer who wants to deploy a new internal API. A mature platform might allow them to:
- Create the service from a supported template.
- Receive a repository with tests and pipeline configuration.
- Provision a development environment automatically.
- Obtain a workload identity without creating long-lived credentials.
- Expose the service through an approved ingress pattern.
- Access logs, metrics, and traces.
- View cost and ownership metadata.
- Promote the service through environments using defined controls.
The developer can see what happened, diagnose common failures, and complete routine operations without waiting for the platform team.
That is a platform capability.
A form that creates eight Jira tickets is not.
Tickets are not the enemy
Tickets remain appropriate for exceptional security reviews, regulatory approvals, high-risk production operations, significant capacity commitments, and new architectural patterns the platform does not yet support.
The problem is not that tickets exist. The problem is using tickets as the default API between developers and infrastructure teams.
Routine, repeatable, and low-risk work should become automated over time. Exceptional work should remain visible precisely because it is exceptional. When every request is a ticket, organisations lose the ability to distinguish genuine judgment from administrative habit.
Warning signs that the platform has become a help desk
The diagnosis is usually visible long before anyone admits it:
- Developers cannot complete common tasks without contacting the platform team.
- The portal submits requests more often than it executes actions.
- Every new workload requires a meeting.
- Documentation explains organisational procedures more than technical capabilities.
- Support demand grows in proportion to adoption.
- Teams maintain unofficial workarounds.
- Exceptions are common but rarely influence the roadmap.
- Platform engineers spend more time processing requests than improving capabilities.
- Success is measured by resources provisioned rather than developer time saved.
- Only the platform team can diagnose platform failures.
One warning sign is manageable. Eight is an operating model wearing a portal costume.
Escaping the help desk model
Start with one complete workflow. Automating three common journeys from beginning to end is more valuable than partially automating thirty services and placing the missing steps in a runbook.
Then remove one human dependency at a time. Find every point where a developer waits for another team. Decide whether policy as code, better defaults, improved documentation, or a more reliable API can remove that dependency.
Classify support requests. Repeated questions are evidence of unclear feedback, missing capabilities or documentation that exists mainly to satisfy an audit. Use those requests to shape the roadmap.
Provide governed escape hatches. Advanced teams will encounter requirements that the platform does not support. Give them a documented route with explicit ownership and controls instead of forcing the workaround underground.
Measure outcomes: elapsed time, failed attempts, voluntary adoption, support demand, and developer satisfaction. Resource counts describe activity. Time saved describes value.
Finally, keep the platform smaller than its ambitions. Do not abstract every cloud service or support every application pattern. A platform becomes valuable by being dependable, not universal. The cloud providers have already built enormous catalogues. You do not need to recreate one with fewer engineers and an internal logo.
The conversations that no longer need to happen
Platform engineering is valuable when it reduces the organisational interactions required to deliver software safely. It fails when the platform team becomes another mandatory stop on the journey to production.
A portal can hide complexity. A platform should remove unnecessary dependencies.
The distinction is easy to miss because both can have templates, catalogues, APIs, and excellent diagrams. You see it in what developers do next. If routine work completes reliably, with useful feedback and appropriate controls, the platform is doing its job. If the next step is waiting for somebody to read a ticket, the organisation has only moved the queue behind a nicer door.
The success of an internal developer platform is not measured by how many services appear in its catalogue. It is measured by how many routine conversations no longer need to happen.
