When OKRs Attack: A Framework for Reviewing OKR Problems

You may have heard the reminder that the daily stand-up meeting in Scrum is not a status meeting, it’s a commitment meeting.  It’s a chance to pick a focus for the day, share it with your team, and push everything else to the side.  I like to think of it as giving yourself the gift of focus.

A few years ago, I was reflecting on failures with my own personal daily commitments.  Thought I wasn’t on a scrum team, I was setting out my tasks at the start of each day.  Rather than saying them out loud to my team, I wrote them down.  I found a few frequently recurring categories of problems.  Later, doing retrospectives on OKRs, I was reminded of these categories.  The timescale was different, but the problems were largely the same.

There are seven categories.  The first six are typical problems that trip us all up, especially in the first two to three quarters of OKR adoption.  Once we can routinely manage those six hurdles, we run into the seventh, which is a catch-all: execution.  It’s a good thing when your main failures (if any) come from execution.  It means you have made routine of evading those other pitfalls, and you can dive into fine-tuning your performance.

Sometimes you will fall short of a commitment for a combination of these reasons.  The value of this framework is not in perfectly assessing which category was to blame; it’s in helping you pick apart what could otherwise be a confusing jumble of conflated problems.  Do your best to pinpoint the biggest reason you failed to hit each Key Result, consider what you would have done differently if you could do it again, and keep this in mind as you head into your next set of OKRs

Underestimation
The work was bigger than you expected.

  • Examples:
    • A known step took longer than expected.
    • You discovered unknown steps along the way.
  • Remedies:
    • Roughly plan the sequence of events for quarter.  Backwards planning can be good here.  Careful not to overdo it.  If you do, it will be harder to respond to new information as it comes.  Even if you manage to throw away your plans when things change, you will have lost that planning time forever.  So keep the planning rough/high-level.
    • Do more up-front risk/dependency analysis.
    • Write outcome-based OKRs that give you more latitude to adjust.

Overcommitment
The work was about what you expected, you simply took on more than you could possibly achieve.  We all do this.  Remember: there is no virtue in taking on more than you can possibly accomplish.

  • Examples:
    • Too many OKRs.
    • OKRs too big/ambitious.
  • Remedies:
    • Don’t overcommit!  Easier said than done, of course.  But if you have 2-3 straight quarters of data telling you that you took on too much, it will be a little easier.

Blocks
You felt unable to proceed at some point.

  • Examples:
    • Had to wait 5 wks for department X to send material.
    • Development environment databases down for five days.
  • Remedies:
    • Is the block really, completely out of your control? We often take too passive a stance in response to blocks.  Don’t let them defeat you!  What have you tried? Could you have acted sooner or gone further?  Could you have escalated or sought other assistance to unblock yourself?
    • Before the quarter starts, take ownership of identifying all critical needs and gaining commitment from others on meeting them.
    • Write outcome-based OKRs that give you more latitude to adjust.

Distractions
You focused on something other than the OKRs you set.  Death from a thousand cuts of distraction is one of the most common problems, and one of the hardest to avoid.

  • Examples:
    • Prioritized other work over OKRs.  This often happens unconsciously: something else comes up, and you do it without considering the negative impact on your prior commitments.
    • Went an extra mile on a given OKR.  Going the extra mile is often seen as a good thing, but you have to consider the impact of that extra work on other priorities.  Remember that every choice to do something is also a choice not to do something else.
  • Remedies:
    • Strictly check impact on OKRs whenever other work shows up.  Will doing the work jeopardize your chance of success with OKRs?  If so, is it higher priority than the OKRs?  If so, what is the likely impact on your OKRs?  Share that that impact with all stakeholders before proceeding.
    • If you’re about to make give something an extra touch, ask yourself what impact it has on other OKRs. If you are taking extra time, it has to come from somewhere!

Poorly Written OKRs
OKRs were too task-oriented or too vague about what done would look like.

  • Examples:
    • I finished the task-oriented Key Results, but missed the spirit of the objective.
    • Partway through the quarter, I abandoned the Key Results because I realized it was the wrong approach.
    • I had Key Results like “Start initiative X” or “Make progress on project Z”.
  • Remedies
    • Remember: Key Results aren’t what you do (tasks/outputs); they are what happens as a result of what you do (outcomes).
    • Remember: Key Results show what you will finish, not what you will start.
    • When setting a Key Result, imagine yourself scoring it at the end of the period.  Will it be easy to tell whether or not the work is done?  If not, rewrite the Key Result with a more definitive finish line.

Mid-Quarter OKR Change
If at all possible, you should avoid doing this.  But sometimes you have no choice. Two examples:

  • A new demand appears out of the blue, taking priority over your OKR.  A big demand, not a dentist’s appointment.
  • After some progress, you learned that the entire OKR should be scrapped.  Could be due to a change in the business environment, a major technical miscalculation, etc.

If you must make such a change, clear it with all stakeholders first.  Then, at the end of the quarter, make sure you look back to figure out what happened and how to avoid such changes in the future. If this happens to you more than once or twice a year, you definitely need to re-examine what’s going on.

Execution
If the problem is not in one of the six categories above, congratulations! You’ve avoided the common pitfalls.  You are likely operating with a much higher degree of focus and alignment than you were before adopting OKRs.  But the work continues: without the confusion of those common pitfalls, you can now start fine-tuning your approach to maximize achievement of your outcomes.  Good luck!

Advertisements

2 thoughts on “When OKRs Attack: A Framework for Reviewing OKR Problems

  1. Hi there, you use the term OKR’s in an interesting way here. Have you written anything about how you’ve defined them? I tended, in my mind to swap that out for Sprint Goals to give myself context, but interested in your thoughts?

  2. Thanks for reading and for your comment. We use Objectives and Key Results (OKRs) in my company to set our medium-term (three-month/six-sprint) goals. But as noted in the post, the framework largely applies to any commitment, be it the one you personally make at daily scrum, the sprint goal you set as a team at sprint plannings, or longer-term goals like OKRs. I hope this answers your question. If not, please let me know.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s