From "one fair metric" to "a fair metric per team"
You can now write a good OKR (b2) and judge whether a metric is fair to grade on (b3). The problem is that a company does not have one metric - it has a tree. Cartwheel's revenue decomposes into Sessions × Conversion Rate × Average Order Value, and each branch splits again into levers that different teams own. Tonight you give every function an Objective and two to three Key Results on a lever it controls, with a note on why that lever is fair for that team. Then the attribution rule: the shared North Star is watched jointly, never dropped on one team's scorecard. The linchpin still holds - none of these scores feed pay.
Decompose the North Star, then hand out the branches 7 min live
The e-commerce metric tree is the map. Revenue per visitor is the trunk; it factors into sessions, conversion, and order value; each factor breaks into levers a specific team can move. Fairness comes from handing each team the branch it controls - not the trunk.
LiveControllability is the fairness test for a branch3 min▶
A branch is fair to grade a team on only if the team can actually move it. Two quick checks:
- Does the team hold the lever? Growth owns spend and channel mix, so CAC and ROAS are fair. Growth does not own the checkout page, so grading Growth on site conversion rate is measuring someone else's work.
- Is the lever mostly free of other teams' effects? The cleaner the ownership, the fairer the grade. Where two teams share a lever, either split it into sub-levers each can own, or move it up to the "watched together" line.
The conversion-rate blame game. Before the tree, Cartwheel graded Growth on conversion rate. Growth drove more traffic, conversion dipped (new visitors convert lower), and Growth "failed" for succeeding. The tree fixed it: Growth owns sessions and traffic quality; Product owns the conversion of that traffic. Same company, two fair grades instead of one unfair one.
DORA for Engineering, joint ownership for the North Star 6 min live
Engineering is where bad metrics do the most damage. Counting lines of code rewards bloat, punishes deletion, and - now that AI generates code by the screenful - measures almost nothing. The DORA metrics measure the flow of value instead, and they are self-checking: speed is held honest by stability.
Self-studyThe attribution rule - watch the shared outcome, grade the lever2 min read▶
The North Star - revenue per visitor, or overall conversion - is moved by everyone at once. That is a feature, not a bug: it forces teams to pull together. But it makes the shared number impossible to attribute fairly, so the rule is firm:
- Grade each team on its controllable lever. Product on checkout completion, Growth on CAC, Ops on on-time delivery. These are clean enough to be fair.
- Watch the North Star jointly. Put revenue per visitor on a shared dashboard every team sees, discussed together in a cross-functional review. No one is graded on it alone; everyone is accountable to it together.
HBR's guidance is the same at the team level: set OKRs for teams, not to rank individuals. Shared outcomes belong to shared conversations, not to one person's scorecard.
A fair OKR for every Cartwheel function ★ 14 min · everyone tries
The centrepiece of the whole track. For each function, give it an Objective, two or three Key Results on a lever it controls, and a one-line note on why that lever is fair for that team.
For each function, find its branch on the tree from Part 1 - the lever it actually holds.
Write an Objective that points at that branch, then 2-3 Key Results as measurable outcomes (from b2).
Add the controllability note: one line on why this team, and not another, should be graded on this.
| Function | Objective | Key Results (the lever) | Controllability note |
|---|---|---|---|
| Growth / Marketing | Bring in efficient, high-intent traffic | CAC ↓, ROAS ↑, non-paid sessions ↑ | Owns spend + channel mix; does NOT own site conversion |
| Product / UX | Turn more visitors into buyers | Conversion rate ↑, checkout completion ↑, activation ↑ | Owns the on-site experience the visitor moves through |
| Engineering | Ship value fast and safely | Deploy frequency, change-failure rate, p75 page load | DORA, self-checking; never lines of code |
| Operations / Fulfilment | Deliver reliably at the right cost | On-time delivery ↑, cost per order ↓, inventory turns ↑ | Owns the warehouse + carrier levers, not demand |
| Support / CX | Resolve issues well, first time | CSAT ↑, first-response time ↓, first-contact resolution ↑ | "Tickets closed" alone is gameable; pair with quality |
| Merchandising | Grow basket value and healthy margin | AOV ↑, category margin ↑, sell-through ↑ | Owns assortment + pricing mix, not site traffic |
Fix Engineering: swap lines-of-code for the DORA four ★ 8 min · do your own
Cartwheel's old engineering scorecard graded lines of code shipped per sprint. Replace it with a fair system and score both against the b3 checklist.
Name the bad metric and its failure: lines of code is an activity count, trivially gamed (verbose code, no deletion), and now inflated by AI code generation.
Replace it with the DORA four as a system: deploy frequency and lead time for speed, change-failure rate and time-to-restore for stability - plus p75 page load as the user-facing outcome.
Score the old and the new against the six-point fair-metric checklist from b3.
| Check (from b3) | Lines of code | DORA four + p75 load |
|---|---|---|
| Outcome not activity | ✗ pure activity | ✓ flow + stability outcomes |
| Controllable | ◐ but meaningless | ✓ team owns its pipeline |
| Hard to game | ✗ trivially inflated | ✓ speed checked by stability |
| Holistic | ✗ one number | ✓ speed + stability + user speed |
Goodhart, twice over. The moment Cartwheel made lines of code a target, engineers wrote more verbose code and stopped deleting dead code - the metric went up while the codebase got worse. Then AI assistants arrived and any developer could generate thousands of lines in an afternoon, making the number meaningless as a measure of anything. DORA survives because it measures the outcome (value flowing safely to users), not the typing.
Try it yourself - this week ◐ 30-45 min total
- Draw your own company's metric tree: what is the North Star, and what two or three factors multiply into it?
- For each of your teams, write an Objective and 2-3 Key Results on a lever that team controls, plus the controllability note.
- Find one metric a team is graded on that it does not fully control. Split it into sub-levers, or move it to the watched-together line.
- If you manage engineers, replace any activity count (lines, commits, story points as output) with the DORA four plus one user-facing outcome.
- Optional: read the DORA metrics overview (dora.dev) and the HBR piece "Use OKRs to Set Goals for Teams, Not Individuals" before b5.
Sources covered (cited)
Taught from the e-commerce measurement canon plus engineering and team-OKR sources. This session covers:
Three questions before you go 🎯 ◐ 90 seconds
1 · Why is grading Growth / Marketing on site conversion rate unfair?
Controllability is the fairness test. Growth owns CAC, ROAS, and traffic quality. Conversion of that traffic is Product's lever. Grade each team on the branch it actually holds.
2 · What makes the DORA metrics a fair, self-checking system for Engineering?
Deploy frequency and lead time measure speed; change-failure rate and time-to-restore measure stability. You cannot rush deploys without failure rate rising to expose it. Lines of code, by contrast, rewards bloat and is inflated by AI code generation.
3 · How should the shared North Star (revenue per visitor) be handled?
The North Star is moved by everyone, so it cannot be attributed to one team fairly. Grade each team on its lever; watch the shared outcome together in a cross-functional review. Shared outcomes belong to shared conversations.