When you create an internal developer platform, treating the platform as a product is crucial. That means you need to measure progress with a product mindset, too. The MONK metrics help measure your progress and prove the value of Platform Engineering to your organization.
Measure Platform Engineering with MONK metrics
MONK metrics mix platform adoption and performance with metrics to show impact on the platform’s customers; the developers:
- Market share
- Onboarding time
- Net Promoter Score (NPS)
- Key customer metrics
Market share
Your market share is the number of developers who use the platform rather than an alternative. You must run a regulated market, so you can’t force people to use your platform. Developers who opt not to use the platform must have the same responsibility to deliver security, reliability, and governance requirements.
Developers should have the option not to use the internal developer platform. The platform team should respond competitively by improving the platform to gain market share. If developers move off the platform, find out why. Take a second look at your relationship with developers and explore why they didn’t flag an issue before moving away.
To understand your market share, you should track the number of developers:
- In the organization
- The platform could help
- Using the platform
When you need to choose between possible features for the platform, it helps to consider the impact it will have on market share. What problems are causing pain for development teams that your platform could solve? Understanding the share, and the trend over time, can help your decision-making.
You can increase your market share by supporting more scenarios or convincing teams to move onto an existing ‘golden pathway’. Avoid adding workflows you can’t do well and focus on spreading the joy developers will experience by adopting one you can handle.
Onboarding time
Your internal developer platform should shorten the time it takes to get a new developer’s first change into Production. New developers should find it easier to start as the platform simplifies workflows and removes the need to learn some underlying technologies.
You should also track the onboarding experience for teams adopting the platform. Opting in should be easy, and the benefits should be quickly apparent. Developers don’t have weeks to invest in platform adoption, so you need to make the onboarding process swift and easy. Building case studies with teams using the platform will help convince others to consider it.
Net Promoter Score
Net Promoter Score (NPS) is a popular market research metric used by two-thirds of the Fortune 1000. Your organization may already collect this from end customers, but you must also collect the platform NPS from the developers. You only need to ask one question to collect NPS, collecting a score from 0 to 10 as the answer:
How likely are you to recommend the internal developer platform to another developer?
You can group responses based on the answer:
- 0-6: Detractors
- 7-8: Passives
- 9-10: Promoters
To calculate the score, take the percentage of promoters, and subtract the detractors.
| Score | % of responses |
|---|---|
| 0-6 | 20 |
| 7-8 | 35 |
| 9-10 | 45 |
With the table above, you can ignore passives (35%) and calculate the NPS as promoters (45%) minus detractors (20%). So, a net promoter score of 25.
Positive scores are good and negative scores need improvement. The software-as-a-service industry has an NPS in the range of 30 to 40, according to Beamer and userpilot.
A downward trend in NPS can show the platform fails to address an essential developer pain. It may also suggest developers are considering a move away from the platform.
When you collect NPS, you should ask further questions, not least why the user chose their score. This provides valuable product feedback. Don’t pester the same customer for feedback too often and limit how many survey questions you ask as you want to show you respect their time.
Key customer metrics
Your customers, the developers, are also tracking their own success metrics. For example, they may use DORA metrics or the SPACE framework. When talking with your customers, ask what measurements they care about and find ways to track them.
Many platforms are introduced to improve developer experience, reduce cognitive overload, and prevent burnout. Whatever motivated your organization to invest in a platform will be something to track over time.
You can help developers achieve or exceed goals by adding needed features to the internal developer platform. If you do this, they’ll love the platform and encourage others to adopt it. The DevOps capability model can help find techniques or practices you can add to your golden pathways to improve software delivery and operational performance.
Summary
Don’t only collect numbers. Regular conversations with developers are crucial whether they use the platform or not. Your customers (and potential customers) know their pain points and can help you find areas to help.
Regular customer interaction shows you run a healthy Platform Engineering effort.
MONK metrics help you:
- Define the product roadmap for your internal developer platform
- Start essential conversations with customers
- Show the platform’s value to the people who pay to build it
MONK metrics should be part of your product management strategy. You also must speak to developers to find out more and keep track of the problems they care about.
More reading
- DevOps metrics
- DORA metrics
- DevEx metrics
- SPACE framework
- Measuring Continuous Delivery and DevOps (white paper)
Help us continuously improve
Please let us know if you have any feedback about this page.
