Coming up with OKRs, in the beginning, is often hard. OKRs make a ton of sense when someone else tells you about them, but many will have a writer’s block when creating their own OKR for the first time.
One of the most common dilemmas is –
can Objectives and Key Results contain tasks
? The standard answer to this is – no. Most OKR experts will red flag this from the get-go.
I’d actually beg to differ, but let’s first examine why many times tasks should not be part of your OKRs.
The conventional logic
The basic idea of OKRs is that we define an aspirational objective, which informs everyone what is it that we try to achieve and attach to it three to five key results which define our measures of success.
So, for example, a classical example would be:
Provide amazing customer support
Key Result 1:
Reduce average response time to customer inquiry to 20 minutes
Key Result 2:
Increase customer satisfaction rate above 90%
Key Result 3:
Resolve customer issues in less than 5 emails
With this OKR, we can see our intention from the objective and we also have three key results which will allow us to measure how successful we are in achieving our objective. We also don’t have any tasks – neither in the objective nor in the key results. By completing various tasks – we will achieve this objective. So, best practices all the way.
The case for tasks as OKRs
I will argue that there is a time and place for a task to be either objective or key result. The key factor for deciding is:
how likely am I to accomplish this task?
A task as an objective
Let us consider following task:
Release next version of our software
. This is typically a normal task, that teams routinely do. However, about 10 years ago I was on a team where we couldn’t ship the next version for over 2 years. We were so overdue and so over budget, that at one moment we started to doubt we would ever finish it. Even once we’ve released it – for the next year, every incremental version was months late.
So, releasing the next version of our software – on time – was very much our objective and, boy, was it aspirational.
On the other hand, teams that routinely release software on time – should not have this objective. So, we see how important context is.
A task as a key result
Just last quarter, I had a personal key result of writing 60 blog posts. This key result could easily be considered as a really bad one. First, it’s a task and second, it measures output, not outcome.
However, my logic was following – I know what is the outcome of writing content and it is extremely hard to write 60 blog posts in a quarter (it comes to 1 post every working day). If my key result was to write a 5 blog posts, that would be a horrible key result. With this particular key result, my success was not to generate traffic (I already knew that content correlates to traffic), but rather my success was to be disciplined enough to write regular content.
So, here again, we can see how a task – depending on the context – can be a valid key result.
Another example, for tasks as key results, is our engineering team – which had a key result to close 300 issues in JIRA in a quarter. Without the context, this sounds as the most ridiculous key result one could come up with. However, what we tried to achieve was not to close more issues.
Our objective was to be more agile, and closing 300 issues was a great proxy metric for this. First, to close 300 issues – all of the issues had to be logged in JIRA and maintained properly – which helps agility and transparency. Secondly, the only way for the 4 people in our product team to close 300 issues in a quarter was to really break them down in small chunks – which is another paramount of agility.
Again, we see how context can make – on a surface absurd key result – a valid one.
The rule of thumb
The most important thing for having good OKRs is to understand clearly what do you want to achieve; rules can be broken – that’s fine – as long as there is logic behind your madness.
The basic rule of thumb I always follow is: how likely is this to happen? If I am sure it will, then it has nothing with OKRs; otherwise it’s fair game.
Subscribe to our blogGet the latest blog posts delivered straight to your inbox
First in our series of blog posts dealing with common pitfalls of implementing OKRs in an organization is the one of setting too many objectives. It is advised that no person or team has more than 3 objectives per OKR period (usually quarter). In practice, however – when just starting out – people tend to write
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