The quarterly review looks reassuring. Project owners report progress, the dashboard is mostly green, and everyone has a slide explaining what they’ve delivered. Then someone asks whether customers are better off, whether decisions are faster, or whether the organisation’s main priority has moved. The room gets quieter.
An OKR framework should make that conversation easier. But in a hierarchical organisation, a visible goal can also feel like a visible risk. Getting the template right matters. Getting people comfortable enough to say “we’re off track and need help” matters just as much.
What the OKR Framework Is and Where It Came From
OKRs work like a GPS for team priorities. The objective is the destination. The key results are the checkpoints that confirm the team is following the right route.
In plain terms, an OKR pairs a qualitative statement of what a team wants to accomplish with measurable evidence of progress within a defined period. “Make onboarding straightforward for new customers” sets a direction. Its key results establish what would count as straightforward.
John Doerr’s Measure What Matters describes the approach originating at Intel in the 1970s, where Andy Grove adapted management-by-objectives principles; Doerr learned the method at Intel in 1975 and introduced it to Google in 1999.
That history explains why the framework stays deliberately light. An OKR creates a working agreement about candour as much as direction. In hierarchical or regulated organisations, teams may soften an at-risk result until review day. A visible checkpoint gives managers an earlier chance to remove a blocker, reorder work, or challenge an unrealistic objective. Its purpose is to trigger that conversation while there is still time to act.
OKRs compared with other planning tools
Each tool serves a different management question.
| Tool | Answers | Typical cycle | How success is judged | Best used for |
|---|---|---|---|---|
| OKR | Where the team is heading and proof it got there | Quarterly, with annual direction | Example convention: scored 0.0 to 1.0 on key results | Aligning teams around a few priorities |
| KPI | Is a business metric staying healthy? | Continuous | Within or outside an agreed threshold | Monitoring normal operations |
| Project plan | What tasks must finish and when? | Per project | Done or not done | Tracking delivery milestones |
| Annual target (MBO style) | What number does the person or unit hit this year? | Yearly | Hit or missed | Setting an appraisal baseline |
Treat the OKR scoring scale shown here as an example to agree before launch. Teams can adopt a different convention if it produces clearer discussions.
Practical distinction: A project plan can show that you delivered the solution. A key result should help establish whether the solution worked.
Leaders need this distinction when their portfolio contains more projects than anyone can meaningfully prioritise. Keep the delivery plans, operational indicators and appraisal requirements. Use OKRs to clarify which changes deserve concentrated attention, and make the other tools serve that direction.
Writing Objectives That Point in One Direction
Compare these objective drafts:
| Weak objective | Stronger objective |
|---|---|
| Improve onboarding | Help new hires feel productive in their first month without chasing the same answers twice |
| Improve finance processes | Make month-end close something the CFO trusts without a second check |
The stronger versions describe an experience worth changing. They don’t prescribe the solution, so the team can investigate whether the problem lies in information, approvals, systems or unclear responsibilities.
A useful objective is qualitative, motivating, tied to the cycle, and ambitious yet credible. Motivating doesn’t mean dramatic. For a finance team, a dependable close may be more meaningful than a grand promise to transform finance.
Test the wording before debating targets
Apply these tests with the people who’ll do the work:
-
Explain the purpose: Can a new colleague explain why it matters in one breath?
-
Describe the change: Does it name a better business or customer condition, rather than a department’s activity?
-
Check its significance: Would the team feel proud if it achieved this?
As a starting design choice, use two to four objectives per team per quarter. Treat more than five as a prompt to revisit priorities, not as proof of ambition. These are practical limits for protecting attention, rather than research-derived thresholds.
Start with a verb connected to a change: simplify, establish, strengthen or remove. Avoid copying a KPI name or job title into the objective. Also avoid joining unrelated ambitions with “and”; that usually conceals a prioritisation decision.
There’s an important exception to that wording advice. A phrase such as “faster service with reliable controls” can describe a single outcome with a necessary constraint, rather than separate objectives.
For a short workshop this week, draft three objectives on a whiteboard and read them aloud. Ask the team which customer, colleague or decision would be different if each succeeded. Cut anything that sounds like a job description.
Writing Key Results That Show Real Change
In one regulated launch I supported, every milestone showed green while customers still waited weeks. The activity log looked disciplined. The outcome was stuck.
That gap is the test. Ask: could this number improve while the business gets worse? Training attendance can rise while coaching stays weak. Release count can climb while defects move later into production. Keep the activity in the delivery plan and measure the condition it was meant to change.
A measurable key result is also a trust test. In hierarchical organisations, people often choose numbers they can defend, then smooth bad news before review. I keep one objective to a short set, often three to five key results, because longer lists give at-risk work places to hide.
Weak key results and stronger rewrites
Treat the targets below as examples to adapt, with definitions checked against your own baseline and risk appetite.
| Weak key result | What is wrong | Stronger version |
|---|---|---|
| Launch the new onboarding app | Shipped is an output; behaviour change is missing | 80 percent of new hires finish their first-month checklist unaided within 30 days |
| Hold ten training sessions | Activity count with no evidence of impact | 80 percent of trained managers complete a live coaching check within 30 days |
| Improve customer satisfaction | No number and no baseline | Raise post-resolution CSAT by 5 points against the Q1 baseline, surveyed monthly |
| Be more agile | Cannot be measured or disputed | Reduce the average release cycle from six weeks to two weeks for two product teams |
| Reduce cost of support | Direction with no threshold or time frame | Lower cost per resolved ticket by 12 percent against the March baseline, measured monthly |
Even the stronger versions need scrutiny. Define what “unaided” means, what a coaching check demonstrates, and whether cheaper support leaves customers with unresolved problems. A precise target can still reward the wrong behaviour.
Make the evidence inspectable
For every key result, record:
-
Accountability: A named owner who can explain progress and coordinate action.
-
Measurement: Metric definition, baseline, target and data source.
-
Review controls: Review frequency and the escalation threshold.
Then separate early signals from final outcomes. The share of accounts with a scheduled review can warn the team while retention work is still fixable. Retention shows the eventual outcome; a booked review shows motion that may fade.
Measurement rule: If nobody can explain where the baseline came from, the target is not ready for commitment.
Where data is missing, reserve the first two weeks for measurement as a planning choice. Label estimates as estimates, agree the collection method, and hold commitment until the team understands its starting point. The awkward conversation happens early, while the number can still be challenged without blame.
A Full OKR Example for an AI Adoption Goal
Consider a hypothetical mid-sized Singapore insurer. Its board has approved investment in AI-assisted claims triage, but operations leaders haven’t agreed what successful adoption means. The technology team wants deployment, claims managers want less waiting, and risk leaders want clear accountability.
A workable team objective is: Use AI to speed up claims triage while keeping decisions accountable and visible to customers.
Governance belongs inside that objective, not in a separate document nobody discusses during delivery. Singapore’s Model AI Governance Framework implementation guide covers four areas: internal governance structures and measures, human involvement in AI-augmented decisions, operations management, and stakeholder interaction and communication.
Worked key results for a claims triage AI objective
All figures below are illustrative examples, not results from a real insurer. Assess progress by the end of the proposed cycle.
| Key result | Baseline | Target | Owner | Data source |
|---|---|---|---|---|
| Every live AI use case has a named accountable owner | 3 of 9 | 9 of 9 | Office of the Chief Risk Officer | AI use-case register |
| Risk assessment completed before go-live | 2 of 6 | 6 of 6 | Head of Data Governance | Risk review log |
| Triage model accuracy on monthly audit sample | Measure before target approval | 90 percent, provisional until baseline validation | Claims analytics lead | Monthly model test results |
| AI-assisted decisions explained to affected customers | 0 published | 1 published policy plus explanation template | Customer operations lead | Website and complaint log |
The accuracy target remains provisional deliberately. The team must define correct triage, the audit sample and the consequences of different errors before committing. Publishing an explanation policy also isn’t enough on its own; the owner needs evidence that affected customers receive usable explanations.
Pair acceleration with a guardrail
There’s no key result counting claims processed per day. Higher throughput could coexist with poor routing or inadequate review, so it wouldn’t establish successful adoption.
The governance set above is a foundation, not the complete evidence for the speed promise. Before approving the full OKR, add or substitute a measured triage-time outcome, with human-review and quality guardrails beside it. Don’t claim faster triage from model accuracy alone.
Ekipa’s guidance on how Agile thinking accelerates AI adoption offers a useful connection between iterative delivery and adoption. Adapt the structure to your sector, but keep business benefit and operating controls visible together.
Setting Your First Quarterly OKR Cycle, Step by Step
The sequence matters more than the template. If teams write objectives before leadership agrees priorities, they’re being asked to resolve strategic disagreements through local planning.
Use this sequence as a proposed implementation approach. Its workshop lengths and checkpoints are planning suggestions, not research-backed requirements.
Move from leadership choices to executable commitments
-
Agree company priorities: Ask leadership for two or three outcomes that deserve concentrated effort. A budget allocation isn’t an outcome, and a cost target without a service constraint can create conflicting expectations.
-
Let teams draft their contribution: Each team proposes two to four objectives linked to a company priority. Avoid allocating identical wording down the hierarchy; teams need room to identify the change they can influence.
-
Build the measurement record: Draft key results with the evidence fields described earlier. Mark missing baselines “measure first” rather than negotiating confident-looking targets around uncertain data.
-
Check line of sight: Every team objective should trace to a priority, and every key result to an objective. Ask owners to explain those links aloud. If the explanation depends on several assumptions, investigate before publishing.
-
Surface dependencies together: Hold a half-day working session with the people whose work touches the objectives. Identify approvals, shared specialists, data access and operational obligations. Inviting only objective owners leaves important constraints outside the room.
-
Agree reviews and scoring: Decide how evidence becomes a score and what triggers escalation. For leaders supporting these conversations, Coachful’s OKR planning guidance for executive coaches is an additional planning resource.
-
Publish and test usability: Make the agreed set accessible, then revisit it in week two. Check whether owners can retrieve the data and explain movement. Don’t wait until cycle-end to discover that a metric can’t be calculated.
Use a readiness gate
Before launch, confirm that:
-
Quality has an owner: Someone has authority to reject activity-only key results.
-
Time is protected: Reviews are in calendars, and operational work is reflected in capacity.
-
Rules are visible: Scoring, escalation and target-change decisions are written down.
Where capability is the gap, Ekipa offers an Objectives & Key Results course for setting and tracking goals that align the organisation. Where delivery stalls between teams, its Agile Roadmap Planning Session brings transformation leads into a structured review of the operating model and delivery bottlenecks.
Start with a team or cross-functional value stream. Expand after the review habits hold, not just because the first planning workshop went well.
Cadence, Check-Ins and How to Score Each Key Result
A usable scoring convention is 0.0 to 0.3 for little progress or off-track results, 0.4 to 0.6 for meaningful progress with gaps, and 0.7 to 1.0 for substantial delivery. These are practitioner bands, not research findings. Define the calculation for each metric in advance; a high band doesn’t waive a mandatory control.
Quarterly OKR rhythm at a glance
This is an illustrative twelve-week operating schedule. Adapt the durations to the decisions required rather than adding meetings mechanically.
| Rhythm | Typical length | Main question |
|---|---|---|
| Weekly check-in | 15 to 30 minutes | Which key results are at risk and why? |
| Fortnightly review | 45 to 60 minutes | Are the leading indicators and dependencies moving? |
| Mid-cycle decision, around week six of twelve | 60 to 90 minutes | Keep, change or stop each key result? |
| End-of-cycle scoring, week twelve | 60 minutes | What was delivered, scored from 0.0 to 1.0, and what did we learn? |
| Quarterly planning | Half a day | Which objectives go into the next cycle? |
| Annual strategic review | One to two days | Is the direction behind the objectives still right? |
For stretch objectives, an average around 0.6 to 0.7 can be a useful practitioner rule of thumb. If every stretch result reaches 1.0, question whether targets were too safe, but inspect the context before concluding. Committed controls shouldn’t be treated as stretch experiments.
Make candour measurable before you score it
In hierarchical or regulated teams, the first cycle often produces green statuses that turn red in week eleven. Set an internal baseline before launch: count how many risks, owner requests and dependency warnings surface in the first two check-ins, then compare the same behaviours at mid-cycle. If silence is the pattern, treat that as a trust signal and change the forum. Use smaller review groups, clearer escalation rules, and facilitator questions that ask what evidence would make the status amber.
Keep the conversation useful rather than theatrical. Ekipa promotes regular communication through stand-up meetings, sprint planning sessions, sprint review sessions and sprint retrospectives. Use short check-ins for blockers, reviews for evidence, and agile retrospectives for continuous improvement to examine how the team works.
An honest warning gives a manager something useful to act on. A reassuring score without evidence doesn’t.
At midpoint, decide keep, change or stop, and record the reason. Retain the original target so adaptation doesn’t become silent rewriting.
Keeping Teams Aligned Without a Rigid Cascade
I have seen first-cycle OKR programmes where every team slide quotes the company objective word for word. That looks aligned. It usually means nobody made a decision. Alignment means each team can explain, in its own words, how its work contributes to the priority above it. Use a traceable chain: company priority, division objective, team objective, individual commitment.
Those links show contribution rather than reporting lines. An individual commitment may be dependency work, technical review or operational support; it doesn’t automatically need a separate personal OKR.
Make the link and the dependency explicit
A company prioritises regional growth. A team proposes: “Make onboarding dependable for new SME accounts in Singapore.” Its planning record names the growth priority it serves and the dependency it needs from compliance for timely account reviews. If either link is missing, the objective is floating.
Completed onboarding calls are supporting commitments on their own. Pair that work with an outcome measure, such as accounts reaching first transaction, rather than rewarding call completion alone.
Ekipa has facilitated multiple-day big room planning sessions with more than 30 people across organisational layers, including vision and purpose work, team agreements and inter-team dependencies. In its dairy-company transformation, the 9 Grids strategic framework gave each Management Team member ownership of a Grid, supported by Grid Leads and cross-functional teams. Coordination of that kind carries the alignment; a cascade diagram alone does not.
Measure whether people understand and can challenge
In hierarchical, regulated organisations, the common failure is quiet compliance. Teams mark goals green because flagging a risk feels unsafe, and the first honest signal arrives two weeks before the quarter ends. So test alignment by asking, not by reading slides. Ask a team member to describe the company objective, where their key result sits under it, and what would make them report a goal as at risk early.
Before the pilot, establish baselines for:
-
Strategic understanding: The share of staff who can describe the company objective accurately.
-
Dependency visibility: The proportion of key results with relevant cross-team dependencies recorded.
-
Decision latency: The time blocked work waits for an accountable decision.
Then assign the conflict question before the cycle starts. When two team objectives compete for the same capacity, one named owner decides, typically the leader accountable for the shared outcome, and the call goes into the planning record with its reason. Teams keep discretion over how they deliver; leaders keep responsibility for resolving priorities and constraints. The habits behind that split are covered in Ekipa’s guide to building accountability and self-organisation in agile teams.
In regulated settings, retain decision ownership and escalation records without making every review a compliance hearing. Compare pilot evidence with the baseline, and scale once metric definitions, data ownership and review behaviours are stable.
Common Questions About OKRs
What if every key result comes back green?
Treat a full green board as a prompt to inspect the quiet parts. Ask each owner what risk they absorbed, which dependency nearly slipped, and what would turn the result amber next month. If the answers stay vague, pair the score with one operational indicator the team cannot easily smooth over, such as repeat customer contact or release rollback rate, so optimism has to meet evidence.
What should happen when two teams’ key results collide?
Put the conflict in one sentence: which objective matters more this quarter, and what trade-off is acceptable. Bring both owners and the sponsor into the same review, choose a shared result or a clear priority, then give the lower-priority team a stop or de-scope that protects capacity. Set a date to test whether the chosen trade-off still holds.
Can a sponsor change an OKR mid-cycle?
Yes, when the assumption behind it breaks. Make the change explicit: state the trigger, the work that stops, the result that stays stable, and the review date. Quiet mid-quarter edits teach people to game the draft. A visible change teaches them the framework can absorb reality.
How do you get honest scores in a hierarchy?
Open reviews with confidence and risk before the number: “What are we least sure about?” Reward early warnings by removing a blocker. In rooms where senior opinion carries weight, have the most senior person score last so the evidence is heard before authority.
Where to Start Next Quarter
An OKR framework is useful when people can make choices with it. Keep priorities few, inspect outcomes rather than activity, and make honest discussion more valuable than a reassuring status update.
Choose a pilot team or value stream before next quarter begins. This week, draft its objectives and ask the people doing the work what would prevent them from reporting a problem openly. Address that answer alongside the measurement design.
Training can help when the difficulty is writing usable goals. A joint operating-model review is more appropriate when the core problem is hand-offs, competing priorities or unavailable decision-makers. Choose support for the constraint you have, then run the full cycle before widening the rollout.
Ekipa helps teams connect strategy with day-to-day execution through training, coaching and structured planning. If you’re preparing an OKR pilot, visit Ekipa to discuss goal-setting capability or a planning session focused on the bottlenecks between your teams. Bring your draft priorities and the dependencies you’re struggling to resolve.