11 min read
Terracotta Army
Next in trending

The Last Re-Org You’ll Ever Do

New (and old) thinking about organization design may lead to ever-evolving entities

The Last Re-Org You’ll Ever Do

New (and old) thinking about organization design may lead to ever-evolving entities


Established institutions have been reorganizing as long as they've been organized. As circumstances change, the shape and makeup of the workforce must be adapted accordingly. Today’s most disruptive organizations however, are beginning to organize around a new pattern: the ability to evolve in real time.

Pretend for a moment that you're the CEO of Strong Co. (a fictionalized blend of our actual experiences with the Fortune 500). Strong Co. is a software and hardware business with over 10,000 employees and hundreds of thousands of customers. You wake up every day thinking about your organization and the same words keep repeating in your head: “We are too damn slow. And we're focused on the wrong things. If we don’t change the way we’re working, I’m going to preside over the slow decline of a once great business.”

Looking at the organization honestly, you can see the problem. Your people simply aren't working together! You have a plethora of departments, and boatloads of talented people, but communication has broken down. Customer Insights won't talk to Innovation, and the Technology group isn’t even in the same building as the Design team. How can a company with 2,000 developers take six months to update a web page?!

It didn't used to be this way. When Strong Co. was smaller it was so different. Sure, the office was tiny and people were sitting on top of each other, but things happened fast. In many ways, you wish you could go back to those good old days. Unfortunately, nostalgia isn't going to fix this problem.

You know what you have to do. It’s time to reorganize. But how to get it right this time? You could change the people in leadership roles. Perhaps if the groups had better leadership, they'd get their act together. Or you could break your departments up into smaller and more focused versions of themselves — one for each line of business. Hell, you could even divide the business by customer, creating consumer and B2B organizations that mirror each other.

But something tells you none of that is right. A voice in the back of your head whispers, “You’ll be re-organizing again in three years…”


Here’s the problem. The design of an organization with 10,000 people in it is an insurmountable intellectual puzzle. Whatever your mental model of the organization might be, it’s too simplistic. No human, and no current machine, can handle the complexity. It’s literally impossible.

In Notes on The Synthesis of Form, author and polymath Christopher Alexander talks about the exponential nature of design challenges. Designing something as simple as a tea kettle requires the consideration of over 200 different variables, from the thickness of the handle to how it sits on the burner. Now consider how many variables exist in a company that operates in 20 countries, with 10,000 employees, and 250,000 customers. All those constituents and requirements are overwhelming, and as a result, you default to a more “blunt” solution.

Further, even if you could make it work by sheer force of will (or genius), external change and entropy are going to render your new structure inadequate. And that is the central problem with modern corporate structure: it doesn’t get better under pressure.

And that is the central problem with modern corporate structure: it doesn't get better under pressure.

In 2012, author and epistemic rapscallion Nassim Nicholas Taleb (re)introduced us to an age-old concept he calls antifragility. In his view, non-fragile systems can be characterized in one of three ways: robust, resilient, or antifragile. Robust systems are strong and powerful, but ultimately breakable, as in the myth of the sword of Damocles. Resilient systems behave differently — they can be broken down, but they build themselves back up to their former stature, as in the myth of the Phoenix rising from the ashes. And finally, Antifragile systems, which actually thrive on volatility, as in the case of the Hydra, which grows back two heads whenever one is cut off.

At best, modern bureaucratic institutions are robust, and occasionally resilient. But becoming antifragile is far more elusive. The prevailing theory is that large institutions need to standardize and mechanize their processes and practices—creating order and structure—therefore unlocking economies of scale. Yet, antifragile systems (like nature) tend to promote intense variation and randomness (referred to as optionality by Taleb), to ensure that new mutations, models, and approaches are always present, ready to take the lead if/when circumstances change. Antifragile systems are redundant, with countless backup plans. They are not efficient, but they are effective.

This need to respond to changing circumstances is compounded by the increasing pace of technological innovation. One of the key ideas shared by Clayton Christensen in The Innovator’s Dilemma is that technologies improve faster than user’s needs increase (sidenote: worth reading Chris Dixon’s post on this as well as watching this summary of the concept). What this means is that every new adjacent possibility in technology that opens up a new way to serve your market (e.g. mobile, apps, IoT, cloud, big data, sensors, 3D printing) will appear to be irrelevant to your core customer initially, but over time these products and services will catch and surpass you. Remember how “irrelevant” and “pointless” the iPad was when it was first released? How “impractical” cloud storage was before Dropbox and its ilk? This accelerating technology pattern is the new normal, whether your industry is robust (think: jet engines), resilient (think: music), or antifragile (think: cryptocurrency).


We know that we can’t hold the perfect corporate structure in our minds. And we know that for it to thrive under pressure, uncertainty, and volatility we need variation and redundancy. Most of all, it’s clear that our organizations need the ability to adapt rapidly to the pace of technological change. But, what does that mean for the future of organization design? What kind of structure delivers on all that?

To get a hint, we look to today’s most disruptive and purposeful companies. I recently wrote about how the next generation of great organizations are using a fundamentally different approach to running their business. One of the most interesting differences is the way they’re experimenting with structure, specifically: roles, teams, and authority.

Several approaches show promise. Three in particular stand out as radical, effective, and related: Holacracy, Agile Squads, and Self Organizing. I contend that they are all essentially variations on a theme that will define the next age of corporate structure: the emergent org.


Holacracy

This diagram from Holacracy One depicts the sensing and processing of tensions through operations and governance

In the last year, one structure that has gained attention among the technology elite is Holacracy, which is a system of governance used by both our company (Undercurrent), as well as at Medium, and even Zappos (update: since the time of this writing, Zappos has announced a full deployment of Holacracy). Holacracy is a modified and evolved form of sociocracy that focuses on distributed authority through self-managing and self-sufficient teams known as circles. It focuses exclusively on governance, distributing authority to the working edges of the organization, and sensing and processing work-related issues as the organization evolves. The basic tenets of Holacracy are that authority should be distributed, everyone should be able to sense and process (solve) the tensions (ideas/problems) they perceive, roles and employees are not one-to-one, and that the organization can and should evolve toward its “requisite structure” (the ultimate structure for its current environment). Holacracy achieves these goals through meetings that are specially designed to turn ideas/problems into roles, accountabilities, and policies—all of which promote “safe to try” next steps, projects, and actions. This is well summarized in the chart above as well as on the Holacracy One website. Holacracy’s strength is that it works for any organization (not just an engineering culture), and it has a nice blend of rules/controls and emergence. Like Monopoly or any good game, Holacracy seems complex in theory but gets easier as you play.

This diagram from H. Kniberg and A. Ivarsson depicts the structure of squads, tribes, chapters, and guilds deployed at Spotify in late 2012

Agile Squads

The second framework worth exploring is a version of agile/lean development methodology that is being deployed at Spotify (among others). In a brief but savvy whitepaper written late last year, Henrik Kniberg and Anders Ivarsson share how Spotify thinks about roles and teams. Essentially, they have turned the matrix organization on its side (for an interesting detour into divisional vs. functional organizations check out Ben Thompson’s post on Microsoft’s re-org as well as his follow up piece). Instead of an engineering department, a design department, and a marketing department that each collaborate on products with dubious ownership, they organize vertically around products (or more specifically pieces of products) and traditional disciplines are loosely held horizontally. The main unit of organization in this model is called a “Squad,” or what Jeff Bezos might call a two pizza team. This small group (usually 7-10 people) is self-sufficient, multi-disciplinary, autonomous, and focused on a particular product, problem, or module (often with a core KPI or OKR). Think of it as a mini startup. Groups of Squads that are related through product or strategy are called “Tribes.” Groups of people who practice the same discipline (design, UX, development) organize and collaborate as “Chapters,” and communities of interest that aren’t specific to a Chapter (like QA or Agile) are called “Guilds.” The squad model’s strength is that it allows one person to be a member of several different groups with completely different functions, while not losing sight of the most important thing (the user/product). What makes it flexible is squads are formed, grown, and divided or dispersed with little fanfare as the business evolves. There is much to grok here—for further information on how Spotify builds products, I recommend this paper.

This diagram from the Valve Employee Handbook depicts the various internal impressions of the company’s flat hierarchy

Self Organizing

Our third framework is something we refer to as Self Organizing or Open Allocation. Two companies leading this charge are Valve and GitHub. Like the examples above, these companies seek to create a structure that will evolve over time and put authority and trust in the hands of their talented employees. Unlike the examples above, they accomplish this by essentially having no structure. Employees are encouraged to work on whatever they want — to find the projects that engage them and do the best work of their lives. Valve has codified this approach in their somewhat internet-famous employee handbook. GitHub exposed their Open Allocation approach in a more recent piece on fastcolabs.com. This approach is not without its perils. To be done well, it requires extremely high talent density (so that you trust people to make all their own decisions) and a tightly-knit culture of communication (so that everyone knows what the hell is going on). Certain cultural norms about performance and unspoken power structures (something Holacracy addresses head on) almost certainly play a role here, for good or bad. While this concept may be more of an ideal than a practical reality, these firms (and others like them) are actively scaling it and testing its mettle, with astoundingly good results.

What is the Pattern Here?

The defining characteristics of these models are fairly straightforward. They aim to distribute authority and autonomy to individuals and teams. They let the changing nature of the work (expansion/contraction/shifting) impact the structure of roles and teams in a fluid way. They try to make the implicit explicit and prize transparent communication. They allow individuals to gather and work as members of multiple groups with multiple contexts and they go far beyond the disingenuous “dotted line” nonsense of the traditional corporation. They minimize the role of management to systems-level issues and strategies that can only be solved with a bird’s eye view, pushing everything else to the edge. And they organize the work, the teams, and the individuals around a purpose — unpacked for each context. If these themes sound familiar, that’s because they’re the traits associated with workplaces that create intrinsic motivation (remember Dan Pink’s autonomy, mastery, and purpose?). Think of them like a first principles approach to organization design.


The Art of Letting Go

How it might play out at Strong Co.? What is a modern bureaucracy to do? Can any of this be accomplished at a scale of 10,000 or even 100,000+ people? Our belief is that it can (and will), but not by force. Unlike the re-orgs of the past that were executed quickly, decisively, and often without regard for culture, this transition — the last transition — must be handled with care and allowed to unfold. What follows is a set of steps to consider, based on our experience inside global companies experimenting with these ideas.

Step One. Evaluate your people and culture. You’re going to be asking them to undertake a pretty radical transformation that will feel scary at times. To succeed, you need a handle on who is ready, who is capable, and who is unwilling to change. What skills are missing? What experience? In terms of talent, you really won’t know what you have until you ask them to work in a new way. Note: don’t assume that everyone you have will be bad at this. The people and teams that blow your mind may come from the places you least expect.
Step Two. Select a method for distributing authority and evolving your structure. You may be drawn to one of the models above, or a hybrid of all of them. The truth is that it doesn't matter much, as long as the system can learn and change on its own going forward. Our initial POV is that cultures and departments that are more focused on product development will adopt Agile Squads more readily, while those that practice a wider range of disciplines may find it easier to start with Holacracy. Self Organizing may be the most challenging to adopt, but startups or new divisions will do well here, since they can protect talent density from scratch. In all cases, results may vary, but commit to the self-editing nature of any approach.
Step Three. Select one product or one subset of customers that you can safely isolate and serve. You want a team that has pretty much total control over the experience for a small group of customers. You’re trying to create a “startup” within your core business here. This is the group that is going to start using your new approach to structure, roles, and governance.
Step Four. Increase talent density. In order to take full advantage of this amount of freedom and uncertainty, your people are going to need to be top shelf. Once you have a team (or group of teams) in mind, you’ll want to look for missing skills and capabilities. Because of the amount of autonomy and self-sufficiency required in any of these approaches, a team of 7-10 people will need to be packed with multidisciplinary skills in a way that may feel unfamiliar. Give them the team members to do it (or the leeway to hire at will).
Step Five. Practice. That group must work under the new approach in plain sight, and with zero interruption or interference from business as usual. That may require reinforcement on your part. Be their guardian. Everyone shares two goals here: create a winning product or service, and keep editing/refining the team.
Step Six. Show and tell, rinse and repeat. Become a prolific propagandist. The best change is the change that’s demanded, not forced. As that group (and the groups around it) become more comfortable with your new model, expand it, by adding customer segments and products to the new emergent organization. This is your roll out. Timing is crucial here—as you don’t want to move too quickly or wait too long. Get plenty of outside perspective and input on readiness from other organizations that already deploy a similar approach. You’re part of an emerging community of organizational innovators now, so please, share your story and the lessons you learn. This is the final frontier.

To learn more about Responsive Organizations, visit undercurrent.com and stay up to date with our latest thinking by subscribing to our weekly newsletter.