Big Rocks

the more widespread a term is, the less it holds to its original purpose - Weasel's law #4

Someone surely has claimed or discussed this phenomenom before. It’s why people who claim Agile doesn’t work aren’t actually following (m)any rules of Agile. It’s why people who have never used story points don’t like story points, it’s why the term “AI” means seven different things to five different people, and it’s why OKRs are a disaster…

…for most teams.

Obligatory Intro

OKRs (Objectives and Key Results) are a goal setting framework that came out of Andy Grove’s work at Intel in the 1970s. He discusss them in High Output Management, and there are numerous books on using them - but only two good ones I know of - Grove’s book, and one other that I’ll get to later..

OKR Hate

I’m going to guess that you probably hate OKRs. If you’ve had the experience of most people, you probably have a good reason to hate OKRs. People typically have terrible experiences with OKRs because they were asked to create OKRs not knowing how to start or why they’re doing them. They’re dropped on the team like a wet sack of flour with no justification. Worse are the situations where the org buys an “OKR Tool” to track them across the organization with the plan of building scorecards that show organizational progress…and fireworks and dancing unicorns, and…

…it’s awful.

Like other widespread terms in software and management, the term has blown up enough into different meanings - and has been implemented poorly enough times that telling your team to use OKRs is going to send them running into dark places.

The Trick is to Lie

I have had moderate success with OKRs in my career. I like them, and think they’re actually a pretty powerful tool. I've been most successful with OKRs when I’ve lied to my teams about using them.

In the same vein, I don’t like to tell teams, “We’re doing Agile” - too many bad tastes. Instead, I tell them that we’re going to work on building fast feedback loops into our processes, use frequent delivery to determine what the customer needs, and continuously adapt and improve. It’s way easier to get across when I just focus on the basics.

Similarly, my preferred approach to OKRs is usually the following brainstorm with my leadership team.

Q1: If our team does really well over the next six months (or whatever time frame is important), what changes? What’s different for our customers? What do we want to see happen?

I ask them to be slightly aspirational, but not too much. It’s always a good discussion (in the old days I’d make heavy use of stickies on a whiteboard), but shared notes in a video conference works really well too. I don’t like to have more than a few, so we may do some prioritization or voting, but in not too long of a time, we have a few “Big Rocks” we want to move. They can be things like, “Significantly enhance developer productivity via improved tools and development environments”, or even “Create a culture of continuous improvement and quality at <our company>.

Once we agree on a few Big Rocks, I ask another question:

Q2: What are a few things we can measure that will let us know if we’re pecking away at these big rocks. Sometimes when we do this, we tweak the Big Rocks. Sometimes we change the Big Rocks - but this part of the exercise is great for making sure we really understand what those big rocks mean.

There’s zero reason I can think of to tell people that these are OKRs.

Once people know that this exercise is about OKRs, they begin perusing the fifty million websites offering OKR tips (most miss the point), or they want to buy one of the ten thousand OKR tools available for purchase. There’s too much conflicting information and too much utter shit out there for this to be a good path.

There’s no joy in that, so I try to avoid it as much as I can.

Alignment and Clarity

I think a lot of orgs “do OKRs” for the sake of “doing OKRs”. A leader on the team creates shitty OKRs with no input from the team, they’re announced at an all-hands meeting, and never looked at again (please give this post a “like” or send me a dollar if you’ve seen this first hand - I could use the ego boost and money).

For me, the OKR process is about two things - Alignment and Clarity.

In the inital brainstorm I discussed above, the output is a set of OKRs (but remember, don’t call them that). More importantly, the outcome of that exercise is Alignment and Clarity. In the exercise, the entire leadership team has bought into a few slightly aspirational goals and in how we want to measure them. We’re clear on what we do, and aligned on how we want to get it done. It’s super-freaking powerful.

Rinse, Lather, Repeat

In The Advantage, Patrick Lencioni writes a lot about organizational health - and shares and discusses the concept in this graphic.

In short - get the leadership team aligned, create clarity on what’s important, then overcommunicate and reinforce clarity on what’s important.

Practically, this means that if you want OKRs to be successful, you should review them weekly with your leadership team. In Christina Wodtke’s wonderful business fable Radical Focus, she presents a one-slide (doc) format like this.

I’ve used this in the past, as well as slight variations / adaptations with a lot of luck. It’s a tool for driving conversation - do the priorities match with the objectives? Are we sacrificing team health in search of hitting a number? What is our confidence level?

It gets the team clearly aligned on what’s important, what we’re working on, and how it’s going. It gives the team alignment and clarity on how we’re accomplishing our biggest goals.

I still don’t tell anyone it’s OKRs. It’s a trap.

You Don’t Need Them

All that said, you don’t need OKRs. No team needs them. But your teams need clarity and alignment for sure, and one method that works is OKRs. I’m not at all fanatical about them - they’re just one tool in the toolbox - but I know how to use the tool, and I know how it works. For example, Lencioni doesn’t talk about OKRs at all, but he does emphasize the importance of clarity around the organization's purpose, values, and strategic priorities.

In the end, it comes down to the same thing I talk about a lot in these posts. You can tell your teams to do a bunch of work and see what happens, or you can work on building a culture where a bunch of work is guaranteed to happen. You do you.

-A 0:0