The Blind Spots of Platform Engineering • Matt McLarty & Erik Wilde
Matt McLarty and Erik Wilde explore the blind spots in platform engineering, arguing that a narrow focus on developer velocity and toolchains overlooks the critical need for creating reusable, API-driven business capabilities that deliver tangible value and organizational optionality.
Platform engineering, while rooted in the valuable principles of DevOps, often suffers from a significant blind spot: an excessive focus on the mechanics of software delivery at the expense of business outcomes. The movement risks optimizing the “how” of building software—velocity, toolchains, and developer experience—while neglecting the “what” and “why.”
The Narrow Definition of Platform Engineering
The common definition of platform engineering often centers on creating toolchains and workflows for self-service capabilities in a cloud-native context. For example, platformengineering.org defines it as:
“the discipline of designing and building tool chains and workflows that enable self-service capabilities for software engineering organizations in the cloud-native era.”
This definition is inherently IT-centric and engineering-focused. It fails to bridge the most critical chasm in modern enterprises: the one between the business and the technology organization (DevOps). While DevOps successfully brought development and operations together, the next leap in value comes from aligning technology capabilities directly with business goals. A platform defined purely in technical terms struggles to demonstrate its value to business leaders who approve the budget.
Misunderstanding the “Platform”
The term “platform” itself is overloaded, leading to confusion. A distinction should be made between different types of platforms:
- IT Platforms: The underlying infrastructure.
- Internal Developer Platforms (IDPs): The primary focus of platform engineering, aimed at developer efficiency.
- API Platforms: A collection of reusable business and technical capabilities.
- Business Platforms: The set of digital building blocks that constitute the business’s functionality.
- Platform Business Models: Business models like Uber or Airbnb.
Platform engineering, in its current incarnation, almost exclusively refers to the IDP. This creates a risk of investing heavily in building things faster without ensuring the right, most valuable things are being built.
The Missing Piece: Optionality and APIs
The true value of a platform lies in creating optionality—the capacity to combine and recombine existing business capabilities in novel ways to address new market opportunities, creating “happy accidents.” This is achieved by building a rich catalog of reusable business building blocks exposed as APIs.
A platform should not just be a set of CI/CD pipelines and infrastructure services. It should be an environment where developers can easily discover and consume existing business capabilities, like customer data or order processing functions. The default assumption should be that anything built is exposed as a reusable API, creating a forcing function for composability. If a developer’s first step isn’t to check a catalog of existing assets, a major opportunity for leverage is lost.
Avoiding the Hype Cycle Trap
Like Service-Oriented Architecture (SOA) and microservices before it, platform engineering is at risk of becoming a technology hype cycle. This pattern occurs when the industry latches onto the technical implementation (e.g., “SOA means SOAP,” “microservices means Kubernetes”) and loses sight of the core principles (e.g., reusability, modularity). Organizations then become frustrated when they don’t see the promised benefits.
The focus should not be on building a “cathedral” based on what companies like Amazon or Netflix do. Instead, organizations should take an incremental approach, guided by tangible business outcomes. If the problem is slow time-to-market, one must analyze the entire value stream. Investing in a state-of-the-art CI/CD pipeline is pointless if the bottleneck is a month-long manual testing cycle.
Shifting Down and Focusing on Outcomes
The concept of “shifting left” in DevOps was about addressing issues early in the development lifecycle. Platform engineering introduces the idea of shifting down—moving responsibilities from individual product teams into the platform itself to gain efficiency and consistency. The crucial question is what to shift down. This decision should be guided by business value, not just technical elegance.
Ultimately, the success of a platform engineering initiative should be measured by its ability to accelerate business outcomes. A simple litmus test is to ask: Are the only APIs in your platform the ones for the platform’s own services? If so, you are likely missing the opportunity to build a true business platform that fosters innovation, reusability, and strategic optionality. The conversation must be elevated from pure technology to how the platform enables the business to win.