Measure Before Someone Calls Platform Engineering Expensive
In 2026, justifying Platform Engineering investment has become the top priority for CTOs and VPs of Engineering. With costs ranging from ¥20M to ¥80M at large enterprises — and hundreds of millions annually at the largest organizations — the question "So what actually improved?" is coming from executives more frequently than ever. Organizations that cannot answer that question are beginning to face restructuring.
The challenge is that Platform Engineering outcomes are embedded in the daily experience of developers, making them hard to capture with simple KPIs. Even when deployment frequency increases, it's not always clear whether Platform Engineering deserves the credit, whether other refactoring work drove it, or whether release standards were simply loosened. The solution lies in operational design that uses multiple frameworks in combination.
DORA: Still the "Minimum Baseline" Standard
The four DORA metrics — Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Restore — have been entrenched as standard delivery capability benchmarks since Nicole Forsgren and colleagues published *Accelerate* in 2018. The 10th edition of the State of DevOps Report in 2026 continues to treat them as core metrics, and the Elite-tier thresholds remain essentially unchanged: deployments multiple times per day, lead time under one day, CFR below 5%, and MTTR under one hour.
The limitation of DORA is that it does not measure individual developer experience. An Elite-performing organization where developers achieve those numbers by firefighting emergency deployments overnight is a very different animal from one where an automated pipeline produces the same results calmly. SPACE and DevEx emerged after 2020 to fill exactly this blind spot.
SPACE: Five Dimensions of Team Health
The SPACE framework (Forsgren, Storey, Maddila, Zimmermann, Houck, Butler, 2021) captures developer productivity across five dimensions: Satisfaction and Well-being, Performance, Activity, Communication and Collaboration, and Efficiency and Flow. Its defining rule is that you must always combine multiple dimensions — never measure just one in isolation. This was a direct rebuke to the anti-pattern of chasing Activity metrics like commit counts.
In practice, SPACE implementation means selecting two to three indicators per dimension and measuring them regularly. For example: Satisfaction via a quarterly Developer Experience Survey and turnover rate; Performance via service uptime and feature adoption; Activity via pull request volume and meaningful commit rate; Communication via code review turnaround time and mentor nomination rate; Efficiency and Flow via the proportion of uninterrupted focus time and frequency of interruptions. The critical commitment is to never use these numbers for individual performance evaluation — once you break that rule, Goodhart's Law takes over and the metrics stop functioning.
DevEx Framework (2023): Feedback Loops, Cognitive Load, Flow State
The DevEx Framework published by Nicole Forsgren and colleagues in 2023 centers on three areas that Platform Engineering can directly improve: Feedback Loops, Cognitive Load, and Flow State. Whereas SPACE provides a bird's-eye view of team health, DevEx focuses specifically on what the platform can actually touch — which is its key differentiator.
Feedback Loops refers to the time between a code change and knowing its result — the chain from local build time to CI pipeline time, PR review time, staging deployment time, and time to observe in production. This is the area most directly impacted by Platform Engineering improvements. Cognitive Load is the burden of what developers have to hold in memory: the quality of on-call documentation, how discoverable internal APIs are, how automated environment setup is. Flow State is how many consecutive hours of focused work a developer can get, and is a function of notification frequency, meeting density, and interruption count.
The official DevEx Framework recommendation is to combine perception (subjective) and workflow (measured) data — running quarterly surveys alongside daily telemetry in parallel.
Developer Experience Index (DXI): Integrating into a Single Score
One of the most common questions in the field is "Is our situation actually getting better?" — and people want a simple, clear answer. DXI (Developer Experience Index), introduced in 2023 by DX (CEO Abi Noda), responds to that need. As of 2026, more than 200 large enterprises have adopted it.
DXI uses a 14-question survey on a 5-point Likert scale, calculating a weighted average score from 0 to 100. The questions cover areas where Platform Engineering has direct influence: Deep Work Time, Ease of Deploy, Confidence in Making Changes, Quality of Internal Documentation, and others. Based on DX's internal benchmarks, the median score sits at 68, the top quartile at 80 or above, and the bottom quartile at 55 or below.
DXI's appeal is that it enables rough estimates like "a one-point increase translates to X hours of productivity gain." DX's meta-analysis finds a correlation of 0.5 hours of productivity improvement per developer per week for every one-point rise in DXI — which can be converted into a monetary figure using labor costs and presented to the board. It is a simplification, but it works as a communication bridge between Platform teams and leadership.
Tool Selection: Opsera, Faros AI, Jellyfish
Even with frameworks in place, data collection, aggregation, and visualization require tooling. Here is a breakdown of the three leading products in 2026.
Opsera, known for "DevOps Intelligence," excels at pipeline-centric data collection. It extracts DORA metrics from Jenkins, GitHub Actions, Azure DevOps, and GitLab CI with minimal configuration. It is well-suited to organizations that prioritize visibility into CI/CD operational health. Opsera holds SOC2 Type II and FedRAMP Moderate certifications, making it viable for regulated industries.
Faros AI, positioned as an "Engineering Operations Platform," provides a comprehensive data model with strong integration across Jira, Git, CI, Incident, and Calendar tools. It supports simultaneous measurement of DORA, SPACE, and DevEx, and added AI-based Bottleneck Detection in 2025. It also supports write-out to data warehouses (Snowflake, BigQuery), making it popular with organizations that prioritize internal BI integration.
Jellyfish, in the "Engineering Management Platform" category, is most distinguished by its visualization of investment allocation across Feature, KTLO, Tech Debt, and Innovation work. DORA and SPACE are supported as standard, and it auto-generates "engineering investment vs. outcomes" numbers that are effective for conversations with Finance. It is best suited to organizations that prioritize board-level reporting.
As a rule of thumb: choose Opsera if pipeline optimization is the priority, Faros AI for holistic optimization with AI-driven insights, and Jellyfish for Finance alignment and investment allocation visibility. As of 2026, implementation track records in the Japanese market are approximately 30 organizations for Opsera, 15 for Faros AI, and 20 for Jellyfish. All three offer partial Japanese UI, with full localization planned for the second half of 2026.
Organizational Maturity Model: Match Metrics to Stage
One common failure is trying to measure everything from the start. Metrics that don't match an organization's maturity become hollow and counterproductive. The following staged model works well in practice.
Stage 1 - Ad-hoc (just after the Platform team is formed): Start with just two of the four DORA metrics — Deployment Frequency and Lead Time. The goal is to build the measurement infrastructure itself; precision is secondary.
Stage 2 - Foundational (12–18 months in): All four DORA metrics plus DXI survey twice a year. Add Platform adoption metrics — number of services registered in the catalog, Golden Path utilization rate.
Stage 3 - Intentional (when the platform is operating as a product): Continued DORA + quarterly DXI + multiple SPACE dimensions + actual measurement of DevEx Framework Feedback Loops. Quarterly Platform NPS.
Stage 4 - Optimized (when the platform is approaching a Profit Center function): All of the above + monetary ROI conversion + investment allocation analysis. Quarterly reporting to the board.
Stage 5 - Transformative: The platform itself becomes a candidate for external productization or benchmarking contribution. External visibility through conference presentations at Platform Engineering Day or KubeCon, and OSS contributions.
Practical Language for "Generating ROI"
When presenting to leadership, simpler is stronger. A DXI increase of 5 points equals X thousand hours per year, which converts to Y hundred million yen. P1 incidents down Z per month, SRE on-call fatigue index improved by W%. Golden Path-adopted services: N, average time-to-first-deploy reduced from X days to Y hours. Don't show these on a dashboard — fit them on one slide.
In 2026, "we improve developer experience" alone won't protect a Platform Engineering budget. Measure what matters, and speak a shared language with leadership. That is the fastest path to establishing Platform Engineering as a cultural infrastructure.