Atulpriya Sharma, as a CNCF Ambassador and organizer of the Platform Engineering TCG, argues that the most important question in platform engineering is not whether an organization has built a platform, but how developers actually interact with its capabilities. Organizations that do not yet have an official platform often rely on scattered scripts and individual knowledge, while other organizations may have a developer portal, a CLI, and ready-made paths but still process requests manually. In both cases, the problem lies in the maturity of the interface through which teams consume platform capabilities.
The article draws on the CNCF Platform Engineering Maturity Model, which independently measures five aspects: investment, adoption, interfaces, operations, and measurement. Each aspect has four levels: ad hoc, operational, scalable, and optimizing. Under the model, an organization does not advance as a single unit; it may progress in one aspect while remaining behind in another. The analysis focuses on the interfaces aspect: the templates, CLI interfaces, portals, and APIs used by developers.
Four Stages of the Platform Interface
At the first level, the organization relies on custom procedures: manual requests, processes that differ between teams, and knowledge passed from one person to another. The absence of an official platform name does not mean that no platform exists in practice; repeated messages to a particular engineer asking them to provision a database represent the current platform interface, even if it is unmanaged.
The second level is standardized tools. Here, golden paths or paved roads, documentation, templates, and consistent interfaces emerge to provide and monitor capabilities. The results generally appear positive: higher adoption, faster onboarding of new employees, and improved metrics. However, requests outside the expected path still require intervention from the platform team, so the interface is standardized without being self-service.
At the third level, self-service solutions emerge, allowing developers to execute most routine requests without going through the platform team. This level measures team behavior more than it relies on metrics alone: tickets for routine provisioning decline, new engineers begin using the platform directly, and the platform team’s work shifts from executing individual requests to improving the framework that manages them. According to examples cited by the author, organizations reported a 40% to 60% decline in exception requests after adding configuration options for self-service.
At the fourth level, integrated services make platform capabilities a transparent part of everyday work tools. When a new service is created, monitoring, logging, and security can be integrated automatically, while security policies enforce their rules through the platform instead of requiring developers to negotiate them manually. The platform becomes nearly invisible, and its success is measured by how rarely developers have to think about infrastructure.
Why Do Organizations Stop at the Second Level?
The analysis identifies four recurring problems. The first is the queue problem: golden paths cover common cases, but exceptional cases may account for 30% of the work in large organizations. The author gives the example of a retail organization that used a golden path to deploy Kubernetes through Helm charts and ArgoCD. Adoption reached 85% within six months, but 40 exception cases accumulated, and the team began spending 60% of its time on configurations outside the path.
The second is the expertise gap; platform teams may build general capabilities that do not fully meet the needs of specialized teams, prompting those teams to develop alternatives. The third is the maintenance trap: every new capability creates an additional surface to update, test, and patch when a vulnerability appears or Kubernetes is upgraded. The author mentions a case in which old Helm chart interfaces, cloud-provider-specific dependencies, and network assumptions accumulated until updating them became risky.
The fourth problem is rigidity. A golden path reflects assumptions that are valid when it is designed, but those assumptions may become constraints as technologies, processes, and team needs change. At that point, exceptions and shadow infrastructure multiply, and the platform team becomes a factory for individual solutions instead of improving the core interface.
What Changes in Practice?
To move from the first level to the second, the author suggests naming what already exists before building a new portal: identify the requests that occur most frequently, consume the most time, and are most amenable to standardization, then choose a single golden path and genuinely improve it before expanding the catalog.
To move from the second level to the third, the platform team must stop being a mandatory human link. This requires making golden paths configurable, with validated options and constraints enforced through policies rather than hard-coded values, while providing escape routes for legitimate cases. The analysis also recommends measuring demand before automating it; in an example from the media sector, recording requests for three months revealed that 20% of request types accounted for 80% of the volume. Self-service was built for those patterns first, and the backlog fell by 60% within six months.
The interface should also be treated as a product, rather than focusing only on back-end capabilities. Discoverability, validation rules, contracts, and how unexpected requests are handled are all part of the product. As organizations approach the fourth level, automation shifts from an operation selected by the developer to smart defaults enforced by policies within Git, the development environment, and CI/CD systems, with ownership of capabilities distributed among security, database, and monitoring teams under clear contracts.
certi.news’s Reading
The actual change highlighted by the article is the shift in the success criterion for a developer platform from the number of tools and paths launched to the degree of autonomy users receive, and then to how deeply those capabilities are integrated into the workflow. This matters to platform teams because they may appear to increase adoption while transferring the burden of execution to a queue of exceptions and maintenance work.
However, the examples and figures presented here are offered by the author as observations from interactions with organizations, not as an independent quantitative study proving that the same percentages apply to every organization. Reaching the fourth level also presupposes maturity in contracts, policies, and ownership distribution—things that purchasing a portal or adding an AI agent alone cannot provide. The conclusion raises an important open question: a self-service interface designed for developers is not necessarily an interface that AI agents can consume, since they interact with APIs at frequencies and in patterns unlike human workflows. Therefore, the maturity of machine-consumable interfaces may be the next stage that platform teams need to measure.