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.
Holonic (flow) systems .., but let’s keep rebranding old ideas with new terminology
I was curious to read this article as only recently I learnt about TOSD. The comparison with TT is interesting since for me they are 2 opposite framework, the exact opposite, TOSD is negating the very central point of TT (teams). They both talk about time but they both get it wrong in my opinion as time is fundamentally incompatible with flow. You can't talk about time if you want to create the condition for flow and so there is not time constraints, nor "fast flow".
I was particularly interested in understanding where the comparison between the 3 "school of thoughts" was leading and once I finished reading I did not have much clarity. I think the article tries to say that they are all saying the same thing in different words, I don't think that is true. I think they are very different in their fundamentals. What really attracted my attention though was the video and the interview with Niels Pflaeging attached to this article.
He was presented as having helped many organisations, but there seem to be few public, independently documented case studies showing BetaCodex transformations with before/after data, failures, trade-offs, and replication evidence compared to say TT, especially in the software industry.
From the video I understand and agree that many organisations can be over-bureaucratic, too centralised, and too far removed from real customer value. Isn't this the problem with the European Union, but was brexit the right response? Revolutionary and bold in the proclamation, a great flop in the realisation and implementation. Ok, pushing more decision-making towards the people closest to the work make sense, to some degree, it is a reasonable idea but negating structure or shifting left everything is not the solution. By comparison take again referendums, which are not democracy per se but only one tool, few rare moments of a shift left practice in a a democracy, more on democracy later....
In my opinion in the video Neils confuses "value creation" with "structure" or "formal structure". This is very confusing: value creation is the goal of an any organisation assuming a structure. It is very hard to believe that an organisation does not want to achieve value creation. How can it be? That's the goal, not the structure itself supporting the goal achievement.
A structure, in fact, is very helpful if it explain roles, decision rights, accountabilities, funding, interfaces, and conflict resolutions precisely to achieve value creation and keep the flow of work going. Why would you call that bureaucracy and remove it?
Also, you can get rid of hierarchy without renouncing at a formal structures. Formal does not necessarily mean hierarchical, this is a very important distinction. A cooperative, federation, or democratic association can be highly formal and somehow bureaucratic by design (see the EU again), without being necessarily command-and-control. Is that the best formal structure, probably not, it is way too slow but asserting that the alternative is value creation is not adding any actual value to the conversation or how an organisation should be organised in my opinion: value creation was always the goal. Removing hierarchy, which might be a good thing in many cases, does not remove the need for rules, governance, safeguards and formalisation of the way of working. Command-and-control is just one form of leadership failure, not the definition of leadership or a formal/structured way of working.
The alternative presented risks becoming just too tribal and opinionated. Neils criticises bureaucracy, but then leans heavily on mastery as the solution, and peer recognition and reputation. Talking about reputation is dangerous. These can amplify heroes, insiders, dominant personalities, and existing privilege. For minorities, newcomers, dissenters, or people doing invisible work, this can be even less fair and insidious than formal hierarchy. The problem is not solved for sure, it's shifted and tribalised again.
It seems to me that throughout the interview the centre/periphery model is asserted more than proven. The example of central cells renting equipment to peripheral cells raises a serious contradiction. If the centre owns key assets and the periphery "pays" to use them, then the centre still controls scarce resources. How that is empowerment? It can become a transfer-pricing mechanism where the periphery carries cost, risk, and cognitive load while central asset owners retain power: often the case with "false" devops team in the form of formal Infrastructure centralised teams. This resembles a common failure pattern in digital organisations: “shift left” is presented as empowerment, but in practice infrastructure teams push complexity and operational burden onto product teams without truly making platforms easier to consume. It is obvious that customer facing teams should have more power and room for action. But again a polarising argument takes over pretty soon again: central functions are not automatically wasteful can all be essential to value creation. The question is not whether the centre should disappear - maybe, it really depends from the context - but how it should be governed and made accountable. Many committees are wasteful, political, or bureaucratic. But a committee is simply a coordination mechanism. Some are bad; some are essential.
Turns out that the cell model is still a structure and is not clear how it "creates value" (which is the goal). Peripheral cells, central cells, internal markets, rental relationships, and service relationships are all formal design choices. So the issue is not “structure versus no structure.” It is which structure, with what governance, incentives, and protections.
Finally, the political analogies are confused. The talk contrasts decentralisation with fascism, stalinism, and authoritarianism, and then uses democracy as an analogy for decentralised organising. But democracy is not decentralisation.
Democracy does indeed depends on rules, procedures, delegation, accountability, and limits on power, constitutions! Removing structure while relying on reputation and informal influence will create hidden authority rather than real democracy. A democratic or human-centred organisation will have a degree of "bureaucracy" and formality by design because it needs transparent criteria, fair process, support, retraining, appeal mechanisms, and protections against arbitrary exclusion.