If there's one thing that can really derail a promising OKR implementation, it's training debt.
So what do we mean by training debt? There's an expression in the world of software development called technical debt which is defined as "the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer". Training debt is, unsurprisingly, the training equivalent that I have coined - when an organisation decides to cut corners on training and knowledge transfer in the pursuit of greater velocity, or reduced expense in the short term. But training shouldn't be viewed as a ‘nice to have’ and something which can be picked up or left out on a whim... it's critical to the success or failure of the implementation.
It's easy though to understand the motivation behind skipping the training elements. The first thing we do when a client engages us is to deliver an educational piece about the OKR framework in general, and how best it might be applied to the client's specific organisation. This rapid transfer of knowledge can be both a blessing and a curse however, as the senior leadership team are suddenly, in one fell swoop, entirely aligned in their understanding of how to implement OKRs, and buoyed by this new found understanding they are usually eager to harness the benefits as quickly as possible.
In many minds this often means getting the rest of the organisation ‘doing OKRs’ as quickly as possible, so the apparent logical next step is to start developing content - the top level OKRs. Once this has been done though there is a potential problem - no-one else in the organisation really understands OKRs. They weren't privy to the original knowledge transfer, so how could they? But we often see leadership wanting to maintain or even increase momentum, or worse still, save money, by skipping the obvious step of educating the rest of the organisation - the very people who'll be expected to live and breathe OKRs - and instead go straight into development of lower level Objectives and Key Results. Time and again leadership fails to recognise that having an understanding of the framework at the top of the organisation does not by itself mean that the organisation as a whole does.
We hear the words “learning by doing” and “learning by osmosis”, but in this context that is really saying "let's just crack on and see". But OKRs are not as simple to implement as they are to understand, and swerving this critical part of the process can fundamentally undermine the whole implementation. It's a bit like learning how to drive, employing a chauffeur with zero training, and assuring them they don't need a license as they can learn on the job through trial and error, and a little feedback from the back seat. That's literally a car crash waiting to happen!
So what we end up with from the outset might not really be what we'd call ‘quality’ or ‘best practice’ OKRs. That doesn't mean to say that the organisation won't learn over time, but this will be through mistakes, and mistakes are, more often than not, costly. Bad habits will have become baked into the process way before any good habits can develop. And that ultimately creates more work - reworking poorly developed OKRs, and spending time unlearning the bad habits while reinforcing the good.
But the answer is so simple - don't omit the training elements up front. See them as an integral part of a successful implementation. Omitting them might speed up the process and save money in the short term, but doing things properly pays dividends. As John Wooden, an American basketball player, once said: "If you don't have time to do it right, when will you have time to do it over?" Wise words indeed.