Bring the OKR pain forward

A recent survey by OKR International showed that 78% of teams couldn’t get OKRs right when they introduced it. That’s a big number. And what’s more surprising is that the OKR framework itself is fairly minimalistic compared to something like EoS or Scaling Up. So how come there is such little initial success with the adoption of a goal-setting methodology that has only 2 components (the objectives and the key results).

At Tability we have a bit of a unique understanding of this issue because 95% of our customers are using our platform to track their OKRs. Over the years we’ve spoken to more than 500 teams about their goals and there are a few good reasons why it is so challenging to get OKRs right on your first try.

Why OKRs fail the first time

While businesses can be vastly different, it’s often the same patterns that will determine successes and failures. You could be having hundreds of different conversations, and you’ll see the same 3 themes emerging when asking about OKR failures;

• It’s hard to flip an output-centric culture
• Buy-in takes time
• Too much reporting, not enough conversations

Problem 1: It’s hard to flip an output-centric culture 

If you ask “what are your key results?” to someone that doesn’t know the OKR framework, they’ll likely respond with a list of projects that they need to deliver.

They interpreted the question literally and gave you the list of things that they must build/ship/complete.

But in the world of OKR, a key result should capture the expected impact of your work, instead of the work itself. For instance, instead of having “Launching a LinkedIn ad campaign” as a key result, you should instead track “Get XX customers using LinkedIn as a channel”.

Problem 2: Buy-in takes time

The first time I got introduced to OKRs, it felt like yet another spreadsheet to fill for management (I was a Product Manager at the time). Fast forward to today, and I truly think that OKRs is one of the best tools available to companies that want to scale alignment without adding many layers of middle management.

The reason why it took me roughly 3 cycles to “get” the value of OKRs is that many of the benefits are experienced as a collective rather than an individual. Let me explain by taking a look at how Design Systems get adopted.

A Design System is a collection of standards and reusable components that can be used to create applications. It’s especially helpful for orgs that have multiple products built by different teams. But, just like with OKRs, you can face some initial pushback when you’re rolling it out. Why? Because you’re forcing teams to adopt a standard that you know will pay off globally, but feels like a downgrade to them locally.

This is exactly what I experienced when Atlassian rolled out its design system. From a team perspective, it felt like you had to give up on some awesome custom components that worked beautifully in your specific product. But, if you zoomed out to consider the experience of a user having multiple Atlassian products, it meant that they had a much better experience as everything always felt familiar and consistent. We got there in the end, but it took some time and effort to get complete buy-in.

Let’s get back to OKRs. You could let each team design their own goal-setting methodologies with their own terms and rules. But this would quickly lead to chaos at scale. The OKR framework is effectively a Design System for goal-setting, and it brings a consistent and familiar experience throughout an org.

But, it’ll take time for people to see that.

Problem 3: Too much reporting, not enough conversations

The overwhelming majority of people we spoke to started by “tracking” their OKRs in spreadsheets. I put tracking in quotes here, because a lot of the time things look like that:

• Day 1: add your OKRs to the spreadsheet.
• Day 1…30: *chirp chirp*
• Day 30: quick quick, let’s update that spreadsheet before the review meeting
• Day 30-60: *chirp chirp*
• Day 60: quick quick, let’s update that spreadsheet before the review meeting
• Etc…

There's not much tracking that goes one during the month, and weeks go by before people take another glance at their objectives.

OKRs won’t be helpful if they’re reduced to being a reporting exercise at the end of each month. First, it will be super hard for your team to stay focused on the right things. Not because they won’t care, but because solving hard problems requires 100% of your attention. You’re either thinking about the problem, or thinking about why you’re working on that problem. It’s hard to do both at the same time.

So, if a team starts to work on a lead gen problem, they might run into some other issues around website optimization, or work on improving the drip feed – but is it what matters now?

Your OKRs should be a constant beacon that helps teams notice quickly when they’re drifting away from their goals. And this can only happen if progress on goals becomes a continuous conversation rather than a slide deck that is sent for consideration.

Low hanging fruits to solve common OKR issues

Ok, so I just wrote 650 words talking about problems. It might be time to offer some solutions.

Before we dive in, I need to state that there are no shortcuts for cultural changes. Atlassian solved the Design System buy-in by having repeated conversations and presentations about the decision to have standard components. You’ll most likely need to do the same to get OKR buy-in. The benefits might be obvious to you, but there’s a high chance that others don’t see it that way.

Hold on.

I might have one small tip here.

One thing that helped get everyone on board with the Design System was to show how jarring the experience was when going from one product to another (or even from one screen to another!). Tabs would differ, buttons would have different patterns, users would struggle to complete simple cross-product workflows. Perhaps you could do the same by asking every team to send their strategy doc as is (don’t cheat by crafting a new page), and see how easy it is for team A to understand what team B is focused on.

Ok, now let’s take a look at some low hanging fruits.

Enforce limits

The first thing you should do is limit the number of OKRs. It’s tempting to get everyone to have goals, but it’s best to start small while you’re making the transition from being project-centric to being outcome-driven.

Here’s a simple set of rules:

• Only top-level and team-level OKRs (no individual OKRs)
• No more than 3 objectives per plan
• No more than 4 key results per objective

Setting limits will reduce the risk of reproducing your roadmap in your OKRs. Scarcity will create focus and clarity. If you only have 8 to 12 key results to capture your intent, then you’ll have to really pick things that best represent success at the end of the quarter.

Another limit: no one should be owning more than 5 key results for the quarter. Why? The owner’s job is to share progress updates with the rest of the org by doing regular check-ins. It’s an important task that can only be done well if you have enough time to reflect. 5mins per KR x 5 KRs = 25 mins. That sounds fun and doable. But the quality of the check-ins will rapidly plummet if you start giving more key results to people.

A quick way to find plans and user with too many OKRs

You can use Tability’s Audit feature to quickly surface plans and users that have too many key results attached to them. Once your team add their OKRs to Tability, the platform will scan all the goals to identify common issues that should be fixed. This could be:

• A user with too many goals
• KRs without owners or not measurable
• Plans without check-ins
• Etc

This will help OKR champions that want to quickly provide assistance to their teams.

Make OKRs part of your weekly routine

There’s a great quote from the book “Continuous Delivery”.

If it hurts, do it more often, and bring the pain forward” - Jez Humble

This phrase was given in the context of software deployments that are hard to automate. You could stick to gathering your team once a month to go through a tedious release process. Or you can bring the pain forward and do what is necessary to deploy your code every week. This will force you to look at your problem and figure out how you can remove friction and make things as painless as possible.

The same can be said for OKRs.

First of all, your team should be reviewing progress on goals at the beginning of each week.

This is the best way to keep everyone aligned and put the goals back at the center (remember, 95% of the week is about outputs).

Second of all, if weekly OKR tracking is painful, the answer shouldn’t be to look at the OKRs less often. It should be to figure out where the friction points are and to do what it takes to achieve a weekly cadence without stress.

A simple way to reduce OKR pain

Just like software teams use CI/CD tools to automate deployments, you can use Tability to automate the boring parts of OKRs:

• Get live dashboard for every plans
• Automated check-ins reminders via email/Slack/push notifications
• Alert notifications, progress charts, insights and metrics
• Email digest, presentation mode, etc… All the dashboards you need for stakeholders are 1-click away
• You can connect Tability to your tools to automatically pull data

Check out the demo below from Wyl if you want to see it in action 👇

Connect OKRs to strategic projects

Outcome-driven doesn’t mean that projects are no longer in the picture. Your projects still matter, but they’re now treated like bets that can help you achieve your key OKRs instead of critical commitments that should be delivered no matter what.

This is also why you should have a healthy feedback loop between your outcomes (OKRs) and your outputs (strategic projects/initiatives). Every week, your team will be delivering specific outputs. And every week, you should be able to measure their impact. If some works well, double down on it. But it should also be ok to drop bets that aren’t paying off.

In practice this means that you need to find a way to connect your high-level initiatives to existing OKRs (don’t do that for low-level tasks). Of course, you’ll have business-as-usual projects that won’t be tied to specific key results or objectives. But it should be super easy to go the other way around to answer the question “what are we currently doing to achieve this OKR?”.

A quick way to connect outcomes to outputs

In Tability, you can simply list initiatives under each key result, including linking items from your project management tool. Once linked, Tability will offer many different ways to map strategic projects to the goals in progress.

What’s next

I struggled a bit to find the right title for this post. I thought it’d be about Design or Software analogies, but it’s Jez Humble’s quote that brought it back home.

Getting dozens of people across dozens of teams to be in sync is painful. But the counterintuitive thing is that we should confront the pain and invest in syncing more often. The alternative is unlikely to help us. Worse, it could harm our culture in the long run.

If you’re looking for more tips, we have a list of 15 rules designed to simplify OKRs. We call that model Flowing OKRs, and it should at least create some useful debates.