This is the fourth article in our Platform engineering survival: Solving the core challenges series.
Today, the mandate for senior leaders is clear: reduce operating expenses (OPEX) and eliminate inefficiencies. For many organizations, the answer is platform engineering — a strategic layer designed to bridge the gap between infrastructure and application development.
However, a recurring pattern of failure has emerged. Large organizations invest millions into internal platforms only to find, three years later, that no one is using them. The platform becomes another "silo of tools" rather than a driver of accelerated growth.
In this article, Jason Wolfe, a seasoned Thoughtworks platform strategist, shares his insights into why platforms fail to gain traction and how senior leaders can shift their strategy from "toil reduction" to "user-centric enablement."
The accidental platform: Why adoption stalls
Many platforms are funded by accident. They begin as a localized solution to a specific vertical problem — usually a "toil-centric" issue where a team is overwhelmed by repetitive manual tasks. Leadership sees an opportunity to reduce OPEX by automating these tasks and funds a small investment expecting a big return.
While this approach might put out a local fire, it often fails to scale horizontally across the enterprise for three key reasons:
Toil removal vs. value creation: Removing toil makes a platform cheaper to run, but it doesn't necessarily make it better for those consuming the platform. If the platform only solves the operations team's problems, the developers (the primary customers) see no reason to migrate.
The "crust" of legacy thinking: Platforms are often born from old-school operations or monitoring teams. These teams frequently bring their "legacy crust" — old ticket-based workflows and vague boundaries — into the new platform, essentially rebranding old bottlenecks with a new "platform engineering" label.
Horizontal scalability gap: Success in one vertical (e.g., a specific product team) does not guarantee success in another (e.g., finance or HR). Leadership often tries to copy-paste a vertical solution into a horizontal one without resetting their understanding of the new users' needs.
First, get to know your customers: A case study in success
Jason highlights a standout success story involving a massive government agency platform serving thousands of developers. While most corporate environments prize "coding early" for rapid value delivery, this project flipped the ratio. A delayed project kickoff created an opportunity to build a foundation of deep investigation, with the team using this time to comprehensively evaluate and understand user needs and pain points before spending just six months writing code.
The result? They reduced the "time to hello world" — the time it takes a developer to get a simple application into production — from nine months to five minutes.
How they achieved it:
Deep friction identification: Instead of guessing what developers needed, the team invested their time identifying the primary source of friction: security and compliance.
Strategic pre-certification: They discovered developers were losing weeks waiting for security scans. The solution wasn't a faster scanner; it was a human agreement. The platform team provided pre-certified images, and if a developer used these images, the security team agreed to bypass certain manual checks.
The 80% rule: They didn't try to build a platform for everyone. They aimed for 60-80% of use cases. By narrowing the scope, they were able to release a product that was "fit to task" rather than a bloated system that tried to please everyone while serving no one.
Shifting the leadership mindset: Platform as a product
To overcome the adoption challenge, senior leaders must stop viewing the platform as an internal IT project and start viewing it as a product sold to an internal market. Jason shares three recommendations:
1. Survey the "feet on the street"
A common mistake is surveying other executives, directors or architects about platform needs. These stakeholders don't use the platform; developers do.
"If you aren't surveying the users broadly, you're going to have a bad time," warns Jason.
Executives should demand data from the developers on the ground. The most critical question to ask is: "What is your single biggest friction point in the current delivery lifecycle?" If the platform doesn't solve that specific pain, adoption will remain near zero.
2. Define clear boundaries
A healthy platform should look like a utility (e.g., AWS or GitHub). You don't call AWS into a "war room" when your app crashes; you check a status page. If your platform team is constantly pulled into crisis calls to "prove the health of the platform," your boundaries are too gray. Success is defined by clear interfaces that allow developers to self-serve without human intervention.
3. Move from vertical to horizontal with intention
When scaling a platform across departments, resist the urge to copy-paste. Systems thinking is required. Just as a software module must be redesigned to fit into a broader ecosystem, a platform's integration points (with finance, security, or compliance) must be re-evaluated for every new internal customer segment.
The path forward: Investment and patience
The J-curve of platform efficacy is a reality that leadership must accept. Initially, progress is slow. The planning phase looks like "doing nothing," and the initial release may only show modest gains. However, once the platform hits the fairway — where it is fit to task and solves genuine developer pain — adoption spreads "like wildfire."
The strategic checklist for senior leaders:
Audit the origin story: Is your platform team just the old "Ops team" with a new name?
Protect the planning phase: Resist the urge to demand code in week one. Invest in user sentiment and journey mapping.
Automate the "un-automatable:" Look at manual bottlenecks like security or finance. These are often solved through human negotiation and policy changes, which the platform then codifies.
Measure adoption, not features: A platform with 100 features and 10 users is a failure. A platform with five features and 5,000 users is a triumph.
By focusing on the developer experience and treating internal friction as the primary enemy, organizations can move past the "toil-reduction" trap and build platforms that truly accelerate the business.
Ready to turn the tide?
Don't let your platform become another silo. Start by surveying your developers today to find their true friction points and get an honest view of the current state of internal platforms.
In the next article, we explore how to escape the labyrinth of technical complexity and cognitive burden
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.