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 at Medium and Zappos. 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.