Bridging the gap between platform engineering and business value | Thoughtworks

Enable javascript in your browser for better experience. Need to know to enable it?<br>Go<br>here.

Search

Close

Ask Tai

Bridging the gap between platform engineering and business value

Blogs<br>Back

Blogs<br>Back

Close

Platforms

Legacy modernization

Blog

By

Punit Lad

Published: July 08, 2026

This is the sixth article in our Platform engineering survival: Solving the core challenges series.

In modern software delivery, platform engineering is often considered as the “holy grail” of developer effectiveness. It provides a foundation of centralized infrastructure, self-service portals and standardized workflows which allows developers and the business to move faster and build better products.

However, many organizations hit a wall before they ever reach platform maturity. The platform is seen as a bloated overhead, and following an awkward meeting where a CFO asks what 20 expensive engineers are actually delivering to the bottom line, budgets are frozen. According to Punit Lad, platform specialist, technical lead and infrastructure engineer at Thoughtworks, the primary hurdle isn't the technology, but the lack of business case and financial alignment.

The assessment disconnect

Most engagements begin with a focus on efficiency and effectiveness. Business leaders are looking to address development problem spots and decide that a platform is the solution. However, leaders who approve the budget often exit after the kickoff. By moving away from the groundwork of the assessment, they miss opportunities to understand the specific bottlenecks or the technical details, causing development to slow down.

The remaining group of infrastructure, DevOps and site reliability engineer (SRE) specialists will continue to discuss technical nuances. But because the business is absent, a shared understanding of the problem space is never built, with technology viewed as a “black box” that the business simply trusts will work. This “trust in advance” is actually dangerous because of the disconnect it creates. Down the road, this often manifests as a financial crisis that those business leaders can’t truly understand.

The two-level removal problem

Platform engineering almost always suffers from being “at least two levels removed” from actual business value.

Because the platform team's consumers are internal developers rather than external users, the business struggles to see the direct ROI. To a CFO, a platform team can look like a massive cost center that isn't directly generating revenue. (We often see a platform engineering team created as an offshoot of existing infrastructure / DevOps teams, which have pre-existing budgets associated with them).

The business might come back and say, “Why are you spending tons of money developing this platform engineering case? How does it actually impact the business?” If we can't speak the language of time-to-value or market share, we lose.

Punit Lad

Platform SME, Technical Lead and Infrastructure Engineer, Thoughtworks

The financial trap: OPEX vs. CAPEX

New platforms teams inherit the cost model of the legacy operations teams that it would be replacing. Traditionally, the legacy operations team is seen as OPEX (operating expense), a reactive cost of doing business. When the platform engineering initiative starts, it inherits this cost structure. However, during the build and migration phase, costs actually increase. This is because the organization is effectively running two environments: the old legacy infrastructure and the new platform.

In the short term, the new platform doesn’t have the customer base or maturity (organizationally and politically) that the legacy infrastructure has. And without a strong business narrative, this spike in cost to infrastructure as a whole will look like a failure. This often leads leadership to question the increase in cost and for the platform and infrastructure  leadership to respond. To survive, platform teams must shift the narrative from reactive spending to CAPEX (capital expenditure). A proactive investment needs to be made in the organization's future capacity to scale, drive efficiency and be ready for changing market or customer demands.

Justifying CAPEX with incomplete data

Shifting the narrative to CAPEX requires platform teams to speak the language of the business, yet they often lack the raw, high-fidelity data needed to do so. We need to acknowledge the fact that the ability for platform teams to justify CAPEX expenditure relies on existing data. Due to the fact that the legacy infrastructure and devops practices are often sprawling and undocumented, data like time to value (TTV) and time to recovery (TTR) are difficult to capture. The initial business cases are frequently built on subjective assessments and small-sample interviews rather than organization-wide raw truths. Ironically, while the platform itself is the tool that would eventually...