Platform engineering is becoming an increasingly popular approach to software delivery because it offers benefits such as improved time-to-market speed, increased developer happiness, and breaking down of team silos. We wrote extensively about platform engineering, specifically that it’s not, in fact, new and DevOps is not dead. However, given how many enterprises have struggled with delivering DevOps business value, they might view building internal digital platforms to aid software delivery as an actionable plan to achieve everything DevOps ever promised.
But how do you avoid falling into the same trap that held 80% of companies back from adopting DevOps?
Our advice: treat your platform like an internal product, and your wider teams as your customers. This means that your success metrics should be the same as you would use for your customers - with a platform engineering twist.
Key goals of Platform Engineering
When setting up your success metrics, it’s important to not lose sight of what your Platform Engineering strategy should aim for. According to the 2023 State of DevOps report, these were the top goals companies set for their platform teams.
Educating and empowering developer and product teams is a major priority for platform teams, followed by iteration speed and security processes. This people-centric approach is the same one you should adopt in your metrics. Reinventing tools is only half the job - you need to make sure your people are comfortable using the new frameworks. Streamlining and automating processes according to DevX best practices helps the entire organization move more quickly and drive a competitive edge.
Platform Engineering KPIs
According to the 2023 State of DevOps report, after adopting Platform Engineering, the majority of enterprises saw improvements in system reliability (60%), productivity and efficiency (59%), and workflow standards (57%), while 42% reported improved development time.
Productivity
Measuring lines of code produced by developers in X amount of time is an outdated metric used these days perhaps only by the likes of Elon Musk. Developer productivity is a sensitive subject, and while platform engineering promises to speed up software development, it doesn’t happen by making developers deliver more.
Instead, it’s about creating the best conditions for your devs to thrive in. Think about the bottlenecks and obstacles that your teams have to deal with daily and how much they have to rely on experts to get their work done. Complex infrastructure deployments, creating new environments, shipping features - all these require DevOps help, which inevitably clogs up processes. KPIs centered around streamlining and simplifying the software delivery process should be your focus.
This is a measurement that tracks the time from when a user story is initiated to when it’s ready for delivery. This time can also include discussions about the user story, how long it was waiting in the backlog, and how much time it took the story to move from pickup to release.
If your lead time for changes is too high, it’s a clear sign of a roadblock somewhere in your processes, causing items in the backlog not to move along. Automating whatever could be automated will help keep your lead time low, as it shows your teams are quick to adapt to feedback and deliver on their goals.
Deployment frequency tracks how often your end-users deploy code to production. It’s a good measure of the value your engineering teams can deliver to customers. However well-oiled your workflow may be, it can fail to deliver sufficient value if you’re not deploying frequently enough.
High deployment frequency shows that your team can make frequent changes to code and make it live — with little fuss and delays. The easier time your end-users have deploying new infra, the faster it's going to happen. Consequently, this lagging indicator shows that your development teams are efficiently adopting continuous integration and continuous delivery (CI/CD) practices, deploying small pieces of code frequently, and having a solid grasp of the infrastructure
While it might seem a bit unethical to group developer happiness with productivity, fortunately, it turns out that developer happiness and productivity are positively correlated. Platform engineering is specifically aimed at improving the developer experience, which is why measuring your DevX stats is important.
Stability
Stability measures your ability to enable product engineers to make changes confidently and without breaking the end customer experience.
- Change Failure Rate (CFR)
Change failure rate measures the percentage of failed deployments to production. This lagging indicator can give you a clear view of software quality and stability. Divide the number of deployments that caused failures by the total number of deployments to get this metric.
By monitoring this metric over time, you can get a good idea of how much effort goes into addressing problems and how much goes into releasing new code. When it’s above 15%, your teams are probably spending too much time fixing problems. This means they could be more productive elsewhere, or some processes need to be improved.
- Mean Time to Recover (MTTR)
Mean time to recover is another lagging indicator that shows you how quickly a service can resume normal operation after an interruption. To determine this KPI, calculate how long it takes to deploy a patch after an issue is reported.
Even the best DevOps teams experience unanticipated downtime and issues from time to time. You can’t stop failures from happening — but you need to know how long it takes to get things back up and running after they do.
Efficiency
Productivity and efficiency often get grouped in the same category, but we want to specifically look at cost-effective efficiency metrics, which include the cost of cloud resources, infrastructure, and licenses, as well as the cost of platform engineering teams. Platform engineering is all about the efficient use of resources, so FinOps and GreenOps modules would benefit your resource strategy.
Resource allocation offers the foundation for productive conversations about balancing several objectives with a fixed amount of resources. Platform engineering should help you distribute limited resources evenly and know exactly where they are spent. Executives will appreciate this metric since it demonstrates whether engineers are focusing on the company’s most crucial goals.
Knowing where you spend your money will help you catch overrunning cloud expenses and waste. As we’ve already mentioned, resource efficiency is one of the pillars of platform engineering, and that’s why we encourage companies to take a sober approach to their cloud consumption.
Transparent cost KPIs will help you achieve this goal. Giving end-users and platform teams alike the ability to see the cost impact of their architecture designs before deploying or a holistic overview of all cloud expenses will be the make-or-break element in your success.
Platform Engineering KPI dashboards
Many of these KPIs have a shared responsibility between teams - keep this in mind when visualizing your metrics. Transparency and observability are one of the things that contribute to breaking down team silos, so shared comprehensive KPI dashboards are something to consider. Consider, for example, what KPIs look like at Cycloid:
Bottom line
Given that a third of platform teams are still struggling with the wider team’s resistance to platform adoption, keeping an eye on your adoption progress should be among your wider KPIs. After all, a platform is meant to benefit the whole company and bring teams to work closer together, and that requires cooperation on all sides.
No matter which metrics you choose, it’s important to set realistic expectations within the company during the early years of platform team adoption. Your KPIs will evolve as you move through your Platform Engineering journey, but in the early stages, you should focus on making it much easier for platform and product teams to ingest their data and make it actionable.
Curious about Cycloid Platform Engineering? Get a personalized demo from our team: