Outcomes vs Outputs
This is the typical challenge, and pretty much everyone finds writing outcome oriented statements difficult. In my experience, it’s not because people don’t know what outcomes are.
I think the biggest challenge is because people spend the vast amount of their thinking time thinking about outputs – what their tasks are, what they need to produce, are they late, is the quality OK, do they need help, are there any risks etc. They spend comparatively little time thinking about the bigger picture of why they’re doing all that work. I think output thinking is so prevalent in society, that if by chance, you met someone who spends most of their time thinking about why they do things, you might casually wonder if that person is going through some form of existential crisis.
Given the relative familiarity of output thinking and the relative novelty of outcome thinking, it’s little wonder that early attempts at defining outcome oriented Key Results are generally poor. Here’s an example of a collection of collaborating teams who collectively own API Management within my client’s IT Organisation had as a “relatively mature OKR”.
Make services easier to use
- Increase the number of APIs available to the customer from X to Y
- Increase the number of automated releases per week from X to Y
- Document the CI/CD pipeline by EOYWhile the Objective (“make services easier to use”) is great, even a cursory examination of the Key Results confirm that they’re all in direct control of the teams, and are therefore outputs. After some coaching, they were able to rewrite it like this:
Make services easier to use
- Increase the number of API calls per day from X to Y
- Decrease the lead time to develop an API from X to Y days
Amateur Coach 