TL;DR: Platform ROI helps us evaluate whether the value generated by a platform justifies its cost. Adoption metrics show whether development teams are using it, while outcome metrics help us determine whether it is solving the problems it was designed to address.
We end this series with one question: Is it worth the investment?
When we talk about investment, what are we actually concerned about?
Almost everything we do consumes two resources: money and time. Time also has an economic value, which we can estimate using factors such as hourly labor costs and the work that could be accomplished during those hours.
Return on Investment (ROI) is a financial measure that helps us evaluate the benefits of an investment relative to its cost.
Before calculating ROI, we need to establish a few assumptions.
How many users do we need to serve? How long is the platform expected to last? What could an incident or an extended period of downtime cost the business?
These assumptions give us a basis for estimating the investment and its expected benefits. Without them, translating technical improvements into business value becomes difficult, and defending the investment becomes even harder.
Each organization has its own objectives for implementing a platform engineering team.
For example, a retail system supporting military logistics may prioritize security, reliability and availability because disruptions could affect essential supplies. A retail system designed to handle Black Friday may place greater emphasis on scalability and its ability to handle sudden traffic spikes.
Both systems require reliable infrastructure, but their operational priorities differ. Those priorities influence how we define and measure success.
This brings us to the second part: Adoption Metrics.
What Should We Measure?
Before collecting metrics, we need to understand what we want to achieve.
If our objective is to reduce the time developers spend preparing environments, we should measure how long the process takes before and after implementing the platform.
If our objective is to improve reliability, we should examine system availability, incident frequency, and recovery time before and after.
If our objective is to support more development teams without increasing operational workload at the same rate, we should measure how many teams the platform can support and how much effort is required to maintain it.
The important thing is to measure what matters to the organization and connect those measurements to clearly defined objectives.
Adoption is not proof of success
Imagine we build a platform that provides automated deployment, environment provisioning, monitoring, and other self-service capabilities.
After six months, we discover that 80% of our eligible development teams are using it.
Is that a success? So what we set out to achieve?
If our objective was to encourage teams to use a standardized deployment process, adoption may be a useful indicator of progress.
If our objective was to reduce deployment time by 50%, we need additional evidence to determine whether we achieved that target.
Teams might use the platform while continuing to experience slow deployments. They could also spend more time working around platform limitations than they did before.
This is why we distinguish between adoption metrics and outcome metrics.
Adoption metrics tell us whether people are using the platform. Outcome metrics tell us whether the platform is delivering the results we expected.
Both matter because they answer different questions.
Choosing the Right Adoption Metrics
This is a few common examples.
1. Adoption Rate
How many eligible teams or developers are actually using the platform?
For example, if 40 out of 50 eligible development teams use the platform, the adoption rate is 80%.
However, we should also consider how those teams use it. Are they relying on the platform for their daily work, or did they create one test environment and never return?
Regular usage and the range of platform capabilities being used can provide a clearer picture of adoption.
2. Time to First Value
How long does it take a new team to get something useful from the platform?
For example, how long does it take a developer to provision an environment and deploy their first application?
If the same process previously took three days and now takes 30 minutes, we have a measurable improvement.
This metric helps us evaluate the initial developer experience and identify friction in onboarding, environment provisioning, and deployment workflows.
3. Self-Service Success Rate
How often can developers complete tasks successfully without requiring direct assistance from the platform team?
If developers can provision infrastructure, configure environments, and deploy applications themselves, the platform team can spend less time handling repetitive requests.
We can measure the proportion of self-service attempts that succeed without manual intervention. We should also track failed attempts, escalations, and the support effort required to resolve problems.
A high self-service success rate is useful when developers can complete their work reliably and safely.
4. Developer Satisfaction
Do developers find the platform useful and easy to work with?
We can collect feedback through surveys, interviews, or regular discussions with development teams.
A platform may meet its technical requirements while creating a frustrating developer experience. If developers consistently encounter confusing workflows, slow responses, or restrictive configurations, they may look for alternative ways to complete their work.
Developer satisfaction helps us identify these problems and prioritize improvements. Feedback becomes more useful when we connect it to specific workflows and observable platform performance.
Connecting Adoption to ROI
Now we can connect adoption metrics to our original question:
Is the investment worth it?
Let’s use a simplified example.
Imagine an organization invests $200,000 in building and operating an internal platform during its first year.
The platform serves 50 developers and saves each developer an estimated four hours per month by automating repetitive tasks.
If we estimate the economic value of developer time at $80 per hour, the annual value of the time saved would be:
50 developers × 4 hours × 12 months × $80 = $192,000.
In this example, the estimated value of the time saved is $192,000, compared with a first-year platform investment of $200,000.
Using a simplified ROI calculation:
ROI = (Benefits − Costs) × 100%
___________________
Costs
The result would be:
($192,000 − $200,000) × 100% = −4%.
_____________________
$200,000
Based on these assumptions, the estimated value of developer time saved falls $8,000 short of the first-year investment.
Does this mean the platform has failed?
The calculation alone cannot tell us that.
The $192,000 represents the estimated economic value of the time released from repetitive tasks. It does not automatically represent $192,000 in cash savings. The financial benefit depends partly on how developers use that time, such as delivering valuable features, improving reliability, or reducing work that would otherwise require additional resources.
The calculation also excludes other potential benefits, including reduced incident costs, improved security, faster delivery of business features, and lower operational effort in subsequent years.
We should evaluate these benefits using evidence and reasonable estimates. Counting every possible improvement as a financial saving would overstate the return.
The example illustrates why we need to define our assumptions, objectives, and measurement methods before calculating ROI.
The Cost of Not Having a Platform?
There is another side to the calculation that is easy to overlook: the cost of continuing with the existing approach.
Without a platform, developers may spend time building and maintaining similar tooling across multiple teams. Infrastructure provisioning may remain manual, and operational knowledge may become scattered across the organization.
These activities consume resources, even when their costs do not appear as a separate line item in a platform budget.
When evaluating an investment, we should compare the proposed platform against a realistic alternative.
That alternative might involve continuing with the existing process, improving the current tooling, or adopting an existing platform solution.
The question is whether investing in the platform provides greater value than the available alternatives, considering their respective costs, risks, and expected outcomes.
End of this part.
Throughout this series, we have discussed how to approach platform engineering.
However, some projects may require us to scale back rather than scale up. We may need to start smaller while preparing for future growth. If legacy systems are still needed, we must consider how to mitigate their risks and maintain an appropriate level of security.
All these decisions come down to understanding the trade-offs and evaluating whether the expected benefits justify the costs.
Platform engineering is not successful simply because we have built a platform, deployed the infrastructure, or attracted a large number of users.
We need to understand why the organization is investing in it, what outcomes it expects, and how we will measure those outcomes.
We do not need perfect predictions before starting a platform engineering initiative, just reasonable assumptions, measurable objectives, and a willingness to revisit our calculations when the actual results differ from our expectations.
After all, our goal is to build something that solves real problems and is worth the resources we invest in it.
Back to Certified Cloud Native Platform Engineering Associate Preparation