Platform Engineering
Why Platform Engineering Success Depends on Product Mindset, Not Just Technology
A platform engineer explains how infrastructure-first thinking and technical over-engineering sabotage adoption—and why understanding your users is the real secret to building platforms developers actually want to use.
InfoQ
The most common failure mode in platform engineering isn't a technical one—it's a human one. Max Korbacher, a consultant and author specializing in platform engineering, argues that the gap between building a platform and building one that developers genuinely adopt comes down to mindset: treating the effort as a product for internal customers, not an infrastructure project with a deadline.
The Problem with Infrastructure-First Thinking#
Most internal development platforms fail for reasons that have little to do with the quality of their code. Adoption struggles, misaligned management expectations, and unmet developer needs are the real culprits. The classic trap is building a flashy portal—like Backstage—before understanding what problems it's supposed to solve. A portal installed fresh is empty; configuring it to deliver value demands months of work and multiple engineers before delivering any tangible benefit.
The root cause often traces back to how platform teams approach the work itself. Teams that come from infrastructure and DevOps backgrounds naturally fall into infrastructure-first thinking, beginning with architectural decisions and building upward from the technology stack rather than outward from user needs. This means designing for technical elegance rather than developer experience. The result: over-engineered systems, tools added based on conference excitement rather than actual problems, and platforms that solve no one's real pain points.
Organizational Chaos Breeds Duplicated Effort#
The environment where platforms live is rarely stable. Large organizations face waves of reorganization, staff turnover, and industry hype cycles—from IoT to cloud-native to Kubernetes to AI. Each shifts priorities and splinters alignment. When there's no unified approach, teams build their own solutions. The result is duplicated effort across operations, release management, user management, and internal tooling—work that could have been centralized but instead becomes a patchwork.
These patches are inherently temporary and hard to sustain. Traditional DevOps teams inherit the burden: on-call schedules, emergency fixes, and the thankless job of keeping systems alive. Platform engineering is meant to be different—not a fire-fighting ops team, but a product organization that produces something developers want to use without coercion.
