Let's Start from Scratch: Organizational Design in the Age of AI

Introducing the Harmony Pattern Language for Hybrid Teams

With the community-driven Harmony Pattern Language, we can offer a new path for designing viable hybrid teams that can thrive in our AI-driven future.

Why Start from Scratch?

Organizational models such as Team Topologies, SAFe, Holacracy, Spotify Model, and unFIX were created before the rise of AI, intelligent agents, and hybrid human-AI teams. They were designed for organizations composed entirely of humans. But organizations today increasingly integrate AI agents and digital workers alongside people, which fundamentally transforms the future of work. It is time we revamp our mental models for the age of AI.

Second, the traditional boundaries of employees versus contractors, gig workers, and fractional workers are dissolving, which enables a much richer variety of organizational forms. Frontier firms, solopreneurs, liquid workforces, DAOs, NAOs, flash teams, multi-agent systems, and autonomous enterprises are already here (or arriving soon). Working with pre-AI organizational design models is like browsing the web with Windows 95. We need a new design language to fit the modern reality.

Third, the lean-agile industrial complex needs a new direction. No more "agile is dead" nonsense. Organizations strive for enterprise agility, accelerating innovation in an increasingly complex world, but no single method or framework can solve everyone's problems. We need a way to stitch together the many models and frameworks we already have—a universal interface for organizational design.

Ambitious? Damn right.

Worth trying? Absolutely.

That's why I believe it's best to start from scratch.

We need a new language for decentralized, network-first organizations in the age of AI. This new language should recognize and honor the wisdom embedded in the many models that came before, acknowledging their strengths and addressing their blind spots. No blaming, no shaming. Just borrowing the best bits and then connecting different methods for the various parts that people need. We should retain the valuable perspectives of different communities and thought leaders while adapting their insights for a hybrid human-agent future of work.

We should do that as a community.

And the language should be free.

Let me show you what I mean.

Harmony Pattern Language

I propose to co-develop the Harmony Pattern Language as a shared vocabulary for hybrid organizations and networked agentic organizations in the age of intelligent machines.

Harmony's goal is to provide neutral, systemic patterns that describe how to organize teams and organizational units to remain viable, adaptive, and scalable. We seek to synthesize and extend the insights of earlier models into an inclusive taxonomy that different communities can recognize and use for their own purposes. We happily link back to any valuable sources elsewhere because we prefer not to reinvent the wheel. We design the interface that connects different models while upgrading their insights for the future of work.

Harmony comes with a Creative Commons 0 license (public domain) that allows anyone to use the patterns for any purpose, at no charge. We allow everyone to make presentations, record videos, write books, and create courseware, without restrictions. Anything contributed to and published on the Harmony website is free to use. After all, if we want to make a stand against monopolies and tyranny, we need everyone (including the AIs) to talk about harmony.

Let's examine how that could work in practice.

VSM as the Foundation

The Viable System Model (VSM), developed by Stafford Beer, is a theory rooted in systems thinking that views any organization as a living system designed to survive and adapt in a changing environment. It outlines the functions for an organization to remain viable by balancing its internal operations and its response to the external world. The model's core principle is that for a system to be "viable," it must be able to manage internal complexity, coordinate its daily activities, and also maintain a separate, future-oriented function to scan the environment and formulate policy for long-term survival.

Over fifty years after its first publication, many systems thinkers still consider the VSM the best framework for 21st-century organizations. As a lens through which to evaluate organizational design, it's perfect for our purposes.

The Viable System Model identifies five systemic functions required for viability:

1. System 1 – Operations: Core functions for performing work and managing flow.

2. System 2 – Coordination: Synchronizing and avoiding conflict among operations.

3. System 3 – Optimization & Control: Allocating resources and enforcing constraints.

4. System 4 – Intelligence & Adaptation: Scanning the environment, planning, and adapting.

5. System 5 – Identity & Culture: Defining purpose, values, and governance.

The VSM lens suggests systems increase their viability by addressing these five functions, no matter at which organizational level: individuals, teams, business units, or enterprises. This makes the VSM a fractal model.

Team Topologies as a Starting Point

Team Topologies, developed by Matthew Skelton and Manuel Pais, provides a model for organizing teams to optimize the flow of value. Their approach is based on a key principle: to manage the cognitive load on teams and enable them to deliver software quickly and effectively. There is only so much cognitive load a team can handle to respond quickly in a fast-changing environment.

Note: Some authors have pointed out that "team cognitive load" is a non-scientific concept and possibly a generous extrapolation of the actual science of cognitive load. I'm not concerned about this because we can arrive at exactly the same conclusion by using the Law of Requisite Variety, perhaps the most fundamental law in systems thinking: To manage a complex situation or problem, your available options or behaviors must be complex and varied enough to handle the potential challenges. In other words, the limits of a team's mental models directly relate to its chance of survival in a complex environment.

Team Topologies helps organizations design a structure that aligns with their business goals, avoiding common pitfalls like communication bottlenecks and excessive dependencies. This focus on intentional organizational design allows for increased speed, autonomy, and adaptability in the face of complex challenges.

Team Topologies provides four team types:

• Stream-Aligned Team: primarily maps onto VSM System 1 (Operations) with partial inclusion of some functions from Systems 2, 3, and 4.

• Complicated-Subsystem Team: primarily maps onto VSM System 1 (Operations)

• Enabling Team: primarily maps onto VSM System 2 (Coordination)

• Platform Team: primarily maps onto VSM System 3 (Optimization and Control)

Using the lens of VSM, the patterns of Team Topologies map well to System 1 and partially to Systems 2 and 3, but Team Topologies does not cover Systems 4 (Intelligence & Adaptation) and 5 (Identity & Culture) and therefore lacks "upward closure." We cannot design a viable system using only the Team Topologies patterns unless we force the teams to absorb the functions of VSM Systems 4 and 5. But that would increase cognitive load. 🤷🏻‍♂️

The unFIX model as the Augmentation

The unFIX model is a design toolbox for organizations that prioritizes versatility, continuous innovation, and the human experience. It's deliberately not a rigid framework or a set of prescribed processes, but rather a pattern library that organizations can use like LEGO blocks to build their own unique, adaptable structure. The model focuses on the concepts of small, dynamic teams and empowers managers to facilitate, not control. It emphasizes a bottom-up, flexible approach to help businesses respond to rapid change and avoid the common pitfalls of fixed hierarchies and organizational silos.

The unFIX model adds several useful elements not included in Team Topologies:

• Governance Crew → intended to cover higher-level functions across VSM Systems 3–5 (optimization, adaptation, identity).

• Experience Crew → VSM System 4 (Intelligence & Adaptation, with a focus on customers).

• Partnership Crew → VSM System 4 (Intelligence & Adaptation, with a focus on vendors).

Note: In the illustration I've used familiar colors, making it easy to recognize and match the Team Topologies and unFIX team types (described below). I've collapsed the Experience Crew and Partnership Crew from the unFIX model into one Stakeholder Unit, and I added a new Orchestration Unit. Both are explained below.

Using the additional patterns that unFIX provides, we can achieve closure. We can design organizations that are complete and viable, as described by the VSM.

Mandatory Functions, But Optional Units

From the perspective of VSM, all five layers are essential for an organization to be viable. However, from the perspective of Team Topologies and unFIX, each of the team types is optional. Each team type has a dedicated "home" in one of the five VSM layers but (depending on their cognitive load) any team can assume additional functions across the other VSM layers.

Note: For ease of readability, I sometimes refer to VSM "layers" rather than VSM "systems," but I mean exactly the same thing.

For example, the Stream-Aligned Team (Value Stream Crew) naturally sits at VSM layer 1, which is all about daily operations. But in the absence of other teams, they'll have to absorb the functions of layers 2, 3, 4, and 5. And that might be too much cognitive load for the average agile team!

To properly address the cognitive load (or the "requisite variety" of handling all functions), I propose that each VSM System has at least one (and sometimes two) unit types that consider that System their "home." When cognitive load for any team gets too high, there will be pressure to split the team into separate teams, and the most natural splits to make are according to VSM's five systems: add a dedicated Support Unit (if needed), add a dedicated Service Unit (if needed), add a dedicated Orchestration Unit (if needed), and so on.

Worth repeating: only the functions of the VSM are required for viability. The core purpose of organization design is to figure out how to organize people in teams to partially or completely cover the five functions of the VSM. We can achieve that with one team, with two teams, or with twenty teams.

A solopreneur would be responsible for everything from VSM layers 1 to 5, perhaps while delegating some tasks to AI agents situated in specific layers of the VSM. And a mid-level layer of a large enterprise might have dozens of teams collaborating across the five layers, with multiple teams in each. But the solopreneur and the enterprise both strive for the same thing: viability in a complex environment.

Harmony's Neutral Synthesis

With Harmony, we use the Viable System Model as a starting point to integrate various organization design models (such as Team Topologies and unFIX) into a neutral taxonomy. I propose using the following simple names to describe the purpose of each unit type without allegiance to any specific model.

Note: I use 'Unit' to describe any organizational element that fulfills a VSM function - whether that's a single AI agent, an individual human, a coordinated team, or a loose network of contributors.

• Flow Unit (Stream-Aligned Team, Value Stream Crew)

• Domain Unit (Complicated Subsystem Team, Capability Crew)

• Support Unit (Enabling Team, Facilitation Crew)

• Service Unit (Platform Team, Platform Crew)

• Orchestration Unit (no equivalent in TT/unFIX)

• Stakeholder Unit (Experience Crew, Partnership Crew)

• Governance Unit (Governance Crew)

We acknowledge that VSM's functions are distinct. Organization designers should not carelessly combine System 1 (operation), System 2 (coordination), System 3 (control), System 4 (adaptation), and System 5 (identity) in just one team. While a single unit might cover multiple functions, Harmony emphasizes that these functions remain distinct and, when the cognitive load of covering multiple VSM layers becomes excessive, a separation into distinct units is advisable.

The Harmony Unit Patterns

I want to remind the reader that each of the units described in this set of patterns can comprise humans, robots, AI agents, or a combination of them ("human-AI teams" or "hybrid teams"). We are upgrading existing models for the age of AI, remember? And thus, we intentionally rethink every pattern to ensure it is ready for the future of work.

In later expansions of the Harmony pattern language, we might go into more detail about the various options of human-AI collaboration and what that means for the various unit type patterns. For now, let's define them first.

VSM System 1 – Operations

• Flow Unit (Stream-Aligned Team, Value Stream Crew): Aligned to a stream of value, responsible for end-to-end delivery. It's the typical cross-functional agile team.

• Domain Unit (Complicated Subsystem Team, Capability Crew): Provides deep expertise for complex subsystems or a specialized knowledge domain.

We should mention that both Team Topologies and the unFIX Model have a strong preference for Flow Units (cross-functional teams) over Domain Units (specialist teams). We should only introduce a Domain Unit (Complicated Subsystem Team/Capability Crew) when the cognitive load of its domain/specialization exceeds what the Flow Unit (Stream-Aligned Team/Value Stream Crew) can handle.

VSM System 2 – Coordination

• Support Unit (Enabling Team, Facilitation Crew): Helps other units coordinate, adopt practices, and reduce friction. Typically focused on facilitation and synchronization.

Note: A team implemented as a Support Unit may occasionally veer into optimization (VSM layer 3), but if its role becomes primarily about prioritization and resource allocation, we should consider it to be an Orchestration Unit, not a Support Unit.

When no dedicated Support Unit(s) exist, the coordination functions of System 2 are typically divided among Flow Unit(s) and Domain Unit(s) themselves. (That's the "self-organization" part the agile community loves to discuss.)

Note: The crucial difference between Support Units and Service Units (see the next section) is that Support Units provide coordination help (System 2) while Service Units provide delegated control through dependencies (System 3).

VSM System 3 – Optimization & Control

• Service Unit (Platform Team, Platform Crew): Provides reusable services and infrastructure. While their primary function is reducing cognitive load, their existence introduces a level of delegated control—Flow Units choose to offload certain responsibilities to Service Units, implicitly making them part of the viable system's optimization function.

• Orchestration Unit: Responsible for operational-level prioritization, resource allocation, and workflow integration across units. Often the home of product managers and project managers when operational units cannot absorb this responsibility themselves. (Or when traditional management doesn't trust the operational teams to be self-organizing!)

A Service Unit exercises implicit control when teams have optimized some of their work by allowing themselves to depend on a shared function, preferably offered in a "self-service" interaction mode (see Team Topologies). In contrast, an Orchestration Unit exercises explicit control because its purpose is to decide, in a "traditional" manner, which team gets allocated which work and which resources.

Note: Neither Team Topologies nor the unFIX model offers an equivalent of the Orchestration Unit, because agilists despise the idea of "command and control." However, this "anti-pattern" definitely exists in traditional organizations, and is now making a surprise comeback in the age of AI in the form of AI agent orchestration. AI agents are not humans, and they definitely do not self-organize!

When no dedicated Service Unit(s) and Orchestration Unit(s) exist, the optimization & control functions of System 3 are typically divided among teams implemented as Flow Unit(s) or as a Governance Unit.

System 4 – Intelligence & Adaptation

• Stakeholder Units (Experience Crew, Partnership Crew). Provides strategic-level adaptation and environmental scanning. Ensures long-term viability by connecting the organization to its wider ecosystem. These units come in different flavors:

  • Customer Unit: Focuses on customer experience and market sensing.

  • Partner Units: Manages vendor, supplier, and ecosystem relationships.

  • Compliance Unit: Interfaces with legal, regulatory, and policy environments.

  • People Unit: Focuses on employees, contractors, and talent markets.

We can imagine any number of specialized stakeholder units, depending on the relevance of certain subsets of stakeholders that the viable system needs to respond to.

Note: In response to including the Experience Crew and Partnership Crew in the unFIX model, more than one person has suggested extending the unFIX model with an Employee Crew. In the Harmony language, I propose to collapse them into just one unit type and let organization designers decide how many of them they need, and in which flavors (for which stakeholders).

If no dedicated Stakeholder Unit(s) exist, the intelligence & adaptation functions of System 4 should be divided among the teams implemented as Flow Unit(s) and as the Governance Unit.

System 5 – Identity & Culture

• Governance Unit (Governance Crew): Defines and enacts purpose, values, and culture. In larger organizations, System 5 may be handled by a distinct governance body (e.g., a board or leadership team). In smaller organizations, it may be embodied within a single individual.

Importantly, the Governance Unit operates at the level of the recursive system it belongs to. A team's Governance Unit focuses on its internal culture and working agreements, while a higher-level Governance Unit may take responsibility for the purpose and identity of the larger organization it is part of.

Note: Governance ≠ traditional power. The presence of a Governance Unit need not reinforce command-and-control power structures. Many decentralized organizations (e.g., GitHub, Buurtzorg, Morning Star, Semco, Valve, Haier) use governance functions that are distributed and participatory. The language is neutral on how governance is implemented. I expect this will be a matter of future extensions of the Harmony Pattern Language.

Other Potential Units

I want to stress that the Harmony Pattern Language is supposed to be extensible. We can identify more unit types and add them to the picture later, at any of the five VSM layers. For example, should we add a Project Unit to VSM System 1? Or maybe an Exploration Unit at System 4?

What about circles in Holacracy and Sociocracy? Do they deserve to be included in Harmony as a separate pattern or are they simply units with an unidentified purpose?

What about SAFe roles and teams such as Release Train Engineer (RTE), Lean Portfolio Management (LPM), and the Lean-Agile Center of Excellence (LACE)? Do they easily map onto one of the unit types? If not, do they deserve inclusion as new patterns?

I invite the community to discuss and vote.

Key Clarifications

At the risk of repeating myself, I think the following points deserve mention:

• Functions, not units, are essential. Through the VSM lens, we see five functions that correlate with organizational viability, but the patterns I described are optional. VSM requires System 1 to 5 for viability, but we can instantiate them in many ways: one person, a single team, or many. There is no single unit type that is mandatory. Organizations can assess their coverage of VSM functions and consciously choose how to fill the gaps in a way that does not exceed the cognitive load of any individual person or team.

• Support vs. Control distinction. Support Units are coordination-oriented (System 2), but if they become primarily responsible for resource allocation or prioritization, they effectively act as Orchestration Units (System 3). And vice versa, Orchestration Units are mainly efficiency-oriented (System 3), but if they become primarily responsible for coordination, they effectively drop to the level of Support Units (System 2). I suspect many teams do a mix of both.

• Decentralized applicability. As Stafford Beer has shown, hierarchies emerge naturally. They are not exclusive to traditional organizations—network structures also have hierarchical scopes. (For example, household … street … town … city … district … state … country, etc.) In fact, by adopting Harmony patterns (or their Team Topology/unFIX equivalents), traditionally structured organizations can begin their journey toward a more decentralized, networked organization design—not losing their hierarchy, but allowing it to emerge more naturally.

• Fractal scalability. The pattern language itself is fractal: we can apply the same set of patterns at different levels. Organizations built with these patterns may or may not appear fractal, depending on their emergent structures. It should be evident that an organization is unlikely to be fractal after randomly adopting just a few of our patterns.

• Coherence with optionality. All unit types are optional, and while VSM suggests that covering all functions increases viability, organizations can consciously choose their level of coverage. This means that an organization's implementation of the taxonomy flexes to context, while the underlying functional map remains coherent. For example, there's no law that requires your team to cover the functions of layer 4 (intelligence & adaptation). But as anyone in the agile community knows, if you don't, your team will probably fail faster.

On Holons and Holarchies

On a side-note, the Harmony patterns as described in this document fit neatly with the concept of a holarchy.

The concept of holons, introduced by Arthur Koestler, states that every entity is simultaneously a whole and a part. Nested holons form a holarchy: a layered system where each unit is both autonomous and integrated. This lens fits seamlessly with VSM's recursion principle: every viable system (a team, a department, a business) is itself a holon.

Harmony explicitly embraces this "holonic" perspective. All unit types are holons: complete systems with their own identity and viability, yet also parts of larger holons. This explains why the taxonomy is fractal—it repeats at every scale.

Note: Holacracy was an attempt to operationalize holons through roles and circles. While influential, Holacracy became rigid through its constitutional and top-down implementation approach. In contrast, Harmony treats holons as patterns: flexible, optional, and extensible. In this way, Harmony aims to be holonic without the dogma, drawing on holarchy and the VSM as a systems theory foundation without binding organizations to a single prescriptive method. In fact, we want Harmony to act as the interface between multiple methods and frameworks that can easily co-exist.

---

Welcome to The Maverick Mapmaker — where M-shaped, multidisciplinary professionals learn how to orchestrate work between humans and AI. If you refuse to be put in one box… if your mix of skills is your edge… if you want tactics for thriving in the age of AI without falling for hype or doom — this is your place. Stay sharp, stay multidisciplinary, and stay ahead. Subscribe to my Substack now.

---

Conclusion

The Harmony Pattern Language extends the strengths of existing models while addressing some of their gaps:

• From VSM, we inherit the principle of viability closure across five systemic functions.

• From Team Topologies, we inherit clarity in defining operational boundaries and managing cognitive load.

• From unFIX, we inherit explicit governance and stakeholder relations.

• From holarchies, we inherit the philosophical foundation that explains why these patterns repeat at every level.

By integrating these perspectives, Harmony becomes a neutral, systemic, and extensible pattern language.

With organizations integrating AI agents and digital workers alongside people, we can now update our mental models for the age of AI. (That's why I added the Orchestration Unit, for example.) When we further develop this new language, we can start describing frontier firms, solopreneurs, liquid workforces, DAOs, NAOs, flash teams, multi-agent systems, and autonomous enterprises. And we don't discard the wisdom of the old models. Instead, we stitch them together through a new interface for organizational design. Organizations can still use any model or framework of their preference if they interface well with others through our common language.

I started with Team Topologies and the unFIX model, but there's much more to be done.

Jurgen

P.S. The Harmony Pattern Language is a collaborative effort: community-driven and 100% free to use. Do you want to join the discussion? Contribute your own suggestions and vote on what to include? Join me here.