A company sets an objective to make customer onboarding more dependable. Product commits to a new setup flow, Engineering targets fewer setup errors, and Support aims to reduce the time spent on onboarding questions. At the quarterly review, each team reports progress, but customers still wait for account approval from another department.
The goals have made some work visible without establishing how the complete customer process will improve. The missing approval dependency also means that a better setup flow cannot deliver the expected result on its own.
Objectives and key results can help express a desired improvement and the evidence used to assess it. Their usefulness depends on the measures, commitments, and review practices around them. Problems can arise from how the organisation applies the framework, from the limitations of a chosen measure, or from conditions that a goal-setting process cannot resolve alone.
Treating every difficulty as an inevitable property of OKRs obscures those distinctions. The company needs to examine what was promised, what each measure represents, and which decisions would make the shared outcome more achievable.
Clarifying the Kind of Commitment Being Made
An objective should provide a meaningful direction, while its key results describe evidence of progress or achievement. A task list can support that work, but completing tasks does not necessarily establish the objective has been met.
For onboarding, launching a setup screen is a deliverable. Customers completing a useful task with fewer errors is a different result. The team needs a reasoned connection between the two, with enough operating detail to test whether that connection holds.
The organisation should also establish whether a target is a firm commitment, an ambitious aim, or an investigation. The expectations for an essential service requirement differ from those for a speculative improvement. Combining them under one grading rule can make the meaning of a score unclear.
OKR practices vary. Google’s published goal-setting guidance describes graduated scoring rather than a universal binary pass or fail. That example does not establish the right grading approach for every company, but it shows why a narrowly missed target should not automatically be described as framework-defined failure.
The company should explain its own approach before work begins. Staff need to know how uncertainty, partial progress, and changed conditions will be discussed. Without that agreement, an apparently shared target can carry very different expectations for the people involved.
Checking Whether a Key Result Represents the Objective
A measure is a selected view of the outcome. It may provide useful evidence while leaving important aspects unobserved. The onboarding team should consider what customers experience and what could improve the number without improving that experience.
Lower support handling time could reflect clearer guidance, or it could result from ending contacts before the customer’s problem is resolved. Fewer reported defects could mean better software or weaker reporting. These possibilities require investigation rather than an assumption that every favourable trend means the same thing.
The team can use complementary evidence. Time to an accepted resolution, repeat contact, error severity, and customer task completion may each illuminate a different aspect. The goal is a manageable set that supports decisions, not an expanding dashboard intended to eliminate judgment.
Atlassian’s goals, signals, and measures exercise offers a way to discuss how evidence relates to an intended outcome. Its practical value is in examining that relationship with the people who understand the work.
Targets also need a basis. A baseline, customer requirement, or supported estimate can explain why a particular improvement is worth pursuing. Where the target is exploratory, the review should acknowledge that uncertainty rather than treat the number as a measured prediction.
Deliberate misclassification or misleading reporting should not be excused as a necessary response to targets. The organisation can examine incentives while retaining clear expectations about honest evidence. Staff also need a safe route to report when a measure is producing an unintended consequence.
Planning the Shared Outcome Across Team Boundaries
The onboarding objective may reasonably span Product, Engineering, Support, and account approval. It does not have to decompose into independent individual goals. The organisation should choose a structure that reflects how the outcome is produced.
A shared objective can work when responsibilities and commitments are clear. One team may maintain the setup flow, another may provide the approval service, and a programme owner may coordinate the customer journey. Their contributions need to connect through a workable sequence.
The dependency should identify what is needed, who can supply it, and how readiness will be confirmed. A reference to another team’s roadmap is insufficient if that team has not accepted the work or secured capacity for it.
Coordination also needs a way to resolve conflict. If account approval competes with an important financial deadline, the company must decide how to change scope, timing, or allocation. Rewriting the objective more elegantly will not create the missing specialist time.
Local measures should be reviewed alongside the shared result. Engineering may reduce errors while customers still wait for a business decision. That can be valuable progress without establishing that the whole outcome is achieved. The review should preserve both facts.
This is a limitation of using goals as a complete operating model. OKRs can make the desired outcome explicit, while resource planning, decision rights, and dependency agreements establish whether the organisation can act on it.
Matching the Review to the Work’s Time Horizon
A quarterly review can be useful without requiring every objective to begin and end within that quarter. Organisations can retain a longer-term outcome and review its supporting evidence at intervals suited to the work.
Atlassian describes an approach involving annual OKRs refreshed quarterly and tracked monthly. This is one example of a cadence, rather than a prescription the onboarding programme must follow. The company needs a rhythm that fits its decisions and expected effects.
Some evidence arrives quickly. A setup failure or an inaccessible screen can be investigated as soon as it appears. Retention or renewal effects may require substantially longer. A quarterly score should not collapse these different observation periods into one unexplained judgment.
Foundation work also needs an intelligible account. A permission change or integration test may enable a later customer result without immediately moving the final measure. The team should record what the work established and what uncertainty remains, rather than assign an arbitrary percentage of outcome achievement to every completed task.
The review can then distinguish incomplete implementation from an outcome not yet observable. It should also consider whether a distant promised benefit is being used to avoid investigating a visible problem now.
The important question is what the current evidence supports and which decision it should inform. Calendar consistency is useful for administration, but it should not substitute for that reasoning.
Connecting Goals to Capacity and Performance Expectations
An objective becomes a credible commitment when the required work has a realistic place in the plan. Engineering may already support production, while the approval team has earlier obligations. The relevant owners need to agree what changes to provide capacity.
Prioritisation should reach those choices. Adding several ambitious goals without resolving their shared dependencies can produce competition that appears later as weak goal achievement.
The organisation should also distinguish a team outcome from an assessment of an individual’s conduct or contribution. Customers’ behaviour, another team’s delivery, and changing market conditions can affect a result. A score alone cannot explain which decisions a particular person controlled.
If goals influence reward or promotion, that connection needs scrutiny. Strong pressure to report a favourable number can discourage experimentation or conceal uncertainty. A fair review should examine evidence, collaboration, agreed responsibilities, and changes in conditions alongside the result.
Conversely, uncertainty should not erase commitments. A team should report a material risk early, explain what changed, and obtain a revised decision where necessary. The response needs accountability for the actual choices and communication involved, rather than automatic blame or automatic exemption.
Revising the Objective From What the Work Reveals
The onboarding review should ask whether the selected measures remain useful and whether the proposed intervention addresses the principal constraint. A faster setup screen may help little until account approval changes. The next commitment should follow that finding.
The company might retain the outcome and revise its approach, change an unrealistic target, or narrow the customer group. It may also stop a goal that no longer represents a worthwhile use of resources. The reasons should be recorded so a revision does not silently erase the original expectation.
Feedback loops connect those decisions to later evidence. After changing the approval route, the company should check whether customers actually complete onboarding sooner and whether errors or work elsewhere have increased.
A favourable score can still conceal an unresolved problem, just as a missed target can include a valuable improvement. The review needs the underlying evidence and enough context to interpret it. The purpose is to improve the next choice, not simply generate a league table of goal completion.
For this company, OKRs help when they make the customer outcome and its evidence easier to discuss. They stop helping when the score replaces investigation or the written alignment substitutes for a resource commitment. Examining those operating choices gives the organisation a more precise response than declaring either the framework or its users inherently at fault.
