TBM 309: Zombie Practices and Processes

The September 17th prioritization workshop sold out. To accommodate people in Melbourne, Auckland, Singapore, Hong Kong, and Tokyo, I launched a workshop during APAC business hours on October 3rd (2nd here in California). There are ~15 slots still open. Learn more here.

---

I recently ran an in-house OKR workshop. In ~20 minutes, I taught the group how to identify good and bad OKRs. By the end of the hour, the group of around thirty PMs, designers, and engineers was writing perfectly passable real-world OKRs. By minute ninety, the group was making good common-sense decisions on more advanced puzzles, like when a project delivery-oriented result might be OK, dealing with efforts with lots of dependencies, and identifying "early signals" when dealing with extra lagging effects.

We stopped for the day. Mission accomplished.

In theory, using OKRs is straightforward. Or, put another way, imagine you are part of a five-person startup, and together, you decide that setting goals in the OKR style is your thing. Very little (in theory) will stand in your way, even if you've never heard about or used OKRs. 

If all of this is true, why do companies have so many challenges with OKRs? Why do they treat them as yet another zombie process that no one particularly believes in or thinks about, yet continue "checking the box" quarter after quarter?

Or, backing up, why does the exact same dynamic happen with many things in products that are theoretically easy and common sense yet lose all of their potential utility "at scale" or once the practices have been baked into an operating system?

Why?

In your five-person startup, if OKRs fail to help you focus and reflect—or simply end up being redundant and a waste of time because you are all in the same room—you'll stop using them. Or the team will have a conversation, make some tweaks, and give it another try. The situation is different in a larger company: the OKR process becomes intertwined and institutionalized, making it difficult to pivot or discard, even when it's no longer serving its intended purpose. The startup is OK with learning as they go. The big company is afraid to admit it is learning and has likely connected all sorts of weight and implications to the process (like performance reviews, etc.)

It is a shift from using—the practice works for YOU—to "it's something we must do."

In the startup, if the OKRs fail to capture reality on the ground, hiding it will be extremely difficult. For example, if the startup team spends 50% of its time doing something not captured in the goals, the incoherence will be palpable and impossible to hide. In larger settings, people learn to live with that incoherence. They realize that some things aren't worth making visible outside the team. Otherwise, it will attract unwelcome attention ("No one will prioritize the refactoring if we make it public, but the whole system will topple over unless we do!"). They start seeing things like OKRs as the "formal" or "official" view of priorities and not something particularly meaningful internally within the team.

Elaborating goals has the potential to create a lot of focus. But what if the OKR process continues to reflect habits like too much WIP, too many priorities, too much cognitive load, juggling too many dependencies, and too little strategic focus? What if everyone lists out everything they would do anyway, squints at a couple of vague high-level company goals, and "Just make sure it lines up"? What if the leadership team pivots the strategy midway through each quarter, and the OKRs carry no weight? What if you can't point at an OKR and say, "Not now"? No one gives them much brain power outside of ensuring they don't set themselves up to look bad. It becomes a zombie process.

At scale, practices drift from their original intent. For example, OKRs are meant to drive team alignment and focus, but over time, companies might add individual OKRs and use OKRs as part of performance management. Before you know it, OKRs read like a promotion packet.

Left unaddressed, you often see situations where thousands of people believe [insert practice here] is a waste of time. However, they keep doing it because they've learned how to work around it and because someone in a position of power feels strongly about doing [practice].

---

Like the newsletter? Support TBM by upgrading your subscription. Get an invite to a Slack group where I answer questions.

---

The Zombie Drift

High level, you see:

• A growing chasm between the real world and the "official" world

• The practice stops becoming useful to teams on the front lines

• Confidence that other parties will "play the game" drops

• Teams learn how to adapt (to stay safe and protected)

• Compliance starts to revolve solely around optics

• Sunk cost fallacy ("We can't just STOP doing OKRs, what would that say?")

• Fewer opportunities (or motivation) to challenge the practice

• Because the practice isn't functional, leaders ALSO start treating it as a zombie process and try to find other ways to get the desired effect

Fighting this downward spiral is what makes these theoretically simple things hard.

Fight Mission Drift

So what can you do?

Philip Selznick's Leadership in Administration discusses the idea of mission drift. Mission drift is when the original mission becomes diluted or compromised by the institutionalization of processes or external pressures. To fight mission drift, leaders must regularly revisit the original purpose of a practice or process. Ask: What was this tool supposed to achieve? Are we still using it for that purpose, or has it been co-opted for something else? Are we doing this because it's useful or just because it's the way we've always done it?

Make sure to allow for local adaption. In theory, OKRs allow local adaption by providing a fairly ubiquitous interface (the object and result). In reality, organizations often slip into enforcing rules that turn it into a mono process. Try to avoid that.

Encourage people to challenge the process regularly! The minute you fall into "because that's how things work around here" (when they obviously don't work), you've lost the team's hearts and minds.

(Less of a) Training Problem

Why did I start this post with a section on learning OKRs? Companies often perceive things as learning or training challenges. If something is hard, the teams need more training! In Talk to the Elephant: Design Learning for Behavior Change, Julie Dirksen lists factors that may inhibit new behaviors:

• Lack of feedback

• Unclear goals

• Unlearning an existing behavior

• Unawareness of consequences/bigger picture

• Lack of environment or process support

• Anxiety/fear/discomfort

• Lack of confidence/belief about capabilities

• Mistrust

• Social proof

• Lack of autonomy/ownership

• Learned helplessness

• Misaligned incentives

• Lack of identity or value alignment

• Emotional reaction

Processes like OKRs fall apart not because people don't understand them but because they lack meaningful feedback, have unclear goals, are buried under conflicting incentives, or have learned to distrust the system. Zombie processes arise when we don't address these factors.