DORA is good , but is it enough for platform engineering ? Let's talk 🙂

Would be surprised if you find someone saying Yes 😉

Let me think 😄 DORA is for a project, a team(also a group of projects) or a company,we can record the four key metrics to measure our project, team or the whole org. But to platform engineering, DORA meet application projects and platform projects on one level , actually they are not on same level, good platforms and good developer expericence will facilitate application developement , right ? So I think DORA is not enough for paltform engineering. We need to measure the value of platforms,especailly how important the platforms are .

Good resource I tend to go back to regularly is https://medium.com/wise-engineering/platform-engineering-kpis-6a3215f0ee14

Lead Time for Change measures overall efficiency. When broken down into the 4 phases of time - Coding (time to PR) > Pickup (time to first response) > Review (time to merge) > Deploy (time to prod) - this is what allows Platform Eng to know what to optimize for (@Ralf Huuck’s image - is it the PR time? build times? scanning? etc?). Tons and tons of research out there already specifically around PR Cycle Time. 1. Nudging

In a randomized trial on 147 repositories in use at Microsoft, Nudge was able to reduce pull request resolution time by 60% for 8,500 pull requests, when compared to overdue pull requests for which Nudge did not send a notification. Furthermore, developers receiving Nudge notifications resolved 73% of these notifications as positive. We observed similar results when scaling up the deployment of Nudge to 8,000 repositories at Microsoft, for which Nudge sent 210,000 notifications during a full year.

2. Meta

We’ve found a correlation between slow diff review times (P75) and engineer dissatisfaction. Our tools to surface diffs to the right reviewers at key moments in the code review lifecycle have significantly improved the diff review experience.

3. LinkedIn - Dev Prod Engineering - measures happiness and productivity @Olivier Kouame

Here are some of the metrics we decided to adopt:

• Developer Build Time (P50 and P90) - measures the time, in seconds, developers spend waiting for their builds to finish locally during development.

• Code Reviewer Response Time (P50 and P90) - measures how long it takes, in business hours, for code reviewers to respond to each update of the code review from the author.

• Post-Commit CI Speed (P50 and P90) - measures how long it takes, in minutes, for each commit to get through the continuous integration (CI) pipeline.

• CI Determinism - the opposite of test flakiness—the chance that a test suite’s result will be valid (not a flake)

• Deployment Success Rate - measures how often deployments succeed.

• Net User Satisfaction (NSAT) - measures, on a quarterly basis, how happy developers are overall with our development systems.

@Nočnica Mellifera FYI about DORA & PE 😄