A recent study earlier this year surfaced that in many organizations, platform engineering teams currently struggle with measuring and providing baselines that could set up useful insights for their team, their current and prospective customers, in addition to executives. Similar to lacking telemetry around application health, it will be difficult to tell a compelling story about whether a Platform Engineering practice is moving in the right direction.
The goal of this short blog post is to provide a starting point for teams who currently simply don’t know how or where to start, or what “good” could look like. The example provided below isn’t perfect but it hopefully help some teams gain some perspective on how to implement this in practice.
For our example below, we’ve chosen to pick a very narrow “Unified Secrets Manager” platform product / service that allows developers or AI agents (or subagents), to interact with an API that allows CRUD operations for Kubernetes-based application secrets. The scorecard is split into 4 general sections:
- North Star - this section most closely mirrors the MONK metrics with a few topical additions chosen by the organization in question
- Adoption and engagement drivers - this section focuses on the more strategic functionality or areas that drive one, or all of, developer productivity, happiness, adoption, or areas where we may think if we invest more engineering time in, we’ll realize bigger gains on any of those facets
- Platform health - most teams are well versed in these - it’s a combination between The DORA “Golden 5” and some service specific SLOs that the hypothetical team in question has decided to emphasize and share more broadly.
- Financials - usually the topic that executive level audiences care the most about - “can we get unit economics so we can both benchmark or measure for effectiveness / efficiency?”
The example is fairly self-explanatory. A few callouts:
- RYG - Red, Yellow, Green. A, traffic-light style, color-coded, framework used in project management, business, and healthcare to quickly assess status or health.
- Note the ownership column in the relevant sections where appropriate. Yes, a sliver of a product manager, or a dedicated one, to the Platform Engineering team is a must. In some areas, the only owner is the Platform Product Manager (PPM)
- It’s perfectly acceptable to have some areas and metrics under active development as long as teams provide an ETA for when they expect to have those available.
- These types of scorecards are really useful during Platform Quarterly Business Review (QBR) meetings / forums. It’s OK to capture them, store them in a VCS, so you can create a “year in review” or Year-over-Year lookbacks or comparisons.
- Feel free to experiment with the approach, layout, and visualization. There isn’t a right or a wrong answer - you’d know what works best for your organization’s culture, audience, and preferences. Finally, this works for any platform capability: CI templates, env provisioning, service mesh onboarding, DB-as-a-service, etc
Good luck!
