Is Platform Engineering in Danger?
How Enterprise stifles innovation: A Tale of Agile, DevOps, and Platform Engineering
It seems that every time a new and innovative way of working comes along—whether it’s Agile, DevOps, or now Platform Engineering—enterprises manage to take something promising and drain the life out of it. Why? Because true cultural change is hard, and organizations seem content to slap on new job titles and subtly tweak processes, instead of committing to meaningful transformation. In the end, they create bureaucratic systems that suffocate innovation, leaving us with the same old problems under shiny new labels.
The Rise and Fall of Agile
Agile was born out of a desire to improve software development. It emphasised customer collaboration over contract negotiation, responding to change over following a rigid plan, and delivering working software frequently. Its foundation rested on individuals and interactions rather than processes and tools. In theory, Agile was a game changer—a framework that allowed teams to adapt quickly, fostering both innovation and efficiency.
Yet, in the corporate world, Agile became something else. Instead of embracing its principles, companies wanted a system to follow—ironically the exact opposite of what the Agile manifesto stood for. Agile was supposed to be flexible, but as enterprises tried to standardise it, we saw the rise of prescriptive frameworks like Scrum. Suddenly, Agile meant endless meetings—daily stand-ups, sprint planning sessions, retrospectives, and grooming sessions that seemed to prioritise procedure over productivity.
Things only worsened with SAFe (Scaled Agile Framework), which promised to bring Agile to large organisations but instead turned into a bureaucratic nightmare. Companies were more concerned with adhering to the framework than delivering value. It became another checklist, void of the creativity and adaptability that Agile was supposed to foster.
Adding to the mess, Lean practices, typically used in manufacturing, became twisted into cost-cutting exercises that drained creativity from teams. IT departments became obsessed with eliminating anything deemed “waste,” leaving little room for innovation or experimentation.
Agile, once noble in its intent, became just another set of rigid procedures in the enterprise world—a far cry from its original vision.
DevOps: A Rebranding of the Status Quo
We sadly saw a similar story unfold with DevOps, once heralded as the solution to the age-old tension between development and operations. Its promise was simple: by tearing down the silos between these two groups, organisations could deliver software faster, with fewer errors and more reliability. The idea was sound. A cultural shift was needed—one that emphasised business value, customer focus, collaboration, and shared responsibility.
Instead, in many large enterprises, what we got was a rebranding exercise. Operations teams learned to install a few open-source tools, and suddenly declared themselves "DevOps". But the silos remained. DevOps was supposed to unify development and operations, but too often, the cultural change required for this integration was overlooked because, well, cultural change is hard. It’s much easier to change the names on org charts than to foster genuine collaboration between teams that historically never worked well together.
Many companies drank the Kool-Aid of tooling. Open-source tools flooded the market, and engineers jumped on them as a way to avoid the difficult work of fostering cultural change. But DevOps is about more than tools. It’s about bridging the gap between development and operations in a way that aligns with business objectives. Large enterprises, however, seemed more concerned with ticking off “DevOps” on their digital transformation checklist than implementing the real changes needed for success.
Will Platform Engineering Suffer the Same Fate?
Which brings us to Platform Engineering, the latest buzzword in the tech world. On paper, it’s about creating internal platforms that serve developers, making their work easier and more efficient. Done right, it’s customer-centric, focused on delivering business value, and guided by constant feedback. But if history tells us anything, it’s that Platform Engineering is in danger of suffering the same fate as Agile and DevOps.
I’m already seeing many enterprise infrastructure teams being rebranded as “Platform Teams”, without the necessary shift to a product mindset. Instead of focusing on developer enablement and feedback loops, I’ve seen teams become obsessed with the platform itself. As my good friend, Coté, once said that “Kubernetes is great, but it’s been a 7 year distraction”. Such teams build what they assume developers want, and are surprised when their offering is ignored.
“At the heart of the problem is that many infrastructure teams struggle to accept that their job is primarily to serve the needs of developers.”
When speaking with a new “developer focussed” team, one of my favourite questions to ask is “what IDE do your developers primarily use?” Eyes quickly dart around the room until one brave soul answers as best they can, but the mood changes when I joyfully ask how they’re devs are finding it, or what the most used plugins are. The truth is that infrastructure teams very rarely spend any time worrying or discussing with developers what their average day actually looks like.
It’s a sociotechnical problem that we’re trying to solve, and so, unsurprisingly, communication is at its core. Mel Conway is the OG of developer experience, and his work highlights how important it is for platform engineers to have strong feedback loops with developers; if they don’t, then they risk building systems that bear no resemblance of the needs of those who actually use their platforms.
Successful Platform Engineering requires a broad skill set that blends technical expertise with business acumen, customer empathy, and even marketing savvy. It demands people who can identify opportunities, understand customer needs, and innovate accordingly—a far cry from the typical ops role, and what engineers are likely to learn through any Computer Science degree or formal IT training.
Culture Eats Innovation for Breakfast
At its core, the problem is that enterprises are hesitant to embrace the cultural changes necessary for these movements to succeed. It’s a long journey of introspection and iterative change, not something that can be bought or copied from somewhere else.
Agile, DevOps, and Platform Engineering is about people, not tools.
Cultural change requires effort, introspection, and a bravery to rethink old habits. Without it, every new idea—whether Agile, DevOps, or Platform Engineering—will continue to be stifled by bureaucracy and corporate inertia. In the end, it’s not the methodologies themselves that fail, but the enterprise’s unwillingness to do the hard work of real change.