Here's what's wrong with most OKRs software (and how we fixed it)

Every day there are 100+ mentions of OKRs on Twitter. What used to be an obscure Enterprise framework has gotten so popular that people are now making jokes about it (if you're new to OKRs, we have a guide for you).

A quick look at the search trends for "okrs" will confirm that sentiment. Interest in OKRs has almost doubled in the past 12 months as teams have started to prioritise outcomes over outputs. And it makes sense! OKRs are a great way to manage focus at scale, especially when you're remote.

This rise in popularity generally contrasts with the sentiment around OKRs tooling as most teams still prefer to use spreadsheets to track their goals. Now, I love spreadsheets (they're the ultimate MVP), but OKRs won't scale well with them. I'll go even further by saying that spreadsheets will get in the way of having effective OKRs.

But, there's some truth to the criticism. Many OKRs tools have been built as a reporting layer for a C-suite persona, forgetting that OKRs should be about helping teams collaborate around outcomes.

TL;DR: OKRs may benefit leadership the most, but the tooling that supports the framework should be team-first, leadership-second.

Let's see why.

Understanding what OKRs vendors got wrong

This discussion will be much more about Design principles than feature sets. That's because most of the issues with existing OKRs tools come from having one significant design flaw in them: they're built for execs rather than the team.

This single decision is responsible for 90% of the frustrations that teams have.

Problem #1: OKRs have asymmetric benefits

One key challenge of OKRs is that you can't pitch the same value arguments to leadership and individual contributors (ICs). OKRs tend to be extremely appealing from a leadership perspective:

1. Visibility on goals increases.
2. Teams are better aligned.
3. It's much simpler to set a North Star.
4. Accountability improves naturally.

But things don't always look so bright for the rest of the team. When OKRs are introduced, they often feel like an extra chore to those working with them. Worse, it can be interpreted as disguised micro-management if not careful (you're giving me extra goals + new reporting tasks).

So, the first challenge for organisations adopting OKRs is ensuring that the team also see benefits in the framework. For instance:

• They'll have clear traces of the impact they're making.
• They'll have more ownership of their goals.
• They'll be empowered to decide how to achieve said goals.

Now, what does this have to do with OKRs tools?

Well, the knee-jerk reaction for a vendor would be to create a product that prioritises the needs of the C-suite since they're the ones seeing the most benefits.

But this takes us to problem #2.

Problem #2: OKRs impact individual contributors and teams the most

Here's our puzzle: CXOs get the most value out of OKRs, but the framework impacts managers and ICs the most.

Once OKRs are set, they will heavily influence the work done during the quarter. Of course, you'll still have business-as-usual stuff, but a significant portion of the effort should go toward achieving the OKRs.

This means that OKRs should be readily accessible to the team as they'll need them to plan and execute their strategy.

But there's more. It's not enough to set goals at the beginning of the quarter. You also need to track them during the quarter, and weekly check-ins are crucial to maintaining focus.

• Peter Kappus writes that "check-ins are the most important part of OKRs".
• Felipe Castro cautions people not to let their OKRs turn into New Year's resolutions.
• Christina Wodtke tells us that "cadence is probably the single most important thing" for OKRs.

The easier it is for a team to have weekly discussions around the OKRs, the better they'll execute their strategy.

And this is where things tend to break with traditional OKRs software. Many tools have been built top-down, putting much effort into the reporting layer and treating check-ins as a second-class feature.

I'd argue that we should build OKRs platform the other way around. If we make it easy for teams to use OKRs, then leadership will see incredible results through a renewed focus and engagement (and the reports will still be there).

Problem #3: Strategic initiatives need to be close to their respective goals

It's one thing to know the progress status of a specific KR, it's another to understand what teams are doing to move the needle. Quite often, you end up in a situation where goals are in one place (spreadsheets, docs) and strategic projects in another (Jira, ClickUp, Asana...). This may seem ok in theory, but in practice it introduces a lot of friction if you truly want to be outcome-driven.

The best results-driven teams are able to quickly draw the relationships between the work in progress in the impact it has on their objectives. A good OKR solution should allow you to map outcomes to outputs seamlessly.

‍

How to build a team-first OKRs platform

Our team looked at the problems above, and here are the key principles that drove design decisions when we decided to build Tability:

• We adopted simplicity as a feature.
• We designed our platform to be about bottom-up collaboration.
• We decided to align rather than cascade goals.
• We prioritised continuous feedback and conversations.

Treat simplicity as a feature

The larger the team, the simpler the product should be. It may sound obvious, but it is particularly challenging to keep a product easy to use at scale.

However, this is especially relevant for an OKRs platform. Setting goals will be useless if no one can find them, or if keeping track of progress is a pain. It's difficult to quantify simplicity, but we treat it as a feature of our platform.

Modern teams need modern tools that don't get in the way of work.

Built for bottom-up feedback rather than top-down reporting

Most OKRs-tools are built by starting with the reporting layer. Why? Because it makes pitching CXOs easier. But it also means that the goal-tracking and goal-setting experiences get neglected.

In practice, it looks like a tool with great dashboards, but a lot of friction when it comes to sharing progress updates or finding your focus.

A team-first OKRs platform should be built the other way around. It's imperative to have a great goal-setting and goal-tracking UX to have effective OKRs. This is the base layer that will allow you to have continuous updates and accurate reports at the top.

OKRs-related software should feel like a collaboration platform instead of a reporting tool.

Stop promoting cascading models

We've written extensively about the dangers of cascading OKRs, and we're not the only ones.

But, many vendors took their cue from the book Measure What Matters that introduced a simplified cascading OKRs example. The result is an experience where teams are forced into rigid hierarchies that are costly to produce and maintain.

By contrast, we decided to use a flexible networking model where you can align goals after they've been created. You can create direct relationships between OKRs, but you will also have many occasions where a team will have a set of independent OKRs that only have a loose relationship with parent OKRs.

Tability will give you a high-level mapping of OKRs out-of-the box, but it doesn't force users to create deep connections between every item.

Once again, the goal is to prioritise flexibility and reduce friction. The easier it is to use and maintain your OKRs, the easier it will be to see transparent progress and adjust your strategy when necessary.

Prioritising continuous feedback

Distractions are part of work. Achieving a specific goal will involve many meetings, calls, specs, designs, demos, emails, etc. All this while also taking care of business-as-usual stuff.

It should be expected that teams lose track of their OKRs when they're busy doing work and putting out fires. It's just impossible to think about the bigger picture and sweat the details at the same time.

So the answer isn't to blame people when you see their attention drifting away from the OKRs. Instead, you should set up a system that takes care of bringing the OKRs to the top of the mind.

We knew this when we created Tability, and we separated the platform into 2 components:

• A platform to set and track goals.
• A bot that keeps you accountable.

Our bot acts as a gentle accountability buddy that helps you stay on top of your goals by sharing progress every week.

These updates will, in turn, help others understand how execution is going and generate weekly discussions around the key outcomes that matter.

Outcome-driven teams need outcome-focused tools

OKRs going mainstream is a natural consequence of organisations becoming more and more outcome-driven. Current OKRs/goal-tracking software feel inadequate because many of them were built with Enterprise customers in mind.

But by 2025, most teams will have a dedicated platform for goals and keeping things in spreadsheets will be unproductive. Remote teams using dedicated tools will have a significantly better operating cadence — not because OKRs are magic, but because they'll know where to focus their efforts, and what to adjust faster.

So, this is us.

We're building Tability as a team-first, community-driven platform for OKRs, and we're sure aiming to be your future platform of choice. Check our platform at https://tability.io, and send us your feedback!