In today’s cloud-native era, a surprising yet common misalignment often arises within platform engineering teams: they’re led by someone from an IT infrastructure background rather than someone who has "lived the life" of the platform's primary users—developers.
This structure typically leads to a “build and mandate” approach, where the engineering team chooses all the platform tools, the platform is built to their specifications, and its use is enforced through policy.
This approach is seen repeatedly, and at the recent Gartner IT Symposium, several talks were given on this topic. The talks explained how Platform Engineering teams need to rethink their behaviors, stop designing to their wishes, and instead design to the explicit needs of their users.
In the modern software landscape, it’s the development teams, not the IT operations teams, that are the primary consumers of the systems delivered by platform engineering teams.
Developers rely on these platforms to be fast, flexible, and user-friendly, allowing them to build, test, and deploy code efficiently. However, when an IT infrastructure leader manages platform engineering, the approach can default to one that prioritizes stability and control over developer productivity and agility. Additionally, the platform engineering team often determines the developer-facing toolsets based on their assumptions of need rather than researching the actual needs (and constraints) of their users.
This difference in priorities leads to friction. Gartner’s research has consistently shown that for platform engineering to succeed, it must be customer-centric—designing around the needs of its users rather than the preferences of its builders. Developers, not platform engineers, should ultimately influence which tools are integrated and how they’re presented, ensuring the platform truly enhances productivity.
When infrastructure-oriented leaders lead platform engineering teams, platforms are often developed with a top-down mandate approach. This can result in rigid platforms that don’t adapt well to the dynamic needs of modern development. Developers, who thrive in agile environments and prefer self-service tools, often find these platforms obstructive rather than supportive, time-wasters rather than time savers. What does this result in? Shadow IT, where developers seek out (and often create) alternate services to serve their needs.
In contrast, leaders with a DevOps or software engineering background bring an inherently different perspective. They understand the need for flexibility and on-demand access because they’ve lived through the challenges developers face daily. Instead of building platforms around control, they build platforms around demand, fostering a naturally attractive environment for developers to adopt and engage with.
To design a platform that developers want to use, leadership must have experience with the challenges of the development cycle. A leader with a development or DevOps background understands the pain points of slow pipelines, poor integration, and bottlenecks in deployment. They’re in a better position to create a platform that solves real problems and adds value, rather than just checking boxes.
Platforms built with this demand-driven approach avoid the mandate trap. Developers naturally gravitate toward tools and systems that make their jobs easier, and when these tools are designed with their needs in mind, adoption becomes organic rather than enforced. Demand-driven platforms grow because they solve real issues, not because they’re mandated.
Many companies that have adopted a developer-led approach to platform engineering report increased engagement and higher satisfaction among their development teams. These platforms are designed to adapt quickly to user needs, driven by someone who understands the workflows and bottlenecks that developers face. They are also very aware of the impact that context switching and increasing the cognitive load on developers creates. Developers don't want to spend hours navigating complex tools, regardless of how "best of breed" they purport to be (e.g., backstage); developers want a tool that allows them to get their job done fast, with very little context switching needed.
The demand-driven approach aligns with Gartner’s advice that platform engineering must avoid “engineering for the sake of engineering - i.e don't build a cruise ship when your developers want a kayak.” Rather than allowing platform engineers free rein to choose tools based on personal preference or technical curiosity, the platform’s functionality is shaped by what its users truly need and nothing more.
If platform engineering is to meet the needs of modern cloud-native development teams, is it now time to rethink its leadership structure?
Instead of handing the reins to IT infrastructure veterans, should we empower leaders from software engineering backgrounds? These leaders have the insight and experience to prioritize developer-friendly tools and functionality that align with the workflows of their users.
So, rather than “build and mandate,” let’s build for demand. A platform that solves genuine needs doesn’t require mandates to ensure its use. In the cloud-native era, the key to platform engineering success is a leader who understands that their primary customers are the developers—and they’re here to serve.
What are your thoughts on this?
Neil