We began using OKRs at my job a few quarters ago and it's been amazing. Though there are two very important points to make here, that I don't think the OP inclu

We began using OKRs at my job a few quarters ago and it's been amazing. Though there are two very important points to make here, that I don't think the OP included: 1. Contrary to the article, I would say that OKR's need not be binary (complete or incomplete). We use a 0-1 scale but we consider >=0.7 to be considered "done enough". The reason we do this is to encourage our teams to strive for ambitious yet realistic goals. 2. Essential to the idea of OKRs is the distinction between outcomes and outputs. An output is the actual work you're going to do, whereas the outcome is the resulting change/effect you want to have. A KR should track the outcome, not the output. When devs first start out using OKRs, they write in KRs like "decrease lines of code by 25%". This is actually an output. An outcome would be "customer spends 50% less time waiting for page load". Reducing the lines of code would contribute to that outcome, but so would many other things. Those are outputs. Here's a great book on the subject: https://www.amazon.com/Outcomes-Over-Output-customer-behavior-ebook/dp/B07QJ1Y8Y5 https://www.amazon.com/Outcomes-Over-Output-customer-behavio...