3 ms·

The key results are not a problem just for you! You are hitting the nail on the head. Check out section 6 of this study ( https://arxiv.org/pdf/2311.00236.pdf h

The key results are not a problem just for you! You are hitting the nail on the head. Check out section 6 of this study ( https://arxiv.org/pdf/2311.00236.pdf https://arxiv.org/pdf/2311.00236.pdf ) - defining good OKRs is problem number 1, and data issues are the 2nd most cited concern! I wrote a piece about the common issues that people face creating OKRs. There are a few common mistakes that people make which makes key results unmeasurable: https://koliber.com/articles/top-okr-mistakes https://koliber.com/articles/top-okr-mistakes > the gradual accumulation of small fixes/hacks is not something you can put a metric on I've done it before. On one team, we had a goal to reduce the number of linting errors and warnings from 18,000+ by 50% (while not growing the number of INGORES). The team was reluctant at first, because "it's only linting and it does not matter." But they relented and eventually started fixing things here and there. And the number started going down, albeit slowly. And over time we got the number of linting errors down to 18 (or something close), because people found time here and there to improve things. And the team learned how to use OKRs. And they put in place a style guide and an auto-linter. And they started using it so that the errors did not come back. And there were plans in place to put in more sophisticated style analysis and run another OKR agains that. They literally matured in the code development practices way beyond just linting, just becuase of the relentless drive on one seemingly insignificant OKR. This is just one example. You can use OKRs with engineering metrics to improve lots of things: - fix the top 10 Jira tickets tagged with #techdebt - reduce linting errors by 20% - reduce number of functions with a cyclometric complexity of 10+ by 50% - research 5 static code analysis tools - increase unit test code coverage from 56% to 62% You can go many different ways. I've helped engineering teams do this well, starting with deciding what makes sense to improve and getting buy-in, through defining the OKRs, building the system of measuring it, and most importantly, driving the OKR every week. In the case you cited, with a bunch of hacks, I'd approach it like this: - Create a OKRs like "Reduce tech debt". - One of the key results would be "Identify 50 hacky places in code, and create Jira tickets for them" or something similar, by Jan 31st." - 2nd OKR would be "Refactor XX out of the 50 hacky places identified by Jira tickets, by March 31st" Pick numbers that work for you.

bootsmann 3y ago
Whats the benefit of OKRs as a system in your example? You're essentially just creating a list of to-dos to check, no?
- dalyons 3y ago
  Todos are binary, OKRs are (supposed to be) measurable continuously. Ie, we only did 5 of the top 10 tech debt tasks so the goal was 50% achieved
- koliber 3y ago
  Key results can be more granular and less granular. Think of it as a continuum. Some are continuous: - Improve the time to first byte for the homepage by 500ms. This one is continuous, because time is continuous. Realistically it will be quantized into milliseconds, but that's nitpicking. You can get less granular: - solve 500 linting errors This one is kind of continuous, but there are 500 distinct steps. Each week it is feasible that you can solve a handful, and can see movement and improvement. - add 5 unit tests to XYZ module Now we are getting much less granular. It is a checklist of 5 TODOs. But you can track the progress. Its unlikely each week you will make an improvement, but on some weeks you need to if you want to hit "5" by the end of the quarter. - hire a new DevOps engineer This is a binary, checkbox, or hit-or-miss key result. Sometimes they makes sense. It's not great if they make up the majority of the key results on an OKR. The good news is that you can make it more granular. Create a plan for hiring an engineer. Break out the steps, assign a percentage to each step, and track it as a 0-100% key result. This way, as you write a job description, post it, create a pipeline, review resumes, and hold interviews, you can track and share the progress.
ninkendo 3y ago
Your advice could be generalized into: - Take whatever it is you want to do and break it down into N jira tickets - Make an OKR saying “solve these N jira tickets by date X”, with the result indicator being “number of those particular jira tickets solved” - At the end, your OKR percentage is some fraction of N This works regardless of what the thing you’re trying to do is. It goes against the spirit of OKR’s which is to use metrics that matter to the business (number of users onboarded, page load time, conversion percentage, etc) to justify work. That’s what the “results” in OKR’s are supposed to mean.

bootsmann 3y ago

Whats the benefit of OKRs as a system in your example? You're essentially just creating a list of to-dos to check, no?

dalyons 3y ago
Todos are binary, OKRs are (supposed to be) measurable continuously. Ie, we only did 5 of the top 10 tech debt tasks so the goal was 50% achieved
koliber 3y ago
Key results can be more granular and less granular. Think of it as a continuum. Some are continuous: - Improve the time to first byte for the homepage by 500ms. This one is continuous, because time is continuous. Realistically it will be quantized into milliseconds, but that's nitpicking. You can get less granular: - solve 500 linting errors This one is kind of continuous, but there are 500 distinct steps. Each week it is feasible that you can solve a handful, and can see movement and improvement. - add 5 unit tests to XYZ module Now we are getting much less granular. It is a checklist of 5 TODOs. But you can track the progress. Its unlikely each week you will make an improvement, but on some weeks you need to if you want to hit "5" by the end of the quarter. - hire a new DevOps engineer This is a binary, checkbox, or hit-or-miss key result. Sometimes they makes sense. It's not great if they make up the majority of the key results on an OKR. The good news is that you can make it more granular. Create a plan for hiring an engineer. Break out the steps, assign a percentage to each step, and track it as a 0-100% key result. This way, as you write a job description, post it, create a pipeline, review resumes, and hold interviews, you can track and share the progress.

ninkendo 3y ago

Your advice could be generalized into: - Take whatever it is you want to do and break it down into N jira tickets - Make an OKR saying “solve these N jira tickets by date X”, with the result indicator being “number of those particular jira tickets solved” - At the end, your OKR percentage is some fraction of N This works regardless of what the thing you’re trying to do is. It goes against the spirit of OKR’s which is to use metrics that matter to the business (number of users onboarded, page load time, conversion percentage, etc) to justify work. That’s what the “results” in OKR’s are supposed to mean.