(Each week, I write a post about OKRs. You can see the series of posts here; if you have a question about OKRs you’d like to see me cover down the road, drop me a line.)
Over the last ten years, I’ve reviewed hundreds of draft OKRs for teams. There are any number of fairly obvious mistakes teams make when they’re first experimenting with OKRs, but three of most common that show up again and again are: 1) a lack of metrics that will help with grading at the end of a quarter, 2) an incremental approach to improvement that fails to codify ambition into the team’s goals, and 3) too many goals fragment the team’s energy and dilute their ability to achieve truly impactful outcomes.
But for teams that are lucky who avoid those pitfalls, it’s not necessarily smooth sailing. I’ve worked with a number of teams who found themselves with good grades at the end of the quarter, but were surprised to find themselves no better off than they were at the beginning of the quarter. (Or worse, they’d actually lost momentum, or even reversed course.) When that happens, it feels awful, and it’s natural to conclude that OKRs don’t work.
A few weeks ago, I wrote about binary OKRs, and said this:
Baked into many of these binary goals is a hypothesis: if we do this [ship/decide/develop], then this [other good thing] will happen. What you and your team should do is try to articulate what that other good thing is, and build your OKRs around that.
In my scenario above – good grades produced bad outcomes – one common culprit is that the key results focused on the first part of the hypothesis (we should do [x]), not the second (this good thing will happen). At the end of the quarter, they could honestly give themselves a good score – we did the thing! – only to find themselves wondering why the business hadn’t materially improved.
It helps to tell people to focus on the outcomes when writing OKRs, but that’s often easier said than done. When coaching the CEO of a security company a few years ago, I told him to approach his OKRs like he would a red team exercise: was it possible to succeed at the OKRs but do harm to the company? If so, approach that OKR like a vulnerability. Address the vulnerability by rewriting it – ensure that the objectives and their key results are impossible to be harmful if successfully achieved. If you eliminate the vulnerability, you improve your odds of a good grade at the end of a quarter aligning with the actual outcome you wanted to produce.
The lesson? When you’re reviewing your team’s draft OKRs going into a new quarter, think like a red team: could you actively harm the company by achieving the goals as written? How might a competitor phrase your OKRs to appear beneficial but that could actively inhibit the team’s progress? Putting on an adversarial hat when reviewing draft OKRs can help isolate and remediate problematic OKRs so that good grades are synonymous with momentum and progress at the end of the quarter.
One response to “Red Team OKRs”
Love the idea of the red team. We call it “specter of unintended consequences”, e.g. optimizing for revenue and leaving out customer satisfaction; optimizing for MAU without delivering user value; … The idea is always: “If I disregard the spirit of the objective, how can I game the key results to make me look good without actually having to do well.