Saw a tweet about this the other day, pretty crazy this company does OKR meetings on weekends: <a href="https://twitter.com/PeregrineBadger/status/1585262424780730373?s=20&t=7bXni6RbpzXDJHZE9QpBFA" rel="nofollow">https://twitter.com/PeregrineBadger/status/15852624247807303...</a> not sure about the employees' perspective but it seems to be working well!
They're fine enough for aligning the work of few related teams, but OKRs suck when forced on individuals as the focus for regularly scheduled performance evaluations.
"They’re hard, but sold as something that everyone should do, so everyone does them poorly, and most people don’t see any value as a result."<p>OKRs are inane management fad. OKRs are "hard" because Objectives are vague and Key Results are vague leading to vague definitions of success and arbitrary flag planting.<p>Any management concept that is simultaneously so hard that no one does it right, but yet everyone is doing it is proof in point how valueless it truly is. Of course, when compensation, bonuses, and kudos are tied to OKR, people will keep doing them, as hard or as vague as they might be.<p>"Good OKRs tell a story about what is important, they help you inspire people to think about why they are working on what they’re working on, and I think they carry a bit of energy that comes from seeing how it all fits together in a succinct form."<p>That sounds more like a mission statement to me.
OKR's are great for one thing: They force writing, which in turn forces clarity of thought. It's the clarity and focus that's important.
In my dysfunctional organization we spend half of every quarter planning OKRs for the next.<p>First we have to collect all of the O's from top down and adjacent team blockers. Then we have to craft measurable KRs. Engineers are usually involved to size the effort of each. Then we need to make sure the total size maps to our bandwidth. We spend weeks prioritizing, and negotiating, pushing back up and to the side the work we can't take, and organizing cross-team dependencies to refine them to the final prioritized set.<p>At this point engineers have been dragged far into the planning process for sizing and have been thrashed by hearing glimmers of a chance to work on project X only to find out it's de-prioritized for project Y and now they have to size that effort instead.<p>The PMs will remind you if there isn't a number or a binary-sounding deliverable in every KR, and will hound you about getting a baseline and building the measurement tooling if there isn't one available. Sometimes making something measurable means instrumenting A/B tests, building dashboards, or instrumenting some metric capture. If it can't be measured, it can't be done in the OKR framework.<p>Once we begin the actual work In the glorious 4-week period where we aren't planning our next quarter OKRs, we're meeting daily and weekly to report progress at different levels. It's exhausting. This is where a lot of blatant funny business occurs with how folks measure and report progress that destroys the whole process.<p>I think on paper OKRs sound logical. Concrete goals and measurable deliverables are good. In practice it's a huge time suck and far less actual progress is made. It's a toilsome framework and a drain on morale. The only folks who seem to like OKRs are upper-management and PMs who are so detached from actual work that it's the only way they can feel like things are happening.
If someone is forcing you to implement OKRs, ask them to apply OKR to that process.<p>What is the objective that you're trying to achieve with OKRs?<p>How are you going to measure success (remember, you have to measure outcomes, not outputs)?<p>For a methodology that is all about metrics, it is almost impossible to measure.