Team OKR

Origin & evolution

The method came from Andy Grove at Intel in the 1970s, who took Peter Drucker's Management by Objectives and added measurable Key Results, an approach he called iMBO and documented in High Output Management (1983) (What Matters). John Doerr learned it in Grove's Intel course in 1975, carried it to Google in 1999, and later wrote *Measure What Matters* (2018), which made OKRs standard vocabulary across the industry.

The defining debate at the team level is cascade versus align. The traditional cascade treats a higher Key Result as the next level's Objective, building a strict tree from the top down. The practical complaint is that the tree is brittle: any change at the top forces every team beneath it to rebuild, and teams end up connecting their work to a parent Key Result for the sake of the diagram (Tability). The alignment camp, argued among others by Jeff Gothelf, keeps a few company objectives fixed and lets teams set their own OKRs that respect the intent of those anchors rather than inherit their exact metrics🔢MetricStrategyA unified metric that measures progress, health, or behaviour across the productView reference →. Most organisations blend the two: cascade two or three strategic anchors, align the rest horizontally.

The second long-running tension is output versus outcome🏆OutcomeStrategyA desired business or user outcomeView reference →. A Key Result like "ship the new onboarding flow" measures activity; "lift activation from 38% to 50%" measures a change in user behaviour. Grove's own framing favoured results over tasks☑️TaskProduct SpecificationA unit of work within a story or epicView reference →, and modern practice treats outcome Key Results as the standard a team OKR should reach for.

How it works in practice

The company holds one objective: become the default tool for solo product creators. A growth team sets a team OKR beneath it. Objective: new users reach value in their first session. Key Results: lift week-one activation from 38% to 50%, cut median time-to-first-graph from 14 minutes to 6, and raise the seven-day return rate from 22% to 30%. None of these is inherited verbatim from the company objective; the team chose metrics it can actually move, and aligned them to the intent. Two of the three are outcomes (behaviour changed), one is a leading proxy. At cycle review the team scores 0.6 on activation and 0.9 on time-to-value, and the conversation is about the gap, not about whether the document matched the parent.

Team OKR vs. its neighbours

• Objective is the qualitative aim, the direction. The team OKR is the whole package, one Objective plus its Key Results, owned by a specific team for a specific cycle. The same word does double duty, so the graph keeps the company-level objective and the team's commitment as distinct nodes.
• Key Result is one measurable component of an OKR. A team OKR contains several. A Key Result on its own, with no Objective above it, is a metric with a target, not a goal.
• Team is the group that owns and is judged on the OKR. The OKR belongs to the team for the cycle; the team persists across cycles. One team targets one set of OKRs at a time, which is what keeps focus from fragmenting.

In the graph

In the Unified Product Graph, team_okr🏅Team OKRTeam & OrganisationA team-level OKR is a leaf in the Operations & Quality region, team_org domain. Three edges encode the double-binding that defines it: a team owns its commitment through team_targets_team_okrTeamtargetsTeam OKRhierarchy, and the OKR aligns upward through team_okr_aligns_with_objectiveTeam OKRaligns withObjectivecross-domain and team_okr_aligns_with_key_resultTeam OKRaligns withKey Resultcross-domain. Modelling alignment as an explicit edge, rather than forcing a strict parent hierarchy, is the graph taking a side in the cascade-versus-align debate: a team OKR can connect to a company objective or to a higher Key Result while remaining the team's own, and you can query whether any team OKR is orphaned, aligned to nothing the company actually committed to.