Beyond Compelling: Building Meaningful Platforms

Platform teams have become a key part of many modern tech organisations. They are often seen as enablers of developer productivity, reducing cognitive load by handling cross-cutting concerns and letting product teams focus on delivering value. Their work supports delivery at scale, not by owning feature development, but by creating the conditions that make it faster and safer.

But in practice, things often play out differently. Starting out with platform teams, especially in organisations consisting mature and experienced dev teams, platform teams can become just another dependency, one that teams have to wait on or work around. Their solutions, while well-intentioned, may not always fit the needs of every context. Worse, they can constrain autonomy when offerings are pushed top-down rather than discovered through collaboration.

This article offers a different lens for thinking about platform, not as a collection of tools, but as a set of abstracted common concerns. From this perspective, the real value of a platform lies in surfacing, evolving, and stewarding abstractions that make sense across domains. And sometimes, the most effective way to build those abstractions isn't through a dedicated team at all.

What Actually Makes a Platform a Platform?

A common refrain I hear about platform offerings is that they should be "compelling". While the word brings positive connotations (after all, who wouldn’t want a compelling offering?), it is ultimately vague and can be quite damaging. It doesn’t clarify what makes a platform valuable or how to build something that truly meets the needs of development teams. A platform's real value lies not in its appeal but in how effectively it helps teams solve real problems.

Platform is often seen, and rightly so, as a foundational layer: CI/CD pipelines, authentication services, observability tooling, and so on. But platform capabilities don’t have to be limited to low-level building blocks. In some contexts, higher-level concerns can also be treated as platform offerings. These concerns can be approached horizontally, making them applicable across development teams.

What counts as a horizontal, reusable capability can vary depending on the organisational context. A feature flag capability, for instance, might be tightly coupled to a specific product domain in one scenario (vertical), while in another, it could evolve into a generalised, cross-cutting service (horizontal) that supports many teams.

The key is that platform capabilities should aim to be reusable and supportive, not just technically shared, but meaningful across multiple domains. And while these capabilities form the foundation of a platform, their real value only emerges when they help product teams solve real problems in actual services. Standing alone, they serve little purpose. In context, their value only becomes real.

A CI/CD pipeline, for instance, has little value in its abstract form. Its effectiveness depends on how it supports the specific codebase structures, deployment models, and feedback loops of the teams relying on it. Similarly, an internal authentication service only becomes useful when it fits the security model, user flows, and requirements of the consuming application.

Building the Wrong Thing, Beautifully

Platform offerings are more than just tools. They represent abstracted concerns that can be reused across teams in their specific contexts while hiding underlying complexity. But abstractions are difficult to get right. Their usefulness depends entirely on how well they align with the realities of their use, and they are difficult to create upfront or validate in isolation.

And here lies the problem: most abstractions fail when they are inferred too early. A platform team that builds a generalised solution before the different contexts in which it might be used are well understood often ends up producing something that looks polished but does not quite fit the needs of development teams. At best it is ignored. At worst it is mandated, becoming a constraint rather than an enabler.

Yet waiting for teams to converge organically on a shared need is not without risk either. By the time such a need emerges and is clearly worth abstracting, the organisation may already be facing delays as teams wait for the platform team to provide a solution they can reuse in their context. When the platform team is then asked to step in, they often become a bottleneck.

This creates a kind of paradox: the best abstractions emerge from actual use, but the platform team is often expected to define them before that use exists.

Building the Right Thing, Collaboratively

Good platform design means adapting to the changing needs of teams, not forcing them to adapt to the platform. However, to avoid becoming a bottleneck, the platform must stay one step ahead, anticipating needs based on the business vision and shifts in the tech landscape. We can't afford to simply wait for demand to shape the offering, as this passive approach could lead to delays.

Creating something meaningful, useful, and ultimately widely adopted isn’t easy, but a few pieces of advice might help steer platform work in that direction.

1. Start Small

The most effective abstractions are those discovered through use. Starting with a basic, simple capability makes it easier to identify what’s truly fundamental across teams. For example, consider managing application or service configuration. Initially, you might just provide a way to store and retrieve configuration settings as key-value pairs. As different teams start using it, they might identify the need for features like environment-specific configurations, validation rules, or versioning. By starting with this minimal, core capability, the abstraction can evolve over time based on real needs, instead of trying to predict and build for every potential requirement from the start.

One way to set a solid foundation for such abstractions is to rely on established open standards. OpenAPI for HTTP API descriptions, OAuth 2 for authorisation, and OpenTelemetry for observability are just a few examples. These standards provide mature, widely adopted frameworks for addressing common problems, making it easier to meet baseline needs across teams. They also help the platform stay a step ahead. When teams require something beyond what these standards offer, those needs emerge naturally through use and if they prove to be horizontal and applicable across contexts, they can then guide the thoughtful evolution of the platform.

2. Design for Modularity

By default, platform capabilities should favour modularity and composability, enabling teams to adopt only what fits their specific context. This approach supports diverse needs and makes the platform easier to evolve over time. Offering platform features as composable building blocks helps tailor solutions without enforcing a one-size-fits-all model. For example, instead of a single, rigid Infrastructure-as-Code template (AWS CloudFormation, Terraform etc.), the platform team might provide a set of modular templates that handle common concerns such as networking, compute, monitoring, access control which teams can compose and tailor to their specific use cases. This approach enables consistency without sacrificing flexibility, allowing teams to adopt only what they need while still benefiting from shared best practices and guardrails.

3. Don’t Rush

It’s tempting to try to build a complete offering quickly, but abstractions need time to mature. Pushing a solution too early can lead to misalignment with actual needs. A more measured pace gives space for real patterns to emerge, while still relying on teams to handle non-core concerns where appropriate.

4. Let It Emerge Through Collaboration

The most meaningful platforms are not imposed. They’re discovered through collaboration. The starting point is often a solution developed by one team to solve a particular problem. Through open sharing and discussion, other teams begin to recognise that they’re facing similar challenges. This natural convergence of needs can reveal a common capability worth elevating into the platform.

Of course, one of the hardest parts is determining whether a solution developed in a specific context is truly applicable across others. That requires deliberate discovery: surfacing the underlying capability and describing it in measurable terms to validate that it meets the broader need. This is not trivial and it deserves deeper treatment in a separate discussion.

By borrowing proven solutions from product teams and refining them into reusable capabilities, we not only create useful offerings but also build trust and alignment. This collaborative process ensures that the platform feels like something the teams have helped shape, rather than something imposed upon them. It fosters a sense of ownership and autonomy because the platform evolves alongside the teams, addressing their concerns and adapting to their needs, not constraining them.

You Don’t Always Need a Platform Team (Yet)

Thinking about the paradox of platforms and following the guidelines above, we can draw a few observations.

First, we need to shift the mentality that "platform = internal tools", where the focus is on building products for developers in the same way product teams build for customers. Adopting a dogmatic product-thinking mindset, focusing solely on roadmaps, backlogs, and shipping features, isn’t always ideal for platforms. Platforms are not products in the traditional sense. They are enablers of other products. Treating dev teams like customers to be "served" can create distance and erode trust. Instead, platforms work best when built with teams, through shared problem-solving, not for them in isolation.

Largely, the most effective platform offerings emerge naturally through collaboration, reuse, and convergence across product teams. In such cases, the need for a dedicated platform team is not a given. A centralised team may not be necessary upfront, or even at all. What’s important to recognise is that a platform is not an organisational structure. It is an emergent outcome of collaborative effort. This approach helps ensure platform offerings are closely aligned with the actual challenges developers face, increasing the chances they’ll be adopted.

Together, these observations reflect a common dynamic that many organisations encounter, especially in the early stages of adopting platforms to support mature development teams.

Of course, I’m not implying that platform teams aren’t needed. The point is that they shouldn’t be established from the start in every scenario, but rather emerge organically as specific needs arise across development teams. Their value becomes clear when common challenges surface that require dedicated focus and expertise. As the platform evolves and shared services grow in complexity, platform teams can step in to refine and manage the abstractions that support the wider audience, ensuring alignment with business goals and technical requirements.

In both cases, the same four pieces of advice still apply. I like to think of platform teams as backstage heroes, always present when needed, never stealing the spotlight.