OKR Alignment Models

okr-alignment-models.js

// Architectural Assumptions
// * Objectives don't align to other Objectives, they should be aspirational/motivational and unique
// * The total progress of an Objective averages this.keyResultsProgress + linked.keyResultsProgress
// * Mapping key results to parent KRs is strictly optional (although that is sort of the point!)
// * KRs may inherit multiple alignments but can only ever align themselves to a single parent

// For a good answer as to why we want one-to-many see the answer of "Can I align to multiple
// objectives?" taken from here: https://www.perdoo.com/blog/okr-and-alignment/

// Note: linking cells in sheets is trivial, so that gets around typical inheritance type problems.
// Anything we decide here would be imposed by us, not Google Sheets.

// average of all linked keyResults
const totalProgress = function (keyResults) {
  return keyResults.reduce((acc, val) => acc + val) / keyResults.length
}

// linking key results would use Google Sheet env magic/logic to link one cell to others
const linkKeyResults = function (keyResults) {
  return keyResults
}

// Company level OKR model
let companyObjectives = [
  {
    description: '',
    keyResults: [
      {
        description: '',
        progress: 10
      },
      {
        description: '',
        progress: 20
      }
    ],
    linked: {
      keyResults: linkKeyResults()
    },
    progress: {
      total: totalProgress([...this.keyResults, ...this.linked.keyResults])
    }
  }
]

// version one: link department level key results to parent objective
let departmentObjectives1 = [
  {
    description: '',
    // here, we align department KRs to company Objectives
    keyResults: [
      {
        alignedTo: companyObjectives[1],
        description: '',
        progress: 10
      },
      {
        alignedTo: companyObjectives[2],
        description: '',
        progress: 20
      },
      {
        alignedTo: null,
        description: '',
        progress: 30
      }
    ],
    linked: {
      keyResults: linkKeyResults()
    },
    progress: {
      total: totalProgress([...this.keyResults, ...this.linked.keyResults])
    }
  }
]

// version two: link department level key results to specific parent key results
let departmentObjectives2 = [
  {
    description: '',
    // here, we align department KRs to specific company KRs
    keyResults: [
      {
        alignedTo: companyObjectives[1].keyResults[1],
        description: '',
        progress: 10
      },
      {
        alignedTo: companyObjectives[3].keyResults[2],
        description: '',
        progress: 20
      },
      {
        alignedTo: null,
        description: '',
        progress: 20
      }
    ],
    linked: {
      keyResults: linkKeyResults()
    },
    progress: {
      total: totalProgress([...this.keyResults, ...this.linked.keyResults])
    }
  }
]

// version three: link department level key results to any key result
let departmentObjectives3 = [
  {
    description: '',
    // here, we align department level KRs to department and company KRs
    keyResults: [
      {
        alignedTo: companyObjectives[1].keyResults[1], // here, we align to a company KR
        description: '',
        progress: 10
      },
      {
        alignedTo: departmentObjectives2[2].keyResults[3], // here, we align to a sibling KR
        description: '',
        progress: 20
      },
      {
        alignedTo: null,
        description: '',
        progress: 20
      }
    ],
    linked: {
      keyResults: linkKeyResults()
    },
    progress: {
      total: totalProgress([...this.keyResults, ...this.linked.keyResults])
    }
  }
]

module.exports = {
  companyObjectives,
  departmentObjectives1,
  departmentObjectives2,
  departmentObjectives3
}

OKR Alignment Models

Out of all of these possible alignment models, I would argue version two is the most flexible while remaining true to the "OKR spirit", and it is the model we use at Comgy.

Pros

• allows department objectives and key results to stand alone, if necessary (no alignment option)
• by aligning key results, and not objectives, it doesn't force department level objectives to align to a single C-level Objective, but instead contribute to multiple different C-level objectives simultaneously*
• many-to-one-parent model keeps KRs clean and targeted at a single parent level KR while allowing objectives to be far-reaching/creative

Cons

• many-to-one-parent model means key results cannot align to siblings, and there may be some cases where aligning to another department's key result makes sense (admittedly hard to think of)

*This is often how most departments work, i.e. the operations department in some companies might contribute to different financial key results as well as workplace culture/internal satisfaction key results, which would likely fall under two seperate C-level objectives, but might fall under a single department level objective.

Closing Thoughts

All models assume that objectives should not align to other objectives (up, down, or sideways) since if key results are the bread and butter of objectives, why spend any time aligning the leftovers?