Building and Running an OKR Process (as the Operator Who Owns It)
Takeaway: OKRs are a goal-setting discipline that Andy Grove built at Intel and John Doerr later carried to Google, and the operator's job isn't to admire the framework but to run the unglamorous cadence that makes it real: setting a small number of measurable results, scoring them honestly, and keeping the whole thing lightweight enough that people actually use it.
If you own operations for an executive, sooner or later you will be handed the goal-setting process, and it will often be some version of OKRs. Objectives and Key Results are the most widely adopted planning framework in technology and increasingly beyond it. They're also one of the most commonly botched, usually because the people running them treat OKRs as a form to fill out rather than a discipline to practice. Understanding where the method came from makes it much easier to run well.
Where OKRs actually come from
OKRs didn't originate in a productivity blog. The lineage is specific and worth getting right, because it explains what the method is for.
Andy Grove, then a senior leader and later CEO at Intel, developed the approach in the 1970s. He took Peter Drucker's older idea of Management by Objectives and sharpened it by insisting that every objective be paired with measurable key results. Grove described the system in his 1983 book High Output Management, framing it around two simple questions: where do I want to go, which is the objective, and how will I know I'm getting there, which are the key results (What Matters, The Origin Story). Grove's version was deliberately quantitative. A key result that couldn't be measured didn't count.
John Doerr learned the system directly from Grove as a young Intel employee in the 1970s. Decades later, as a partner at the venture firm Kleiner Perkins, Doerr introduced OKRs to a young Google in 1999, and the company scaled the practice as it grew. Doerr eventually wrote the book that made the term mainstream, Measure What Matters, in 2018. Attributing OKRs to Doerr alone is a common error; he is the popularizer and the bridge to Silicon Valley, but the method is Grove's.
Getting this history straight isn't trivia. It reminds you that OKRs were invented by an operator running a real company under real pressure, not by consultants. The point was always focus and honest measurement, not process for its own sake.
What an OKR actually is
The structure is simple, which is part of why people overcomplicate it.
An objective is a qualitative, memorable statement of what you want to achieve. It should be meaningful and a little ambitious, the kind of thing a team can rally around. "Become the default tool for small-business bookkeeping" is an objective.
Key results are the two to five measurable outcomes that tell you whether you hit the objective. They're quantitative and time-bound. Crucially, they measure results, not activity. "Ship three features" is an activity. "Increase weekly active accounts from 10,000 to 25,000" is a result. The discipline of writing results rather than tasks is where most of the value lives, because it forces people to say what the work is actually for.
A healthy set is small. A team with fifteen objectives has no objectives; it has a to-do list wearing a costume. Grove's original instinct, and Google's practice, was to keep the number low enough that everyone can hold the priorities in their head.
The two flavors of OKR, and why the difference matters
Google's published guidance draws a distinction that prevents a lot of confusion, and any operator running the process should adopt it explicitly.
Committed OKRs are goals the team agrees must be delivered in full. The expected score is 1.0, and missing one requires a real explanation, because it points to an error in planning or execution (Google re:Work).
Aspirational OKRs describe a more ambitious future that the team doesn't yet know how to fully reach. These are meant to be stretch goals. Google's guidance is that the expected average score for aspirational OKRs is around 0.7, with high variance, and that consistently scoring 1.0 on them means the goals weren't ambitious enough.
The trap Google names directly is mislabeling. Marking a committed goal as aspirational lets teams quietly deprioritize it. Marking an aspirational goal as committed creates defensiveness and punishes the ambition the framework is supposed to reward. As the operator, one of your highest-value contributions is forcing that label to be explicit for every objective, because it sets the emotional contract for how a miss will be read.
Running the process: the cadence is the product
The framework is easy. The cadence is the job. A workable operating rhythm looks like this.
Set at the top first. Company-level OKRs come before team-level ones. Teams then write OKRs that ladder up to the company's, so that everyone can see how their work connects to the priorities the executive actually cares about. This alignment, done in the open, is most of the point. If team goals are set before company goals, you get a bottom-up list that adds up to nothing.
Draft, then negotiate. Good OKRs aren't dictated and they're not purely bottom-up. The practical method is a mix: leadership sets direction, teams draft, and the two reconcile. Expect this to take real time in the first cycle and less in later ones.
Score honestly at the close. At the end of the period, each key result gets a score, commonly on a 0.0 to 1.0 scale. Google's expectation is that a healthy average across aspirational OKRs lands around 0.6 to 0.7. The reason to want that number rather than a perfect 1.0 is subtle but important: an organization that hits every goal every quarter is setting its sights too low. Scoring isn't a performance review. It's a learning tool, and treating it as a weapon is the fastest way to make people sandbag their goals.
Keep it lightweight. The most common way an operator kills an OKR process is by wrapping it in so much tooling and ceremony that people dread it. Grove's version fit in a notebook. Whatever system you use, the test is whether a team member can tell you their objectives from memory. If they have to open a document to remember what they're trying to achieve, the process has already failed at its one job.
Common failure modes to watch for
A few patterns recur often enough to name.
Turning key results into a task list is the most frequent. If your key results read like a project plan, you're measuring effort, not outcomes. Rewrite them as results a customer or a metric would notice.
Setting too many is the second. Focus is the whole benefit; a long list surrenders it.
Tying OKR scores directly to compensation is the third, and it's corrosive. The moment people's bonuses depend on the score, they set safe goals and stop stretching, which defeats the aspirational half of the system. Both Grove's writing and Google's guidance treat OKRs as a focusing and learning tool, kept deliberately separate from formal performance ratings.
Finally, setting and forgetting. OKRs that are written in a planning offsite and never mentioned again are worse than no OKRs, because they teach the organization that the executive's stated priorities don't mean anything. The mid-cycle check-in, brief and regular, is what keeps them alive.
FAQ
Who invented OKRs? Andy Grove developed the method at Intel in the 1970s, building on Peter Drucker's Management by Objectives, and described it in his 1983 book High Output Management. John Doerr learned it at Intel and later brought it to Google in 1999, then popularized it in Measure What Matters (2018). The framework is Grove's; Doerr is its most influential evangelist.
What score should we be aiming for? For aspirational OKRs, Google's guidance points to an average around 0.7 on a 0.0 to 1.0 scale, with committed OKRs expected to reach 1.0 (Google re:Work). Consistently hitting 1.0 on stretch goals usually means the goals weren't ambitious enough.
Should OKR scores affect pay or performance reviews? Most practitioners, and Google's own guidance, advise keeping them separate. Tying scores to compensation pushes people to set safe, easily achievable goals, which undermines the stretch the framework is designed to encourage.
What is the difference between an objective and a key result? The objective is the qualitative "what" you want to achieve. Key results are the two to five measurable outcomes that prove you achieved it. If a key result describes an activity rather than a measurable result, rewrite it.
How do I set up and run an OKR process? Set company-level OKRs first, then have teams draft goals that ladder up to them, reconciling the two so everyone sees how their work connects. Label each objective committed or aspirational up front, since that sets the contract for how a miss reads. Keep the set small, run a brief mid-cycle check-in, and score honestly at the close as a learning tool, not a performance review. Keep it lightweight enough that people remember their objectives without opening a document (Google re:Work).
If you're about to run a planning cycle, join The Brief, our free newsletter for exec-ops professionals, and get our OKR drafting worksheet, a simple format for separating objectives from key results, labeling committed versus aspirational, and laddering team goals up to the company's.
