Bridging the gap between platform engineering and business value

Platform engineering teams often struggle to demonstrate business value, leading to budget freezes and financial crises. Thoughtworks specialist Punit Lad says the primary hurdle is a lack of business case and financial alignment, not technology. To survive, platform teams must shift the narrative from reactive OPEX spending to proactive CAPEX investment.

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. 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 automate and provide these vital metrics, teams must first secure long-term investment based on these incomplete early assessments to reach that level of operational maturity. Winning the business with three key levers If you’re looking to secure or protect funding for a platform initiative, you must lead with metrics the business understands. 1. Cost reduction and economies of scale This is the easiest narrative to sell, as most every stakeholder is looking to save money. By centralizing infrastructure, you can leverage volume discounts and reduce redundant tools. However, be warned: these savings can often take several years, often between two to five, to fully manifest. If you promise immediate cost-cutting, you may face a nosedive in trust when the bill stays high during the migration phase. 2. Time-to-value TTV and time-to-recovery In business terms, TTV is about market share. If a development team takes months / years to get a feature into production, the company can easily lose to more agile competitors. Platform engineering reduces the friction of development and allows development teams to reduce their time to value and time to recovery. Because the raw data may not be directly available, platform teams need to speak directly to how improving these core metrics has a business impact. The days / weeks / months saved in a path to production directly results in the business’ ability to capture market opportunities at a moment's notice. 3. Compliance and security While cost is the easiest conversation, security is the most critical. A platform can enforce security protocols like CVE scanning, infrastructure hardening and compliance requirements by default. The immediate goal to development teams is time to value, but that time to value must still adhere to organizational compliance and security requirements. Investment in a platform team, ensure adherence across your sprawling development organization, through the use of reusable and conformed assets. The business value then states there is normalized prevention of security and compliance requirements, further preventing harm to the business and its customers. ie. preventing a data breach that could cost millions in fines and a total loss of customer trust . Platform teams aren’t just allowing teams to move at the speed that they need to, but ensuring the brand is protected. The path forward: Speaking the language of the CFO To bridge the gap, platform leaders must stop demoing Kubernetes clusters and start showcasing business outcomes. There must be a proactive effort to have the business be part of those initial assessments and not just there for introductions . They are and must be a key part of why the platform needs to exist, and should be there to help understand and shape the initiatives like discovery, inception, etc , along with your technology leaders. The value proposition of “you get more with less” is incredibly strong. The challenge is that this “more” velocity, security and “less” long-term cost efficiency must be mapped directly to the bottom line. If you want your platform to survive the next budget cut, bring the business back into the room. Show them how effective engineering isn't just a technical “nice-to-have”, but a core driver of customer satisfaction and competitive advantage. Disclaimer: The statements and opinions expressed in this article are those of the author s and do not necessarily reflect the positions of Thoughtworks.