OKRs: A Return to Command & Control (Micromanagement)?

The Agile world has spent the last 20 years evangelizing self-organizing teams. Yet, just because people learn that self-organizing is the way of Agile teams does not mean it happens. Slowly, little by little, the message has been getting through, and teams have been getting more autonomous.

Of course, that can be quite frustrating if you are a manager who feels engineering teams do what the engineers want to do and never listen to you. "Obviously", the managers say, "our problems would be solved if those doing the work simply did what they were told to do."

The struggle between managers and workers isn't new, but since Agile appeared, the workers have found a new legitimacy. Now, the arrival of OKRs is reopening the old questions.

Many people see OKRs as a method of telling others what to do. After all, they derive from Management by Objective, and there seems to be a clear need to cascade OKRs down a command hierarchy. The inclusion of measurements means leaders can both express their commands clearly and check if the result meets the expected standard. 

Better still, OKRs are just tailor-made to cascade down: each team takes the objective they are given to be their own. They tear off the key results, upgrade each item to an objective and add new key results. The newly formed OKR can then be passed to a lesser team. It's OKRs all the way down!

What Is There Not to Like?

One can say, "OKRs give management the legitimacy and tools to resurrect command and control". Maybe.

It is hardly surprising that, in the first instance, OKRs are seized on by management types as a way of reimposing control. But that is a flawed understanding. Even if it was true in 1970s Intel - where OKRs originated - it is not how modern teams should be using committed and aspirational OKRs. It is not 1970 today, and the (unfinished) Agile revolution has changed how teams work.

No team is an island; there are few teams that do not face multiple disparate demands on their time. The people best positioned to decide actions are those with the most information. Once upon a time, say on a classic 1930s production line, that might be the manager who could view the entire process and consider external factors.

Today the people with the best information are very likely to be those doing the work, especially when one takes a team view. The coders know how the system works, they know how to go about manufacturing code, and they also know where the traps are. Next to them sit the product specialists who speak to customers and understand what is needed. Close by is the support desk fielding help calls and bug reports. Collectively this team has the most information.

Teams are closest to the actual work, so they should have more decision-making autonomy

The idea of devolving authority down to those closest to work is not new. It reappears again and again: Kazuo Inamori built Kyocera on the principle of Ameoba Management - with each business unit considered its own decision-making entity. Another Japanese company, Uniqlo, expounds a philosophy of Zen-in Keiei, "under which every employee adopts the mindset of a business manager, regardless of his or her position."

Philip Tetlock, in Superforcasting, describes the Prussian army practice of allowing unit commanders to decide how to accomplish their objectives. This approach was inherited and used effectively by the Wehrmacht until leadership intervened and started directing operations. 

How the shared leadership concept work according to Lean and Agile

40 years later, the US military embraced the principle of "Mission command." Each commander and unit is given the authority to direct their own mission. I will leave it to readers to consider recent military campaigns that might have pitted a smaller army with devolved authority against a larger but centrally directed force.

The Connection to Today's World

In the digital age, this is more important than ever. When our machines do most of the actual work, what is left is mainly decision-making. Escalating a question up a chain of command and a decision back down creates delay. And since technology has made everything faster, that delay is more apparent than ever.

Maximizing our return on investment in digital transformation demands process change to maximize the authority that individuals and teams have. Changing technology without complementary changes to processes and culture leaves benefits unrealized.

(Notice that I'm not mentioning how people are more motivated and more productive when they have more control over their work. Nor have I mentioned that the millennial generation now entering the workforce expects more autonomy in their work.)

Undoubtedly some people see OKRs as a mechanism for reimposing, centralized planning, and top-down command-and-control. However, such an approach flies in the face of our modern world. OKRs have a role to play in this world, but it is not to reimpose control.

Nobody is challenging the idea that leadership can determine the missions or objectives of the larger entity. However, the operating units - whether they be software development teams, battalions, or even individuals should have the power to decide how to tackle problems and complete their mission.

How to Think About Structuring OKRs (in a Non-Micromanagement Way)?

Leaders still have a responsibility to talk about an organization's higher purpose - what I call Level-1 objectives. Leadership still sets the culture and allocates resources. And leaders still set the strategy and determine missions - Level-2 goals in my lexicon.

Level-1 goals are largely invariant, they are often tied to the raison d'être of the organization. If they change, that happens slowly over time. Level-2 goals do change but not very often, they are long-lasting, and they support advancing the purpose (Level-1).

OKRs fit in at Level-3. Teams are tasked with missions that further the organization's purpose, but OKRs are written by the teams. OKRs are the teams' response to those missions (i.e., the Level-2 goals) for the next period, typically a quarter.

OKRs are Level-3 goals

Think of it like a contract, or API, for the team: the organization sets the context, and the team responds with the outcomes they will aim for in the next period (quarter).

Thus, OKRs are not given to teams. OKRs are not a magic form of telepathy that transfers management wants to teams. Rather team members set their own goals for the coming period and visualize them using OKRs. Those goals are not random, they are set by a team to reflect how the team will respond to all incoming demands: demands from management to fulfill their mission, demands from customers, technological demands (update the library, refactor the code), or operational "DevOps" needs, for example.

Given the proliferation of demands on the modern team, it is the team, not a central planning authority, that is best placed to determine how to meet those demands. OKRs, level-3 goals, guide the work the team does until the end of the period when they are reviewed and reset.

That does not exclude managers and leaders from the OKR setting processes. Setting OKRs should be a collaborative team effort, and managers are team members too. Other leaders are stakeholders who have a legitimate stake and deserve to have their voices heard. Managers and leaders do not have the right to set OKRs for the team, but they do deserve to have their voices heard, and teams have a responsibility to respect their wishes. When conflicts arise, both sides need to work together to find OKRs that work for all. Indeed, finding such conflicts is itself a success because it allows resolution.

Organizational feedback loops

It is easy to paraphrase this approach to OKR setting as cascading up rather than cascading down, but that view is too simplistic. The term cascading OKRs implies a forceful one-way transfer which is exactly the opposite of collaboration and consultation. Neither the giver nor the receiver should expect the other to unquestioningly accept the button.

At The End of The Day

After listening to different voices, the team decides their priorities for the coming period and codifies these as OKRs. In doing so, some things are implicitly excluded or deprioritized. Because these decisions are codified in a standardized format - Objective with Key Results - they can be shared and understood by many. If necessary, the team can iterate to incorporate feedback from stakeholders.

If leaders find their priorities are not reflected in the OKRs, then there are two possibilities. Either the leaders did not communicate clearly, or the team decided other demands were more important. In either case, there is a discussion to be had, and both sides can learn and differences resolved. 

As with much else in the Agile world: the tools don't so much fix the problem as make it visible.