OKRs Don’t Solve Dependencies, They Reveal Them

Working with a multi-national financial services company last week the topic of dependencies came up repeatedly. As we were using OKRs to help teams determine the human behaviors they wanted their customers to change to ensure they were delivering value, the same concern appeared in many of their questions. “We can’t deliver this outcome on our own. We’re dependent on two other teams to do this.” The other version of this that was discussed regularly was the realization that setting key results in terms of their customers’ customers’ behavior (think B2B2C) was a losing proposition. They had no control over what their customers did with the products and services they bought before offering them to their own customers. There was too much risk to committing to key results and the teams were getting stuck.?

OKRs Make Dependencies Obvious

In the same way that OKRs don’t delivery our strategy for you, they also don’t resolve dependencies in large organizations. In fact, and perhaps frustrating for many enterprise teams, they end up exposing them. These dependencies are important to surface because they reveal sometimes well-known but little discussed constraints to delivering value to market quickly. Teams are regularly bogged down by a series of organizational demands and inefficiencies that make it impossible to get continuous improvement into customer hands. When a team takes on an outcome (or key result) as a goal they’re initially challenged to understand where that outcome takes place in the customer journey. Unless you’re working on the very first step your customers take when using your product, it’s important to understand where they’re coming from and where they’re headed to once they’ve completed their work in your part of the product.?

None of Us Work in a Silo

It doesn’t take very long for a team to recognize that as much as they’d like to believe they work autonomously, they rely heavily on the work of teams that come before and after them. Imagine for a minute that you work on the authentication team. Your team’s job is to optimize the user experience of authenticating into your system. You take on a key result of “reducing password failure rates by 90%.” As you start working towards this goal it becomes clear that the customer’s experience in the onboarding process (the part where they set up their account and relevant credentials) plays a huge role in whether or not the user is set up properly in the system, remembers their password and knows how to authenticate successfully. If the onboarding team doesn’t hit their goals, yours are going to suffer – no matter how easy it is to authenticate into your product.?

On the other side of the authentication workflow is not only the rest of the product experience but also support services like the call center team. They often take the brunt of the customer complaints when their passwords fail (or they can’t remember them). So while your team’s goal is to reduce the number of times your users fail to sign in, if they’re not set up properly when onboarded your goals will suffer. At the same time the call center is working to improve their work and your success in getting users authenticated is a dependency for them. None of us work in a silo.?

Forcing a Different Look at the Work

In the past you would have built your features, the onboarding team would have built theirs and the call center would have implemented its own processes and policies. Success would have been measured by the deployment of these features and policies. Now, however, working with OKRs has shown that none of these departments can succeed without a closer collaboration with the others. How you create that collaboration and build a cohesive user journey for your customers is not a small challenge. But, at least now, you’re aware that your success depends on your colleagues’ success as well. You have the justification and motivation to reach out to these other teams to understand their needs and discuss how you might work together so that everyone hits their dependent key result goals together.?

OKRs Aren’t a Silver Bullet but More of a Flashlight

The OKRs you put in place didn’t solve your dependency goals. That’s going to take a much bigger effort of organizational design and incentive structuring. What it did do, however, is reveal that these dependencies exist and, most importantly, that they create a significant threat to the success of the teams on their own. They push the organization towards a more transparent collaboration model. Your customers don’t care about your organizational design. The better we understand the dependencies in making their journey successful, the sooner we can get to work improving them.?