A thread on OKRs.

I'm solidly in favour of a planning architecture of some kind for any team-size collection of people > about 5. OKRs have some advantages over other planning architectures IME, but also some disadvantages.

There are a couple of things I like about them:

1) The kind of gatekeeping behaviour that surrounds them is not as impenetrable as some other industry practices, IMHO. i.e. it's easy to sling some stuff together and get started. No necessity to get yourself consulted-up.

2) They are intended to be a high-level steering mechanism, and as such surface concerns about direction, mutual co-operation, etc etc, which generally don't happen in the context of an individual team. A useful spur to thinking like an owner.

3) The internal Google tooling around them made it trivially easy to look at other team's stuff and figure out if there was overlap/clash/areas of mutual support/etc. (Some of that might be gone now.)

4) It focuses effort on thinking about what goals should be and how they are phrased to make them SMART (measurable, etc etc) which helps to short-circuit insular team thinking.

[...pausing...]

5) Common practice at the time inside G (now different??) was that you should expect to score 0.7 out of 1.0 on your OKRs "on average".

Whether or not that ended up taking place, setting that expectation helped to do two valuable things:

5a) when I first joined Amazon, the message I got was "expect to fail, because if you're doing your job right, you're doing new/difficult things no-one else is doing, and you'll probably fail plenty times. that's ok." It's actually very hard to hear that message properly.

5b) I felt that hearing the company expects 70% was a pretty good analogue. In other words, a useful exhortation to success.

5c) The converse culture, where everything must be a total success all the time, is cultural death. The incentives switch to hiding things and lying.

In corporate culture, if everything must be a success, nothing can be. Instead, planning and presentations turn into a game of picking off the outliers; those who distinguished themselves by trying hard and failing. Hard to construct a genuine set of ambitions in that environment

There are a couple of things I didn't like about OKRs:

1) As with every serious planning architecture, there's a lot of ritual around them. Ritual can drain meaning. Engineers in general preferred to opt out of ritual and therefore most of the serious discussion about prios etc.

2) OKRs were an okayish fit for SRE project work, which in general suffered from the interrupt-driven/production fire problems.

SRE project work was kinda like batch scheduling; it'd get done, eventually. Your big hope was that it would still be relevant by the time it was done

3) There were arguments that never converged about what level of goal was most appropriate for a team, and the interplay between the usefulness of a high-level goal and specifying its implementation as concretely as possible.

For example, "Keep the site up", "Make X more reliable" versus "Enumerate top 5 source of known outages in the trailing quarter and eliminate their root cause(s)/contributing factors".

In theory the O is "keep the site up" and the KR is "enumerate the outages". However, lots of things could fit under such an O and there were continual questions about O-grouping and what could fit elsewhere.

Overall, I thought OKRs, though responsible for, as I say, a certain amount of ritual and non-productive argument, were a pretty decent way of actually steering a pretty complicated ship. They scaled well, set good expectations, and helped remind you what was important.

But that partially relied on a set of cultural behaviours which were not 100% to do with OKRs -- ambition, forgiveness, and accommodation for sure -- and if those behaviours change or are absent, the usefulness of OKRs could well decrease.

For example, if in fact as https://twitter.com/flameeyes/status/1355990084668059650 suggests, OKR completion rates are now part of performance ratings, well, that is a very different framing.

It comes across like attempting to increase "legibility" (cf @lhochstein) at the expense of effectiveness.

In another galaxy: 'the more you tighten your grip, the more [the objectives] will slip through your fingers'.

Ultimately, great things are done by:
1) giving people freedom/autonomy
2) encouraging them to reflect, and take feedback
3) in a safe environment

Steer, not control.