> For the complete documentation index, see [llms.txt](https://jamiewen00.gitbook.io/tech-lead-handbook/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://jamiewen00.gitbook.io/tech-lead-handbook/product/okrs.md).

# OKRs

## The What

* Objectives are **ambitious** and may feel somewhat uncomfortable
* Key results are measurable and should be easy to grade with a **number**

## The How

### Leadership team

As an engineering lead, you might be part of the leadership team in your department. You should be able to influence the OKRs settings at an early stage. Help LT assess the feasibility and opt-out unrealistic expectations.

* Set up objectives
* Define key results
* Allocate capacity on a high level (e.g., development buckets)

### Delivery team

As an engineering lead, you are the key member of the delivery team, you should work with product managers, and help

* Revise the objectives and key results
* Break down into main themes or initiatives
* Provide feedback to the leadership team

### Stretch goal

* OKRs are not KPI
* OKRs are not BAU
* The “sweet spot” for an OKR grade is **60% – 70%** (according to Google re:Work)

## :white\_check\_mark: Exceptions

* The OKRs might look very different to a BAU team, an innovation team, or a platform engineering team

## :red\_circle: Red Flags

* Product Manager “owns” the OKRs (No, the team owns the OKRs)
* The leadership team assigns OKRs (No, the communication is two-way)
* OKRs are KPIs (No, OKRs are not related to performance review)
* OKRs are BAU (No, OKRs should be achievable with challenges)

## :scroll: Tips

* Tech Lead is a key contributor to OKRs settings
* Keep it high level
* Give the team space to run discovery and delivery

## :hole: Pitfalls

* Being granular
* Being prescriptive

### Ref

* OKRs 101: <https://www.whatmatters.com/get-started/>
* Google Rework: <https://rework.withgoogle.com/guides/set-goals-with-okrs>