Your Developers Don't Need More Tools. They Need a Paved Path.
In this article
We have heard the same story from every enterprise client we’ve worked with in the past two years. It goes something like this: “We bought Kubernetes. Then we bought Backstage. Then we bought ServiceNow. Developers are still opening tickets and waiting three weeks for a database.”
The problem was not the tool count. It was the absence of opinionated defaults, clear ownership, and a self-service path that actually works.
The Real Problem Is Not Tool Count
Enterprises are drowning in DevOps tooling. A 2024 Puppet State of DevOps survey put the average enterprise toolchain at over 40 tools. Not 40 categories of tools. Forty individual products, each with its own login, its own configuration, its own learning curve.
We have walked into client environments where teams use Jira for ticketing, ServiceNow for change management, Confluence for docs, GitHub for source control, Azure DevOps for pipelines, Artifactory for artifacts, SonarQube for code quality, Terraform Cloud for IaC, ArgoCD for GitOps, Datadog for monitoring, PagerDuty for alerting, and Vault for secrets. That is twelve tools before anyone writes a line of application code. Each one was purchased to solve a real problem. Together, they create a new one: nobody knows how to get anything done.
The instinct when developers complain about being slow is to buy another tool. A developer portal. An AI coding assistant. A new CI platform. But adding tool number 41 to a stack of 40 rarely fixes the underlying issue. The answer is usually better defaults, integration, and a cleaner self-service path through what you already have.
Where Guardrails Are Controls and Where They Are Conveniences
Good guardrails are a mix of enforced controls and friction-reducing defaults. The enforcement keeps the platform safe. The defaults keep it usable.
In enterprise Azure, some guardrails are outright restrictions: allowed SKUs, approved regions, enforced tags, network patterns, RBAC boundaries, and Azure Policy denies. Calling those “not restrictions” would be dishonest. They are restrictions, and they exist for good reason.
Other guardrails are conveniences that remove decisions. Need a PostgreSQL database? Don’t file a ticket. Don’t write Terraform from scratch. Don’t pick from six different modules on your internal registry. Submit a YAML file or API request with your database name, size, and environment. The platform provisions it with the right networking, the right backup schedule, the right monitoring, and the right cost tags.
The best guardrails combine both: you can’t deploy without tags (restriction), but the pipeline auto-applies standard tags from your project metadata (convenience). Developers hit the control point without feeling blocked.
For the minority of requests that don’t fit the standard path, there must be an explicit exception route with ownership, justification, and a defined response time. Without that, developers will work around the platform instead of through it.
We wrote about one concrete implementation of this model in our piece on building a YAML-driven infrastructure catalog. The pattern separates what teams want (a YAML configuration or API request) from how it gets provisioned (Terraform stacks owned by the platform team). Application developers never touch HCL. They describe what they need, and the platform delivers it.
What Developers Actually Want From Self-Service
The word “self-service” gets thrown around a lot, usually by vendors selling developer portals. When you talk to developers about what they actually want, the list is shorter and more specific.
They want to provision a new environment without waiting for another team. They want to deploy code to production without filing a change request. They want to find the service they depend on and know whether it’s healthy. They want to onboard to a new project without spending two days setting up local tooling.
Developers want fewer disconnected choices, not more. They want the right default, fast. They also want discoverability: knowing what’s available, what’s approved, and how to request it. That interface can be YAML, a CLI, an API, or a portal. The form factor matters less than whether there’s a good paved path underneath.
Tools like Backstage and Port work well as a discovery layer when the defaults are already solid. They fail when they’re deployed on top of an empty platform as a substitute for having one. A portal without paved paths underneath is a catalog of confusion.
The platform teams that succeed build for the common case first. One default way to create a service. One default way to deploy it. One default way to connect it to a database. An explicit exception path for the minority case. The teams that fail try to accommodate every team’s unique workflow instead of defining a good default. We have seen organisations spend eighteen months building an Internal Developer Platform that nobody used because it tried to support every edge case before shipping anything standard.
What This Looks Like in Azure
Concretely, a paved path in an Azure enterprise often includes:
An approved landing zone model that gives each team a subscription with networking, identity, policy, and monitoring pre-configured. Azure Verified Modules or standardised Terraform modules that bake in security best practices, diagnostic settings, RBAC, and tagging so that a developer who requests a Key Vault gets a compliant, logged, correctly-tagged Key Vault without a meeting about it.
Pipeline templates for standard service types that handle build, test, scan, and deploy for 80% of workloads. Policy-enforced defaults that ensure every resource gets cost tags, diagnostic settings, and approved network configurations. Auto-instrumented monitoring via Application Insights or OpenTelemetry sidecars, so observability is on by default, not a separate onboarding task.
And a clear exception path for teams that genuinely need something non-standard: a request, a justification, a review, and a response time.
As we covered in our Container Apps vs AKS decision framework, even the choice of container platform is itself a guardrail. Defaulting teams to Container Apps instead of AKS removes months of operational overhead. The teams that genuinely need Kubernetes can still use AKS, but the paved path shouldn’t start with the most complex option.
Measuring Whether Your Platform Is Working
You can’t justify a platform team’s existence with vibes. You need numbers. Two categories of metrics matter.
Delivery metrics tell you whether the platform is making things faster. DORA metrics are the starting point: deployment frequency should go up, lead time for changes should go down, change failure rate should stay flat or improve, and mean time to recovery should drop. DORA’s own guidance cautions that these metrics work best when measured per service or application and that context matters. Don’t aggregate them into a single organisation-wide score and expect useful signal.
Platform product metrics tell you whether the platform is being adopted and is solving the right problems. These are often more actionable than DORA for a platform team:
- Adoption rate of paved paths (what percentage of new services use the standard templates?)
- Median provisioning time (how long from request to running environment?)
- Time to first deploy (how fast can a new team go from zero to running in non-production?)
- Exception rate (what percentage of requests don’t fit the standard path?)
- Percentage of workloads on standard templates versus bespoke configurations
- Support tickets per 100 onboarded services
- Developer satisfaction (short quarterly survey, one key question: “How easy is it to get what you need from the platform?”)
If DORA metrics don’t move in six months and adoption stays flat, either the wrong problem is being solved or critical bottlenecks remain outside the platform team’s control.
Why Platform Teams Fail as Projects and Succeed as Products
Platform engineering is 30% technology and 70% organisational change. You can build the best self-service platform in the world, and it will fail if you don’t change the incentives around it.
The platform team needs to operate like a product team, not a project team. That means having an actual product boundary, a roadmap, service-level expectations for the teams they serve, and a regular internal customer discovery loop. A platform with no product owner and no adoption accountability usually becomes a tooling graveyard with better branding.
The operations team needs to let go. In most enterprises, the Ops or infrastructure team controls provisioning because it was the only way to maintain governance. A self-service platform with guardrails replaces that control with automation. The governance is still there, encoded in templates, policies, and pipeline checks. But humans are no longer the bottleneck. That is a hard transition for teams whose identity is built around being gatekeepers.
Leadership needs to fund it properly. A platform team is not two engineers who build tooling in their spare time. It is a dedicated team with a dedicated backlog, building and maintaining a product that the rest of engineering depends on. Underfund it and you get a half-finished portal that everyone works around.
Where to Start
If you’re reading this and thinking “we should do something about our platform,” start with one painful workflow, not an internal platform moonshot.
Pick the thing developers complain about most. In our experience, it is almost always environment provisioning, CI/CD pipeline setup, or database onboarding. Build a good solution for that one thing. Ship it. Get feedback. Iterate.
Adopt where possible, build where necessary. You don’t need to write a developer portal from scratch when Backstage and Port exist. You don’t need to write your own Terraform modules for common resources when Azure Verified Modules are available. Your platform team’s time is better spent on the integration glue that connects these pieces to your specific environment.
Measure from day one. Before you build anything, capture your baseline: how long does provisioning take today? How many tools does a developer touch to deploy? What’s your deployment frequency? Without a baseline, you can’t prove the platform is working, and without proof, the platform team is the first budget line to get cut.
Treat the platform as a product with real users. Talk to developers every two weeks. Watch them use the platform. See where they get stuck. The best platform teams we work with have a channel where developers report friction, and the platform team treats every message like a bug report.
Related: YAML-Driven Terraform: Building a Self-Service Infrastructure Catalog shows one concrete implementation of a catalog-driven paved path. Azure Verified Modules covers when to use standardised modules and when to write your own.
Ready to automate your infrastructure?
From Infrastructure as Code to CI/CD pipelines, we help teams ship faster with confidence and less manual overhead.
