A practical guide to goals and OKRs

Learn to distinguish objectives, key results and tasks, choose useful measures and adapt goals as work changes. This practical guide to OKRs brings together a step-by-step approach, illustrative examples, a reusable worksheet and answers to common questions. Start with the section closest to your current challenge, then use the working session to turn the guidance into a clear next action.

Write the objective in plain language

An objective describes a meaningful direction. It should help people understand why the work matters. A key result describes evidence that the objective is being achieved. A task describes work you intend to do. Keep those three things distinct.

“Improve the new customer experience” is a direction. “Create an onboarding deck” is a task. A key result needs a useful outcome and a baseline before the team chooses a target.

Choose measures that reflect the outcome

Select measures the team can interpret and influence. Record the starting point, the target, the time window and the source of the measurement. Avoid a target chosen only because it sounds ambitious.

• State the problem the objective addresses.
• Choose a small set of complementary results.
• Document dependencies outside the team’s control.
• Agree when the result should be reviewed.
• Identify a quality check that discourages gaming the measure.

Use an example carefully

Illustrative objective: Make new employees confident in their first project.

Possible results include a shorter time to the first independently completed task, clearer role expectations reported during check-ins and fewer unresolved access blockers. Set targets only after understanding the baseline and the work.

The activity plan might include assigning a buddy, improving a role guide and scheduling a project introduction. Completing those tasks alone does not prove the objective was achieved.

Review and adapt

Discuss progress in regular check-ins. Ask whether the measure still reflects the objective and whether a new dependency has changed what the team can achieve. Record changes so a later review can interpret the result fairly.

Use the OKR examples library as a starting point for discussion, then adapt the measures to the team. Connect progress to performance reviews without reducing a person’s contribution to a single score.

Put the guide into practice

Set aside a working session with the people who own this process and one or two people who experience it. Use a fictional or appropriately authorised case, so the discussion can be specific without sharing unnecessary personal information. The purpose is to leave with a usable decision or document, not just agreement that the topic matters.

Prepare the case

Choose a team priority and describe the change it is intended to create. Ask participants to distinguish an objective, a key result and a task. Use an example such as improving a customer handover: a new checklist is an activity, while fewer unresolved handover questions may be evidence of the intended improvement.

Write the starting assumptions down before discussing solutions. If the group disagrees on what happened, identify the information needed to resolve that difference rather than building a plan on an untested story.

Work through the decision

Draft a small set of key results with baselines, evidence sources and owners. Check whether the measures complement each other and whether a quality safeguard is needed. Discuss what the team can influence and which dependencies require another owner’s agreement. Avoid a target chosen only because it sounds ambitious.

Ask each participant to explain the proposed decision in their own words. Differences in interpretation often reveal an unclear criterion, a missing responsibility or an instruction that will be difficult to follow.

Test an exception

Introduce a change in demand or a dependency outside the team’s control. Decide whether the objective remains useful and whether the key result needs revision. Record the reason and effective date. A good review should distinguish learning and adaptation from quietly changing a target to make results look successful.

Record what changes in this situation and what remains the same. An exception should lead to a clear next step, with an owner, rather than an informal workaround that nobody can explain later.

Agree the handoff

Connect the objective to a regular discussion about progress, blockers and decisions. Give the owner a record of measures and assumptions, not only a score. At the end of the cycle, review what the result teaches the team and which priorities should continue, change or stop.

Finish by confirming the owner, the next action and the date when the result will be reviewed. Give the person receiving the work enough context to continue without repeating the whole discussion.

Frequently asked questions

How do OKRs differ from KPIs?

A key performance indicator monitors an important aspect of ongoing activity or performance. An OKR connects a chosen objective with evidence of progress towards it. A useful KPI may inform a key result, but a dashboard of measures is not automatically a set of OKRs. Decide which change the team is pursuing and use ongoing indicators to understand context and quality.

Should every key result have a number?

A clear numerical measure can help when it genuinely reflects the outcome and has a reliable definition. Some work is better assessed through observable acceptance evidence, such as a tested process or an agreed decision. Avoid counting activity merely to create a number. Whatever form the result takes, agree how progress will be assessed before the end of the cycle.

Should OKR completion determine an employee rating?

A goal result is one part of performance context. Consider the nature of the target, changed priorities, dependencies and contributions beyond the measure. Directly equating a score with an employee rating can encourage narrow targets or gaming. Explain how goal evidence is used in the organisation’s review process and keep the wider assessment grounded in role expectations and actual work.

Review the first cycle

Ask whether the key results helped the team make decisions during the cycle. If measures were consulted only at the end, simplify the review rhythm or reconsider their relevance. Preserve lessons about assumptions and dependencies so the next cycle starts from better evidence rather than a copied list of targets.

Keep a brief record of what was tried, what participants found useful and what needs to change. Compare the result with the original problem rather than judging success only by completion. If the process created extra work without improving clarity, quality or support, simplify it and test again. Share the agreed change with the people who will use it, and name the person responsible for keeping the guidance current.

Worked planning example: improve customer onboarding

Imagine a team whose customers reach the first useful outcome slowly. The objective is to make the start of the service clearer and more effective. Before setting a target, the team examines the current journey and agrees what “first useful outcome” means. It checks whether the information is collected consistently and whether different customer groups need different treatment.

The team might use one result about the time to that outcome and another about unresolved support issues. These measures balance speed with quality. The activity plan could include a revised welcome sequence, a clearer handover and a named owner for access problems. Those activities support the objective, but completing them does not prove the customer experience improved.

During the cycle, the team reviews progress and the assumptions behind the measures. If a new customer segment changes the work, it records that context. At the end, it asks whether customers reached a useful outcome more reliably, what remained difficult and which changes should continue. This example is illustrative; the measures and targets need to be designed around the actual service.

The owner should also decide what evidence is sufficient before work starts. That agreement makes later discussion more useful than a retrospective argument about whether a dashboard number really represented success.

About New Dynamics

New Dynamics connects goals, feedback, recognition and reviews around the way organisations work. This guide is published by the New Dynamics Editorial Team as part of our practical library for HR leaders, managers and People teams.

Use the examples and worksheets to structure your own discussions and adapt them to your organisation. Illustrative scenarios are not customer case studies. Policy and employment guidance needs appropriate local review before adoption.

For questions about this guide, corrections or a conversation about your performance management process, email contact@new-dynamics.com. Explore the complete guide library for related resources.