What Percentage of Key Results Are Actually Tasks in Disguise? I Counted My Own.

I was pulling together a one-pager for our Q3 mid-quarter sync last week, and I did the thing I always do before a strategy conversation: I opened the OKR tracker from two quarters back to see how we actually did against what we said we'd do.

Fourteen Key Results from Q1. Eleven marked green. I felt good about that for exactly as long as it took me to read the third one: "Launch the redesigned customer onboarding flow." Green. Done. Shipped March 3rd, right on schedule.

Except I sat there and asked myself something I hadn't asked back in January when we wrote it: would this have happened if we'd never called it a Key Result at all?

It would have. Product had already scoped the onboarding redesign in December. Design had wireframes before we'd even finished the planning offsite. Engineering was staffed and building it regardless of what box we checked on the OKR doc. I hadn't written a goal. I'd written a project plan, dressed it up in outcome language, and handed myself a green checkmark for doing work that was already going to get done whether or not anyone tracked it.

The 52% Problem

Turns out I'm not the outlier. One OKR platform's own audit of its customer base — roughly 7,857 published Key Results — found that 52% of them weren't real outcome measures at all (okrstool.com, 2026). That's a vendor auditing its own data, not a neutral third-party study, so take the exact number with the grain of salt it deserves. But even a directionally accurate version of "just over half" is still tasks with a percentage sign taped on for credibility. A real Key Result measures whether something changed in the business because of the work. A disguised task just confirms the work got done, regardless of whether it moved anything.

That means for most teams, roughly half of what shows up on the quarterly OKR deck as a "goal" was never really at risk. It would have happened anyway. The only thing goal-tracking added was a green checkmark and a false sense that the planning process is what made it real.

The Key Result That Was Actually Just My To-Do List

Here's the thing about "launch the redesigned customer onboarding flow" — it's not a bad sentence. It reads exactly like every other Key Result in every OKR template I've ever seen, mine included. It has a verb. It has a deadline attached to the quarter. It sat next to real outcome measures on the same tracker and nobody in the room flagged it as different, including me, and I've been running goal-setting cycles for six years.

I went back through the other thirteen. Two more failed the same test. "Complete the migration to the new billing system" — already scoped, already staffed, contractually committed before Q1 started. "Roll out the updated sales enablement deck to the whole team" — a task on someone's calendar for eight weeks before it appeared on the OKR doc.

Three out of fourteen. Not the worst ratio compared to the 52% figure, but three real projects that consumed real planning-cycle attention while contributing nothing to whether we actually knew if the quarter had worked. Somewhere between the January planning doc and my green checkmark, nobody flagged that these three didn't have an outcome measure attached to them. That's exactly the kind of gap an early-warning system should catch on day three of the quarter, not in a retro six months later. That's the specific problem we built Rhythms' Radar to solve. It surfaces a task quietly masquerading as a goal while there's still a quarter left to fix it, instead of leaving you to discover it in hindsight.

The One Question That Tells You Which Kind You Have

The test isn't about how the sentence is written. Plenty of disguised tasks are worded perfectly — action verb, specific deadline, measurable-sounding language. The test is about causality, and it's one question: would this have happened whether or not we called it a goal?

"Launch the onboarding redesign" is a task. It happens or it doesn't, and the decision to build it was made months before the OKR doc existed. "Reduce time-to-first-value from 14 days to 7" is a Key Result. It measures whether the redesign actually changed what a new customer experiences — and it's entirely possible to launch the redesign, hit the deadline, mark it green, and have time-to-first-value stay exactly where it was. The task can succeed while the outcome fails. That gap is the whole point of writing outcome measures in the first place, and it's the gap that disappears the moment your Key Results are secretly tasks.

I watched this exact failure mode play out across thousands of OKR rollouts when we were building Ally.io and later running Viva Goals inside Microsoft, and it took years to see the actual pattern underneath it. Teams didn't fail at OKRs because they lacked discipline or skipped their check-ins. They failed because roughly half of what they were tracking wasn't a goal to begin with — it was a project plan wearing a goal's clothes, and no amount of weekly check-in discipline fixes a Key Result that was never measuring an outcome.

Why Disguised Tasks Are So Easy to Write (and So Satisfying to Check Off)

There's a reason this happens at this scale and it isn't laziness. Tasks are easy to write because you already know exactly what "done" looks like — the redesign either ships or it doesn't. Outcomes are hard to write because you have to commit to a number you might miss for reasons partly outside your control. Writing "reduce time-to-first-value to 7 days" means the redesign could ship perfectly and the metric could still not move, and now you have to explain that in the next review. Writing "launch the redesign" means you get to be right no matter what the redesign actually does.

Checking off a task also feels like progress in a way that watching a metric doesn't move never does. There's a real dopamine hit in marking something green, closing the ticket, updating the tracker. A real Key Result can sit at 40% for six straight weeks while you're doing everything right, and that's a much harder thing to report on in a Monday staff meeting than "shipped, on time, green."

This is also exactly why a review that just confirms the work happened doesn't catch the problem — it's built to answer "did the task get done," not "did anything change." A weekly status check that pulls "on track / at risk / done" from a project tool will happily tell you the onboarding redesign shipped on schedule and never once ask whether time-to-first-value actually moved. That's the difference between a review that performs alignment and one that's grounded in what actually changed — which is the whole reason we built Rhythms' Reviews to pull from outcome data, not just task status, when it assembles what leadership sees.

Teams that keep writing disguised tasks aren't undisciplined. They're responding rationally to a system that rewards the wrong kind of certainty. If your only options are "commit to a number you might miss" or "commit to a project you control completely," most people will quietly choose the second one every single planning cycle — which is also a large part of why so many OKR rollouts look great in January and feel dead by March.

How to Audit Your Current Key Results This Week

This doesn't require a new framework, a new tool, or a longer planning cycle. It requires thirty minutes with your current Key Result list and one question, asked out loud, for each one: would this have happened anyway, tracked or not?

Pull up your current quarter's Key Results — all of them, not just the ones you're worried about. For each one, ask who decided this work was happening, and when. If the honest answer is "Product/Engineering/Sales already committed to this before the OKR doc existed," you're looking at a task. If the honest answer is "we genuinely don't know if this will move, and that's why we're tracking it," you're looking at a real Key Result.

The ones that fail the test don't need to disappear from your roadmap — the onboarding redesign still needed to happen, and it was still good work. What needs to change is what you call it and where you track it. Move it to your project list, and replace it in the OKR tracker with the outcome question it was supposed to answer: not "did we ship the redesign" but "did time-to-first-value actually move because we shipped it."

This is exactly the case for real goal cascading, not just goal tracking. When a Key Result genuinely measures an outcome, a change at the top actually changes what's true underneath it — a CEO who shifts the Q3 target on time-to-first-value should see that ripple into every team whose work touches onboarding. A disguised task doesn't cascade like that. It just sits there being finished, disconnected from whether the number the company actually cares about ever moved. That live connection between a top-level shift and every downstream target is what Rhythms' Goals & Alignment is built to maintain — not a spreadsheet everyone has to remember to update by hand, and not a rollout that stalls out the moment the initial planning energy wears off.

Do this audit once, honestly, and you'll probably find your own version of my three-out-of-fourteen. Do it every planning cycle, and you stop rediscovering the same problem every quarter.

The Question I Actually Carry Now

I still think "launch the redesigned customer onboarding flow" was worth doing. I'd greenlight it again tomorrow. What I wouldn't do again is let it sit on the OKR tracker next to Key Results that were actually measuring something, both of them marked green, both of them treated as equally meaningful proof that the quarter worked.

The uncomfortable part isn't that I got this wrong once. It's that I'd been running planning cycles for six years before I ever asked the question that would have caught it. If half of what most teams call a goal would have happened regardless of whether they'd ever written it down, the real failure isn't in the execution. It's in mistaking the plan for the point.

If you're still marking tasks green and calling them goals, try Rhythms for free at rhythms.ai.

Frequently Asked Questions

What percentage of Key Results are actually tasks in disguise?

An analysis of a large sample of published Key Results found that 52% were tasks or KPIs relabeled as Key Results, not genuine outcome measures. That means for most teams, roughly half of what's tracked as a "goal" would have happened anyway regardless of whether it was framed as one — the tracking added a checkmark, not an outcome.

What's the actual difference between a Key Result and a task?

A task is something you do; a Key Result is something that changes because of what you did. "Launch the onboarding redesign" is a task — it happens or it doesn't, and the decision was usually made before the planning cycle started. "Reduce time-to-first-value from 14 days to 7" is a Key Result — it measures whether the launch actually changed what a customer experiences, and it's possible to do the task perfectly while the outcome doesn't move at all.

Why do my team's OKRs feel like a to-do list?

Because they probably are one. If most of your Key Results would have happened whether or not you called them Key Results, you've written a project plan and labeled it a goal-setting exercise. The fix isn't more tracking discipline or more frequent check-ins — it's rewriting the Key Results themselves so each one measures an outcome instead of confirming a task got done, and doing that audit at the start of every planning cycle instead of once as a cleanup project. That recurring cadence is exactly what we built into Rhythms' Playbooks, so the question runs automatically before a disguised task ever makes it onto the tracker.

How do I test whether a Key Result is real or disguised?

Ask: would this have happened anyway, task-list or no task-list? If the answer is yes — if Product, Engineering, or Sales had already committed to the work before the OKR doc existed — it's a task. If the honest answer is "only if we actually changed something about how the business works," it's a real Key Result. Run this question against your full list, not just the ones that already feel shaky; the ones that pass without hesitation are usually obvious, and the ones that make you pause are the ones worth rewriting.