Shared OKRs: The "secret" weapon to breaking down silos
One widespread piece of advice on OKR—and goals in general—is that you should “focus on goals that you can control alone.” Companies don’t want, for example, the marketing team to say that they didn’t achieve their OKRs because engineering didn’t do theirs, so they tell each team to focus on what they can control. The problem is that, by definition, this approach creates silos. If each team—or individual—focuses only on what they can control, every issue that requires cross-team coordination is stranded.
Whatever the organizational structure, there is always “white space” between different teams and departments. Companies need to learn to manage that white space, since we all depend on one another somehow, especially as companies scale. We need to enable teams to solve dependencies and work together on common priorities.
Shared OKRs align us around outcomes
That is why one of the underlying principles of OKR is that we align around outcomes, not silos. We start by thinking about what we want to achieve and then align our OKRs with other individuals or teams—even if they work in other functions, departments, or business units.
One of the underlying principles of OKR is that we align around outcomes, not silos.
Traditional approaches often focus on vertical alignment: ensuring that your goals align with your boss’s goals and with her boss’s goals, which can create silos. OKR focuses on 360º alignment - top, down, and sideways - eliminating silos and addressing interdependencies.
Shared OKRs are the most effective tool to create alignment between different teams or functions. In a shared OKR, two or more teams share the same OKR, but each one has different activities. You can either share the whole OKR (meaning the Objective and a set of Key Results), or you can share just a single KR.
When you decide on a shared OKR, you are creating an ad hoc team that will last as long as you have that shared OKR. Think of it as activating a "virtual squad" with all the teams/individuals required to achieve the shared OKR.
Defining shared OKRs
Keep in mind that OKR is not about everything that you do, so the small stuff does not need to be included on your shared OKRs. For example, if your marketing team wants to improve conversion rates on your website and needs engineers to complete certain activities, this means they’ve identified a dependency and need to solve it. If we are dealing with something small like changing a form, it usually means that the engineering team can track it as part of their day-to-day work and we don't need a shared OKR for it.
What would constitute a dependency that’s big enough to be considered a shared OKR between these two teams? Imagine if the marketing team was trying to increase usage of a feature, which would probably require not only promoting the feature but also improving it. Expanding the usage of that feature would be an excellent example of a shared OKR between marketing and a cross-functional product team (which usually also includes engineering and UX).
As another example, imagine that you worked as the recruiting manager of a large company. If everyone that had an open position decided to share that OKR with you, you could end up with dozens of Key Results, which misses the whole point of setting clear priorities. So hiring a single person would usually not be a shared OKR, while hiring 100 probably does need to be part of an OKR.
While we’re talking terminology, I’d like to mention that the terms “cross-functional” or “multi-disciplinary” OKRs can be misleading. Many dependencies exist inside the same function or department, which means we often need shared OKR inside the same function or discipline. The most common example is large product organizations where one product team depends on another, but that also happens inside other functions such as marketing, finance, or legal.
Deciding if shared OKRs are right for your organization
Creating alignment is one of the main reasons companies adopt OKR in the first place, but without shared OKRs they are merely playing alignment theater—giving off the illusion of striving for alignment—while continuing to work in silos as they always have.
Shared OKRs exist to solve dependencies. The more dependencies you have, the more you need shared OKRs. For example, companies organized around functional structures usually need a lot of shared OKRs, while companies using cross-functional teams or “squads" tend to have fewer dependencies and thus fewer shared OKRs. Dependencies always exist, so you always have some need for sharing OKRs.
Sharing is one of the hidden gems of the OKR world. It is a crucial concept, but few organizations use it well. People are so stuck in the silo mentality that once someone argued with me on Twitter that shared OKRs didn't exist and only gave up when I pointed him to the articles on my blog (check out Tips from an ex-Googler: Aligning Teams with Shared OKRs to read more on this topic).
The nuts & bolts of shared OKRs
Remember that a shared OKR creates an ad hoc team. Just like any other team, people who share an OKR should have regular check-ins to track results and adjust the corresponding activities "for the duration of the shared OKR,” which is often a quarter, but may vary depending on the complexity of the goal.
A shared OKR means that a group of people share ownership and accountability for it. People are obsessed with individual accountability over OKRs, but you can't use a one-size-fits-all approach. Some people play individual sports, and some people play team sports. If you play tennis, you have an individual scoreboard, but if you play basketball, you have a team scoreboard.
What matters is helping the team win. People who argue that you always need to have a single responsible individual seem to forget that people have played in teams since childhood and understand very well the dynamics of team accountability.
If you play tennis, you have an individual scoreboard, but if you play basketball, you have a team scoreboard. What matters is helping the team win.
A few pitfalls to avoid
The most common mistake is not using shared OKRs at all and not teaching employees how to use them. For the companies that are already using shared OKRs, I see a few common pitfalls.
The first one is failing to map all dependencies. Sometimes people assume that another team will be able to help without checking with the other team first. This usually does not end well. I have a great story about a team from Google Maps that failed to achieve their OKRs because they worked in silos and didn't share their OKRs.
The opposite mistake is also common: people want to share their OKR with everyone else in the company, which also misses the point.
Finally, sometimes companies create shared OKRs that are so big that diffusion of responsibility kicks in and individuals assume that others are responsible for taking action. That is why we always try to break down the shared OKRs into smaller chunks. If that is not possible, we may need a strong program manager to lead that shared OKR.