In the world of software, developers are the new COGS - and software companies the world over are now on the quest to improve their profitability (and cash flow, and distributions to shareholders). This is the way the world works, and this blog is not a commentary on capitalism. Rather, this serves merely as context for why platform teams exist: the great developer experience push is merely the quest to improve developer velocity.
In this noble quest, deploying infrastructure has been identified as a major impediment to developer velocity. Many organizations have now invested in platform engineering to create reusable, standardized, and faster infrastructure configuration.
Despite the great time-saving dreams of even the best platform teams, platform engineering initiatives often fall short. Below, we’ll explore three of the most common reasons for failure.
1. Becoming an Impediment
While platforms are intended to accelerate development, they can quickly become bottlenecks. Overly rigid platform architectures hinder developers by introducing cumbersome workflows and inflexible, confusing templates.
Consider Terraform modules, the classic example of rigidity:
Imagine a platform team at a large organization that developed a Terraform module to standardize the provisioning of VMs across its cloud infrastructure. The module was designed with strict parameters and configurations to enforce company-wide standards—for example, requiring specific instance types, storage encryption, monitoring, logging, networking settings, security groups, and the list goes on. While the intention was to ensure compliance and consistency, the module quickly became overly rigid.
Consider a scenario where a development team needs to deploy an instance for a new application that requires a slightly different configuration—perhaps enhanced monitoring is required or a unique networking setup is not accounted for in the pre-defined module. This forces the team to spend significant time either lobbying for changes or manually modifying the code, both of which (paradoxically) slow them down instead of helping them move faster.
Frustrated by these constraints, a savvy developer might decide to bypass the module altogether. Instead of using the prescribed module, they write their own Terraform scripts to meet the specific requirements of their project. While this approach allows them to move faster in the short term, it introduces risk that the module aimed to deal with in the first place.
When developers view the platform as an obstacle rather than an enabler, they tend to bypass it, leading to inconsistent practices and platform sprawl. According to Thoughtworks, making platforms optional to start and loosely coupling services can lead to higher adoption by individual engineers.
2. Lack of Clear, Measurable Goals and Tying to Business Outcomes
In their piece on Building Infrastructure Platforms, Poppy Rowse and Chris Shepherd write that successful platform teams start by “creating a goal…that all of your stakeholders [buy] into”.
Without clearly defined objectives, a platform initiative can easily become directionless. According to Forrester, setting clear goals for digital transformation and platform efforts is crucial for success. Vague aims like "improve efficiency" or "ensure compliance" lead to fragmented projects that fail to deliver cohesive value, as teams operate without a unified direction.
Consider a platform that is created with the goal of “improving developer experience”. This lacks consensus on a real, measurable goal. When it comes time to make platform UX and process decisions, the lack of clear goals will result in varying opinions (and outcomes).
A real-world example of this can be simplified to UX: should a company’s infrastructure platform users be utilizing code, or a UI? Depending on who you ask in any organization, you will get wildly different answers.
According to Gartner, tying goals of platforms to overall business objectives is associated with higher performing platforms. These goals should be anchored by detailed, compelling problem statements attached to measurable goals.
As Rowse and Shepherd write...
The first step to creating a strategy is to get the right people together to define the problem. This should be a mixture of product and technical executives/budget holders aided by SMEs who can help to give context about what is happening in the organisation
Next, defining specific & measurable goals:
Provide the top 15 product teams with the infrastructure they can easily consume to reduce the time to market by an average of 6 months
Have less than 3 hours of outages in the next 18 months
3. Insufficient Buy-In from Stakeholders/Not talking to customers
A successful platform requires active engagement from all stakeholders. According to Gartner, platform teams are 4.1x more likely to drive higher performance if they engage directly with their platform users for feedback. While this seems obvious, it is far too often that platform teams build things that their stakeholders are not looking for.
Without genuine buy-in from developers, operations, and leadership, a platform risks low adoption and superficial compliance, as teams may revert to legacy systems or create their own workarounds.
It is easy to imagine a scenario where a company’s executives imagine a platform that will totally transform their infrastructure operations. They envision a single set of configurations for every service, with limited offramps for making changes/customizing optionality.
Meanwhile, imagine that developers are envisioning a UI-first tool with nearly unlimited customization options, with hyper-modularity and significant autonomy.
Finally, the platform team is envision a code-first interface with limited support for a UI and a mix of modularity and monolithic behavior. They are most concerned with offloading decision-making, and don’t think that UX is as important as the existence of self-service.
If this scenario sounds familiar, it is because it is far too common: varying personas within companies will have drastically different expectations and preferences. It is the responsibility of the platform team to navigate these preferences, set expectations, define goals, and continuously react & take feedback.
Conclusion
Platform engineering holds transformative potential, but its success depends as much on measurement, buy-in, and communication as it does on creating technically excellent interfaces and automation.
By ensuring the platform serves as an enabler rather than an impediment, setting clear goals, securing stakeholder buy-in, and carefully measuring ROI, organizations can steer their initiatives toward success.
Interested in building an infrastructure developer platform? Resourcely has what you need - get started today.
.png)