One thing we notice with a lot of organizations that just start out with OKRs is that many people just enter their everyday work as Objectives.
For example, a digital marketer may state an objective “Release January Newsletter“, a software developer may put “Fix bugs” or HR manager may state “Hire a sales director“.
While one could argue that these objectives are technically valid, the problem with them is that they are missing the point of OKRs. As a result, organization will not reap the benefit of OKRs and will probably abandon the methodology in few months as useless.
Why is it a problem?
OKRs are about changing status quo, about excellence. Stating your everyday work as an objective is like making a New Year’s Resolution to breath.
OKRs are not a job description. Oxford dictionary defines Objective as a A thing aimed at or sought; a goal – and aiming at doing what you are supposed to do is not exactly ambitious.
In our experience, this problem occurs mostly due to lack of training. Sometimes people in the organization are just told “we are doing OKRs, enter yours by Friday” without being provided with underlying context.
How to fix it?
Whenever we talk about this issue, a common counter argument is that not everyone can work on mission critical, destiny altering endeavours. We’ve heard that it’s easy to define objectives for VPs, but much harder – if not impossible – for rank and file employees. This, however, is not true.
Perhaps it seems like that, as senior leadership is used to being given objectives so it comes more natural, but that is exactly the point of OKRs – make it natural for everyone to work towards objectives.
The simples way to fix this problem is to think of different dimensions of a given task and decide on which one we want to focus. Let us examine the “Fix bugs” example.
There are many dimensions in which we can describe bug fixing effort, but for this example let’s take only two dimensions:
- Complexity of a bug
- Number of bugs we can fix in a given time
So, the curve shows us that we can either fix few complex bugs or many simple ones – which stands to reason. If we pick those two dimensions, then we are in a place to make a conscious decision about what is it that we aim to do – our objective.
One way is to say that we want to reduce a bug inventory, so our objective is to fix as many bugs as possible, in order to make it more manageable.
On the other hand, we may decide to pay off some of the technical debt we’ve accumulated. The assumption is that a spelling mistake in our UI is a bug, but does not represent a technical debt. So, if our objective is to fix some of those complex, lingering, historical mistakes we could focus on those and not the sheer volume.
So, with this simple tweak we have done following:
- Communicate our intensions to the rest of organization (transparency)
- Made a conscious decision about why are we fixing bugs (focus)
This same exercise can be applied to any kind of “everyday work” objective and it is not necessary that there are multiple dimensions or that they are at odds.
When writing an objective, ideally objective will answer both – “what?” and “why?” questions – not only “what?”.