In most organizations there usually is some form of cross-functional team building the product. There are also “horizontal” or “services” disciplines designed to work across these teams and other verticals to provide a specific function or skill. These could be designers (a sadly all-too-common anti-pattern), platform engineers, data scientists and communications specialists, to name a few. While the product teams can create straightforward OKRs related to what they’re building, these services disciplines struggle to adopt OKRs that they feel make sense for not only what they do but how they deliver their work.
“We’re not really on the team.”
I was speaking with a client’s communications and marketing team recently as they shared their struggle with coming up with goals that made sense for them. “We’re not really on any of the project teams,” they told me. “We support them when they need us and then we move on to another project. How do we account for our contribution to the project in an OKR?”
I heard the same thing from a design leader. “How do we set OKRs for the design portion of the work?” In both cases OKRs felt irrelevant to the discipline-specific team because they, and the organization, saw their work as a service being provided to the overall initiative rather than an integral part of the success of that initiative.
Option 1: Make the product better
When we think about these horizontal disciplines as service providers there are only two ways their work can be accounted for with Objectives and Key Results. The first option is to include them as part of the product development team’s goals. In other words, the product team’s OKRs are the service team’s OKRs as well. The designers, communication folks or platform engineers function as a real part of the product team. Their goals are the team’s goals. They win or lose together. There is no division between the “product” goals and the “service team” goals. They work together, as a cohesive unit, to make the product better.
OKRs are a team-based goal setting method. One of the key benefits of using this method is to build that team mentality and shared purpose. When we carve out discipline specific goals we divide the team. We break the shared purpose and alignment. The result is teams that are optimizing locally for the work they’re doing. A designer could say, “I did my 5 revisions and 3 usability tests and the customers we spoke with gave the work a strong thumbs up.” At this point the designer has washed their hands clean of the product and the way it’s implemented, deployed, marketed and ultimately used by customers is not important to them. They “did their work.” The feasibility of their work is not something they’re concerned about because their goal is to deliver good design work. This is how they’re measured.
Option 2: Make the discipline team better
The other option for discipline team OKRs is to set internally-facing goals designed to make the team itself better. For example, you could set an objective to make the communications team the “most desirable communications team in your industry.” You could set key results that measure things like retention of current employees and referrals of new employees from existing team members. The goals set this way focus on creating a great practice, regardless of which product the team works on.
In this case, the goals make a better organization. Ultimately that organization should help make better products. Though in this case we’re only measuring the health of the discipline.
Both options at the same time
These two options are not mutually exclusive. You can set internally facing goals while also having your team members work with their cross-functional colleagues to make better products. In fact, this is the way you should work. This way you’re not only making the product better but you’re also continuously assessing how well you’re leading your specific discipline and how you can improve it.
P.S. — While the idea of services disciplines is common, in my experience this is an anti-pattern. Our goal should always be to build cross-functional, self-sufficient teams. When parts of the process are essentially “outsourced” (or in-sourced?) to part-time disciplines we break shared understanding, alignment and efficiency. Avoid this anti-pattern if you can.