Agile in a command and control world

Your most important task is deciding how to decide

“Teams are self-organizing and autonomous.” - Your Neighborhood Agile Coach

Let’s face it: Most companies operate within the constraints of a command-and-control structure. Leaders at the hierarchy’s apex make decisions, subordinates report status, and a thriving business celebrates the efficiency and accountability of its employees.

Hierarchies excel at delineating the scope of each group’s responsibilities. The better your hierarchy functions, the more likely participants are to describe the delineations as silos, complete with pejorative connotations. Hierarchical organizations don’t function quite as well in modern business as in industrial manufacturing, but they still undeniably work. No one reads Microsoft’s organizational hierarchy “manifesto,” I couldn’t be sure such a thing exists, but its command and control structure hasn’t prevented a three trillion market capitalization.

People do read Spotify’s Agile Model manifesto, which famously declares its intent to empower teams to be fully autonomous. It’s easy to interpret the manifesto as a description of an engineering operating model when, in fact, it’s actually a culture document that describes how team members are expected to behave and communicate. 

Perhaps motivated by Spotify’s promise of workplace bliss, LinkedIn is littered with profiles declaring dedication to servant leadership, although I suspect that, in many cases, it's an aspiration more than an operational reality.

To be clear, I’m not endorsing Microsoft’s approach or knocking Spotify’s; each works extraordinarily well for those companies.

Far more companies operate on a sliding scale of command and control than on a fully autonomous model, and many have attempted to implement some kind of Scrum/Agile methodology to build software (and often, nowhere else in the company).

So, today’s question is: What happens when you try to implement agile in a command-and-control hierarchy?

Agile aspirations, Command and Control realities

In software development, Agile has been The Way for some time now. Agile, and indeed architectural practices like twelve-factor apps–which espouse loose coupling, abstraction, and independence wherever possible–describe teams as self-organizing, independent, and largely autonomous in their decision-making. Agile teams are meant to be customer-focused, iterative, and dedicated to continuous improvement.

I don’t mean to debate how well Agile works in practice; it does for some teams and not very well for others. We persist in implementing it wherever and whenever we can, surprised after the fact when it doesn’t work as well as we hope. I’ve misrecognized the clash of principles between Agile and command and control as poorly implemented Agile.

Most people forget when talking about Agile that the practice is designed to facilitate a particular flow of information and a communication style. However, this communication style is used almost nowhere else in a typical enterprise.

When your company looks like a hierarchy with an Agile network bolted onto it, you are probably better off working on deciding how to decide than you are tinkering with your Agile practices.

Deciding how to decide

Few things are more important to an organization than deciding how to decide. We make dozens of decisions every day. 

As a product leader, ask yourself what decisions you want to make and what decision-making style you’ll use. If you are working from scratch, write down how you want it to work, what core principles you’ll use to guide the team, and hire people who share your belief in those core principles. 

If you are working within an existing organization, survey your team. Ask them to describe what kinds of decisions they are empowered to make and when they are permitted to make them. You’ll quickly learn how decision-making actually functions in your org and whether it matches your intended style. You’ll also learn exactly how many people actually understand what decisions they are empowered to make.

Suppose for a moment there are three decision-making styles: command and Control, Loose Command and Control, and Mostly/Fully Autonomous. Further, none of these styles is inherently bad, and any one of them could work for your organization or company.

In the first model, Command and Control, your team comes to you to make important decisions. You have the final say about vision, strategy, and tactics. You’ve implemented tools and processes to ensure no decisions fall through the cracks. To scale up your capacity, perhaps you’ve designated delegates or committees who can make decisions in your stead, and those delegates fully expect you to override any decision you disagree with. Everyone generally understands that, at some point, they will have to commit to and execute decisions with which they disagree.

In the second model, Loose Command and Control, your team consults you about important decisions, hears your feedback, and decides for themselves. You are involved and retain the right to override but generally want the team to operate and make decisions based on your vision and strategic direction. You are diligent about communicating your vision across the organization, and the team understands the context required to communicate their decisions, how they arrived at their conclusions, the possible implications, and how to measure success and failure. 

In the third model, Fully/Mostly Autonomous, you’ve set the team free to solve the problem and let you know when it’s done. The flow of communication emphasizes the outcome of the decision–what was made, saved, or achieved–rather than the process of arriving at it. You expect and encourage iteration and tolerate failures, contributing to learning and improvement. 

Any of these models could work for your organization. Deciding which to use is as simple as following a heuristic and asking the questions that lead you to the right one.

I worked for a large company that, for better or worse, had implemented a militaristic, rigid hierarchy that could only effectively operate within the constraints of a unified chain-of-command communication style. 

No one did anything without prior approval from the level above, and all strategic decisions came from the top. It worked, sort of, in the sense that the company frequently satisfied its investors enough to stay in business. 

If you had an idea you knew would benefit the business, forget it. By the time you managed to get that idea presented high enough up the chain (the top, remember?) and then had that idea/command passed back down the chain for you to implement, it was likely too late.

Implementing agile in such an environment is a fool’s errand because the rigidity of the rest of the organization renders the benefits moot.

I’ve worked in other organizations with the opposite model, where the entire communication flow was optimized for autonomous decision-making. There are downsides, however. Some people don’t like making decisions, especially impactful and important ones. It’s scary when your decision impacts a company's mission. And so you don’t make a decision; you just defer as long as possible. Others aren’t very good at it, for whatever reason. They hold strong biases, ignore vital information, or are impulsive and rash.

Keeping consistent communication in autonomous optimized environments is difficult. Evidence of this often surfaces at sprint reviews or demo days, where it becomes evident that many teams have recognized a particular problem and gone off to solve it without effectively communicating that to other equally ambitious and autonomous teams. To the chagrin of leaders far removed from the decision-making cycle, a half dozen teams show up and demo pretty much the same thing. (In some companies, this is by design and intended to spark competition that leads to a superior solution. More often than not, and especially if you’ve hired lots of really smart people, you end up with indistinguishably good solutions to a problem, and you’ve burned way more budget than you should.)

And I’ve worked in organizations with a hybrid of the two, with some top-down decision-making, some autonomous organizational structure, and a clear picture of what kinds of decisions belonged in each tier. 

The key to all these scenarios is to be very explicit about what kinds of decisions each individual is allowed to make. Deliberately design the decision-making framework and communicate relentlessly. There isn’t a wrong answer, but don’t expect to achieve full autonomy in an environment that relies heavily on command and control decision-making. Embrace the hierarchy. Know it is there and optimize around it. 

The personality of the person at the top of your product organization determines the model used. She wants nothing more than to make all the decisions because, well, it doesn’t really matter why. Or, she may imbue the team with extreme levels of trust, expecting, in fact, rewarding, autonomous behavior. 

The truth is, properly implemented, either of these models works.

Sometimes, even when you implement the autonomous model, people need help making decisions, and this also has to be an important part of the communication flow and decision-making model. You must empower the team to make decisions and encourage them to ask for help. 

I’ve often joked with teams that I categorize these as “gift card” moments. If you come to me with a problem and no solution, you owe me a gift card worth a couple of coffees at most, but if you come with a problem and a solution, I owe you a gift card, one that is always more valuable. It is never enforced—that’s not the point—but it is a powerful tool to reinforce the style of decision-making you expect.

Educate the organization that asking for help is not only encouraged but, in some cases, required. This is true when a solution requires specialization and expertise, when substantial ambiguity clouds the path forward, or when you are gonna have to spend a shit ton of money.

Communication flow

It feels like stating the obvious to say that all is doomed without a well-thought-through communication flow. Planning your communication flow is your strategic planning. Most strategic planning concerns itself answering the question, “What should we do and how should we do it?” when, in fact, the more pressing question is, “How, when, and where should we talk about what we do and why we are doing it?”

None of the models are easy to implement; they are just hard to implement in different ways.

The command and control model demands a constant flow of communication from the top down to ensure the execution of the plan and implementation of your decisions. You’ll need checkpoints and checklists; your instructions must be clear and concise. You’ll need tools to measure accuracy and correct deviations.

The fully autonomous model requires leaders to have an open-door policy to account for the ad hoc, unpredictable flow of information from the bottom up. You’ll need the flexibility to accept the deviations from the course caused by individual decisions and trust that those decisions align with the overall vision and mission. In the aggregate, the team will arrive at the intended destination even if the path sometimes looks a little squiggly.

The loose command and control model is, obviously, a hybrid of the two. The hybrid model operates within the reality of a company’s hierarchy while searching for the optimum balance between autonomy and accountability. Expect to do a lot of town hall meetings and dedicate time to ask me anything sessions. Show up to sprint reviews and demos. Come prepared to listen and ask questions. This model involves a deep level of engagement across every level of the organization. Everyone needs to hear from you and feel heard by you. 

Structure

My advice is to establish your decision-making model and create a communication flow that supports it before you spend meaningful time on organizational structure. Typically, however, most of us start with structure first and then struggle to adapt our decision-making model to the resulting hierarchy or autonomous network.

This phenomenon is partly a function of companies' hierarchical nature. The first step HR takes to onboard a new employee is establishing to what part of the organization that person belongs and to what reporting structure he falls into. He needs to know who will approve his expense reports, be added to the proper Slack channels, get a laptop, and other domestics. These necessary tasks don’t contribute to developing his autonomy, but he simply cannot be a company member without these events.

While the organizational structure incubates within HR, product leaders must consciously reconstruct it to match how they want the team to operate. If your goal is autonomy, your work is cut out for you.

Commit and execute

Decide on a decision-making model and a communication flow and refine them until they work well for your organization. This might mean deviating from your original intent by adding more autonomy or establishing more control.

Don’t follow trends, and be honest with yourself. If a strong command and control structure works best for you, use it. If a fully autonomous organization gets the job done, choose that. If a hybrid model is for you, make it work.

The best path to servant leadership is deciding how to decide.