How I think about OKRs

OKRs* are so misunderstood that most companies that try to adopt them badly would be better off without them.

Here’s a story I’ve seen way too often.

Things go poorly. Top brass decides to roll out OKRs. They create way too many top-level OKRs. Everyone scrambles to create their own which feeds into that. Suddenly you’ve got a million initiatives that dilute what little focus you had.

Why?

Because they are treated as a band-aid solution to a problem, not a tool to be deployed strategically.

If I’m asked to implement them in a tech team, here’s my thought process.

OKRs are about outcomes.

They need to be relevant to the business, ambitious, and impactful.

Carefully selected.

Only a few.

Each one will open a new front. I don’t want to dilute focus so that “we have OKRs”.

They are a tool.

They help us focus, align the team, and measure progress against a goal.

Let’s say I have an objective to grow the revenue by 30% in Q1. I identify the bottlenecks and I might define a key result to be:

Boost the percentage of new users who complete the onboarding process from 55% to 80% by the end of Q1.

Do you know what you might attempt to get that number up?

I bet you do.

What if I define it like this:

Redesign the onboarding process by the end of Q1.

You have no idea what to do.

What makes it bad?

No outcome. It’s just a task.

No metrics. What will we know how much better it is?

No impact. What does this redesign hope to achieve?

No scope. Redesign can be a paint job a complete rebuild.

No results. It’s going to be launched in Q1, then what?

So, what’s the solution?

Look at everything that makes it bad and do the opposite.

Best regards,

Taj

*OKR = Objective and Key Results