[q7xvh97o2pDhNrh]

OKRs are a good thing. They just get poorly implemented and turned into a political stew.

I know that sounds like the No True OKR paradox [1], but the truth is that it's not even that complicated. [2]

Write down the outcome you want, and then write down a few measurable milestones on the way. Make the whole thing ruthlessly concise. Make each key result objectively measurable. Go execute. Get together as a team occasionally to debate the whole thing and see if it needs to change.

That's the whole thing. No need to over-complicate it.

[1]: https://en.wikipedia.org/wiki/No_true_Scotsman

[2]: https://www.youtube.com/watch?v=1ht_1VAF6ik, the whole system explained in 2 minutes by the OG himself

[hotnfresh]

OKRs run into trouble as soon as they go from “this thing we’re already talking about looks like a good place to use OKRs—let’s come up with a couple to guide our effort” to “your business unit must produce and execute on X OKRs each quarter, and subordinate units must produce and execute on X OKRs supporting those parent OKRs, and you will all be judged based on the outcomes”.

The latter is what in-fact happens nearly everywhere, with predictable results that OKRs just end up as bureaucratic waste that distract from valuable work.

When tools become mandates, tools become obstacles. See also: agile.

[khazhoux]

> OKRs are a good thing

Our company ditched OKRs and we are running much faster. It turned out that people already knew, at any given point in time and to 95% accuracy, what's the most critical work to focus on. We didn't actually need to spend 3 weeks every quarter hammering out OKRs with dozens and dozens of goal-lists across teams (and then another 2 weeks at the end of the quarter doing OKR progress reviews), when the real thing to do was just to fix the Top N things that are broken, and then keep that short-list of top issues fresh every week.

"But, but... how can you make progress without quantitative quarterly goals?? That's outrageous!" Well, you know how those things that are always broken are now getting fixed? That's how.

[majormajor]

In a small company that's relatively straightforward. In a small company you often will even be doing "decide what you want and measure progress against it" without putting a fancy name on it, though.

In a larger company the problem is connecting "person over here's day to day work in a thousand-person org among other orgs" with "CEO's goals for the year." And now you've got people problems that are harder to solve than "just get together and debate them" because it's near-impossible at that size not to have politics, and some people working in bad-faith because they're prioritizing personal objectives over company ones, etc. No need to over-complicate except for human nature.

The usual problem a startup hits of bringing in a big-company guy is that some of these execs have never seen the tools they like (whether it's OKRs or Agile or "make documents for proposals") outside of the context of the big company bureaucracy and politics and then they don't know how to implement them lightly and they end up bringing all the bloat with them which creates more politics than before.