I had aimed to get this series on OKR things finished inside of a quarter – I had progress graphs and everything. We got to 7 out of 10 by the very last day of that quarter (December 31st), then up to 9 out of 10 just days into the next quarter (January 4th), and then… nothing for months.
But finally, at the start of April, we’re here! After the introduction, the origin story, and lots of other posts, today we finish off this list with thing number 10 that nobody tells you…
Some common experiences, when people start using OKRs:
Going round in circles, as every few months you go back to questions about what each team’s purpose really is, what measures matter and how you could define and track them, what things you should focus on … and then revisiting them again as people or teams have changed, the things you agreed don’t seem quite right, or some shift in how you track or describe things seems like the new best answer.
Forgetting what we’re trying to get out of this, as getting the right numbers or submitting all the OKRs into some spreadsheet or tool becomes the only thing you seem to do with OKRs. Like having standups or putting work into columns, this can become “the way you have to do things”, an admin task, with no further reflection on why these got introduced.
Confusion about those stretch goals… the well-explained reasons on the kind of aspirational results to reach for can get forgotten too, or lost in translation as OKRs get spread to more people. I’ve actually heard a team wondering if they should have “implement 4 endpoints in this API” as a key result… they knew it needed 3 and that’s what they were going to build, so this’d mean they got 75% of the measure… is that what “they” want?
Some looming questions, as quarter after quarter ticks by: Shouldn’t we be good at this by now? And, Are we doing something wrong?
It’s not just you.
Adoption of citrus fruits
I once wrote a blog post about scurvy – bear with me, this is relevant! The pirate-themed game Return to Monkey Island has a subplot where you know limes prevent scurvy, but you can’t get anyone to listen to you. I found out later that this story has a real-life parallel.
At one time, scurvy was a huge problem – lots of deaths, and lots of urgency to find a way to prevent it. Despite this, the gap between Britain learning conclusively that lime juice was the answer to lime juice getting used in practice was nearly 200 years. If something actually life-saving is that hard to get adopted, what chance do we have with some maybe-helpful goal setting frameworks?
That post looked at other examples from medicine: in general, any useful new practice that needs people to change their behaviour is incredibly difficult to usefully implement. You can widely encourage or mandate practices that look like the behaviour that some initial group got lots of benefit of, but the issue of not getting the same value is a very common one. There’s lots of examples to read in the post – I found understanding what causes this challenge, and ideas to work round it, very helpful.
Putting in the time
One famously hard to replicate success is Toyota; they’ve consistently performed well and kept improving for decades. And despite massive interest from academics and industry, there’s very little evidence of anyone else getting anything like the same consistent benefit from implementing Toyota’s practices.
The book Toyota Kata by Mike Rother has some helpful insights. Toyota don’t use OKRs, but I can see a similarity in the “kata” he describes: describe the measurable “target condition” you want to get to and the date you’ll aim to reach it by, then experiment with different changes to work out how to move in the right direction. However, the way this and other improvements are carried out at Toyota sound very different than what I’ve seen elsewhere.
Everyone involved has a mentor, often their manager – and getting to be a mentor usually takes at least 10 years working at Toyota, to properly experience the work and the experience of being mentored so you can usefully put it into practice. Once you become a mentor, you’ll still have your own mentor – to help you reflect on the process of mentoring others, and help you get better at it.
In one real-life example, a work station was producing more parts with defects than the expected rate. While the operator was using it, their mentor came along to observe them – and the mentor’s mentor was there too. Can you imagine, in most workplaces, if you’d made a few mistakes recently and then your boss turned up to look over your shoulder? With their boss behind them? “I’m in massive trouble here” might be a common reaction.
At Toyota, as the book describes it, the reaction is different – there’s an understanding that the operator doing the work knows the job thoroughly and isn’t making any obvious errors, or they’d have spotted and corrected them sooner. The mentor is there because there must be some harder to spot issue, and an outside view might help. And that person’s mentor is giving advice and coaching on the mentoring process, to help them and the organisation improve.
This approach – looking for improvements and following concrete, well-defined steps to define, measure and implement them, with support and teaching from experts who’ve been using this process for decades – goes on every day, everywhere, all the time inside the factories the author visited. Picking something and having the same people stick with it so consistently seems worlds away from changes I’ve seen introduced in other orgs. I think things tend to be quickly explained, briefly explored, and expected to work – often with very limited space for expert instruction and reflection.
Like most of the other “things” we’ve discussed in this series: I believe understanding this wider context is important, and easily missed. Knowing that this much time and effort is needed if you want to get benefits from any kind of behaviour change is valuable.
And… we’re done!
And that’s the full set! We’ve covered:
- they’re so fast
- sole focus
- boring
- what else was going on
- you can’t stretch everything
- you can never pick the right measures
- you don’t need them at all
- dropping them might hurt
- complements
- how long change takes
I hope these have been useful, and that we’ve managed to turn “10 things nobody tells you about OKRs” into:
If you’ve finished this whole series might have read enough from me for a lifetime, but if you’re interested in another far-too-long series you could get started on my Minimum Viable Estimation posts. Or, if you’d like something much shorter, maybe try just avoiding the Boaty McBoatface problem?
Leave a Reply