6 Principles for Truly Effective OKRs (Part 2)
By: João Craveiro
Tags: Cross Functional Teams, Service Design, Product Management, Okr, Agile

We have closed Part 1 saying that your Key Result should be measurable. But let’s remind ourselves of an old riddle.

— Five frogs are sitting on a log. Four decide to jump off. How many are left? — Five. There’s a big difference between deciding and doing.

#4) Check In Regularly

It’s not enough to be able to measure your OKRs: you have to really do it. At the very least once a month, you should check in on your OKR scores. This means sharing your current OKR scores (and a high-level summary of what was done to impact those):

within the cross-functional team, and

outside the cross-functional team.

You don’t need to send an email announcement to everyone (in fact you actually shouldn’t), but you must store them somewhere easily accessible to everyone. At Onfido we have all the teams’ OKRs in one place, and I highly recommend that.

Inside the team that owns the OKR, you should naturally check in more regularly than this, in good spirit of Inspect and Adapt. This shouldn’t be a struggle, or too much additional work — if it is, probably there’ something off related to either:

Rule #2 (outcome-oriented key results); and/or

Rule #3 (measure once, cut twice).

Your OKR scores should map directly from a single source of truth about a KPI that, in theory, is already your bread and butter. For instance, at some point, the Service side of our team were checking in on the reopen Key Results weekly: they came up with a roster, so that every Friday one of the team would be responsible for getting the scores and sharing them with the whole team — along with what was done to influence that Key Result, and what’s next.

As much as meetings get a bad reputation, we did also find value in having a regular formal alignment meeting. Cross-functional collaboration should not (and in our case didn’t) only happen at regular checkpoint meetings — but these certainly help ensure alignment and focus. “But why do you have to meet regularly if you collaborate frequently?”, you may ask. Because…

#5) Extreme Cross-Functionality: Involve Stakeholders

…it’s a great opportunity to open up to people with whom you don’t collaborate so frequently. Let your stakeholders in!

Photo by Philipp Berndt on Unsplash

We iterated both the frequency and the format of this meeting, but the one that ultimately stuck was a weekly 30 minutes session with representatives from:

Technology (product / engineering);

Service (service management and applicant support);

Client Services (account management).

Each of these functions adds one slide beforehand to a shared deck, to be used as a backdrop. That slide contains the previous week’s highlights (or lowlights…) regarding their function:

Technology update on what was released / is in the works— and the observed / expected outcomes;

Service on applicant support and quality control trends/issues;

Client Services bring any ups or downs regarding key accounts.

After reviewing action items from the previous alignment meeting, each slide gets a 5 minute timebox; if some issue deserves more discussion, the key people involved get together afterwards to discuss and act. At the end, we keep action items to check upon on the following week. The combination of both constraints (1 slide, 5 minutes) helps everyone focus on what matters — outcomes rather than outputs, as we’ve seen in Part 1 — so that the meeting doesn’t derail into a mere status update or wish list exchange ceremony.

With this format, we create a healthy relationship with our stakeholders, namely Client Services — one based on collaboration. This makes it even easier to take it to the next level when a certain problem requires collaboration beyond:

the 30 minutes window; and

a circle of 1–2 representatives per function.

We went full-on in this direction on one specific occasion, by running a journey workshop, mostly based on Harry Brignull’s article (in our case we skipped the empathy mapping because we already had our persona defined beforehand from an earlier initiative). We wanted to absorb all the collective knowledge, so for this one we got together:

all members of this product development team (engineers, QA, designer);

all the people in the Service function (service management and applicant support) who focus on this line of business;

all the people in the Client Services team who focus on clients in this line of business.

By going through what applicants need to step through, but also how they feel throughout the process (both about Onfido and about the needs and struggles that bring them to having to do a check with Onfido), we identified opportunities based on their outcome for the applicant.

Final board of our user journey workshop (© 2018 Onfido)

These opportunities are then the basis for product discovery, where we engage other techniques (such as opportunity solution tree) to both prioritise opportunities and generate ideas for product experiments to achieve the intended outcomes.

#6) Make Learning Safe

As I’ve mentioned in Part 1, we work in cross-functional, mission-driven and long-lived teams at Onfido.

That’s an essential building block to make learning safe — the team needs to have all the skills necessary to both generate assumptions and prove them right or wrong. Without this, any experiment to learn more requires cross-team coordination, making experimentations (and learning) not only riskier but more expensive.

After having skills-wise autonomous teams in place, an organisation needs to make it okay to get to the end of a quarter with a 0.0 result in an OKR. Of course you don’t want to keep doing it, but when it happens it should lead to a conversation along the lines of “what happened?”, or “what have we learned?” — not “what the hell have you been doing here all quarter, anyway?”.

There are two common pitfalls regarding OKRs that deserve a place as “subrules” of this principle.

Don’t Use OKRs for Performance Review

There’s a whole array of reasons why good OKRs simply won’t work as performance gauges.

If you use OKRs for performance review, you’ll just be inviting people to game the system. We’re humans—if you, as a team, are responsible by defining your own OKRs and you know they put you on the line (performance-wise), guess what? Your OKRs will soon become oriented to outputs (which is something you can control) or to “low-hanging fruit” outcomes — lo and behold, 1.0 across the board, yay! If OKRs are not used for performance review, there’s really no incentive to try and game the system — you’ll only be fooling yourself. If you’re worried that an OKR shared across functions won’t show if one function is not “pulling their weight” and is just coasting on the work other functions are doing, then you have a deeper problem than OKRs can solve.

If OKRs are made to serve their purpose as a means to keep everyone focused on the team’s north star, they are susceptible to external factors. As we’ve seen in Part 1, product development starts with assumptions, and is about experimenting to (dis)prove those assumptions. This means you won’t always get it right from the outset, so it’s not like the number will steadily go up—which is another indicator that OKRs are not right, not only for performance assessment, but as a measure of any kind of output progress measure.

Don’t Use OKRs for Project Management / Progress Tracking

There will be the odd occasion when your team is overtaken by work whose success is almost entirely dominated by one measure: getting it done. This was the case for the first two quarters I was in the Hire team (the two quarters prior to the ones I highlighted in Part 1). We weren’t trying to move any needle, we just needed to transpose a regulatory change into our product by a certain deadline—the outcome was the output!

The temptation to use an output-driven OKR to track progress is strong. Back then, neither us as an organisation nor me individually were as mature in using OKRs as we are now—so guess what: we did have an output-driven OKR for that.

There’s a name for this kind of work: it’s a project, so you should manage it as such, and use appropriate means to track its progress, risks, etc.. OKRs don’t capture these nuances, and in turn they can absorb factors not related to the project—so don’t shoehorn it into OKRs just because it sounds cooler than project management and Gantt charts. If that output-driven project is taking up your whole team for one entire quarter, you should feel safe in your organisation to say “we don’t have an OKR this quarter, we need to get this project done”.

But beware: don’t let that become your default mode. As a product team, working according to a predetermined plan for a predetermined output should be an exception, not the rule—since most of the time you don’t know what you don’t know. When you’re done with such a project, you can and should come back to outcome-driven OKRs, and getting there by quickly and safely making assumptions and learning by testing them.