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

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.