OKRs: how to write, run and score objectives and key results

An illustrative OKR for a software company's onboarding team:

Around them sit a time period (usually a quarter), an owner who keeps updates moving and raises blockers, and a review rhythm that ties the evidence to decisions. A simple drafting pattern: we will [objective], as measured by [key results], by [date]. The test is whether someone outside the team can understand the change and what proof is needed.

OKRs run as a repeating cycle. The process matters as much as the wording:

1. 1

   Choose the change. Find a customer or business problem important enough to focus on this cycle.

2. 2

   Define success. Pick measures that show the problem is improving, not just that work is happening.

3. 3

   Check it can work. Review capacity, data, dependencies and assumptions before committing.

4. 4

   Pick initiatives. Choose the projects or tests most likely to move the results.

5. 5

   Review the evidence. Compare current values with baseline and target at each check-in, and adjust.

6. 6

   Reflect and reset. At cycle end, look at what happened and why, and carry the learning into the next set.

A quarter with short weekly check-ins is a common start, not a rule. Slow outcomes may need longer, and fast tests shorter. Alignment is a conversation: a company objective on retention may lead marketing, product and support to propose different contributions, mixing direction from the top with ideas from teams. Hoshin kanri uses a similar back-and-forth called catchball.

A KPI, or key performance indicator, tracks an important part of performance all the time. An OKR sets a change for one cycle. They work together:

For example, retention stays on the dashboard all year. If it becomes a strategic concern, a team can set an OKR to improve the early customer experience with a retention target as one key result. Keep other health metrics as guardrails: a team working on faster support can watch satisfaction so speed does not come at its cost. Do not turn every dashboard metric into an OKR.

Write the objective around the problem or opportunity, not the department's activity:

The activity version treats delivery as the finish line. The outcome version leaves room to change the solution. Use plain words the team can explain without slides, and if one objective holds several unrelated aims, split it.

For each key result, write down:

• Metric: What changes, and in which direction.
• Baseline: The starting value, measured the same way every time.
• Target: The value that counts as success.
• Population: Which customers, accounts, users or transactions are included.
• Deadline: When the result will be judged.
• Evidence: The report or system that will confirm it.

Improve activation has no finish line. Increase seven-day activation among eligible new accounts from 38% to 50% by quarter end is testable, once you define the activation event and which accounts are eligible. The actionable metrics guide helps pick measures that lead to decisions.

A volume target can push the wrong behavior. Pair it with a measure of quality so the team cannot hit the number while hurting the objective:

Teaching examples. Every baseline and target is made up for illustration and is not a benchmark:

Initiatives such as new targeting rules, content updates, guided setup or better routing go in the plan, not in the key results. Publishing a set number of articles is output, not the result. Before using any example, check that the team can influence it, measure it the same way each time and see change within the cycle. Agree definitions such as sales accepted with the other team first, or a reporting change can look like improvement.

Decide the type before work starts, because each sets different expectations:

Label each OKR clearly. Mixing the two in one list without labels leads to arguments about resources and what counts as success.

Many teams score key results on a scale from 0 to 1, or as a percentage. For a metric that should rise:

progress = (current value − baseline) ÷ (target − baseline)

If a key result starts at 40, targets 60 and ends at 50, progress is (50 − 40) ÷ (60 − 40) = 0.5, or 50%. The same formula works for a falling metric: from 24 contacts down toward 16, a current value of 20 gives (20 − 24) ÷ (16 − 24) = 0.5.

A score says how far the number moved, not whether the objective was achieved. For milestone results or uneven effects, agree a fair method in advance. Do not apply one pass mark to every OKR: a committed result is expected to reach 1.0, while a stretch result can score lower and still show real progress.

Treat the first cycle as a change in planning and review habits, not a document rollout:

1. 1

   Say why you are adopting OKRs. Name the planning problem, such as competing priorities or poor visibility, and how you will judge the pilot.

2. 2

   Start small. Pick one team with an engaged sponsor, usable data and freedom to act on what it learns.

3. 3

   Make the direction clear. Explain the customer or business change that matters and invite the team to propose its part.

4. 4

   Draft few goals. One or two objectives with two to four key results each. Drop measures that add reporting without changing a decision.

5. 5

   Check dependencies and capacity. Confirm help from other teams and decide what work stops or waits. An objective does not create capacity.

6. 6

   Agree owners and evidence. Assign updates, write metric definitions and book the reviews before the cycle starts.

7. 7

   Close with a retrospective. Review the results and the process, and decide what to keep, change or drop before expanding.

Keep individual performance reviews separate from OKR scores. Use results as context in a wider conversation, never as the whole judgment.

A shared spreadsheet is enough for a pilot. Each key result row needs:

Keep progress and confidence apart. A result can move a lot while a new dependency threatens the target, or barely move early in a cycle whose effects arrive later.

Short weekly check-ins work better than a long monthly report. Ask:

• What changed? New values and anything that moved them.
• What did we learn? Which initiatives are helping and which are not.
• How confident are we? Has anything new put the target at risk?
• What decision do we need? Help from another team, a change of initiative, or a call from the owner.
• Is the goal still right? If priorities have changed, revise or retire it in the open and record why.

Changing a goal because the situation changed is fine. Quietly lowering a target to improve the final score is not. At cycle end, compare the evidence with the original definition of success and keep enough notes that the next team understands the result.

1. 1

   Too many objectives. If everything is a priority, nothing is. Keep routine work routine.

2. 2

   Tasks as key results. Workshops, campaigns and releases are initiatives, not proof of success.

3. 3

   Targets nobody controls. If several teams shape an outcome, agree shared duties instead of assigning it to one.

4. 4

   Shifting definitions. Record every change to metric logic, population or data source.

5. 5

   Missed targets as failure. Review assumptions, execution, capacity and outside changes before deciding what to repeat.

6. 6

   Dead goals left on the board. Retire irrelevant goals openly and keep the history.

7. 7

   OKRs instead of strategy. OKRs express priorities that come from strategic choices. Without a clear customer problem and edge, the team measures progress precisely toward a vague destination.

For a first cycle, choose one important problem, draft one objective with a few testable key results, confirm the baselines, name an owner and book the first review. When the team needs software, test shortlisted tools with a real objective and a real review meeting.