OKR Fundamentals · 8 min read

What Are OKRs? 10 Years of Running Them, Distilled

I've been running OKRs across teams for about a decade. Long enough to have set good ones, terrible ones, and a few that quietly went off the rails in week 6 and nobody noticed until quarter-end. Most "what are OKRs" guides skip the part I actually care about, which is what they feel like to run. So that's what I'll write about. The definition is in here too, but the definition is the easy part.

By Max Bondarenko · Last updated May 2026

The one thing OKRs are for

The cleanest way I've heard the problem described: before OKRs, everyone was running, but nobody knew where they were going or why. That was the issue. Not the "where." The "why." OKRs exist to put a sentence on top of the dashboard so the team understands what they're chasing and why this number, this quarter.

That's it. That's the whole point. Most things people get wrong about OKRs come from forgetting this and treating them as a reporting system instead.

The one-sentence definition

An OKR is one qualitative goal (the Objective) plus a few numbers that prove you hit it (the Key Results). That's the whole framework. Everything else is implementation.

The Objective is something you'd say out loud to a friend at the bar and not feel weird about. The KRs take that warm fuzzy ambition and force a number on it. Without the Objective, KRs are just a Notion page of metrics nobody cares about. Without the KRs, the Objective is just optimism with extra steps.

Compass, not whip

The biggest mental model shift, the one I wish somebody had told me earlier: OKRs are a compass, not a whip. Some companies use them as a tool of control. Set the numbers, hold people to them, name and shame at quarter-end. Those companies usually have a sandbagging problem six months later, because nobody sets ambitious targets when missing means punishment.

The teams that get the most out of OKRs treat them as orientation. "Which way are we going? What does winning look like? How will we know?" When that's the frame, ambitious targets are safe to set. People will reach for them.

The calibration trick: pride meets realism

The hardest part of writing an OKR is the number. Too low and it's a foregone conclusion; you've just declared what you were going to do anyway. Too high and the team checks out in week three because it's obviously impossible.

The question I ask when I'm setting a target: "What's the number that, if we hit it, I'd actually be proud to share?" Not satisfied. Proud. There's a difference. And then the second question: "Is that number achievable through gritted teeth?" If yes, that's the OKR. The intersection of realism and pride. When those two cross, you've probably found the right zone.

You'll know you set it correctly if, somewhere around week 5, somebody on the team says "yeah, this is going to be tight." That's the right amount of tight.

Where they came from

Andy Grove invented this at Intel in the 70s. He called it iMBO (Intel Management by Objectives), which was basically Peter Drucker's MBO concept with a faster clock and tighter feedback. John Doerr worked under Grove, watched it work, and in 1999 walked into a startup called Google to show it to Larry and Sergey. They ran the company on OKRs from that point. Larry has said since that he doesn't think Google would have scaled past a few hundred people without something like this.

Most companies you'd recognize use some form of OKRs today. The framework has gotten watered down in plenty of places (mostly because someone read the book and decided the ritual was the point), but the original idea holds up.

How they actually work

The Objective

Should be a sentence you can say out loud without rolling your eyes. Time-bound. Ambitious enough that hitting it would meaningfully change something. If your Objective could be accomplished by the team doing their normal work for 90 days, it's not an Objective. It's a job description.

Good: "Make onboarding so good that new users hit value in their first session."

Bad: "Improve onboarding." (When are you done? Nobody knows. The team finishes some work and you all squint at it and call it victory.)

The Key Results

Numbers. Three parts: starting number, target number, unit. If you can't say "we were at X, now we're at Y, we needed to get to Z," it's not a KR. It's a feeling.

Good: "Day-7 retention from 31% to 55%."

Bad: "Improve user experience." That's a vibe. Vibes don't show up in a weekly check-in.

2 to 4 KRs per Objective is the sweet spot. I've seen teams write 7 because they were afraid to leave something out, and the whole quarter turned into a checklist. If you have more than 5, ask yourself which two you'd cut if your CEO walked in and said pick.

The cadence

Set quarterly. Check in weekly. End of quarter, score honestly, run a real retrospective, write next quarter's OKRs informed by what you learned.

The weekly check-in is the whole game. Teams that set OKRs in January and look at them again in March are running annual reports, not OKRs. The check-in is where you find out a KR is off track in week 4 instead of week 12, when you still have time to do something about it.

Keep it as simple as a door

One of my own rules: if a goal-setting tool requires a manual or an expensive consultant to understand, it's already failed. Same goes for the OKRs themselves. If the team can't recite the company OKRs at a high level by week 3, you wrote too many or you wrote them too complicated.

The Objective should be one sentence. The KRs should be one line each. The whole company OKR set should fit on a single page you could pin in Slack. When it's simple, it actually works. The moment you need a deck to explain your own OKRs, something is off.

Real examples by function

Marketing

KR3 is the one that actually matters. KR1 you can hit with bad work. KR2 you can hit with one viral post nobody buys from. KR3 forces the content to actually be good.

Engineering

Sales

Where this stuff goes wrong (ten years of watching it)

1. Writing tasks as KRs

"Launch new onboarding flow" is not a KR. It's a task. The launch is the thing you're doing. The KR is what the launch is supposed to cause. If your KRs could live in a Linear project as tickets, you've confused activity with outcome.

The test I use: read the KR out loud and ask "could we do this and have it not matter?" If yes, that's a task. Real KRs make the team uncomfortable because they measure whether the work actually worked.

2. Too many of them

3 to 5 company OKRs per quarter. Maybe. We tried six one quarter and ended up doing about 60% of each because there was no forcing function to drop anything. Constraint is the whole point of the framework.

3. No check-ins

The cardinal sin. If you set OKRs and don't look at them for 12 weeks, you don't have OKRs. You have ambitious wishes. Weekly check-ins, mid-quarter review, end-of-quarter retrospective. The check-in is what turns a goal into a system.

4. Tying them to comp

Worst possible move. Second OKR scores affect somebody's bonus, every team writes easier OKRs. You'd do the same thing in their position. OKRs work because they're a place to take ambitious bets. Comp ties make them a place to play it safe. Keep them separate until you have a strong goal-setting culture. Even then, be careful.

5. Running them in spreadsheets

I lived this for years. Spreadsheets are fine for one team. The moment you have more than that, somebody is always asking who has the latest version, the check-in column hasn't been filled in since week 3, and the projections column is just whatever the owner guessed last Tuesday. It doesn't scale. (Yes, I'm biased about this. I built Okiar partly because the spreadsheet was making me crazy.)

What's actually changing in 2026

Two real shifts worth knowing about. First, the check-in is finally getting unbroken. The reason teams skip check-ins isn't laziness. It's that writing a structured update takes 8 minutes per KR and nobody has 30 minutes on a Friday to write five of them. Voice-first capture (talk for 20 seconds, AI structures it) drops the cost enough that the check-in actually happens.

Second, projections. Old OKR tools showed you current value vs target. That's backward-looking. What you want is "at this pace, where will we land at quarter-end?" Linear regression off the check-in history gives you that. It changes the conversation in your weekly meeting from "what did you do this week" to "the model says KR2 lands at 38% on June 30. What's the plan to close the gap?"

That second thing is the one I think will quietly reshape goal management over the next two years. Goals that include their own forecast are a different category of thing than goals that just track progress.

Frequently asked