The OKR technique has enjoyed considerable success, especially inside technology product organizations, from large to small. And there have been some very important lessons learned as teams and organizations work to improve their ability to execute.
OKRs are a very general tool that can be used by anyone in the organization, in any role, or even for your use in your personal life. However, as with any tool, some ways of applying them are better than others.
Throughout this book, I emphasize the importance of a product team. Recall that a product team is a cross‐functional set of professionals, typically comprised of a product manager, a product designer, and a small number of engineers. In addition, there are sometimes additional people with specialized skills included on the team, such as a data analyst, a user researcher, or a test automation engineer.
Also recall that each product team typically is responsible for some significant part of the company's product offering or technology. For example, one product team might be responsible for mobile apps for drivers, another for mobile apps for riders, another might be responsible for secure payment handling, and so on.
The key is that these people with their different skill sets usually come from different functional departments in the company, but they sit and work all day—every day—with their cross‐functional team to solve hard business and technology problems.
It's not unusual in larger organizations to have on the order of 20 to 50 of these cross‐functional product teams, each responsible for different areas, and each product team with its own objectives to work on.
For companies using the OKR system, the problems these teams are asked to tackle are, as you might expect, communicated and tracked through the product team's OKRs. The OKRs also help to ensure that each team is aligned with the objectives of the company.
Moreover, as an organization scales, OKRs become an increasingly necessary tool for ensuring that each product team understands how they are contributing to the greater whole, coordinating work across teams, and avoiding duplicate work.
The reason this is so important to understand is that when organizations first start with OKRs, there's a common tendency to have each functional department create their own OKRs for their own organization. For example, the design department might have objectives related to moving to a responsive design; the engineering department might have objectives related to improving the scalability and performance of the architecture; and the quality department might have objectives relating to the test and release automation.
The problem is that the individual members of each of these functional departments are the actual members of a cross‐functional product team. The product team has business‐related objectives (for example, to reduce the customer acquisition cost, to increase the number of daily active users, or to reduce the time to onboard a new customer), but each person on the team may have their own set of objectives that cascade down through their functional manager.
Imagine if the engineers were told to spend their time on re‐platforming, the designers on moving to a responsive design, and QA on retooling. While each of these may be worthy activities, the chances of solving the business problems that the cross‐functional teams were created to solve are not high.
If you deploy OKRs for your product organization, the key is to focus your OKRs at the product team level.
What all too often happens in this case is that the people on the product teams are conflicted as to where they should be spending their time. This results in confusion, frustration, and disappointing results from leadership and individual contributors alike.
But this is easily avoided.
If you deploy OKRs for your product organization, the key is to focus your OKRs at the product team level.
This means don't let functional team or individual person OKRs confuse the issue.
Focus the attention of the individuals on their product team objectives. If different functional organizations (such as design, engineering, or quality assurance) have larger objectives (such as responsive design, technical debt, and test automation), they should be discussed and prioritized at the leadership team level along with the other business objectives, and then incorporated into the relevant product team's objectives.
Note that it's not a problem for managers of the functional areas to have individual objectives relating to their organization. This is because these people aren't conflicted, as they're not normally serving on a product team.
For example, the head of UX design might be responsible for a strategy for migrating to a responsive design; the head of engineering might be responsible for delivering a strategy around managing technical debt; the head of product management might be responsible for delivering a product vision; or the head of QA might be responsible for selecting a test automation tool.
It's also not normally a big problem if individual contributors (such as a particular engineer, designer, or product manager) has a small number of personal growth‐related objectives (such as improving their knowledge of a particular technology). This assumes the individual isn't committing to a burden that will interfere with their ability to contribute their part to their product team, which of course is their primary responsibility.
The key is that the cascading of OKRs in a product organization needs to be up from the cross‐functional product teams to the company or business‐unit level.