Your Platform Is Probably Working - You Just Can't Prove It

Here's what platform engineers won't say out loud: very few can answer the question "Was it worth it?". This talk tries to help you answer that.

Everyone knows that to call the win you first need to measure success; the hard part: knowing what to measure. This is where people start shopping: DORA, SPACE, DevEx, MONK/MOCK, Scorecards, OKRs and more. So many frameworks, yet 30% of organizations still don't measure anything at all (I guess they didn't know what to pick), while others pick one or two and hope they work.

After building multiple platforms with tools such as Kubernetes Operators, Terraform, Crossplane, pipelines and good old Java, let me tell you what we measured and what really mattered. In every journey, the real challenge wasn't picking a framework: it was figuring out what success actually meant, and then measuring it without losing sight of what we were aiming for.

Let's walk through these frameworks so that you can bring home a "slightly" opinionated approach on how to measure platform initiatives at Day 0 (still building), Day 1 (we got there), and Day 2 (it worked - now scale it, please).

Transcript

1. Cloud Native Days Austria 2026 Your platform is probably working PRESENTER Riccardo Capraro You just can’t prove it ❏ ❏ ❏ Platform Engineer Cloud Native Trento Organizer Freelancer
2. Cloud Native Days Austria 2026 Your platform is probably working You just can’t prove it
3. Cloud Native Days Austria 2026 Your platform is probably working failing You just can’t prove it don’t know it yet
4. What metrics should I use to prove it? 4
5. It started with… 5
6. Books, conferences, talks, … 6
7. It all boils down to this 7
8. Platforms go through different stages of maturity 8
9. At each stage they must prove something different
10. To do that, we use metrics DORA, SPACE, MONK/MOCK, DX Core 4, HEART… 10
11. Panel @ Cloud Native Summit Munich 11
12. Questions… ❏ What did success mean for your platform initiative? ❏ How did you measure it? ❏ Did what you measure change as the platform matured? 12
13. Start with… What metrics should I use to prove that my platform is working? (or framework) 13
14. Start with… What metrics should I use to prove that my platform is working? (or framework) 14
15. Fallacy #1: Goodhart’s law https://www.explainxkcd.com/wiki/index.php/2899:_Goodhart%27s_Law 15
16. Reframe to… Based on my goals, what metrics would help me prove my point? 16
17. Fallacy #2: They don’t get it Let me find another metric to make them understand 17
18. “ Anchor teams and decisions based on user outcomes, not just features or internal metrics. ” 18
19. “ Avoid vanity metrics that look impressive but do not inform real decisions. [..] Ensure that every metric can be acted upon and ties back to user outcomes.” 19
20. Based on my goals, what metrics would help me prove my point? 20
21. Based on my goals, what metrics would help me prove my point? To whom? For what purpose? 21
22. Based on my goals, what metrics would help me prove my point? To whom? For what purpose? To whom is THAT person proving something? For what purpose? 22
23. Fallacy #3: We all share the same goals 23
24. “ Stakeholders have significantly different success criteria than customers do. ” 24
25. “ Which metrics to track at the investment level will depend on how your organization makes investment decisions. ” 25
26. What metrics should I use to prove that my platform is working? REFRAME IT!!! (or framework) 26
27. Based on their goals, what evidence would they need to make a decision? 27
28. Example #1: Pipeline Migration The Objective Migrate pipelines from old tool to Github Actions: ❏ 100+ devs ❏ 4 repos ❏ 5 people on the team 28
29. Questions ❏ What is the fastest way to migrate everyone to the new system? ❏ What is the minimum set of jobs we need to migrate to release from Github Actions? ❏ Team dependencies: who can be migrated first? 29
30. Example #1: Pipeline Migration 30
31. Example #1: Pipeline Migration 31
32. Example #1: Pipeline Migration 32
33. Example #1: Pipeline Migration The Objective Migrating pipelines from old tool to Github Actions Real objectives ❏ Drop old expensive license ❏ Maintain or improve stability ❏ Reduce # of delayed releases 33
34. Example #1: Pipeline Migration The metrics THEY were using to make a decision 34
35. Example #1: Pipeline Migration What we should base our narrative on 35
36. Questions… ❏ What is the fastest way to reduce the number of agents running on the old system ❏ What is the fastest way to reduce the number of seats in the old license 36
37. Example #1: Pipeline Migration 37
38. “ In business terms, the value of a platform [..] lies in its enablement of time to market, or optimizing flexibility in the cost of delay” 38
39. Metrics are used as evidence to inform decisions 39
40. Example #2 Goal Migrate dev environments from Docker Compose to Kubernetes for 100+ devs Decision to be made Roll out a month before going to production? 40
41. Example #2 What we needed to prove ❏ Better than the old one? ❏ The metrics that helped us ❏ % of people that tested the Is it “risk-free”? new system (adoption) ❏ % of people using the new system during the transition period (adoption) ❏ Go/no-go from devs (customer satisfaction) 41
42. Metrics are used as evidence to inform someone else’s decisions 42
43. Example #3 Goal Provide the fastest way for developers to have a service in production Decision to be made A. Clone repo + centralised TF B. Backstage + (A) C. Clone repo + per project TF 43
44. Example #3 What we needed to prove ❏ Number of teams did not ❏ The metrics that helped us ❏ Number of failed setups justify complexity, flexibility is based on provisioning not needed. method (self-service) Devs also just cared about speed to production and ❏ Developer feedback (happiness) ease of use. 44
46. The Foundations 46
47. CNCF Platforms White Paper Platform Engineering Maturity Model 47
48. 1. Why platforms? 2. What is a platform CNCF Platforms White Paper 3. Attributes of successful platforms 4. Attributes of successful platform teams 5. Challenges when implementing platforms 6. How to measure the success of platforms 7. Capabilities of platforms 48
49. Platforms go through different stages Platform Engineering Maturity Model 49
50. Platforms maturity has different levels Platform Engineering Maturity Model 50
51. Platforms maturity has different levels Platform Engineering Maturity Model My experience 51
52. Platforms maturity has different levels Platform Capability Factors W E N An approach to grow internal platforms beyond bottlenecks into thriving marketplaces. 52
53. Platforms go through different stages Platform Engineering Maturity Model 53
54. At each stage they must prove something different 54
55. To do that, we use metrics DORA, SPACE, MONK/MOCK, DX Core 4, HEART… 55
56. Timeline 56
57. DORA ❏ Change lead time ❏ Deployment Frequency ❏ Change failure rate ❏ Failure recovery ❏ Deployment rework rate (2024) 57
58. DORA ❏ Change lead time ❏ Deployment Frequency ❏ Change failure rate ❏ Failure recovery ❏ Deployment rework rate (2024) Software delivery 58
59. SPACE ❏ Satisfaction & Well-being ❏ Performance ❏ Activity ❏ Communication & Collaboration ❏ Efficiency & Flow Developer Productivity 59
60. DevEx Developer Productivity 60
61. DX Core 4 (Dora + Space + DevEx) ❏ Speed ❏ Effectiveness ❏ Quality ❏ Impact Developer Productivity 61
62. DX Core 4 (Dora + Space + DevEx) ❏ Speed ❏ Effectiveness ❏ Quality ❏ Impact Developer Productivity 62
63. MONK (MOCK) ❏ Market share ❏ Onboarding time ❏ Net Promoter Score (NPS) ❏ customer satisfaction (CSAT) ❏ customer effort scores (CES) ❏ Key customer metrics ❏ -> DORA, SPACE Prove value of Platform Engineering 63
64. MONK (MOCK) ❏ Market share ❏ Onboarding time ❏ Net Promoter Score (NPS) ❏ customer satisfaction (CSAT) ❏ customer effort scores (CES) ❏ Key customer metrics Measure progress to prove the value of Platform Engineering to your Organization ❏ -> DORA, SPACE 64
65. HEART ❏ Happiness Goals Signals Metrics (GSM) ❏ Engagement ❏ ❏ Adoption Goals - the objective ❏ ❏ Retention Signals - suggests progress ❏ Task Success towards goal ❏ Metrics - measure signals Product & User Experience 65
66. What about AI? DX AI ❏ Utilization ❏ Impact ❏ Cost 66
67. All in one HEART + GSM User Experience DORA Software Delivery Metrics DevEx Developer Productivity SPACE Developer Productivity MONK/MOCK Value of Platform Engineering DX Core 4 DORA + DevEx + SPACE 67
68. We started with… What metrics should I use to prove that my platform is working? (or framework) 68
69. Reframed to… Based on their goals, what evidence would they need to make a decision? 69
70. The 2 Ways to look at metrics 1⃣ - Metrics are used to provide evidence to inform decisions 70
71. The 2 Ways to look at metrics 2⃣ - We use metrics to feel good 71
72. We use metrics to prove a point feel good ❏ Setting goals ❏ Progress ❏ Developer joy ❏ Gamifying the platform journey 72
73. Look outside the window Talk to: - UX - PM - Decision Makers - Devs - … Ask them: ❏ How do you make decisions? ❏ What do you need me to prove? ❏ What frameworks do you use to track progress/success? 73
74. Thank you! Leave feedback -> 74
75. Connect & let’s talk! 75
76. Ask questions or Tell YOUR STORY in 60 seconds ❏ What was the goal? ❏ What decision needed to be made? ❏ How did you argue for or against it? ❏ What metrics helped you? 76
77. References - Books • • • • • • • • • • Chankramath, A., Cheneweth, N., Oliver, B., & Alvarez, S. (2025). Effective Platform Engineering: Build self-service interfaces to boost developer experience. Manning Publications. Körbächer, M., Grabner, A., & Lipsig, H. (2024). Platform Engineering for Architects: Crafting modern platforms as a product. Packt. Hohpe, G. (2024). Platform Strategy: Innovation Through Harmonization (with contributions by M. Danieli & J.-F. Landreau). Leanpub. Skelton, M., & Pais, M. (2025). Team Topologies: Organizing Business and Technology Teams for Fast Flow (2nd ed., foreword by R. Malan). IT Revolution. Helfand, H. (2020). Dynamic Reteaming: The Art and Wisdom of Changing Teams (2nd ed.). O'Reilly. Allen, R. (2025). User Needs Mapping: Aligning Teams Around What Matters. Leanpub. leanpub Forsgren, N., Humble, J., & Kim, G. (2018). Accelerate: The Science of Lean Software and DevOps. IT Revolution. Moore, G. A. (2014). Crossing the Chasm (3rd ed.). HarperBusiness. Edmondson, A. C. (2018). The Fearless Organization. Wiley. Greever, T. (2020). Articulating Design Decisions (2nd ed.). O'Reilly. 77
78. References - Talks • • • • • • • • • • Cloud Native Summit Munich Panel: Your Platform Is Probably Working - You Just Can't Prove It Why Your Platform Engineering Is Failing (And How to Fix It) - Sam Barlien State of the Art of Platform Engineering • Abby Bangser & Charles Humble • GOTO 2026 Platform Engineering for Developers, Architects & the Rest of Us • Daniel Bryant • GOTO 2025 Ewan Duncan: Rewiring value The ROI of User Experience Developer Joy – How great teams get s%*t done - Sven Peters DORA Metrics in Practice: Make them Observable through your Platf... Danielle Cook & Andreas Grabner From zero to hero: Building an innovative product-oriented platform team - Eline Henriksen Building a platform engineering team: A 101 guide to success - Jean Burellier | PlatformCon 2025 78
79. References - Other links • • Platform Engineering Maturity Model | CNCF TAG App Delivery The Art of Platform Thinking | Thoughtworks 79
80. Bonus 80
81. More questions from What the audience asked 81
82. Question #1 How can we effectively translate engineering-centric metrics into clear business value that resonates with non-technical stakeholders/managers? ❏ ❏ Understand what they need to make decisions (the numbers they understand) Then focus on the translation 82
83. Question #1 What the user says Zweite Kassa, bitte! 83
84. Question #1 What the user says Zweite Kassa, bitte! What your metrics tell you ❏ ❏ Pipeline congestion at the end of the day, no available runners Critical jobs being delayed by low-prio pipelines 84
85. Question #1 What the user says Zweite Kassa, bitte! What they want to hear Our users are frustrated when they spend their whole day at work and get to the end to find out that they need to delay their What your metrics tell you time to go home to wait for jobs ❏ Pipeline congestion at the being delayed. end of the day, no available We don’t really need another runners cashier, just a timer that shows ❏ Critical jobs being delayed by pipeline congestion and a way for them to prioritize critical low-prio pipelines pipelines. 85
86. Question #2 How do you prove success or failure can be attributed to the platform? • Backtrack from outcome 86
87. Question #3 AI-tools are enabling a more diverse group of people to bring workloads to production. Do our platforms need to adapt and if yes, how? ❏ ❏ Yes, platforms need to adapt New users = new needs 87
88. Question #4 Do you agree that most observability platforms are good in proving how they contribute to Dev Experience but lack in proving how they benefit the business? Differently asked: What led to the fact that Developers lost the feeling to be a business stakeholder for their employer? ❏ ❏ ❏ It was never their job and they were never trained to do that You cannot assume that everyone know product management, UX design, business strategy etc. - you need multiple people in your team Learn x-101 helps you be a better stakeholder 88
89. “ What counts as ‘fast enough’ or ‘safe enough’ will shift over time ” 89
90. “ The platform’s product owner handles viability. The platform engineers [..] feasibility. The DevX [..] desirability.” 90
91. The agenda ❏ A lot of questions about success, metrics, ROI,... ❏ Some foundations ❏ The best answers I could come up with ❏ More questions from CNS Munich audience ❏ Tell YOUR STORY in 60 seconds 91
92. Tell YOUR STORY in 60 seconds ❏ Our goal was to… migrate pipelines to GH ❏ We need to prove… teams needed to change how they worked ❏ In order to… get valuable form new system ❏ What helped us was… tracking dependencies across teams to create independent releases 92