Despite the name and intention, in my experience, OKRs is a prime candidate for cargo culting culture into an org and using process as a proxy for actual focus on outcomes.
We didn't communicate top-down, or cross-functionally very well. The executive team, with lots of support from HR, rolled out a really heavy, very process-centric OKR system and assumed that by announcing that Google uses OKRs and providing a portal that we'd start aligning.
It was an abject failure - not because (IMO) OKRs are a bad idea, but because the leadership teams made the mistake of confusing process for communication.
After the big announcement, it was mentioned only ONCE ever again. Seriously.
My team (of six) and I made use of it, but it was very difficult to align it with the goals of, say, our chief revenue officer; someone we met about three times in four years. We went back to using team & personal goals, creatively using our backlog and one-on-ones because there was no input, no updates and no communication about the OKRs.
The start-up failed because it wasted time chasing tactical low-value (tangential) deals instead of delivering against a viable, sustainable strategy. Great place to learn some hard lessons!
I'd use OKRs again for sure - both for their intended purpose, to help avoid the process-as-communication-proxy trap, and to gauge the nature of the organisation implementing them.
People who get shit done do so in spite of OKRs or other formalisms like Agile. OKRs do not help orient work towards what matters, maintain accountability, alert management to schedule slippage, or unify team efforts. OKRs are cargo cult metrics for middle management to bend the ear of higher management to argue and gladhand for bonuses & promotions.
Because outside of those, agile is actually the anti-formalism. It's a whole slew of tools, techniques, methods, and philosophies to choose from for your team and organization. Offices that formalize it are the same ones that'd formalize Waterfall or Vee model or Rational Unified Process or any other approach. And they'll suffer the same consequences regardless of which one they use.
Offices that understand it as a toolkit can actually get value from it (AKA, those who read and internalized the initial manifesto and mostly avoided the consultancies that came out after).
I read a good way of putting it once, “when everyone misuses a tool, beyond a certain point, it’s the tool’s fault.” I think this fits the realities of agile well.
Separately a lot of people will look at this or that pathological issue in agile and say that’s not “real” agile, ignoring that this is just a No True Scotsman fallacy by which you’d vacuously define agile as “all good things” or something.
The main pathology I’ve seen in agile (across half a dozen companies, large & small, with or without formal agile training, etc.) is that it is paradoxically highly inflexible. If certain research tasks need to be a 4-week deep dive that cannot be chopped up into separate tickets on a sprint cadence and cannot be time-boxed, there’s no way to handle it (this happens all the time on research teams).
If one team needs to work on a 3-week cycle all summer instead of the company-wide 2-week cycle, it can’t be done. If there is no way to estimate some points for a certain task, you still are forced to go through the motions and fabricate misleading numbers anyway.
Even the core agile manifesto has to be ignored sometimes. Sometimes sticking to the plan actually is more important than responding to change, and you have to turn down business or tell customers no even if it costs you.
Agile can be used well. It’s just exceedingly rare that it is, to such a degree that we need to admit something’s wrong with agile itself given how easy it is to subvert agile into a bad system.
At this point a lot of people reply by saying, well what alternative is there? I don’t like this because it presumes there has to exist some named alternative that doesn’t suffer agile’s limitations, but no such official method has to exist and that doesn’t mean agile should be used.
Instead, just use some mixture of common sense and planning based on the specific personnel working on the project, their preferences and styles, and randomly stealing things from agile or waterfall or whatever else on an as-needed bases. Don’t give it a name.
That way it is a subjective matter as to whether the outcome was satisfied or not (so that success in an OKR system can remain political and not meritocratic).
This follows from upper levels of the hierarchy to lower levels, so that in the leaf nodes where KRs hit specific projects, it becomes an incredibly stressful negotiation between the pragmatic reality of what needs to get done and how much bandwidth there is vs a stack of forking paths of ambiguous outcomes so that managers want to hedge their bets on all possible outcomes.
If OKRs were treated more like prediction markets, and bonuses or rewards were tied directly to quantified outcomes, then it would be like what you say (and also like what OKRs are supposed to be, rather than what they pay lip service to).
And obviously if the organization is too dysfunctional, the OKR setting process cannot be honestly conducted and will never work. I don’t think the average organization is this bad.