I recently spent a month embedded at a consultancy called Undercurrent, watching how they help organizations become more adaptive and responsive. It's a transformative concept I've been thinking about a lot lately—including the fact that there isn't a common language to succinctly explain what responsive means in this context. So I'll start with an analogy:
Software developers know that the term Agile describes a set of principles that are supposed to help you build better products. Scrum is a development methodology that embodies these principles of building as you learn and adjust accordingly. It's meant to be an improvement on Waterfall development—otherwise known as the way people used to build software when they planned first and built later.
Before Agile popped up, we didn't use the term Waterfall much. That's the way we all built things so we didn't need a word for it. We also didn't need to talk about development methodologies until we had multiple options to compare. Now we all understand "development methodology" to concretely mean "a framework used to structure, plan and control the process of developing an information system."
But what do we call the framework used to run a whole company? Most academics call this an "operating model"—the approach an org takes to structure, planning and process. What's especially interesting, is that while all companies run slightly differently, they effectively all use the same operating model invented over 100 years ago. For example, almost all companies use the same hierarchy that places managers under directors under executives, where decisions come down from the top and action lives at the bottom.
Command & Control (or C&C) is the widely recognized term for this type of organization. And it gets at least one thing right: It creates a common language to describe operating models that everyone can understand. For the first time in over a century, we're beginning to see credible alternatives, and most of them point to this idea of responsiveness—that an organization should be built to learn and respond rapidly by optimizing for the open flow of information; encouraging experimentation and learning in rapid cycles; and organizing a network of employees, customers and partners motivated by a shared purpose.
One of these Responsive methodologies is Holacracy, defined as "a comprehensive practice for structuring, governing and running an organization. It replaces today's top-down, predict-and-control paradigm with a new way of achieving control by distributing power." Right now, this system is being used to the advantage of companies like Zappos, Medium and more.
But before I dive more into Holacracy, let's look at why we even need new organizational methodologies if the old one worked so well for so long.
Why are we so attached to creating detailed upfront plans before we start executing? Well, in the minds of our predecessors, you wouldn't want to start building a 20-floor skyscraper if your foundation was designed to only support 10. You want a concrete plan, and you want to deliver on that plan.
This attitude became so ingrained that a whole ecosystem of consultancies and services grew up around it, enabling lower bids on projects and lots of profit on inevitable change orders. Sub-optimal systems are very well adapted to their environments. This is what makes them so hard to break. For example, it's why Detroit car companies and the UAW were able to pump out crappy cars for so long.
We like this so much that we tried to build software this way, too. Only software is a lot less predictable than construction. It's more art than science. And, it's actually possible and beneficial to change your plans when you learn new information. That's the basis of Agile. You build software in short cycles to collect feedback and adjust quickly. Suddenly, the needs that the old model met changed, and the cost of doing business was no longer worth it.
Creating rigid, long-term plans doesn't work when the solution to a problem is unpredictable. The thing is, unpredictability isn't just affecting software anymore. Now we want all kinds of products and services to move with our rapidly changing wants and demands. We want grocery services that recommend what we need before we know it. We want clothing brands that keep up with the current style. The old C&C way of doing business falls short of these goals. But until now, people thought that was their only choice—C&C or chaos.
Holacracy is simply the first fully formed alternative to C&C that real companies are using successfully. Is it the only replacement? Should everyone switch to it immediately? Definitely not. There will be many other operating models to choose from in the near future.
Like historian Chester Starr once wrote: "Every so often civilization seems to work itself into a corner from which further progress is virtually impossible along the lines then apparent; yet if new ideas are to have a chance the old systems must be so severely shaken that they lose their dominance."
Companies with traditional hierarchy can only change as fast as their leaders can handle it. Bringing on better leaders or simplifying the business will buy time, but they'll still be outpaced by the rate of change.
Seeing this limitation, responsive organizations aim to distribute authority and decision-making to all of their employees—even if it makes them less predictable and efficient in the short run. The goal is to increase their capacity to learn and respond to change by empowering more of them to do so.
A lot of people assume that responsive companies have very few rules about who decides things and why. The most surprising aspect of Holacracy may be how much it relies on rules and process. To avoid chaos, it actually forces you to define roles and accountabilities far more rigorously than the old C&C system.
Let's say there's a meeting of 10 people who need to make an extremely important decision with massive consequences. At a C&C company, the most senior person in the room is responsible for that decision. If that person still doesn't have the authority to pull the trigger, they have to go to their boss. The good news is the decision will eventually get made. The bad news is that everyone in the room is disempowered in the process.
Now imagine those 10 people are from 10 different groups at the company and they all have the same authority. Unless there's broad agreement going in, they'll usually argue about the problem until it gets deadlocked or escalated to their bosses or bosses' bosses. Or worse, it'll fall into the hands of the oldest, youngest, loudest, most politically savvy, male or dominant person—whatever tired, implicit power dynamics dictate.
Responsive organizations also risk falling prey to the tyranny of consensus and backtracking to old systems of authority. That's why clear rules and protocols—like those outlined by Holacracy—are so vital and tend to work well.
Whenever you attempt to change the rules of a system, you'll run into a host of new problems. So, to explain Holacracy, let's look at what changes it makes—one at a time—what issues they cause and how they get solved.
Rapid Iteration Over Static Policies
Just like Agile development systems break work into sprints, Holacracy forces a company to revisit its rules, roles, objectives, and authorities in short cycles. This prevents you from over-planning upfront. It also gives you the chance to re-evaluate your plans, direction and beliefs on a regular, frequent basis.
If you're familiar with , you know that companies create products and services that are reflections of themselves. So it makes sense that in order to rapidly iterate your product, you should also rapidly iterate how your organization works.
To make this happen, Holacracy requires each team to have a regular (let's say monthly) Governance Meeting, where people can suggest changes to teams, roles, policies, accountabilities, etc.
C&C orgs have no such mechanism. Only the people at the top have the ability to rearrange things, and they seldom do because that only adds to unpredictability. These types of changes often have unexpected consequences. Instead of ducking this fact, Holacracy admits it—no change is perfect.
Governance Meetings might sound like time wasted that could be spent "working." My counter argument: Working on the right thing is as—if not more important—than how hard you are working.
Before A/B testing was a widely accepted best practice for building apps, people would argue that building multiple versions was a huge waste of time. Why not just pick the right thing to start with and build it once? We now know we were wrong too often. It's not a waste to build multiple versions if it helps you find the right one. Why should orgs be any different?
Self-Organizing, Adaptive Teams Over Static Teams
In Holacracy, teams are renamed "circles," and they can be created or destroyed anytime. The domain of a circle can be redefined multiple times, and the roles within a circle can be changed accordingly. Sounds messy, but there's one rule that keeps things together: Circles only have the authority to change things that are in the domain of their authority. They can also create new circles under them if that's necessary to get the job done. Essentially, circles are structured hierarchically, they're just subject to constant change that keeps them trained on the most important problems and work at any given time.
Role Not Soul
Allowing all of your employees to propose changes to teams or roles would not work at a C&C company. First, title and rank are too important. And second, people generally only have one role on one team with one focus. People identify 1-1 with their title, making them imprecise and inflexible. Rank also tends to aggregate accountability for everything below it, no matter what your title is. This makes it even less precise. If you talk to 10 CMOs, you'll get 10 different answers about what their job and accountabilities are.
Holacracy fixes this problem by decoupling "role from soul." Roles are defined based on logical groupings of accountabilities or areas of expertise, ignoring the physical number of people at your company. You can have more roles than employees, and it's expected that people will fill multiple roles within several circles. In fact, it's common for one person to handle multiple roles in the same circle. This makes it easy to move accountabilities from person to person without changing titles or hurting egos.
Role Over Rank
Simply decoupling role from soul wouldn’t be adequate given the importance of rank. We’ve all experienced how rank can trump role. While Holacracy may have a hierarchy of circles, it tries to decouple the humans from that hierarchy as much as possible. It would be misleading to say there is no hierarchy, however. Each circle has a single role called Lead Link who has authority over assigning people to other roles in the circle. Unlike a normal "boss" though, the Lead Link isn’t supposed to tell the occupants of those roles how to do their jobs.
Why And Who Over How And What
At a traditional org, a lot of time is spent arguing about what work to do or how to do it. This often takes up the bulk of meeting time and stems from a lack of clear accountability. No one knows who gets to decide what. If anything, attempts to empower employees within traditional frameworks have only made matters worse.
In Holacracy, people don't tell other people how to do their jobs—even the Lead Link. So, instead of arguing about it, Holacratic orgs tend to spend more time arguing about who should be able to decide and why that wasn't clear to begin with. This is by far the most visceral difference I've noticed while observing Holacracy vs. C&C in action.
Networks Over Hierarchies
The most effective way to solve any problem is to put together all of the people with the skills required to solve it. We call this a cross-functional or multi-disciplinary team. Sounds obvious, but as anyone who’s worked at a large company will tell you, it's rarely done in practice.
Earlier, I mentioned that relying on long-term, rigid plans makes it hard to adjust as new information is learned. You may not recognize it but the organizational chart itself is merely the manifestation of an earlier long-term plan.
Imagine you were tasked with creating a car manufacturer from scratch. You'd probably start by figuring out all the products you wanted to make. Then all of the different types of work needed to make those products. You'd then design the org chart around those products and functions. One of your goals would be to create an org chart that gave maximum autonomy to each team by minimizing their dependency on each other. That's because work which can be done wholly within a formal team is much easier than work that requires participation from multiple teams.
This strategy gets increasingly difficult as the number of teams grows. In the end, you get people who have never worked together who really should. This problem has plagued companies forever, but has gotten worse as work becomes more complex and the future less predictable. Our best response to this problem so far has been the addition of the "dotted line" a.k.a. matrix structure. While this may have helped a little, it doesn't address the fundamental issue:
There is no way to design a permanent org structure where the right people can work together with as few dependencies as possible. If that's true, then how do you make sure the right people are on the right teams when new problems arise every day. Especially when changing team structure requires painful and expensive re-orgs.
To address this, Holacracy makes it easy and relatively friction free to create new circles, rearrange people within them, tear it all down and start again. As we saw before, these teams are unconstrained by a long outdated org chart.
Everyone reading this article is probably familiar with what traditional org charts look like, with their rigid reporting structures:
When you adopt Holacracy, however, you move to a much more networked chart where people often take on more than one role and move teams/circles when it makes sense without worrying about breaking some pre-established hierarchy:
Safe To Try
With no clear rank system, it seems like it would be easy for any proposed change to be blocked by others. Holacracy deals with this by creating rules around proposals that favor the proposer over objectors. The idea is to reduce the friction for change by making it easy for anyone to propose changes.
That doesn't mean that there aren't ways to game the system or play politics in responsive systems.
All that said, by taking proposals frequently, there is less pressure to make sure they're perfect. If something doesn't work right, it can be changed by anyone else at any time. Thus, proposals are deemed "safe to try" as long as everyone agrees that they'll help gather valuable data. "Safe to try" is a key idea in Holacracy.
The only valid objections are A) this circle doesn't have the authority over the domain you're changing or B) there is proof the change will cause material harm to the business before it could be mitigated.
So, for example, if someone in the Recruiting Circle proposed a new policy that the company should give 100% of it's revenue to charity, one could object that A) the Recruiting Circle doesn't control company finances and B) giving away all of their money would kill the business. Of course, someone who makes bad proposals repeatedly would eventually be moved and probably fired.
The takeaway is this: You can't simply object because you don't like an idea or have a better one. Even if you make more mistakes this way, you'll learn and course correct faster.
Documentation Over Tribal Knowledge
In a C&C org, the rules are actually quite simple. Your boss bestows authority to you and their boss to them. If you're ever confused about what to do, you can ask your boss. Right or wrong, if you do what they tell you, you're likely safe. Given this simplicity, the rules are rarely written down, other than in the form of an org chart.
Of course, most of the rules are tribal. "Because that's how we've always done it," is a common phrase at traditional companies. Yet no one knows why, who decided that, or who can change the rules. In order to distribute authority in an adaptive way, the rules have to be written down so anyone can look them up and quickly figure out who owns what and what the policies really are.
Glassfrog is the name of the software you use to help you run a Holacratic company. It’s theoretically possible to run Holacracy without it, but it would be hard. This dependence on software doesn't bother me as much as it does others. Technology takes care of many of the things we used to do by hand, which has expanded our capabilities.
Running companies will be no different. Glassfrog helps you document your organizational structure, circles, roles, accountabilities, policies, etc. It also aids in running meetings. Finally, it provides an ongoing record of changes made to the organization. Glassfrog theoretically makes it easier to figure out who owns what, what the rules are, how things have changed over time, and what has been learned.
Transparency Over Privacy
Let’s say you’ve managed to get your org this far and have successfully distributed authority to the edges. Given how much more power your employees have, how can you make sure they have enough context?
In most organizations, work and communication is done in private.
Most of the time, the person documenting things doesn't have a good view of what's changed and what benefits that produced.
There are lots of good tools today to help you move your communication, task management, and documents to places where others in your organization can find them. Yammer, Asana, Trello, Slack, and HipChat are just a few of them.
How do you hire, promote, and fire at a Holacratic company? How should you prioritize what work to do or decide who does what? The rest is up to you. The point isn't to pre-determine what works for everyone. It's to give you a basic structure that helps you make the rules transparent, easy to change, and to increase the rate at which you change them.
So, so many things. The biggest challenge is dealing with how wrong everything feels at first. Most of us have only experienced C&C orgs and have no models for how things might function differently or—ideally—better than usual. As such, it's also impossible not to regress back to old ways of thinking, especially when things go wrong, which they will. You have to give the new system a real try, which means using it to relieve tensions, reinvent itself and solve the problems it creates.
Holacracy "feels" weird to most newcomers. It's often described as "heavy." It was even confusing to me why a system meant to empower people would need so many rules. It was only after witnessing it firsthand that I realized why.
But that power has to end up somewhere. In Holacracy, the power goes to the process itself, making it difficult for individuals to take advantage of their positions. If this feels uncomfortable, realize that it's the direction society has been moving in for some time.
Under dictators, the rules are at the whim of the leader. In a democracy, we write the rules down and make our leaders beholden to them as much as anyone else. Democracy functions because we shifted power from an authority figure to a process we’ve all agreed to follow.
At Undercurrent, it appeared there was a tremendous amount of nuance that made Holacracy work for them. They obviously deeply believed in the principles, which helped them administer the system more effectively. They also agree that Holacracy is not a panacea or definitive replacement for C&C.
I wasn't there when they first switched the Holacracy, but I imagine they've improved with time and persistence. They're also a really smart and thoughtful group of people who went into this knowing it would be hard but it's what they wanted to do to become more flexible, effective and competitive.
I believe that just as more governments are moving toward distributing power to their citizens, so too will more organizations distribute power to employees. At least they will, if they want to create lasting organizations.
Writ large: Distributing decision-making isn’t easy. It goes against generations of learned behaviors and deep-seated mental models. The good news is that we now know it’s possible. From early reports at pioneering companies, it also appears to be extremely beneficial.
If you choose to follow their lead, remember that distributing authority isn’t binary—it’s a spectrum. If you want your organization to become more responsive, you should probably start figuring out how to distribute authority, even if you do it just a little at a time.
My advice is to get started and not let the problems you know you will encounter get in the way. Start trying to move in the right direction, accept that it will cause problems, and use each roadblock as a signal to take it even further.
This article originally appeared on First Round Review and is reprinted with permission.