TTB 4: Everybody Is Saying the Same Thing in Organizational Development
Three Archetype of Nodes ad a Simple Grammar of Agreements
Last month, I sat down with two practitioners whose work I have been following from very different corners of the organizational design world. The first was Niels Pflaeging, author of Organize for Complexity and a familiar name in organization design and development. Niels’s work has always been relevant to me: the idea behind our conversation was to revisit his “Org Physics“ framework, a seminal piece from several years ago that gave me a substantial lens for seeing how, inside most organizations, relational structures overlap with legal ones while remaining inevitably subjugated to the value-creation structures needed to get the job done through domain expertise and mastery.
The second was Alexey Krivitsky, co-author of 10x Organizations and Org Topologies, whose work has been on my radar recently because I felt an overlap with what we are doing on topology at Boundaryless. Org Topologies integrates the organizational-topology conversation with evolution, as we do, and places a strong focus on contextualization and the dangers of adopting frameworks blindly. Both came with their own vocabularies, their own diagrams, their own examples. Neither knows the other’s work very well (I assume), yet when I drew their distinctions side by side, along with other approaches, three structural categories emerged that mapped onto one another with incredible precision. This is not new to me.
Anyone who has been putting out genuinely important ideas about how we organize work in complex organizations over the last fifteen-plus years has arrived at a similar system.
Matthew Skelton and Manuel Pais, in what’s probably the best-known framework, thanks to the widely read book Team Topologies (IT Revolution, 2019), pattern four team types in a (now-familiar) shape: stream-aligned, enabling, platform, and complicated-subsystem teams. Eric Evans, in the seminal Domain-Driven Design (Addison-Wesley, 2003), carves software organizations into core, supporting, and generic subdomains. The genuinely transformative work of Simon Wardley gave us Explorers, Villagers, and Town Planners (three attitudes mapped to the three stages of his evolution axis), as well as the Innovate-Leverage-Componentize framework for understanding innovation. Haier’s Rendanheyi, made open and accessible through Boundaryless’s 3EO methodology developed with HMI (Haier Model Institute), uses User Micro-Enterprises, Node Micro-Enterprises, and Shared Services.
All these communities, who mostly do not read each other (sometimes bordering on conflict), emerged from different problem spaces. IT delivery flow, management theory, software modeling, strategic evolution, Chinese industrial transformation, and agile transformation. The fact that they converge on the same system-of-three reflects something deep about how modular and composable organizations of any non-trivial scale actually work and about the three key shapes that the work of organizing typically takes.
The convergence at two levels
To see this concretely, it helps to lay the schools side by side into what I think is one of the most useful ways to clarify that this convergence operates at two levels, not one: teams and units.
Some schools focus on the capability (or unit) level and ask how such units can be organized within a larger, more complex organization. Here, the unit is the entity in focus: autonomous in delivering a specific set of offerings, P&L-bearing (real or simulated, if internal), market-facing or market-adjacent, and capable of setting its own strategic direction.
Org Topologies, Wardley’s ILC plus EVTP, and Rendanheyi/3EO typically sit here:
Each row encodes a particular combination of market exposure (does the unit face external customers? or can), capability distinctiveness (is what the unit does unique to this organisation, or could it be bought on the open market?), and the direction of strategic autonomy (does the unit decide where it is going, or does it depends on a certain level from enabling scaffolding or centralized decisions?).
Other schools sit more explicitly at the team level (generally a two-pizza team of seven to twelve people). A unit (or organization without sub-units) typically contains one or more teams, and the team patterns describe how the unit organises internally. This is the space where DDD and Team Topologies have traditionally been applied.
BetaCodex is the interesting borderline case here. Cell Structure Design (Silke Hermann and Niels Pflaeging, 2019) builds the whole organisation as a network of team-sized cells, and those cells carry unit semantics: periphery cells hold the market contact, and they purchase services from the centre cells, paying for them. The cell is, in effect, a unit made team-sized – 0collapses the two levels into one. I keep it in the table below because the team scale is where its cells live, but its economics belong to the unit-level conversation.
Read together, the two tables make a simple point: the unit-level schools and the team-level schools operate at different scales. The top table classifies the type of unit you are looking at; the bottom table classifies the type of team that operates within it. They sometimes use the same word – “platform” is the obvious one as it names a unit archetype in one column and a team type in another.
The conflation of these two levels has been, in my reading, the main source of conceptual noise in the org-design discourse of the last decade. Practitioners have at times argued across them as if Team Topologies and Rendanheyi were directly comparable frameworks, when they describe the same phenomenon at different scales of analysis. Once the two levels are separated, the convergence at the unit level becomes obvious, and the team-level patterns become recognizable as how a unit organizes internally, given its archetype. On the other hand, the fact that the language repeats itself suggests that they somehow track the same fundamental dynamics.
I have had direct experience modeling a single Node ME (a technology platform provider) inside a larger industrial company built on a hardware-software portfolio.
Internally, the unit largely operated as a stream-aligned team, but executed a long-term strategy that was largely sponsored and designed by the board, setting the strategic direction. We might be tempted to say that such an architecture does not bode well for autonomy: why should anyone set the strategy centrally? But that is not how things work once development cycles become more strategic and long-term. The fact that such a unit was not made entirely accountable to market signals and retained a certain level of translation of a product development vision into strategy (accumulating a certain risk of being wrong) was also about ensuring the platform unit supported the downstream roadmaps of the market-facing solution units, effectively serving an enabling role in roadmap alignment.
At the same time, as maturation increases, any sane company would try to counteract the captive-market signals from its own product units by opening its platform capabilities to ecosystem partners in an effort to “sense the future,” as Wardley would say.
It is precisely to meet this need that Haier introduced the concept of Node Micro-Enterprises: to instill autonomy, accountability, and healthy tension within the organization.
The team patterns are derivative. They describe how a unit organizes itself given its archetype, market exposure, capability mix, and the constraints the organization places on it. Different units configure their internal teams differently, with different topologies. The convergence is at the archetype level; the team patterns vary within the design freedom that an archetype allows, and that’s exactly what Org Topologies delivery topology explains: in a Node ME / or a technology platform inside a company, serving multiple product units, you may have one team that steers and one that executes.
Why the convergence is not a coincidence
In my experience, this convergence is driven by three economic relationships that exist in any organization above the scale of a small start-up. The first is the relationship with the market: certain units face external customers and bear the consequences of being wrong. They are typically the differentiating ones, the “core” domains of value.
The second is the relationship between those market-facing units and the unique internal capabilities they depend on. These internal capabilities are what make a specific organization distinctive: such units serve other units with something special, even when it is not directly priced in the market.
The third is the relationship with commodity overheads: units doing work the market could supply, but kept internal for reasons of efficiency, coherence, or coordination.
These three types of units also have a clear relationship to innovation. Core nodes provide vertical solutions for the primary use cases of the organization’s end-users; they “operate” the organization’s purpose. Supporting nodes typically “integrate” the diverse needs coming from the market, mediated by the core unit, into more general layers; they become shared “platforms” that support the vertically focused units and push them towards more specialized innovation. Core nodes innovate, supporting platforms leverage, and over time they componentize – standardizing interfaces and modules for others to use more cheaply – so that both internal units and external ecosystem partners can innovate on top.
These internal platforms serve cross-unit needs such as identity, data, UX, and core hardware-software capabilities, while the verticals (solutions) address ICP-specific outcomes. The guiding principles are simple: cleanly separate enabling platforms from vertical solutions and services, and make the bundling of the two a first-class composition.
As maturity grows, the system evolves through the ILC cycle (Innovate → Leverage → Componentize):
It captures emerging needs in the core units, spreads them across solutions
Then standardize them into stable, reusable components to first reduce the cost of innovation internally and later into APIs, SDKs, and modular hardware to promote them into open platforms as shared building blocks for partners
Verticals explore and win on variety and speed, enabling platforms to standardize and scale for coherence and efficiency. Over time, the ILC loop continuously converts proven solution elements into durable platform leverage.
A language for composition
Agreeing on the categories is the easy half. Operationalizing how these units actually interact in a real organization is the hard half. Organizations often lack the collaboration frameworks that would allow units to align autonomously, largely because we still tend to view organizations in industrial terms: vertically integrated, functional, and managerial.
Team Topologies pioneered this space with its “interaction modes” – collaboration, X-as-a-service, and facilitating – but never addressed actual contracts, still implying an organizational authority that assigns roles. Org Topologies maps positions on a grid without specifying the economic relationship between the units that form around its three basic topologies (Resource, Delivery, Adaptive).
Domain-Driven Design offers a genuinely rich set of context-mapping patterns (Customer-Supplier, Partnership, Conformist, Open Host Service, Anticorruption Layer) describing how bounded contexts integrate semantically, but stops short of the economic relationship – who pays whom, who shares revenue, who carries the investment – partly because these patterns were always conceived for teams inside a broader socio-technical system and the responsibility of being accountable to the customer was never really 100% part of conversation.
As a result, the semantic side is well mapped; the contractual side is left implicit.
Simon Wardley is likewise largely non-normative on contracts, even though he recognizes the genuinely pioneering nature of Rendanheyi (and the 3EO), which has embedded contracting deeply into the organizational model, both node-to-node and in more complex configurations. Rendanheyi has adopted investment contracts (its Value Adjustment Mechanisms) as first-class citizens of the organizational grammar, and even invented the Ecosystem Micro-Community Contract, a multi-peer contract that binds several nodes around a complex achievement and introduces frameworks for adaptive governance and shared skin in the game. In their original expression, though, these have been demonstrated to be too Haier-specific institutional instruments rather than transferable primitives.
What is missing across all six is a generative grammar of contracts, plus a theory of the economic interactions between unit types. Both are pieces that Boundaryless has spent years of fieldwork formalizing through our upcoming Open Organization Alliance (O2A) standard (stay tuned and reach out if you’re interested in joining/exploring/pre-reading).
This essential grammar is, paradoxically, small. The three base primitives are:
Purchase: Two units agree to provide a service with an SLA and a payment structure. In the early stages of the evolution, you may not see an actual payment, but at least an agreement specifying what is expected of both parties.
Revenue-split: Two or more units agree to split revenues.
Investment: one or more units agree to invest a capital amount into an investee node in exchange for equity-like ownership.
Two contract-level composition mechanisms complete the grammar:
One for binding many contracts into a single binding agreement, typically across many units.
One for outcome-based triggering, implemented with milestones unlocked either by payers or by oracles (shared sources of truth).
From these atoms, all the named instruments of the other schools can be expressed, and one can architect even the most complex – yet still reasonably manageable – composable organization setups.
In Rendanheyi, an EMC is just a revenue split between N parties, sometimes with a set of outcome-based triggering rules and a shared settlement engine. A VAM is an investment with outcome-based triggering: hit the milestone, receive more equity. In our generalized framework, they appear as recipes, borrowed from Rendanheyi but simplified from institutional monoliths into programmable compositions, because it is time to reach a common language for the platform organization.
If you practice Team Topologies, this reading enriches your toolkit by situating your team patterns within operating units. If you practice DDD, the unit-layer reading and the contract grammar together add two things to your toolkit. First, the unit-layer reading gives you a vocabulary for the organizational attachment of bounded contexts: Evans’s bounded contexts describe semantic boundaries, while the unit-layer reading describes the operating unit in which those boundaries live.
Second, the contract grammar gives you the economic layer beneath your context-mapping patterns. Each integration pattern Evans formalized has a natural counterpart in the grammar:
Context-mapping pattern What the pattern means Contract-grammar counterpart (intuitive mapping) Customer-Supplier The downstream context is a customer of the upstream one: the supplier plans around the customer’s needs, and the customer has a real voice in the supplier’s priorities Purchase contract with downstream negotiating power Conformist The downstream context adopts the upstream model as-is, with no influence over its evolution Purchase contract with upstream-dictated terms Open Host Service + Published Language The upstream context exposes one standardised protocol and shared language for all its consumers, rather than one-off integrations Purchase contract with a standardised service catalogue Partnership Two contexts succeed or fail together and coordinate plans and releases as peers Revenue-split or coordinated commitment Shared Kernel Two teams co-own and co-maintain a shared subset of the model and codebase Investment in a co-owned asset Anticorruption Layer The downstream context builds a translation layer to protect its own model from the upstream one Architectural choice inside one party, not a contract on its own Separate Ways The two contexts deliberately do not integrate at all No contract
So DDD tells you how two contexts integrate semantically; the grammar tells you what is being exchanged economically. They are complementary layers of the same picture.
Wardley practitioners get a contract type appropriate to each evolutionary stage.
Five invariants beneath the grammar
Beneath the grammar sit a handful of practical principles. In our field experience across radically different sectors, they hold at every unit-to-unit interface, regardless of school.
When a unit is deliberately shielded from market discipline, the party providing the shield must bear both the investment and the risk.
The development of a new capability in one node that is needed by another must be either directly funded, paid for with a share of the upside, or covered by an equity-class instrument (a shared cap table). It is never to be assumed as given.
Internal monopolies require governance discipline, or they become a tax on the rest of the organization.
Misaligned incentives between two units cannot be fixed by an SLA alone; revenue-share or shared bonus pools are the only mechanisms that genuinely re-align them.
Two units with high mutual dependency are one unit pretending to be two. The honest move is to consolidate them or to create real exit options.
These five heuristics are invariants you can’t ignore. Any composable architecture that ignores them eventually fails, and we have seen the failure mode in every engagement where one was violated.
The decade of rival vocabularies is closing
I think that - pushed by the need for deep-seated flexibility and interconnectivity - the decade in which each school proposed its own vocabulary as the answer, and we can argue forever that our framework is the right one, is closing.
What remains after the war is over is the substrate beneath it: the nodes, the contract grammar, and the principles that govern the interfaces. That substrate is what Boundaryless has been formalizing through the upcoming O2A (Open Organization Alliance) language, an open grammar for composable organizations.
The long-form version of this argument will appear in a forthcoming whitepaper. This piece is a practitioner-level note; the whitepaper does the long-form work and gives the fuller context.
Curated Links
Team Topologies as the Infrastructure for Agency
Matthew Skelton argues that Team Topologies patterns create the organizational infrastructure needed when AI eliminates traditional hierarchy — exactly the “minimum viable structure” we need to identify.
Special Interview with Zhang Ruimin, Founder of Haier Group
Zhang Ruimin’s 20-year Rendanheyi experiment at Haier offers concrete proof that organizations can eliminate hierarchical superstructure while maintaining coordination through direct user value creation.
Welcome to the personal software revolution
The phenomenon of ‘vibe coding’ demonstrates how AI collapses traditional development infrastructure while making problem definition more critical — a perfect example of structure vs superstructure dynamics.
IC work is the new career flex
Elena Verna’s High-Impact Individual Contributor concept provides concrete evidence for how AI eliminates organizational superstructure while making individual capabilities more valuable.
The Best Companies Will Stop Making Software
The proposed brand-factory split illustrates how AI transforms organizational boundaries across entire industries, not just within companies.
Here Comes (Forward Deployed) Everybody
The emergence of ‘Pit Crew’ roles shows what minimum viable structure looks like in practice — structural roles that bridge generic AI capabilities with specific organizational contexts.
Human Bottlenecks
This analysis of why AI augmentation fails at the individual level explains why organizational transformation requires moving from governing constraints to enabling constraints.
Work Updates
The O2A (Open Organization Alliance) standard is now open for private feedback! At Boundaryless, we’re particularly interested in hearing from operators who are wrestling with the question of structure in their own organizations or from software companies that are operating across the same or - even better - adjacent topics such as governance, OKRs, etc…
Please reach out if you want to have early access for fedabck or to join our upcoming alliance.