An OKR review can be well organised and still leave the work unchanged. Every team has updated its score, the dashboard shows movement, and the meeting finishes on time. Yet the same dependency remains unresolved, the same people are assigned to competing projects, and nobody has decided what to do differently.
Objectives and Key Results provide a way to describe an intended outcome and the evidence of progress towards it. Their practical value depends on how those goals enter everyday decisions. A useful objective helps someone choose between competing requests, investigate an unexpected result, or ask for a change in resources. A score that only travels upwards at reporting time has a more limited role.
This makes an OKR implementation worth examining beyond the quality of its wording. Teams need to understand what they are committing to, how results will be interpreted, and what happens when the evidence challenges the original plan.
Establish What the Goal Means in Practice
Consider a business software company trying to reduce the effort customers spend resolving billing queries. Finance wants fewer manual adjustments, Support wants fewer repeat contacts, and Product wants customers to manage more changes themselves. An objective such as making billing easier could bring those teams together, but it does not settle which problems deserve attention first.
The company needs a working description of the difficulty. Are customers unable to understand an invoice, waiting for a correction, or receiving conflicting answers from different teams? Those situations may share a heading while requiring different work. Reviewing a sample of actual queries gives the objective a more useful basis than selecting a target before understanding the process.
Suppose that investigation identifies repeated contacts about contract amendments. The team can then define an improvement around customers receiving a correct explanation and, where necessary, an accurate adjustment without repeated chasing. That provides a basis for choosing measures and deciding which proposed work contributes.
The commitment also needs to be clear. A demanding exploration of a new service model carries different expectations from a promised correction to an existing billing defect. Describing both as stretch goals would conceal an important difference in responsibility. Describing both as fixed delivery promises would discourage useful investigation.
Google’s published OKR guidance describes its use of ambitious goals and treats low scores as information for subsequent goals. That is a particular approach to goal-setting, rather than a universal rule that achieving a certain fraction of any target constitutes success. Teams should agree on the expectation attached to their goals before results are available.
Make the Measures Usable Before Reporting Them
A key result needs enough definition that people can interpret a change consistently. For the billing example, reducing repeat contacts sounds straightforward until the team asks what counts as a repeat. A customer may contact Support through several channels, reopen a query after a later invoice, or submit two genuinely different questions about the same account.
The measurement should specify the relevant population, the observation period, and how related contacts are identified. Someone also needs to check whether the necessary records exist. A precise target attached to incomplete data can create an appearance of certainty that the team cannot justify.
Establishing a baseline may therefore be part of the first period of work. That need not delay every improvement. Staff can correct an obvious explanation problem while the team investigates the wider pattern. What matters is distinguishing the evidence already available from the evidence still being assembled.
Measures should also be considered together. A reduction in repeat contacts would be less encouraging if customers had simply stopped receiving replies. Resolution time, the accuracy of adjustments, and examples of unresolved cases can help the team interpret the headline result. These supporting checks need not all become separate key results; their purpose is to test whether the reported improvement represents a better service.
Keep the definition stable enough to compare results. If the team changes how it identifies related contacts, it should record the change and assess whether the old and new figures remain comparable. Quietly altering a denominator can make a dashboard look better without any improvement in the underlying experience.
Give the Objective Space in the Work
A new objective competes with existing commitments even when it appears on a separate planning page. Finance still has its reporting deadlines. Support still handles incoming queries. Product still has maintenance work and customer commitments. Writing a shared goal does not make those demands disappear.
Before approving the billing objective, the participating teams should identify the work it is likely to require. Some of that will remain uncertain, but the initial investigation, analysis, implementation, and service preparation still need time. The plan should identify which existing work continues, which can move, and who can approve those changes.
Dependencies need an explicit conversation with the people supplying them. If the improvement requires changes to contract records, the owner of that system needs to understand the request and agree when the work can happen. Listing that team in the OKR document is insufficient. Atlassian’s dependency-mapping exercise offers one practical way to identify dependencies and discuss their owners and risks.
Teams do not need to convert every operational responsibility into an OKR. Routine work can have service measures, maintenance plans, and clear ownership of its own. The important question is whether the combined workload is feasible. Excluding routine responsibilities from the goal list must not exclude them from capacity planning.
When an urgent request arrives, the objective should help frame the decision. Does the request address the same customer difficulty, meet an obligation that takes precedence, or use capacity committed elsewhere? Recording that choice makes the trade-offs behind execution visible. Otherwise the official priorities can remain unchanged while the available time steadily disappears.
Use Reviews to Decide What Happens Next
An effective review connects evidence to a decision. The team should be able to explain what changed, what it thinks contributed, where the explanation is uncertain, and what response it proposes. The score provides an entry point into that discussion.
For the billing team, repeat contacts might remain high after an explanation page is improved. Reviewing cases could show that customers understand the invoice but cannot obtain an authorised adjustment. The next useful action may be to change the correction workflow. Continuing to polish the page because that was the original project would leave the main difficulty untouched.
A different result might need a different response. If contact volume falls only among customers who received direct help from a specialist, the team needs to establish whether the new approach works without that assistance. If results vary by contract type, it may need to narrow the next trial. Neither finding can be understood from an aggregate score alone.
Review frequency should reflect how quickly meaningful evidence becomes available and how soon a decision is needed. A brief operational check may happen frequently, while a reliable assessment of repeat billing issues may require another invoice cycle. Requiring a new numerical improvement at every meeting can encourage explanations of noise.
The people attending must also be able to act on the issues raised. Some decisions belong within the team; others require a sponsor or a system owner. A review that repeatedly records the same external blocker needs a route to resolution. More detailed status reporting will not provide missing authority.
Explain How Results Affect Performance Discussions
People will interpret OKRs partly through what happens when a target is missed. If managers say the goals encourage learning but use the final percentage as an automatic performance ranking, staff receive conflicting instructions. They have a reason to negotiate safer targets and avoid work whose results are difficult to predict.
This does not mean results are irrelevant to individual performance. A review can reasonably examine how someone made decisions, delivered agreed work, collaborated, raised concerns, and responded to evidence. The difficulty is treating a shared business outcome as a complete account of one person’s contribution.
The billing result may depend on customer behaviour, system access, data quality, several teams, and decisions made before the current work began. A manager needs to understand those conditions alongside the employee’s responsibilities. Equally, a claim that the goal was ambitious should not prevent examination of a missed commitment that the person could reasonably have fulfilled.
The distinction should be explained before the review period. Staff need to know whether a goal is exploratory, what delivery commitments remain firm, and how changes will be agreed. This gives both managers and teams a more credible basis for discussing a disappointing result.
Assess Whether the Process Is Helping
A practical OKR trial can start with a limited area of shared work. The billing example provides a manageable test: a defined customer difficulty, participating teams, an initial evidence base, and decisions that those teams need to make together. There is no need to impose individual objectives across the entire organisation to find out whether this improves coordination.
At the end of the trial, examine the process as well as the customer outcome. Did the goal help resolve competing requests? Did the measures reveal something useful? Did reviews change an action or resource decision? Could the team explain the result without spending days reconstructing the records?
Administrative effort matters too. If updates duplicate an existing delivery system, the team should simplify how information is collected. If a key result remains uninterpretable, it needs revision. If the objective has lost relevance, carrying it forward solely to complete the scoring cycle serves little purpose.
The broader failure modes of OKRs are easier to address when they are examined through actual work. The question is whether the organisation has a clearer account of what it is trying to improve and can make better decisions as evidence arrives. A simpler process that supports those decisions can be more useful than an elaborate rollout that only produces a complete set of scores.
