The OKR system is very scalable. I would argue some sort of tool for managing and aligning work is critical to scaling effectively, but it's also true that many companies do struggle with scaling their use of OKRs.
In this chapter, I shine a light on what needs to change as you use the OKR system at scale. Remember that I'm just talking about the product and technology organization here (product management, user experience design, and engineering), and while you can use the techniques I'm about to describe at any scale, I am focused here on growth stage or enterprise organizations.
With startups or small organizations, when everyone essentially knows what everyone else is doing and why, it's normal for each product team to propose their objectives and key results. There's some amount of give and take, and then people get to work. With larger organizations, product teams need more help.
The first help they need is a very clear understanding of the organization‐level objectives. Let's say that the top two objectives for the company are to improve customer lifetime value and expand globally. Let's also say you have on the order of 25 product teams. All the product teams likely have thoughts on both of these organizational objectives, but, clearly, the company will need to be smart about which teams pursue each objective. Some teams might focus on only one, others might contribute to both, and yet other teams may be tackling critical work beyond those two objectives.
Leadership (especially the head of product, head of technology, and head of design) will need to discuss the company objectives and which teams are best suited to pursue each objective.
Moreover, at scale, it is very common to have some significant number of product teams that are there in support of the other product teams. These are often called platform product teams, or shared services product teams. They are very high leverage, but they are a little different in that they generally don't directly serve customers. They serve customers indirectly, usually through the higher‐level, solution‐focused product teams. These platform teams will get requests from most or even all the higher‐level product teams, and they are there to help them succeed. But, again, leadership will need to help coordinate the objectives for these teams and make sure we coordinate the dependencies and align the interests.
Once you have your objectives, there is a very critical reconciliation process in which the leadership team looks at the proposed key results from the product teams and identifies gaps and then looks to what might be adjusted to cover those gaps (for example, enlisting the help of additional teams or reviewing the priority of the work).
At scale, it's much harder to know what product teams are working on which objectives and the progress they are making. There are now a variety of online tools that help organizations make the objectives transparent to the organization. But even with these tools, we lean on management to help connect the dots between teams.
The larger the organization, the longer the list of high‐integrity commitments that are needed, and the more actively they need to be managed and tracked. Delivery managers play a key role in tracking and managing these dependencies and our commitments.
When using OKRs at scale, there's a larger burden on leadership and management to ensure that the organization is truly aligned, that each and every product team understands how they fit into the mix, and that they are there to contribute.
In many enterprise scale organizations, there are essentially multiple business units, and in this case, we would expect that there are corporate level OKRs, but there would also be business unit\endash level OKRs, and the product teams would roll up into those.
In summary, when using OKRs at scale, there's a larger burden on leadership and management to ensure that the organization is truly aligned, that each and every product team understands how they fit into the mix, and what they are there to contribute.