OKRs are NOT guaranteed deliveries

Objectives and key results are a great tool for collaborative goal-setting and for aligned on a company-wide direction. While the key objectives or north-stars might be handed down from C-level management, the concrete objectives and key-results are discovered by the teams. Only they know best, how to achieve the bigger goals of the company. Thus, all teams needs to figure out, how they can best contribute to the company goals.

This is a very valuable process, as it gives teams a lot of clarity about the company direction and also the next bigger topics they have to work on. Furthermore, OKRs, in a condensed form, are easy to communicate and therefore help to build cross-team and company-wide understanding of “who is working on what”. Aligning the OKRs helps to avoid doing the same work twice in different teams and surfaces opportunities for closer collaboration.

OKRs should be challenging, ambitious, and measurable. Furthermore, the team should feel comfortable to commit to them. Team members should at least believe that they could be possible to achieve the goals together. Moreover, the team needs to be convinced that the OKRs are valuable.

A commitment is not a guarantee

Things get complicated, when OKRs are taken for guaranteed. If you have quarterly OKRs in your company and people rely on certain OKRs to be done after three months, this greatly limits the agility of teams and therefore their ability to do the right thing.

Thus, even though teams should be committed to the OKRs they define, they should as well be willing to throw them over-board, if they learn more throughout the quarter and therefore see a better way to take. Often, teams would learn during the quarter and discover some obstacles or some important tasks that need to be done first, to achieve the higher company goal. Furthermore, sometimes critical topics come up or opportunities to generate more value for the company, if the team can take another path.

If, however, people relied on OKRs to be done at the end of the quarter, the teams have no other opportunity than blindly pushing through the OKRs, knowing that they are not working on the most valuable task.

The commitment should be more for the team itself as a motivational aspect than for people outside the team as something to rely on.

But we need to rely on something…

Especially, marketing and sales teams are usually hunting for something cool and new that they can announce and promise to customers as coming soon, ideally with a set-in-stone delivery date. Furthermore, they prefer to announce it some time ahead to create a “I want this” effect in customers. Ideally, customers look forward to the release date like a small child is waiting for Christmas.

How does this work together? Relying on unfinished feature-deliveries is dangerous, as it puts the team into a situation, where they have to deliver or otherwise would disappoint customers and colleagues. Rolling out new features just as they are ready makes it difficult for marketing and customer success teams to prepare the rollout. They might want to announce the upcoming change to customers, prepare documentation and create some excitement for the upcoming feature.

Delaying the rollout of a finished feature just so these teams have enough time to prepare also does not make sense, as it delays real end-user feedback, needed by development teams to iterate on the feature.

However, there might be a compromise in the middle. How about immediately rolling out new features to some customers, while delaying the major rollout until the preparations in marketing and customer success are done?

New features could be rolled out to very loyal, curious or maybe tech-savvy customers first. Usually, those people like to be special and to get the hot new thing before everybody else. For the majority of customers, the feature would be rolled out with some delay. The feature is already in production, and proven to work as intended, and there is no danger in promising it to customers.

This also fits perfectly with the practice of using release toggles to decouple deployments and releases. Ideally, these toggles give you the flexibility to release a new feature to some but not all customers at a time.

Summary

OKRs should help teams to find the right direction and necessary autonomy to work independent for some time (i.e, a quarter). They should motivate the teams to give their best while working towards their goals.

However, they should not be set-in-stone. Teams still should be flexible enough to change their course as soon as they learn about a better path. Other teams should not rely on unfinished work and on certain OKRs to be done at a given time.

Delaying rollouts of finished features to the majority of customers could be an approach to satisfy both sides, the development teams and the marketing or customer success teams.

How are you using OKRs in your company? What are your experiences? Share them here in the comments or via LinkedIn or Twitter.