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 by someone who understands the needs of their primary users—developers. This structure typically leads to a “build and mandate” approach, where tools are chosen, a platform is built, and its use is enforced through policy rather than through demand.
In the modern software landscape, it’s the development teams, not the IT operations teams, that are the primary consumers of platform engineering. Developers rely on these platforms to be fast, flexible, and user-friendly, allowing them to build, test, and deploy code efficiently. But when an IT infrastructure leader manages platform engineering, the approach can default to one that prioritizes stability and control over developer productivity and agility.
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 platform engineering teams are led by infrastructure-oriented leaders, 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 the developers seek out alternate, public, services to serve their needs.
In contrast, leaders with a DevOps or development 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 increasing 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 (eg backstage), Devs 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.” 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, it’s time to rethink its leadership structure. Instead of handing the reins to IT infrastructure veterans, we should empower leaders from development or DevOps backgrounds. These leaders have the insight 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’s naturally adopted doesn’t need 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 you thoughts on this?
Neil