OKR Tracking: What to Track, How Often, and Who Updates It

Most OKR tracking fails quietly. The objectives were written well, the key results were measurable, and then somewhere in the second month of the quarter the numbers stopped being updated by the people who owned them. What remains is a spreadsheet that one programme manager fills in before a leadership review, which is not tracking. It is reporting, and it produces none of the decisions that tracking exists to produce.

The distinction sounds academic until you watch a quarter end with everyone surprised.

What is OKR tracking?

OKR tracking is the recurring practice of updating each key result against its target, reading what the movement says about the objective, and changing what the team does next. Leapsome describes it as an organization’s “ongoing process to set, monitor, and report” on its objectives and key results.

The word that carries the weight is “ongoing”. A number recorded once a quarter is a record of what happened. A number recorded weekly, with an owner who has to say out loud whether they still believe in the target, is an instrument you can steer with. Teams that treat tracking as documentation get the first. Teams that treat it as a decision input get the second.

How often should you track OKR progress?

Weekly at team level, monthly at department level, quarterly for scoring and reset. IBM’s guidance is to “conduct weekly OKR team check-ins”, and Leapsome’s is the same: “update your OKR progress weekly” in a meeting that runs between 15 and 30 minutes.

Weekly is not a ritual number. It is the interval at which a stalled key result still leaves you time to do something, and below which people have not done enough to have anything to report. Anything slower at team level and the arithmetic turns against you. A monthly cadence gives a team three data points in a quarter, and the first one arrives when a third of the time is already gone.

For teams in the Gulf, there is a second reason the interval matters. The institutional benchmark for performance measurement in the UAE has moved fast: the federal Proactive Government Performance System now processes over 150 million data points monthly and is built for “real-time data flow for immediate results measurement”. If you are selling into, partnering with or reporting to entities operating at that cadence, a quarterly internal goal review is not a neutral choice. It is a visible difference in operating speed.

What should you actually track between check-ins?

Track the key result metric, the owner’s confidence in hitting it, and the one or two activities meant to move it this week. Everything else belongs in a project tool, not in the OKR view.

This is where most tracking setups go wrong in the opposite direction from neglect. A team that tracks twenty metrics has not built visibility, it has built a place for the important numbers to hide. Atlassian’s guidance on scope applies directly: “for each objective, you should have a set of two to five key results”, because “more than that and no one will remember them”. A tracking view nobody can hold in their head does not get read.

Confidence is the input teams skip and the one that earns the meeting. A key result at 40 percent in week six tells you almost nothing on its own. A key result at 40 percent whose owner has just moved from high confidence to low tells you something has changed, while there is still quarter left to change it back.

What belongs at each level of the tracking rhythm?

Three levels, each answering a different question and producing a different kind of decision. Tracking breaks when all three collapse into one meeting, because the conversation defaults to the shortest horizon and nobody ever steps back.

Level	Interval	What gets updated	The question it answers	The decision it produces
Key result owner	Weekly, before the team meets	The metric, the confidence call, the blocker	Is this moving, and do I still believe the target?	What I work on for the next seven days
فريق	Weekly, 15 to 30 minutes	Nothing. The team reads what owners already wrote	Which key results are at risk, and who unblocks them?	Where the team’s effort goes, and what gets dropped
Department or leadership	شهريا	Cross-team dependencies and resourcing	Which objectives are drifting, and is that a capacity problem?	Reallocation, or a decision to formally cut an objective

The middle row is the one that gets violated. When owners update during the team meeting rather than before it, the first eight minutes go to reading numbers aloud and the session becomes a status report. Leapsome puts the same point in terms of ownership: “it shouldn’t be one individual’s responsibility to lead the meeting and report on progress”.

Who should update the key results?

The person who owns the outcome, not a programme manager and not a coach. Second-hand updates are the single most reliable early sign that a rollout is drifting back towards paperwork, because the person closest to the work has stopped touching the goal.

This is also the cheapest failure to detect. Look at who last edited each key result. If one name appears against most of them, tracking has already become administration, whatever the dashboard says.

Do you need OKR tracking software?

No, not to start, and the choice matters far less than who maintains the data. A shared sheet that six owners update honestly outperforms a well-designed platform that one person fills in on everyone’s behalf.

Dedicated tooling earns its place at a particular point: when the number of teams makes cross-team dependencies impossible to see by hand, usually somewhere past fifteen or twenty teams, or when you need history across cycles rather than a snapshot of this one. Below that, a tool bought early tends to encode a tracking habit the organization has not formed yet. The habit has to exist first. The software makes an existing discipline cheaper, and it has never once created one.

Is OKR tracking the same as OKR scoring?

No. Tracking is continuous and forward-looking, scoring is periodic and backward-looking, and they answer different questions.

Tracking asks what we change now. Scoring asks what we achieved and what that tells us about how we set targets. IBM describes the common approaches as percentage-based scoring, a traffic light rating, and a numerical value between 0 and 1; Atlassian frames the same scale as “whether you missed, came close to, or hit your stated target”, with “scoring 0.7 on a key result” counted as a success.

Keep them apart on the calendar. Score weekly and every check-in becomes a performance review, and teams respond to performance reviews the way people always have: by setting targets they are confident of hitting. You end up with accurate tracking of unambitious goals, which is the most expensive possible outcome of a well-run process.

What does OKR tracking look like when it is going wrong?

Updates arrive late, they arrive from the wrong person, and the numbers move without anyone changing what they do. The dashboard stays green because nobody wants to be the first to mark something amber.

The pattern our coaches see most is a tracking view with no consequences attached to it. If nothing in the week changes because of what the numbers said, people are behaving rationally when they stop maintaining them.

How do you restart OKR tracking that has lapsed?

Cut the set before you restart the rhythm. Tracking rarely collapses on its own, it collapses under the weight of too many key results for a twenty-minute conversation to cover.

Take the objectives as they stand, keep the two or three key results that would genuinely change a decision if they moved, and archive the rest for the quarter. Then restart with owners updating before the meeting, not in it. Restoring cadence on a cut set takes a few weeks. Restoring it on the original set usually fails a second time, and a second failure is considerably harder to come back from than the first, because people now have evidence that this does not work here. Our coaches rebuild exactly this sequence inside the 90-Day Execution Sprint, and it is the most common reason an organization calls us about تنفيذ OKR rather than training.

Frequently asked questions

How often should OKRs be updated? Weekly by the key result owner, before the team check-in. Monthly at department level, and quarterly for scoring and reset.

What should an OKR dashboard show? Current value against target for each key result, the owner’s confidence, and the date of the last update. The update date is the field that exposes a tracking problem fastest.

Can OKR tracking be done in a spreadsheet? Yes, and for most organizations under fifteen teams it is the better starting point. Dedicated software becomes worthwhile when cross-team dependencies stop being visible by hand.

What is the difference between OKR tracking and KPI tracking? KPIs track the health of things that already run. OKR tracking follows a change you are deliberately trying to make this quarter, which is why it needs a confidence call attached and a KPI does not.

How many key results should one team track? Two to five per objective. Beyond that the set stops being memorable, and a tracking view nobody can hold in their head does not get read.

Who is responsible for OKR tracking? The key result owner updates it. The team lead runs the conversation about it. A coach models both for the first two or three cycles, then hands them back.

---

If your OKR tracking has quietly become one person’s spreadsheet, that is a cadence and ownership problem before it is a tooling problem, and it is usually fixable within a single quarter.

---

About the author

ديرك شميلينكامب is Founder and CEO of the OKR Institute, which has certified more than 70,000 practitioners and run OKR implementation programmes for over 1,000 organizations across 50+ countries since 2017. The OKR Institute is accredited by the International Coaching Federation, the Association for Coaching and HRD Corp.

دورات تدريبية

المشاركات الاخيرة

العلامات

#OKR

#OKR AI agents

#trends 2026