Skip to main content

Designing Your Organization's OKR Model

Guide for OKR program administrators on choosing organizational models, diagnosing structural problems, coaching team leaders, and determining which configuration settings your organization needs.

Updated over a month ago

The Administrative Challenge

As an OKR program administrator, you're not just creating your own goals. You're designing the structural framework everyone else will use. Your configuration decisions, coaching approach, and organizational design determine whether teams get clarity or confusion. Get the model wrong, and you'll spend quarters untangling misaligned hierarchies, mixed time periods, and frustrated team leaders who can't figure out how their goals fit together.

The challenge is multi-layered. You need to understand your organization's strategic planning rhythm, how teams actually work together, where formal hierarchies matter versus where cross-functional collaboration drives outcomes, and how to translate all of that into a coherent OKR structure. Then you need to configure Rhythms to support that structure while coaching team leaders through implementation.

This article provides the frameworks, organizational design patterns, and configuration guidance you need to build an effective OKR model for your organization.

Who Should Read This

This article is for:

  • OKR program administrators responsible for organizational OKR model design

  • Executives and senior leaders setting strategic direction for the OKR program

  • Organizational effectiveness leaders implementing goal-setting frameworks

Looking for something else?

What This Article Covers

  • Your role and unique responsibilities as program administrator

  • Understanding your organizational context before choosing a model

  • Organizational design patterns matched to common use cases

  • Diagnosing and fixing structural problems in existing programs

  • Practical coaching guidance for team leaders

  • Configuration decision logic linking organizational needs to product settings

  • Implementation principles for successful adoption

  • Using Rhythms to validate and improve structure

Prerequisites:

Your Role as OKR Program Administrator

As program administrator, you occupy a unique position. You're responsible for the scaffolding everyone else builds upon.

What Makes Your Role Different

Individual contributors and team owners work within the structure you create. They ask: "How do I align my goals to what exists?"

You ask: "What structure should exist in the first place?"

This means you're responsible for:

1. Organizational Design Decisions

  • Should company goals be annual, quarterly, or both?

  • How many organizational levels should have explicit OKRs?

  • Where do formal teams end and virtual/cross-functional teams begin?

  • What's the maximum acceptable hierarchy depth?

2. Configuration Choices

  • Should initiatives be able to align to Key Results?

  • Should teams be able to create goals with multiple parents?

  • Should initiative progress affect parent progress calculations?

  • What alignment patterns best match how your organization works?

See Model Customization: Configuring Alignment and Contribution Rules for technical configuration details.

3. Coaching and Enablement

  • Helping team leaders structure their goals effectively

  • Diagnosing and fixing structural problems

  • Teaching teams when to create Objectives versus Key Results

  • Guiding appropriate time horizon selection

4. Program Health Monitoring

  • Identifying structural anti-patterns across the organization

  • Spotting misaligned goals and broken hierarchies

  • Ensuring organizational capacity isn't over-committed

See Reports in Rhythms: Monitoring and Improving OKR Program Health for monitoring tools.

The Key Principle for Admins

Your job isn't to create all the goals. It's to create the conditions where teams can create good goals themselves.

This means:

  • Setting organizational defaults that work for 80% of cases

  • Enabling flexibility for the 20% that need different patterns

  • Providing clear examples and coaching for common scenarios

  • Monitoring for structural problems and intervening early

Understanding Your Organizational Context

Before choosing a design pattern or making configuration decisions, understand your organizational reality. Answer these questions to identify which pattern fits your context.

Question 1: What's Your Strategic Planning Rhythm?

How far ahead can you set meaningful, measurable goals?

  • Annual planning is stable and valuable → Consider company annual goals

  • Quarterly is as far as we can predict → Consider company quarterly goals

  • We do both (annual strategic, quarterly execution) → Consider annual + quarterly at company level

Why this matters: Your planning rhythm determines appropriate time horizons. Don't force annual goals if your market changes too quickly for annual predictions to be meaningful.

Question 2: What's Your Organizational Structure?

How many layers exist between company leadership and execution teams?

  • Two levels (Company → Teams) → Standard hierarchical pattern likely fits

  • Three+ levels (Company → Divisions/BUs → Teams) → Enterprise divisional pattern likely fits

  • Matrix (multiple reporting dimensions) → Matrix pattern likely needed

  • Mostly project-based (teams form and reform around initiatives) → Project-driven pattern likely fits

Why this matters: Your structure pattern should match how your organization actually works, not impose an artificial framework.

Question 3: How Do Teams Collaborate on Shared Work?

When multiple teams work on the same initiative:

  • Rare (most work is team-specific) → Standard single-parent alignment works

  • Common (frequent cross-functional initiatives) → Multi-parent alignment likely needed

  • Constant (matrix organization reality) → Multi-parent alignment essential

Why this matters: This determines whether you need multi-parent alignment configuration.

Question 4: How Does Your Organization Measure Success?

What proves an objective was achieved?

  • Outcome metrics (revenue, customers, satisfaction, performance) → Keep default contribution settings (KRs contribute, Objectives/Initiatives don't)

  • Project delivery (shipping features, completing programs) → Consider enabling Initiative contribution

  • Mixed (both outcomes and delivery matter) → Consider enabling Initiative contribution

Why this matters: This determines your contribution configuration decisions.

Organizational Models: Which Structure Fits Your Organization

Choose the model that matches your organizational context from the questions above.

Model A: Most Organizations (Standard Hierarchical)

When to use:

  • Clear company → team → sub-team hierarchy

  • Two organizational levels between company leadership and execution

  • Most tech companies, mid-market B2B, professional services firms

Time Horizon Flexibility:

Your organization can use annual, quarterly, or both at each level based on planning needs:

Company Level Options:

  • Annual + Quarterly (most common): Annual objectives for planning stability, quarterly objectives for execution checkpoints

  • Quarterly only: Maximum agility when annual predictions aren't reliable

  • Annual only (rare): When very long planning cycles are needed

Team Level Options:

  • Quarterly (most common): Execution focus with regular adaptation

  • Annual + Quarterly: Annual team plans with quarterly execution, useful when coordinating with company annual cycles

  • Annual only: When team outcomes take full year to achieve

Constraint: Teams can't have annual goals if company only has quarterly (nothing to align annual goals to at company level)

Structure (Comprehensive - showing all possible elements):

Company Annual Objectives (3-5 maximum)
  ├─ Company Annual Key Results
  │   [Update: Connected to data sources]
  │   [Contributes to Company Objective: Yes]
  │
  ├─ Company Quarterly Objectives (optional checkpoints)
  │   [Aligned to: Company Annual Objectives]
  │   [Contributes to parent: No]
  │   │
  │   └─ Company Quarterly Key Results
  │       [Update: Connected to data sources]
  │       [Contributes to Company Quarterly Objective: Yes]
  │
  ├─ Company Annual Initiatives (year-long programs)
  │   [Update: Often conceptual bundles of work]
  │   [Note: Annual initiatives represent programs, not single trackable projects]
  │   [Contributes to Company Objective: No]
  │   │
  │   └─ Child Initiative: "Q1 Foundation Phase"
  │       [Aligned to: Parent Annual Initiative]
  │       [Update: Connected to Jira - specific quarterly project]
  │
  └─ Team Annual Objectives (when teams benefit from annual planning)
      [Aligned to: Company Annual Objectives]
      [Contributes to parent: No - different altitudes]
      │
      ├─ Team Annual Key Results
      │   [Update: Connected to data sources]
      │   [Contributes to Team Annual Objective: Yes]
      │
      ├─ Team Quarterly Objectives (execution cycles)
      │   [Aligned to: Team Annual Objectives]
      │   [Contributes to parent: No]
      │   │
      │   └─ Team Quarterly Key Results
      │       [Update: Connected to data sources]
      │       [Contributes to Team Quarterly Objective: Yes]
      │
      └─ Team Quarterly Initiatives
          [Aligned to: Team Quarterly Objectives or Team Annual Objectives]
          [Update: Connected to project trackers]
          [Contributes: No]

Time Horizon Combinations in Practice:

Company Annual + Team Quarterly (most common)

  • Company: Annual objectives for stability, optional quarterly checkpoints

  • Teams: Quarterly execution aligned to annual company goals

  • Use when: Company can plan annually, teams need quarterly adaptation

Company Annual + Team Annual (both with quarterly)

  • Company: Annual objectives with quarterly checkpoints

  • Teams: Annual objectives with quarterly execution cycles

  • Use when: Both levels benefit from annual planning continuity

  • Provides maximum stability while enabling quarterly adaptation at both levels

Company Quarterly + Team Quarterly

  • Company: Quarterly objectives only

  • Teams: Quarterly objectives aligned to company

  • Use when: Market too uncertain for annual predictions (startups, rapidly evolving industries)

Why this initiative structure: Annual initiatives often represent programs of work rather than single trackable projects. By creating child initiatives for quarterly phases (each connected to actual project tracker work), you maintain the conceptual annual program while enabling execution tracking at the quarterly level. This requires Initiative-to-Initiative alignment (check your configuration).

Configuration needs:

  • Default: Standard alignment rules work for most cases

  • Consider: Enable Initiative-to-KR alignment if teams need to tie specific work to specific metrics

  • Consider: Enable Initiative-to-Initiative alignment if using annual program + quarterly phase pattern

  • Contribution: Keep defaults (KRs contribute, Objectives/Initiatives don't)

Coaching guidance:

  • "Your team goals should support our company goals. Choose annual, quarterly, or both based on your planning needs and how your work aligns to company time horizons."

  • "Connect your Key Results to data sources for real-time tracking whenever possible"

  • "If using different time horizons than company (e.g., quarterly team goals with annual company goals), your progress won't mathematically roll up to company metrics, but the strategic alignment should be clear"

Model B: Large Enterprises with Divisions

When to use:

  • Multi-level organizational structure (Company → Divisions/Business Units → Teams)

  • Divisions have P&L responsibility or functional autonomy

  • Need coordination across divisions toward company goals

  • Large corporations, global companies with regional divisions

Structure:

Company Annual Objectives (3-5 maximum)
  ├─ Company Annual Key Results
  │   [Update: Connected to data sources or rollup from divisions if Obj-to-Obj contribution enabled]
  │   [Contributes to Company Objective: Yes]
  │
  └─ Division Annual Objectives
      [Aligned to: Company Annual Objectives]
      [Contributes to parent: Potentially yes if divisions compose company - see configuration guidance]
      │
      ├─ Division Annual Key Results
      │   [Update: Connected to data sources or rollup from teams]
      │   [Contributes to Division Objective: Yes]
      │
      └─ Team Quarterly Objectives
          [Aligned to: Division Annual Objectives]
          [Contributes to parent: No - different time scales]
          │
          ├─ Team Quarterly Key Results
          │   [Update: Connected to data sources]
          │   [Contributes to Team Objective: Yes]
          │
          └─ Team Quarterly Initiatives
              [Aligned to: Team Quarterly Objectives]
              [Update: Connected to project trackers]
              [Contributes to Team Objective: No]

Configuration needs:

  • Consider: Enable Objective-to-Objective contribution if divisional Objectives mathematically compose company Objectives

  • Multi-parent: May be needed if matrix reporting exists alongside divisional structure

  • Terminology: Might need custom terminology

Coaching guidance:

  • Division leaders: "Your annual objectives should translate company goals to your division's scope of responsibility"

  • Team leaders: "Your quarterly execution supports divisional annual targets"

  • Watch for: Divisions creating disconnected strategies versus supporting company strategy

Model C: Matrix Organizations

When to use:

  • Multiple reporting or accountability structures simultaneously

  • Product lines × Functions × Geographies organizational model

  • Initiatives genuinely serve multiple objectives across dimensions

  • Need to track both vertical and horizontal alignment

Structure:

Product Line Objectives (Vertical Dimension)
  └─ Product A Quarterly Objective: "Achieve Product A market fit"
      ├─ Product A KR: "Reach 2,000 Product A customers"
      │   [Update: Connected to data source - Product A customer segment]
      │   [Contributes to Product A Objective: Yes]
      │
      └─ Product A KR: "Product A monthly retention > 85%"
          [Update: Connected to data source - Product A retention metrics]
          [Contributes to Product A Objective: Yes]

Functional Objectives (Horizontal Dimension)
  └─ Engineering Quarterly Objective: "Build scalable platform"
      ├─ Engineering KR: "Support 100K concurrent users"
      │   [Update: Connected to data source - platform load metrics]
      │   [Contributes to Engineering Objective: Yes]
      │
      └─ Engineering KR: "Platform uptime > 99.9%"
          [Update: Connected to data source - uptime monitoring]
          [Contributes to Engineering Objective: Yes]

Geographic Objectives (Third Dimension)
  └─ APAC Quarterly Objective: "Establish APAC market presence"
      ├─ APAC KR: "Achieve profitability in APAC region"
      │   [Update: Connected to data source - APAC regional financials]
      │   [Contributes to APAC Objective: Yes]
      │
      └─ APAC KR: "Win 50 APAC customers across all products"
          [Update: Connected to data source - APAC customer tracking]
          [Contributes to APAC Objective: Yes]

Cross-Cutting Initiative: "Build APAC Product A Infrastructure"
  [Aligned to: Product A Objective - serves product line]
  [Aligned to: Engineering Objective - builds platform capability]
  [Aligned to: APAC Objective - enables geographic expansion]
  [Update: Connected to project tracker]
  [Contributes to any parent: No - unless configured otherwise]
  │
  ├─ Sub-Initiative: "Design APAC-specific Product A features"
  │   [Aligned to: Parent initiative]
  │   [Update: Connected to Jira]
  │
  └─ Sub-Initiative: "Build APAC data infrastructure"
      [Aligned to: Parent initiative]
      [Update: Connected to Jira]
  
  Each parent Objective views this initiative through different lens:
    - Product A: Does this enable our product in APAC?
    - Engineering: Does this prove platform scales globally?
    - APAC: Does this enable market entry for Product A?

Configuration needs:

  • REQUIRED: Enable multi-parent alignment (matrix structure demands this capability)

  • Consider: Enable Initiative contribution if work delays should surface across all aligned dimensions

  • Governance: Establish clear primary versus secondary parent designation for resource allocation decisions

Coaching guidance:

  • "Identify which parent is primary for this goal - where does budget and decision authority ultimately sit?"

  • "Be highly selective with multi-parent alignment - not everything needs it, only work that genuinely serves multiple strategic dimensions"

  • "Multi-parent goals require extra coordination and communication about shared ownership"

Model D: Project-Driven Organizations (Virtual and Cross-Functional Teams)

When to use:

  • Cross-functional teams assembled for specific strategic outcomes

  • Teams don't necessarily align with formal org chart

  • Strategic initiatives span multiple departments

  • Consulting firms, agencies, innovation-focused companies with fluid team structures

Structure:

Company Annual Objective: "Transform customer experience"
  ├─ Company Annual KR: "Achieve NPS score > 70"
  │   [Update: Connected to data source - NPS survey system]
  │   [Contributes to Company Objective: Yes]
  │
  └─ Virtual Team Quarterly Objective: "Redesign core customer workflows"
      [Aligned to: Company Annual Objective]
      [Team owner: Designated leader from any department]
      [Team members: Cross-functional contributors from product, design, engineering]
      [Contributes to parent: No - different time scales]
      │
      ├─ Team Quarterly KR: "Launch 5 redesigned workflows"
      │   [Update: Manual tracking or connected to project management]
      │   [Contributes to Virtual Team Objective: Yes]
      │
      ├─ Team Quarterly KR: "Achieve 90% workflow adoption rate"
      │   [Update: Connected to data source - product analytics]
      │   [Contributes to Virtual Team Objective: Yes]
      │
      └─ Team Quarterly Initiative: "Customer journey mapping and redesign"
          [Aligned to: Virtual Team Quarterly Objective]
          [Update: Connected to Jira - project status]
          [Contributes to Virtual Team Objective: No]

Configuration needs:

  • Default: Standard settings work

  • Team setup: Consider creating teams in Rhythms that don't necessarily mirror org chart

  • Permissions: Ensure virtual team owners can create team-level goals

  • Consider: Multi-parent if virtual teams serve multiple company objectives

Coaching guidance:

  • "Virtual teams operate like formal teams in Rhythms - same structure, just different organizational context"

  • "Assign clear ownership even though team doesn't appear on org chart"

  • "When the initiative completes, virtual team may disband - close goals, document learning, and archive the team"

  • "Virtual team members may also have goals in their formal team structure - that's normal and expected"

Diagnosing Structural Problems in Existing Programs

If you're working with an existing OKR program, use these diagnostic tests to identify issues before redesigning or refining your model.

Test 1: Structural Integrity

What to check:

  • Every goal tree starts with an Objective (not orphaned KRs or Initiatives)

  • Key Results never appear as children of Initiatives

  • Every Objective has at least one Key Result defining success

How to diagnose: Prompt Rhythms: "Analyze our organizational OKR structure and identify objectives without defining Key Results"

Common issues:

  • Objectives with only child Objectives (no KRs defining the parent)

  • KRs incorrectly nested under Initiatives

  • Orphaned goals not connected to any parent

How to fix:

  • Add defining Key Results to any Objective before it has child Objectives

  • Restructure KRs to align to Objectives only

  • Connect orphaned goals or archive if no longer relevant

Test 2: Time Horizon Coherence

What to check:

  • Goals at the same hierarchical level share time horizons

  • No mixing of annual, quarterly, and multi-year KRs as peers

  • Time horizons generally match organizational altitude (company annual/quarterly, teams quarterly)

How to diagnose: Prompt Rhythms: "Show me goals with mixed time periods at the same hierarchical level"

Common issues:

  • Annual Objective with peer KRs labeled "2026", "Q1 2026", "Q2 2026"

  • Teams with 5-year goals (wrong altitude)

  • Quarterly checkpoints incorrectly structured as peer KRs instead of child Objectives

How to fix:

  • Restructure so each Objective has KRs at one time horizon

  • Create child Objectives for different time periods

  • Adjust team time horizons to match their altitude (typically quarterly for execution teams)

Test 3: Organizational Capacity

What to check:

  • Company level has 5 or fewer Objectives (forces clarity and prevents resource fragmentation)

  • Teams aren't over-committed with excessive objectives

How to diagnose: Prompt Rhythms: "Identify teams with more than 5 objectives"

Common issues:

  • Company with 8-10 objectives (resources spread too thin)

  • Teams with 7+ objectives (lack of focus)

How to fix:

  • Consolidate related objectives

  • Elevate some objectives to strategic context (documented but not active in Rhythms)

  • Challenge: "If we could only achieve 5 of these, which prove our strategy is working?"

Test 4: Data Source Connectivity

What to check:

  • Key Results connect to data sources when metrics exist in systems

  • Preference for automation over manual updates

  • Appropriate use of automatic rollup for parent Objectives

How to diagnose: Review Key Results using manual updates - are these metrics available in connected systems?

Common issues:

  • KRs manually updated when data exists in Salesforce, analytics platforms, or databases

  • Missing integration opportunities

  • Over-reliance on manual check-ins

How to fix:

  • Enable integrations for commonly tracked metrics

  • Connect KRs to data sources (see Setting Up Auto-Updates)

  • Reserve manual updates for truly qualitative or judgment-based goals

Test 5: Hierarchy Depth

What to check:

  • Most goal trees are 2-3 levels deep

  • Each level has defining Key Results (not just Objectives nesting into Objectives)

How to diagnose: Prompt Rhythms: "Find goal trees deeper than 3 levels in our organization"

Common issues:

  • 4-6 levels of pure Objective nesting

  • Measurements only appearing at the deepest level

  • Confusion about where success is actually defined

How to fix:

  • Add Key Results to intermediate levels

  • Flatten by reducing unnecessary Objective nesting

  • Ensure each Objective is defined before cascading deeper

Coaching Team Leaders: Common Scenarios and How to Help

Your teams will encounter structural challenges. Here's how to guide them through common situations.

Scenario 1: "We Have 15 Key Results and It's Overwhelming"

What you'll see:

Team Objective: "Improve product quality"
  ├─ KR 1: "Bug count < 10"
  ├─ KR 2: "Test coverage > 90%"
  ├─ KR 3: "Performance score > 95"
  ├─ KR 4: "Security audit passed"
  ... (11 more KRs)

The problem: Too many Key Results signals the Objective is too broad or teams are tracking everything instead of focusing.

How to coach:

  1. Ask: "If you could only achieve 3-4 of these, which would prove you improved product quality?"

  2. Those 3-4 become your Key Results

  3. The rest either:

    • Become Initiatives (if they're work to do)

    • Move to separate focused Objectives (if they're different outcomes)

    • Get eliminated (if they're not essential to this Objective)

Restructured:

Objective: "Improve product quality"
  ├─ KR: "Customer-reported bugs < 10 per month"
  │   [Update: Connected to bug tracking]
  ├─ KR: "Product performance score > 95"
  │   [Update: Connected to performance monitoring]
  ├─ KR: "Pass security audit with zero critical findings"
  │   [Update: Manual - annual audit result]
  ├─ Initiative: "Expand test coverage to 90%"
  │   [Update: Connected to Jira]
  └─ Initiative: "Implement automated testing pipeline"
      [Update: Connected to Jira]

Scenario 2: "Our Goals Are Nested Too Deep Without Measurements"

What you'll see:

Company Objective
  └─ Division Objective
      └─ Department Objective
          └─ Team Objective
              └─ Sub-team Objective
                  └─ KR (finally!)

The problem: Objectives nesting without Key Results creates confusion about where success is actually measured.

How to coach:

  1. "Each Objective needs its own Key Results before nesting deeper"

  2. Ask at each level: "What specific outcomes prove success at THIS level?"

  3. Flatten the structure by adding measurements at each level

Restructured:

Company Annual Objective
  ├─ Company Annual KRs (define company success)
  │   [Update: Connected to data sources]
  │
  └─ Division Annual Objective
      ├─ Division Annual KRs (define division success)
      │   [Update: Connected to data sources]
      │
      └─ Team Quarterly Objective
          └─ Team Quarterly KRs (define team success)
              [Update: Connected to data sources]

Now you have 3 levels instead of 6, and each level has clear measurements.

Scenario 3: "We're Mixing Multi-Year, Annual, and Quarterly Goals as Peers"

What you'll see:

Strategic Initiative Objective
  ├─ 5-Year KR: "$60M revenue from new markets"
  ├─ 2026 Annual KR: "$8M revenue"
  ├─ Q1 2026 KR: "$2M revenue"
  └─ Q2 2026 KR: "$4M cumulative revenue"

The problem: Mixing time horizons at the same level makes it impossible to know when the Objective succeeds.

How to coach:

  1. "Rhythms works best with annual and quarterly execution cycles"

  2. "Keep your multi-year strategic context in planning documents, Objective descriptions, or strategic labels"

  3. "Structure in Rhythms should focus on executable annual and quarterly goals"

Restructured:

2026 Annual Objective: "Establish new market presence"
  ├─ Annual KR: "Achieve $8M revenue from new markets by end of 2026"
  │   [Update: Connected to data source - revenue system]
  │   [Description: "Part of 5-year $60M strategic expansion goal"]
  │   [Label: "Strategic Pillar: Market Expansion"]
  │
  └─ Q1 Objective: "Launch market entry program"
      └─ Q1 KR: "Grow from $0 to $2M revenue"
          [Update: Connected to same revenue data source]

Strategic connection approach: Use Objective descriptions to reference multi-year context. Use labels to tag which annual/quarterly goals connect to which strategic pillars or themes. This maintains strategic connection without creating multi-year time periods in the tool.

Scenario 4: "Teams Are Misidentifying Goals"

What you'll see (Variation 1 - Organizational units as objectives):

Objective: "European Sales Region"
  └─ KR: "€3M quarterly revenue"

Objective: "Manufacturing Division"  
  └─ KR: "$8M annual revenue"

What you'll see (Variation 2 - Metrics as objectives):

Objective: "Achieve $10M ARR"
Objective: "Reach 1,000 customers"

The problem:

  • Variation 1: Division/region names aren't outcomes. They're organizational units.

  • Variation 2: These are Key Results masquerading as Objectives. There's a missing higher-level Objective.

How to coach:

For Variation 1:

  1. "The organizational unit is the owner, not the goal itself"

  2. "What outcome does this unit want to achieve?"

  3. "Make the unit the team owner in Rhythms, write a real Objective describing success"

For Variation 2:

  1. "What's the broader outcome this metric proves?"

  2. That broader outcome is your real Objective

  3. The metric becomes a Key Result under it

Restructured (Variation 1):

European Sales Team Quarterly Objective: "Establish market leadership in Europe"
  [Team owner: European Sales Lead]
  ├─ Team KR: "Achieve €3M quarterly revenue"
  │   [Update: Connected to European sales data]
  └─ Team KR: "Win 25 new enterprise accounts"
      [Update: Connected to CRM]

Restructured (Variation 2):

Objective: "Build sustainable recurring revenue model"
  └─ KR: "Achieve $10M ARR"
      [Update: Connected to revenue system]

Objective: "Prove product-market fit at scale"
  └─ KR: "Reach 1,000 active customers"
      [Update: Connected to customer database]

Scenario 5: "We Don't Know If This Should Be a Child Objective or Another Key Result"

The decision framework to teach:

Ask the team these questions:

Question 1: "Does this need its own narrative about success, or is it just another measurement?"

  • Own narrative → Child Objective

  • Another measurement → Peer Key Result

Question 2: "Will multiple people organize their work around this specifically?"

  • Yes, multiple people → Child Objective

  • No, it's one metric → Key Result

Question 3: "Does this use different metrics than the parent?"

  • Different metrics → Likely Child Objective

  • Same metric type → Likely Peer Key Result

Example coaching conversation:

Team: "Should 'Improve onboarding completion' be a child Objective under 'Improve customer retention' or another KR?"

You: "Will multiple people focus specifically on onboarding with their own metrics, or is it just one metric you're tracking?"

Team: "Well, design, product, and customer success all have onboarding work. We need to measure completion rate, time-to-value, and user satisfaction in onboarding."

You: "Then make it a child Objective. It's a focus area with its own success definition and multiple metrics. If it were just 'onboarding completion rate' as a single metric, that would be a KR under retention. But since it's a whole focus area, it needs its own Objective with those three KRs."

Configuration Decision Matrix

Your organizational patterns and coaching needs determine which Model Customization settings to enable. Use this decision logic to connect organizational reality to product configuration.

Decision 1: Should Initiatives Align to Key Results?

Enable Initiative-to-Key Result alignment when:

  • Teams frequently have initiatives that drive one specific metric

  • Work is often tightly scoped to individual Key Results

  • Example: "Database optimization" initiative specifically drives "< 100ms response time" KR

  • Annual initiatives with quarterly child initiatives need this for proper nesting

Keep default (Initiatives to Objectives only) when:

  • Initiatives broadly support multiple Key Results under an Objective

  • You want simpler structure with less nesting complexity

  • Most organizations start here and enable later if needed

Configuration impact: When enabled, teams can nest Initiatives under specific Key Results instead of only aligning to Objectives.

Decision 2: Should Multi-Parent Alignment Be Enabled?

Enable multi-parent alignment when:

  • Cross-functional work is common and significant

  • Matrix organization structure (product × function × geography)

  • Same initiative genuinely advances multiple unrelated objectives

  • You need shared metrics to appear in multiple contexts (company composition tracking + team primary metrics)

Keep default (single parent only) when:

  • Organizational structure is primarily hierarchical

  • You want clearer accountability (one owner per goal)

  • Multi-parent creates more complexity than value for your organization

Configuration impact: When enabled, one Initiative or Key Result can align to multiple parent Objectives. Each alignment is independent. The goal appears in tree view under each parent.

Decision 3: Should Initiatives Contribute to Parent Progress?

Enable Initiative contribution when:

  • Your organization measures success by project completion alongside outcome metrics

  • You want initiative progress percentages to affect parent progress calculations

  • Project-driven culture where shipping deliverables is a key success measure

Keep default (Initiatives don't contribute) when:

  • You want to maintain outcome focus (completing work doesn't automatically equal achieving outcomes)

  • Parent Objectives should measure success via Key Results only

  • You're following OKR best practices about separating activities from outcomes

  • Most organizations keep this default

Configuration impact: When enabled, initiative progress affects parent Objective progress calculations mathematically (as weighted average if configured). Note: Risk status in Rhythms is calculated by comparing actual progress to expected progress. A parent can show 'on track' even if critical initiative work is delayed, as long as overall progress percentage meets expectations. To understand initiative delays, you would need to review the initiative directly or check its connected work management tools. Contribution affects the math, not intelligent risk assessment.

Consider: Whether your organizational culture measures success by outcomes achieved or projects completed. Both approaches are valid for different contexts.

Decision 4: Should Objectives Contribute to Parent Objectives?

Enable Objective-to-Objective contribution when:

  • Divisional structure where division Objectives mathematically compose company Objectives

  • Example: Company Objective "Achieve market leadership" supported by Division A Objective "Lead enterprise segment" and Division B Objective "Lead SMB segment" - if these divisions truly compose total market coverage, contribution may make sense

  • You need automatic rollup across organizational altitude levels

Keep default (Objectives don't contribute) when:

  • Child Objectives represent activities or focus areas toward parent outcomes, not measurements themselves

  • Time horizons differ between parent and child Objectives

  • Most organizations keep this default

Configuration impact: When enabled, child Objective progress can roll up to parent Objective progress. Use carefully, as this requires child Objectives to be true subdivisions of the parent, not just supporting activities.

Decision 5: Custom Terminology

Consider custom terminology when:

  • Your organization uses established language different from standard OKR terms (Goals/Metrics, Outcomes/Targets)

  • Industry-specific terms resonate better with your culture

  • Change management: easing transition from existing goal-setting frameworks

Keep default terminology when:

  • Standard OKR language (Objective, Key Result, Initiative) is widely understood

  • You want consistency with external OKR resources and best practices

  • Most organizations start with defaults

Configuration impact: Changes labels throughout Rhythms UI to match your terminology. Doesn't affect underlying model, just how it's displayed and talked about.

See these articles for configuration:

Implementation Principles: Adopting Your OKR Model

Organizations come to Rhythms with OKR programs in various states (starting fresh, migrating from other tools, refining existing programs). Rather than prescriptive steps, here are principles for successful adoption regardless of your starting point.

Principle 1: Validate at Small Scale Before Org-Wide Rollout

Why this matters: Configuration decisions and structural patterns that seem right in theory may reveal issues in practice.

How to apply:

  • Test your model with 2-3 representative teams first

  • Choose a mix of team types (product, sales, operations, etc.)

  • Select leaders willing to provide candid feedback about what works and what doesn't

What to validate:

  • Can teams create well-structured goals without constant admin intervention?

  • Do alignment patterns make sense to team leaders?

  • Are data source connections working as expected?

  • Does automatic rollup produce meaningful progress calculations?

  • Do teams understand when to create Objectives versus Key Results versus Initiatives?

Adjust configuration and coaching approach based on pilot learning before broader rollout.

Principle 2: Start Simple - Company Structure with Default Configuration

Why this matters: Default settings work for most organizations. Over-configuring early creates unnecessary complexity.

How to apply:

Start with company structure:

  • Establish company-level Objectives and Key Results first

  • Follow your chosen pattern (annual + quarterly, quarterly only, etc.)

  • Connect company KRs to data sources before cascading

  • Limit to 5 company Objectives maximum

Start with default configuration:

  • Use standard alignment rules

  • Keep default contribution settings

  • Observe patterns during pilot and early rollout

  • Only enable additional features when clear organizational need emerges

When to enable features:

  • 3+ teams requesting "Can initiatives align to specific KRs?" → Consider enabling Initiative-to-KR

  • Heavy cross-functional work creating coordination needs → Consider multi-parent alignment

  • Teams measuring success by project delivery → Consider initiative contribution

Configuration should solve observed problems, not theoretical ones.

Principle 3: Provide Examples, Not Just Rules

Why this matters: Teams learn better from concrete examples than abstract principles.

How to apply:

Example prompts for teams to use:

  • "Show me an example of well-structured quarterly team goals"

  • "Help me structure goals that align to our company annual objectives"

Examples accelerate adoption more than documentation alone. Seeing working structure helps teams understand what "good" looks like faster than reading principles.

Principle 4: Monitor and Evolve

Why this matters: Structural problems compound over time. Your initial model won't be perfect. Both early intervention and continuous refinement are essential.

How to apply:

Monitor continuously:

Intervene selectively:

  • When patterns emerge (multiple teams making same mistake)

  • When structural anti-patterns appear (time mixing, missing KRs)

  • When teams explicitly request help

  • Don't micromanage individual team structures unless they violate core principles

Refine based on learning:

  • Collect feedback from team leaders quarterly

  • Observe which configuration options teams wish they had

  • Identify repeated coaching scenarios (signals where model needs clarity)

  • Adjust configuration, add examples, or provide targeted coaching

Expect evolution. The goal isn't a perfect model immediately. It's a model that improves as your organization learns how to use OKRs effectively.

Handling different starting states:

If migrating from another system:

  • Don't try to recreate your entire old structure perfectly in Rhythms

  • Take the opportunity to fix known structural problems during migration

  • Import company-level goals, let teams recreate their own (forces them to learn the model)

  • Use migration as a structural reset, not just data transfer

If refining an existing Rhythms program:

Using Rhythms to Validate Organizational Structure

As program administrator, you can use Rhythms to analyze structure at organizational scale. Combined with Views for filtering, Rhythms provides powerful diagnostic capabilities.

Diagnostic Prompts for Admins

Identifying structural issues:

  • "Analyze our organizational OKR structure and identify objectives without defining Key Results"

  • "Show me goals where time periods are mixed at the same hierarchical level"

  • "Find goal trees deeper than 3 levels"

  • "Identify teams with more than 5 objectives"

Assessing patterns:

  • "Evaluate whether our company-to-team alignment follows best practices"

  • "Show me which teams have unaligned goals"

  • "Identify initiatives that could benefit from multi-parent alignment"

Configuration validation:

  • "Based on our organizational structure, what Model Customization settings should we consider?"

  • "Are there alignment patterns we're trying to create that our current configuration doesn't support?"

Rhythms can analyze your entire organizational hierarchy and surface patterns you might miss when reviewing individual team goals.

Combining Views and Rhythms for Targeted Analysis

Workflow for analyzing specific teams or organizational segments:

  1. Use Views to filter to specific scope

  2. With filtered view active, prompt Rhythms to analyze just that scope

    • "Analyze this team's OKR structure and suggest improvements"

    • "Evaluate time horizon alignment for these goals"

    • Rhythms analyzes only the filtered goals, providing targeted diagnostics

  3. Review analysis and plan coaching approach

This filtered approach lets you:

  • Coach individual teams with specific, relevant analysis

  • Compare structures across similar teams

  • Identify patterns within organizational segments

  • Focus analysis on manageable scope instead of overwhelming yourself with entire org

Coaching Team Leaders Using Rhythms

When working with team leaders who need structural help:

  1. Prepare: Filter to their team's goals in a View

  2. Analyze: Prompt Rhythms - "Evaluate this team's goal structure and identify issues"

  3. Share: Rhythms identifies problems (mixed time periods, missing KRs, too deep nesting, too many objectives)

  4. Coach: Work through Rhythms suggestions with team leader, applying coaching scenarios from this article

  5. Validate: After restructuring, re-run analysis to confirm improvements

Example coaching conversation:

Team leader: "I'm not sure if our structure is right"

You: [Filter view to their team] "Let's have Rhythms analyze your structure"

Rhythms: Identifies 3 Objectives without Key Results, 2 cases of mixed time periods, 8 total objectives (over capacity)

You: "Here's what I'm seeing. Let's work through these together..." [Apply Scenarios 2, 3, and 1 coaching guidance]

This combines your OKR expertise with Rhythms pattern recognition to provide better coaching faster.

Frequently Asked Questions

How do I decide between annual and quarterly company goals?

If your organization can confidently set measurable annual targets and benefits from planning stability (budgeting, resource allocation, strategic coordination), use annual company goals paired with quarterly team execution (Model A, most common). If your market is too uncertain for annual predictions or you need maximum adaptability, use quarterly at all levels (Model A variation). Most mid-size to large organizations use annual + quarterly.

Should division-level Objectives contribute to company-level Objectives?

Only if divisional Objectives mathematically compose company Objectives. Example: If Division A Objective "Lead enterprise segment" and Division B Objective "Lead SMB segment" together equal Company Objective "Achieve market leadership", contribution may make sense. But if divisions represent different activities toward company outcomes (not true subdivisions), keep contribution off and use alignment only. Default is no contribution between Objectives. Enable intentionally after careful consideration.

How do I help teams that are new to OKRs?

Start them with Model A (Standard Hierarchical) using same time horizon as company (quarterly if company is quarterly, annual if company is annual). This is simplest to understand. Point them to Introduction to OKRs for framework basics and Creating OKRs and Initiatives in Rhythms for creation procedures. Coach them to limit objectives (3-5 maximum), define each with clear Key Results at the same time horizon, then add Initiatives for execution plans.

When should I enable multi-parent alignment?

Enable when cross-functional work is common and significant (Model C or D). Matrix organizations almost always need it. Project-driven organizations with virtual teams often benefit. Standard hierarchical organizations usually don't need it unless you want shared metrics to appear in multiple contexts. Multi-parent adds complexity, so only enable if the organizational value (showing shared work across multiple goals) outweighs the complexity cost.

What if teams want to structure their goals differently than our organizational model?

Some flexibility is healthy (different teams have different needs), but ensure they're following core principles: Objectives defined by KRs at same time horizon, appropriate time horizons for their altitude, clear alignment to organizational goals. If a team wants fundamentally different structure, understand why. They may be revealing limitations in your organizational model that need addressing, or they may be misunderstanding OKR principles (coach them back to fundamentals).

How do I know if my configuration is working?

Monitor using Reports (Reports in Rhythms: Monitoring and Improving OKR Program Health). High alignment coverage (>80%) signals structure is clear. Low coverage signals confusion. Run diagnostic tests quarterly. Listen for repeated questions from teams (signals where model isn't clear). Most importantly: Can teams create well-structured goals without constant admin intervention? If yes, your model is working.

Should I let teams customize their own alignment rules?

No. Model Customization is workspace-wide. This is intentional. Organizational consistency matters more than team-level preferences. All teams operate under the same alignment and contribution rules. This ensures goals connect coherently across the organization. If teams need exceptions, that signals your model might need refinement org-wide, not team-specific configuration.

What's the most common mistake administrators make?

Over-configuring too early. Start with default settings. Roll out to pilot teams. Observe what patterns emerge. Only enable additional configuration (multi-parent, Initiative-to-KR, Initiative contribution, Objective-to-Objective contribution) when you see clear organizational need. Default settings work for most organizations. Let configuration solve observed problems, not theoretical ones.

Related Articles

For Understanding OKR Fundamentals:

For Creating and Managing Goals:

For Monitoring Program Health:

For Configuration:

For Team Setup:

Did this answer your question?