Key results · How-to

Key results that add up: splitting one goal across teams

How to break one number into parts that genuinely sum, including ratios and the dependent ones.

A company key result for the year says “grow ARR from $4M to $10M”. Six teams write key results that support it. At the end of the year, every team hits its target, and the company still misses. This happens constantly, and it’s almost always arithmetic, not effort. Here’s how to split a number so the parts genuinely add up to the whole.

Key takeaways

  • First decide what kind of metric it is. Additive metrics sum, ratios are weighted averages, and dependencies contribute without summing.
  • Decompose the parent into a driver tree, for example net new ARR = new business + expansion − churn.
  • Give each slice one owner and size it to that owner’s realistic share, not an even split.
  • Plan child targets to cover a little more than 100% of the parent, because some slices will miss.
  • Link every child key result to its parent so progress rolls up automatically.

Why team key results don’t add up by default

When each team writes its OKRs separately, three things go wrong:

  • Gaps. Nobody owns churn, so the company loses $1M of ARR that no team had a key result to prevent.
  • Double counting. Sales and Marketing both count the same $2M of bookings.
  • Mismatched units. Marketing measures leads, Sales measures meetings, and the company measures ARR. None of them convert cleanly into the others.

The fix is to split the number deliberately, from the top, before teams write their own OKRs around their slice.

Step 1: classify the metric

TypeExamplesHow children combine
AdditiveRevenue, bookings, deals, sign-ups, hires, cost savingsChildren sum to the parent.
Ratio / rateConversion, win rate, retention %, uptime, NPSA weighted average, by each child’s volume.
Thresholdp95 latency, time to hire, security findingsThe parent is as good as the worst child, or a percentile across them.
Dependent“Ship SSO” enabling enterprise bookingsContributes to the parent but doesn’t sum. Link it and name the dependency.

Step 2: decompose it into a driver tree

Write the parent as a formula of things specific teams control. For ARR growth:

Net new ARR = new business + expansion + self-serve − churn

To go from $4M to $10M, the company needs $6M of net new ARR. Suppose last quarter’s data suggests churn of about $1M is likely without intervention. Then gross additions need to reach $7M.

GROSS ADDITIONS · $7.0M New business +$4.0MSALES Expansion +$1.8MCUSTOMER SUCCESS Self-serve +$1.2MPRODUCT · GROWTH CHURN · −$1.0M (CUSTOMER SUCCESS HOLDS IT HERE) NET NEW ARR · COMPANY KEY RESULT +$6.0M · ARR $4M → $10M
A driver tree for one company key result. $4.0M + $1.8M + $1.2M of gross additions, minus churn held at $1.0M, gives exactly the $6.0M the company needs.

Step 3: size each share to the owner, not evenly

An even split (“three teams, $2M each”) ignores how different the channels are. Size each slice from its own baseline and capacity:

  • Start from the run rate. If new business closed $0.8M last year, $4.0M of new bookings this year needs a capacity story to match: more ramped reps, more pipeline, a better win rate. Without one, the target is a wish.
  • Check capacity. Quota per rep × ramped reps, expansion potential in the installed base, trial volume × conversion.
  • Cover more than 100%. If every slice is sized to exactly hit the parent, any single miss sinks it. Many teams plan child targets to add up to 105–115% of the parent.
OwnerKey resultBaselineTargetContributes
VP SalesNew mid-market bookings (ARR)$0.8M$4.8M+$4.0M
Head of CSExpansion ARR$0.3M$2.1M+$1.8M
Head of GrowthSelf-serve ARR$0.4M$1.6M+$1.2M
Head of CSGross churn (ARR), held at or below$1.3M$1.0M−$1.0M
Company: net new ARR+$6.0M

Step 4: handle ratios with weights, not sums

Ratios are where most roll-ups quietly break. Say the company key result is “trial-to-paid conversion from 10% to 14%”, and two segments run trials:

SMB · 600 TRIALS 10% → 60 paid MID-MARKET · 400 TRIALS 20% → 80 paid COMPANY · 1,000 TRIALS 140 paid = 14% not 10% + 20% = 30% not (10% + 20%) ÷ 2 = 15%
Ratios are weighted averages. Company conversion depends on each segment’s rate and its share of volume, so a segment’s ratio target only makes sense next to its volume.

Two rules follow. Set ratio targets per segment together with the volume they apply to. And remember that shifting mix moves the company number even when no segment improves: more mid-market trials alone would lift company conversion here.

Step 5: link the dependent ones

Some of the most important contributions don’t add numerically. Product shipping SSO doesn’t produce ARR by itself, but enterprise bookings can’t happen without it. Treat these as contributing key results:

  • Link them to the parent so the relationship is visible.
  • Measure the outcome they unlock where possible (“deals blocked on SSO from 9 to 0”), not just delivery.
  • Name the dependency in the dependent team’s objective: “Depends on: SSO in production by week 6.”

Common mistakes when splitting key results

  • Even splits. Equal targets across unequal teams guarantee some are sandbagged and others impossible.
  • Forgetting the negative terms. Churn, refunds and attrition subtract. Someone needs to own holding them down.
  • Summing ratios. As above, weight them by volume.
  • Unit drift. If the parent is ARR, child key results that roll up should be ARR too, not “leads” or “meetings”. Those make good leading indicators within a team’s own OKR.
  • Splitting at the last level only. Do the arithmetic at each level, so a VP’s slice is split across their managers the same way.

How OKR.ai keeps the numbers honest

In OKR.ai a key result can roll up into a super key result, usually your manager’s, so each child’s movement contributes to the parent. When you push OKRs to your reports, AI splits them so they cover the parent with no gaps and little overlap. It sizes additive targets to each owner’s realistic share, treats ratios as contributing rather than summed, and writes dependencies into the objective description. You review and edit every number before anything is saved.

See how it works in the OKR workflow docs, or start with the basics in how to write good OKRs.

Frequently asked questions

Should child key results add up to exactly 100% of the parent?

Aim a little higher, often 105–115%, so the parent still lands if one slice misses. Make the buffer explicit so nobody mistakes it for padding.

How do you roll up a percentage key result like uptime?

Uptime and latency don’t sum. Either give the company metric to one owner with contributing key results underneath, or define the parent as a weighted average or a worst case across services.

What if a team’s work supports several parent key results?

Link its key result to the one it moves most, and mention the others in the description. Counting it under several parents is how double counting starts.

Who should do the split, the manager or the team?

Both. The manager proposes the split from the parent target; each owner checks it against their own baseline and capacity and pushes back with data.

Report a bug

What would you like to send?

Sent privately to the OKR.ai team, with this page’s address.