Platform Strategies Need Prerequisites, Not Just Enthusiasm
Developer productivity platforms are widely promoted as a way to reduce the cognitive load on engineering teams and speed up feature delivery. The model is attractive: consolidate shared infrastructure, tooling and operational capabilities into an internal product that product teams can consume as a service. But the decision to build such a platform is an economic one, and it depends on a set of organisational competencies that many companies underestimate.
The gap between ambition and execution is substantial. A platform is not a collection of scripts and clusters. It is, as Evan Bottcher puts it:
A digital platform is a foundation of self-service APIs, tools, services, knowledge and support which are arranged as a compelling internal product.
Platform teams typically take commercial or open-source offerings and host, adapt or extend them so they fit their organisation's specific context. The goal is not to reinvent what the market already provides, but to fill the gap between what can be bought and what is genuinely useful internally. That might mean simplifying a complex Kubernetes offering to match your infrastructure assumptions, improving a build script, or running a workshop to help a team define SLOs. The broad view matters: if it reduces friction for developers, it is platform work, regardless of whether it involves provisioning hardware or documenting an API.
Business Value Must Be Articulated
Before committing to an internal platform, you need a clear business case. That case must weigh the efficiency, quality and time-to-market gains against the full cost of construction and ongoing maintenance. If a commercial tool already covers the need without customisation, buying it is usually the better choice. A platform strategy that increases the amount of undifferentiated work across the organisation is a net loss, even if it consolidates some capabilities.
That justification cannot be a one-time exercise. The economic logic of each feature shifts as vendors release updates and your own organisation changes. Fine-grained decisions about which features to offer and how to offer them require continuous re-evaluation. The backlog should therefore reflect a greater share of continuous improvement than innovation compared with end-user products. Operability work must be a first-class citizen, and teams need to plan for deprecation. Every platform offering will eventually be replaced by a better external option, an internal successor or a decision to return the capability to product teams. Ignoring that lifecycle undermines the initial business case.
Treat the Platform as a Product
The platform's users are your product development teams. Their experience determines whether the platform delivers value. Poor API ergonomics, incomplete documentation or flaky behaviour will drive users away, no matter how sound the underlying technology. Customer empathy and product ownership matter for internal tools just as they do for commercial products.
Internal products have one structural advantage: your users care about the outcome and are often willing to contribute. Some will be enthusiasts, others sceptical. Cultivating the enthusiasts and turning them into early adopters and internal champions is the most effective adoption strategy available. It is also marketing—not the external kind, but the internal communication of roadmap, feedback channels and success stories that keeps the platform relevant.
When things fail, transparency and apology are essential. Outages are inevitable, and how you handle them shapes user trust more than any architecture diagram. Managerial mandates as an adoption mechanism will fail; captive users who resent the platform will neither use it well nor contribute productively to its improvement.
Operational Excellence Is a Trust Requirement
Adopting a platform asks product teams to place significant trust in the platform organisation. That trust rests on technical competence across the fundamentals of infrastructure—networking, scaling, disaster recovery—and on operational maturity. If the platform team struggles with the underlying technology, the products they build for other teams will be fragile.
This means that your platform teams need to have a sound grasp of the fundamentals of software infrastructure, like networking, scaling and disaster recovery.
Beyond raw infrastructure skills, modern operational excellence implies proficiency in SRE practices. Observability, monitoring and SLOs are not optional extras. Without them, you risk breaking developer trust and failing to notice until the damage is done. Incident management needs a mature process: effective alerting, blameless retrospectives and fair support arrangements. Out-of-hours support needs to be properly covered in contracts and budgeted for. It should also be structured to make participation safe and appealing, so that on-call duties are shared broadly rather than falling on a few.
Planning also changes when you operate a platform. Significant changes, such as migrations, must be made gracefully, with deliberate investment to minimise disruption. The inevitable outages must be communicated thoroughly and lessons must feed back into practice.
Building an internal platform is ambitious and forgiving of optimism, but not of missing fundamentals. Organisations without the resolve to develop product thinking, operational excellence and a defensible business case along the way are unlikely to see a worthwhile return. Start early, measure honestly and remain open to the possibility that in your context, the market might already be doing it better.
Engineering Discipline Behind the Platform
A platform organization is more than an operations department, so it needs more than operational skills. Even without building substantial custom applications, your scripts, templates and configuration files will quickly accumulate complexity. To keep your platform easy to change, you have to build it with the same rigor as any other software system.
In an infrastructure context, that means following the three core practices of infrastructure as code defined by Kief Morris: define everything as code, continuously test and deliver all work in progress, and build small, simple pieces that can be changed independently. Consistent application of these practices is what allows an organization to execute on its platform vision. Without them, you might reach a good infrastructure state at a single point in time, but you won't sustain the pace of evolution that development teams' changing needs demand.
Using internal products also places demands on product teams. Good product development teams understand the service levels offered by their dependencies, factor them into their designs, and mitigate risks that could impact their own service level objectives. This matters even more when dependencies are internal, because no matter the quality of your platform, it is unlikely to reach the polish of a commercial SaaS provider.
Team Structure for the Long Run
Individual skill matters, but sustaining excellence requires strong team disciplines. When platform systems are depended on by the rest of the business, it isn't acceptable for expertise to reside with only a few busy individuals. You need autonomous teams with clear missions, and you must avoid individual code or system ownership. Teams need to invest in knowledge sharing, documentation, and onboarding. A single person winning the lottery should never threaten the viability of your platform.
Planning systems must be mature as well. Platform engineering teams need backlogs described in terms of value and clear prioritization processes, otherwise the urgent overwhelms the important. Incidents and unplanned work are inevitable, but if toil consumes too much of a team's time, it will never invest in improving its products. And teams should not try to manage too many platform products at once.
The concept of cognitive load from Team Topologies by Matthew Skelton and Manuel Pais is useful for keeping missions manageable. If a team constantly switches context between unrelated tasks, its cognitive load is too great; the team becomes less capable in its daily work, and new members struggle to gain confidence across all the systems.
Starting Small
Missing these capabilities doesn't disqualify you from a platform strategy. The way in is not to compromise on execution quality, but to be modest in the scope of ambition—at first. Any platform initiative, no matter its size, should produce business value, follow product thinking, be built with operational and software engineering excellence, and be backed by a team structure that can sustain it. Anything less and the boost you hoped to deliver becomes a drag that tarnishes the platform's reputation with internal developers.
Small, focused platform services on well-understood parts of the technology estate have a lower degree of difficulty. They don't let you skip a holistic perspective, but they allow you to get started and grow. Providing a logging cluster that eases operational burden and improves visibility, for instance, has clear business value that doesn't need sophisticated financial modeling. It still requires product thinking (does its availability, freshness and search UI meet developers' needs?), just not the maturity needed for something like a unified developer portal. And it requires software engineering, operational skill and a healthy team—though not as much as building, say, an observability sidecar for every microservice.
The first question should be: what is the smallest thing we can build that would help the product teams? The second: how could we upgrade or migrate away from this when the time comes? The state of the art evolves quickly, and vendor lock-in is no less painful because the vendor is your own organization. If deprecating a platform service means a years-long painful transition, go back to the drawing board. You don't need a detailed calendar or substitute technologies ready to go, but factoring in a realistic lifetime of three to five years and architectural seams for replacement will force simpler, more decoupled designs.
Make platform adoption voluntary. This supports the strategy in two ways. Product teams that can opt out encourage you to keep services loosely coupled, which helps when the time comes to launch a new generation of a service or replace it with a commercial offering. Dependence on product teams' appreciation of the platform also keeps customer delight front and center for the platform organization. Mandatory migration erodes that product thinking discipline over the long term.
A simple maturity classification can set expectations for new platform features, like marking something as beta. Association with SLOs and support tiers is useful—an experimental feature shouldn't offer the same high availability or round-the-clock support as a core one. Full support signals SLOs strong enough for mission-critical components; before that, lighter expectations give the platform team freedom to experiment and validate assumptions before making a long-term commitment.
With these practices in place, platform teams manage small portfolios of very effective products. Cognitive load stays low and focus remains on continuously reducing the development teams' time to market, not just keeping the lights on.
