This is an issue of Through the Boundary, my new Substack newsletter. To receive future editions as soon as they’re published, directly in your inbox, you can subscribe here: https://through-the-boundary.simonecicero.com/subscribe

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.

Through the Boundary is about modular organizations in the age of AI. The most relevant ideas emerging from fieldwork.

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.

1. When a unit is deliberately shielded from market discipline, the party providing the shield must bear both the investment and the risk.
2. 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.
3. Internal monopolies require governance discipline, or they become a tax on the rest of the organization.
4. 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.
5. 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.
6. 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.

This is an issue of Through the Boundary, my new Substack newsletter. To receive future editions as soon as they’re published, directly in your inbox, you can subscribe here: https://through-the-boundary.simonecicero.com/subscribe

Organizations face mounting pressure to modularize and decompose, to become flexible enough for a world that refuses to stay predictable. At the same time, AI is delivering an unprecedented boost to productivity and capability. These twin forces are elevating an emergent discipline called context engineering from a technicality left to software engineers into an organizational practice of strategic importance.

Context engineering is the work of building systems that let humans collaborate with agentic contributors while retaining the capacity to observe, steer, and understand what’s produced, keeping outcomes aligned with the needs of customers and partner ecosystems.

Thanks for reading Through The Boundary! Subscribe for free to receive new posts and support my work.

The case for “deep-seated flexibility”

A few weeks ago, BCG’s Henderson Institute released Beyond Tomorrow: Four Scenarios for the World of 2050, and it has been an engaging read.

The report constructs four scenarios to evaluate the often implicit strategic assumptions underlying organizational strategy and development.

The AI Abundance scenario imagines a post-Compute-Wars world of cheap energy, tripled GDP, and AI-only firms. Battling Blocs is a multipolar stalemate where global trade falls and defense spending nearly triples in a re-regionalized world. Climate Coalition charts the stagnant dream of slow, expensive decarbonization disciplined by a $300-per-ton carbon price, while in Digital Darwinism, governments retreat (due to a failure in managing the climate crash), corporations fill the vacuum, we meddle with the atmosphere, and the wealthiest 1% holds nearly half of global wealth.

Currently, the world seems heading towards a mix of all four scenarios. While the scenarios diverge on growth, geopolitics, energy, governance, and demography, they converge on some strategic recommendations. Among the five “low-regret moves” BCG identifies as payoff-positive across all four futures, the same action recurs in a different form: organizational, operational, and technological modularity.

In AI Abundance, modularity defends against compressed technology cycles, modular IT architectures, multicloud and multiregion stacks, and “modular factories that can rapidly adapt to new innovations.” In Battling Blocs, it lets an organization disconnect from one region without collapsing the value chain, thanks to operating structures designed for “relatively easy separation of markets,” and supply networks that can run semi-autonomously while infrastructure is built for rapid swapping and reconfiguration. In Digital Darwinism, with weak institutions and violent markets, modularity becomes the architecture for surviving turbulence, stacks that can be “swapped, isolated, or localized” as conditions shift. In the hopeful scenario of Climate Coalition, modularity and legibility become key at the product layer: circular design and sustainability constraints require components that can be evaluated and recombined.

All these pressures demand a structural answer: an organization whose units, products, and technology stacks are composable. That holds across all four futures.

The convergence is not accidental. McKinsey’s 2026 State of Organizations report, based on a survey of 10,018 executives across 15 countries, reaches the same conclusion: 86% of organizations are unprepared for AI operations, 72% report direct geopolitical impact, and 38% cite rigid structures as the primary barrier. McKinsey describes three significant forces: Technology Disruption, Economic Disruption, and Workforce Shifts, which reflect deeper structural moves: AI redesigning markets by lowering coordination costs, constant boundary erosion between firms and partner ecosystems, and compressed planning horizons under polycrisis.

McKinsey calls for “deep-seated flexibility” but is frustratingly vague about its operational meaning, surprisingly so, because the operational answer has been practiced for years. We’ve described the evolution from functional to matrix to platform organizations for some time, and the implication has remained the same: deep-seated flexibility is what you get when you do the modularization work, not something abstract.

A deeper strategic pattern is emerging. We’ve been calling for companies to complement a platform motion (centralized on coherence and strong integration) with a portfolio motion. Disruptions and technological democratization have nudged companies toward radical optionality for a while, and AI intensifies this perspective by making portfolio motion dominant over platform motion. AI’s coordination capabilities reduce friction in composition and the portfolio motion, creating more options, empowering small teams to attack niche markets with multiple strategies, and making it more viable, reducing the need for traditional centralized approaches. I wrote about it recently in TTB 2, After the Platform.

Both reports miss the implications of the modularity prescription. When everything becomes composable and coordination costs approach zero, competitive advantage shifts from doing things well, which becomes commoditized, to doing the right thing. In an environment where individual optimization is insufficient and connection ability is decisive, something is “right” only if many others can read the same picture you can, and your strategy is wary of partners’ constraints, capabilities, and interests. Investing in shaping a direction and creating shared meaning becomes the work. Ecosystem partners need to converge on interfaces, workflow models, and integration contracts. Shared languages matter more than traditional business development.

Modularity without context engineering produces fragmentation, not composition. The pieces fit together only if they share a language at the boundary, which must be authored rather than assumed.

Consider two teams modularizing a customer-facing capability. One team defines “customer” as the paying account; the other means the end user. When they try to compose their modules, integration fails: not from technical incompetence but from semantic misalignment. The modules are independently correct and jointly incoherent. Multiply this across dozens of bounded contexts, internal teams and external partners, and you get the cost of modularity without shared meaning: drift. Interfaces accumulate ambiguity, and the organization loses the ability to reconfigure quickly.

Context engineering is the discipline that prevents this: explicitly authoring the concepts, boundaries, and constraints that let autonomous pieces compose into coherent wholes. This semantic work is the focus now.

When iteration goes cheap, intent goes expensive.

The transition inverts competitive advantage. For the past four decades, advantage came from operational excellence, executing known processes faster, cheaper, and more reliably. In the AI era, that gap compresses. When iteration is cheap, and the cost of producing a working artifact drops significantly, doing things well stops being the edge. It becomes the price of entry.

Execution capacity, once scarce, is now abundant. The answer to what we should be executing at all becomes the bottleneck. In software, the focus shifts from writing code to modeling business contexts, organizational capabilities, and ecosystem interactions. Gathering requirements turns out, in hindsight, to have been the strategic discipline all along; the cost of bad modeling was hidden under poor execution. AI makes it visible.

This makes intent the new scarce resource, and intent modeling and context engineering are the new strategic disciplines. As iteration becomes easier, we have more time to think. The hard work is upstream of execution: deciding which problems are worth modeling, which boundaries to draw, and which constraints to author into the system for downstream composable generation. Most of us aren’t investing that returned time effectively.

What remains constant: the human at the boundary

One might think that AI, by making translation across contexts easier, reduces the need for explicit semantics. The opposite is true. As contexts multiply and the market fragments, so do the boundaries. Boundary languages become more important, not less, and not for machines to understand each other but for humans to read what happens at the boundary and drive it intentionally.

In a recent conversation with Alberto Brandolini, he reminded me of the distinction between internal and boundary models, which matters here. The internal language within a bounded context serves different purposes than the published language exposed to units and partners, responding to different evolutionary pressures. There will always be pressure for contextual freedom within domains, but the multiplication of AI-enabled contexts makes boundary legibility more crucial.

This connects to what I have come to think of as the invariant design constraint: human observability and interpretability.

If you build something at the limit of human observability and legibility, model evolution may not affect your product in meaningful ways. When designing new collaboration tools, use human cognitive limits as the primary design constraint rather than AI capabilities. Even as AI improves, human limits remain stable, which makes them a more durable foundation for organizational design than a shifting model frontier. You can design prosthetics that augment observation, a tool for engineers to review workflows faster, or a linting dashboard monitoring KPIs for software best practices, but ultimately, humans need to review, read, and close the feedback loop.

The primary value of context engineering, then, is not in tightly controlling AI outputs, but in maintaining intentional direction-setting and the ability to observe, evaluate, and comprehend the generated content. Subjecting our AI leverage to our understanding will keep things small, modular, and human.

Control matters less than clarity and strategic alignment.

Context engineering becomes the discipline of deciding which artifacts define truth and of authoring the constraints, both of which are central organizational capabilities.

Not a function. A discipline.

Context engineering is a pervasive organizational capability, not a technicality. Large organizations will need multiple context engines operating at different scales; each bounded context requires its own micro-context engine while maintaining coherence with the broader organizational ontology. External ecosystem players must participate in defining the languages, which represents a structural break from traditional platforms that imposed their own linguistic standards.

Context engineering is not about software. It’s a deliberate practice through the same framework across contexts where an organization builds artifacts by integrating agentic capabilities. Whether managing autonomous IT infrastructure, creating AI-assisted media, or recombining organizational capabilities with their interfaces and costs in response to customer needs, the same principles apply.

Three legs, one bundle

In our experience at Boundaryless, context engineering has a three-pronged architecture:

1. A deep meaning layer, typically a context map identifying the bounded contexts in scope, and a navigation language between the map elements describing the key objects existing at the contexts’ boundaries.
2. A business and problem logic layer detailing roles, their capabilities, and use cases with related scenarios, all mapped to the bounded contexts.
3. A user experience and interaction layer, explaining how the capabilities are available to users across interfaces, depending on the product(s).
4. The definition of all three layers cannot be fully delegated to AI. It must remain at human scale; if not fully human-produced in front of a board (ideal), it must at least be fully human-comprehensible.

A Context Bundle is the structured artifact that answers four questions:

• Which concepts are valid?
• Which problem areas are separate and can be developed independently?
• What abilities do actors have?
• What experience do users have?

It’s structured context readable by humans and usable by agents, versioned as intent changes. It provides a method to make organizational intent machine-readable while keeping it human-inspectable.

Whom do I choose to share context with?

Conclusion: in a world of microscopic, modular, adaptive, and AI-enhanced elements, the organization’s value lies in its ability to contextualize.

Identity is no longer defined by our actions but by our configurations, chosen constraints, preferred patterns, and accepted trade-offs.

When an organization decomposes into small, agent-powered units, context becomes the primary organizational attractor, replacing hierarchy, process, and culture as the forces that hold activity together. Hierarchy, process, and culture do not vanish, but become insufficient as primary coherence mechanisms in front of the unleashed generative forces.

The organizing question becomes: with whom do I choose to share context?

Context engineering is the new frontier of organizing. Companies that neglect it will keep telling themselves they can resist modularization by vertically integrating and managing up and down, and they’ll progressively lose coherence, sometimes gradually, sometimes abruptly.

Companies that get this right resemble living systems of meaning: pieces that rapidly reconfigure while keeping identity through constraints and shared intent.

Curated Links

Beyond Tomorrow: Four Scenarios for the World of 2050, April 2026, Nikolaus Lang et al. (BCG Henderson Institute)

BCG’s scenarios reveal that organizational modularity is the consistent strategic move across all possible futures, whether AI abundance democratizes coordination or digital Darwinism concentrates it among elites.

State of Organizations 2026: Three tectonic forces reshaping organizations (McKinsey)

McKinsey identifies “deep-seated flexibility” as the key organizational capability but stays vague about implementation, exactly the gap that explicit context engineering and modular capability-based organization design (RenDanHeYi / Platform Org) addresses.

Apps and programming: two accidental tyrannies

Matuschak’s lecture advocates for composable product architectures and demonstrates how shared semantic foundations (like CodeMirror’s physics) enable plugin ecosystems, encouraging us to think beyond applications. Increasingly relevant as we move into a software-infused age.

AI in World Machine Theory

Rao’s AI framework creating planetary-scale liveness through shared context and memory integration provides the macro lens for understanding how context engineering scales beyond individual organizations to ecosystem-wide coordination.

What is Artificial Experience (AX)

As humans become the limiting factor, the task is to become artificially intelligent, not like machines, but in consciously designing technological futures rather than sleepwalking into whatever emerges. AI as a problem for thought about how we wish to live, not just a problem to be solved.

The Culture of AI Engineering

The Pace Layers framework reveals why AI makes organizational structure more necessary: different context elements must operate at different speeds while maintaining coherence across the entire system.

Work Updates

We’re making progress on the context engineering framework through client deployments and technical development:

• Context Bundle implementation: we built and tested the first Context Bundle prototype, exploring how structured product intent can be made readable and operable by agents.
• O2A specification advancement: the Open Organization Alliance standard now includes formal semantics and is about to be released in its first public version. Discussions with the Protocol Institute about support are ongoing. If you don’t know what the Protocol Institute is, check it out.

I’m looking for design partners who recognize that their competitive advantage lies in context engineering rather than operational execution, and who understand that connecting that to the rest of the organization requires modularization. If you struggle to coordinate capabilities across internal teams and external partners, or see AI create more options than your structure can handle, I’d love to explore how these frameworks apply to your challenges.

Thanks for reading Through The Boundary! Subscribe for free to receive new posts and support my work.

This is an issue of Through the Boundary, my new Substack newsletter. To receive future editions as soon as they’re published, directly in your inbox, you can subscribe here: https://through-the-boundary.simonecicero.com/subscribe

“We want to be the platform.”

At least three leadership teams from different industries (fintech, egov, energy services) have approached me using that exact phrase in the past two months. They have little in common except that, for various reasons, these industries are opening up.

Sometimes it’s a regulatory initiative aimed at breaking long-standing quasi-monopolies; sometimes it’s the effect of AI as an integration technology. In digitally ambitious countries — like India, for example — it’s often the creation of a Digital Public Infrastructure — sometimes for other reasons.

Layers of the value chain that incumbents owned end-to-end are now being cracked open at the protocol level, and the boardroom response is often reflexive: let’s now be the orchestrator before new entrants frame the market.

The platform answer is correct, and the ambition is fine. But it’s almost always incomplete: many product teams carry assumptions from a different era. The capital-P “Platform” (the market-shaping posture from the early 2010s, where one company became the meeting place for supply and demand) is no longer viable. As digitalization moves into real-world industries (energy, mobility, healthcare…), markets are too crowded, open, participatory, and filled with incumbents holding many value chain pieces that a wannabe platform strategy can’t wish away.

The posture that fits this new environment is more systemic and modular: a clear reading of the existing ecosystem, an honest accounting of your fit, plus a portfolio of moves that provide the right value to the right people.

Milan Guenther’s insights from our recent podcast clicked for me: great customer experience visions often fail because we focus on designing the output rather than the thing delivering it.

Organizations spend months perfecting the customer journey map while leaving organizational capabilities and coordination systems as second thoughts: the organizational substrate is often left unarchitected.

The infrastructure that has to exist first

The strategy conversation often collapses into a product one: should we build the aggregation frontend or a multi-tenant onboarding portal? These questions should be seen as downstream of an infrastructural piece for the strategy: semantics, API layers, data, partner onboarding capabilities, observability, and primitives.

These things don’t serve just one product or platform strategy. Rather, they make a substrate for future services.

Once the question shifts from ‘should we build X?‘ to ‘how do we use this challenge to reshape the company’s capability stack and portfolio?,‘ the discussion changes radically.

From a financial and technological perspective, we’re no longer considering a product launch but an urgent multi-year compounding investment. Boards face a harder question: what is the company’s role in a horizontally and modularly organized market?

The challenge is that you cannot expose a clean, modular, well-modeled surface for partners to connect to while running internally on a tangle of implicit dependencies and unclear capabilities.

If partner onboarding drags for months, it’s due to unclear internal capabilities. Deadlocks can’t be technological (AI can integrate anything), but they can be semantic and strategic. It’s because you likely don’t know how to classify and integrate a partner in your company’s value delivery to customers.

You may have a strategic issue: a lack of what Jack Dorsey recently called a company world model (your capabilities and how to mobilize them) and a customer world model (the ecosystem of needs you exist within).

If these are unclear, you can’t articulate your units’ offerings: pricing will become a nightmare, upsell and attach strategy will lag, ARPU will stall, and SLAs will be hard to keep due to uncharted internal dependencies delivering customer value.

In the end, the cleanliness of a published interface depends on the cleanliness of the bounded contexts (well-defined boundaries between business parts) within your company.

The platform you bring to market and the operating model that produces it are the same artifact, viewed from two perspectives.

Catching up with your operating model

What do you do alongside building your platform strategies? What work needs to be done on the operating model? Over the last couple of years, a sequence has emerged for us to do this organizational enablement work in a repeatable way. It’s more useful to think of it as a sequence where each step is the precondition for the next.

The first step is node mapping: every unit, team, and external partner in the current value chain. I’m not talking about an org chart, rather what I recently called the chain of promises: who depends on whom, under which implicit terms, obligations, and compensation?

The second step is unpacking offerings. In a complex organization, each node holds a bundle of specific, mostly unique offerings. The job is to spell them out: what does this unit do, stripped of its history and politics?

The conversation gets uncomfortable here, because this unpacking exposes things nobody wants to make explicit (organizations aren’t markets, right? Just wait a few months): duplications, dependencies that shouldn’t exist, missing capabilities that everyone assumed someone else owned. But that’s the work to do, where it hurts the most, where the information asymmetries have cracked the organization’s effectiveness.

In a recent engagement, a senior leader asked me: “How many dependencies are too many?” And the only honest answer is that sometimes it’s not about unbundling but rebundling: if two units depend on each other all the time, they’re not actually two units; they’re one pretending to be two; they exist because we needed two small kingdoms for two managers. This mapping exercise will reveal it. Once you see it, you can act.

The natural end of this first step is building the service catalog: Layer 0 in our framing. With nodes and capabilities now legible, you can describe what each unit offers to the organization (and eventually, to partners).

When we do this work, we try to do it by archetype. Organizations typically have recurring types of units, shared services, product units, incubated ventures, cross-cutting initiatives, or specializations. They differ in economic logic, dependency structures, and contracting expectations. Naming the archetypes simplifies a messy organization into a small set of templates, each onboarded to the new model.

Then you can finally move into pricing types and business equations. After understanding their cost structures and dependencies, each archetype can define the contracting it aims to use with external or internal customers and providers: tiered subscriptions, on-demand purchases, revenue-share agreements for strategic collaborations based on shared outcomes, tax-based payments for shared services (e.g., as a % of revenues), and internal investments. For a unit to define these service models and business equations, such as how a shared service charges back, how a product unit attributes margin, or how an incubated venture reports progress, becomes the templates that pave the way to real autonomy.

Only at the end does the layered architecture becomes clear: if at Layer 0 you achieve visibility into the catalog, at Layer 1 you can start with virtual economics and shadow P&L. Internal showbacks become possible and meaningful. After overseeing, you can move into Layer 2 with real chargebacks, settlement, and financial autonomy for the nodes.

Suddenly, you are no longer a clunky organization with a (fake) annual budget, requiring continuous board escalations, unclear priorities, and failing commitments. You’re a well-oiled marketplace of capabilities, with clear costs and SLAs.

This sequence connects to a research question in this newsletter, that of Minimum Viable Structure: how much explicit topology, taxonomy, and contractual semantics is enough to maintain coherence once the superstructure (middle management) is removed? This pipeline is an operational answer: the right level of structure will be whatever this process produces in that organization, validated through real use. There’s no universal optimum because the domain change rate varies by industry.

In my experience, companies that fail at this work are the ones that turn it into a megaplan and never start mapping and moving to layer 0: our approach is intentionally layered (Layer 0 before Layer 1 before Layer 2) and portfolio-shaped (multiple unit archetypes, multiple pricing types, no single bet) because the era of all-eggs-in-one-basket Platform transformation that takes 3 years to start is over.

Map nodes as archetypes, write a service catalog for one company slice, and let the rest copy what works. Possibly, the most consequential move you could make this Monday is opening a document and starting to list the nodes, offerings, and dependencies.

Modularity in an agentic age

As if this challenge wasn’t enough, AI brings more: the design problem is shifting from “how do we make this modular?” to “how do we make this agent ready?”

Traditionally, modularity focused on structural decomposition: breaking monoliths into services, products into components, and organizations into units. Now, agents need modules that can describe themselves and negotiate their own composition.

An agent-friendly capability (product, service, unit…) must expose and enrich its interface with context: what it does, constraints, costs, and dependencies: I’m node A; I offer services X, Y, and Z; they cost this, and can be negotiated with these SLAs, and this purchasing model.

When a node exposes its capabilities through machine-readable semantics, agents can reason about it, propose combinations, and form new value chains that include humans providing necessary oversight to prevent misalignments and ensure “intention.”

Context engineering as the new frontier: and the symbient question

As we move toward flatter, modular, and agentic structures, implicit context must become explicit and usable. Context engineering becomes the core organizational capability.

Once the organization is decoupled and modularized, this “Company Model” makes the organization machine-readable, reduces entropy risk, and prevents work duplication and local optima at the expense of the whole. AI agents need the same structural context as the human teams, but in an explicit, machine-readable format.

But in this process of making organizations “computable” and “composable,” there is one tension to flag explicitly. It’s been bothering me for weeks. The practices we rely on to make organizations legible and composable, like Domain-Driven Design, Context Mapping, and contract design, emerged in deeply human sociotechnical contexts.

They were often built to manage politics, knowledge asymmetries, and cognitive constraints within human teams.

These practices are the best we have, but - in adapting them to the AGI age - we still treat the agent as the receiver of our modeling, strategies, and decisions: a consumer of the ontologies and bounded contexts we produce with the assumption that the pipeline is good when the agent creates the desired outcome. Today, it’s with Software development and the harnesses we’re inventing for this. Tomorrow, we’ll assume the same posture with organizational development: we’ll deem the agents good only if they implement a strategy that we define in our boardrooms.

But I’m increasingly convinced that this assumption is wrong, and the output changes substantially if we treat the agent as a symbient, let it surface ambiguities, misses, and expose our conceptual, organizational, or technical debt.

If we recognize that agents (AGI) have subjectivity, we should consider new practices that co-evolve with this new contributors. This - I believe - will change what we build, not just how.

The commons question

I believe this transformation will converge on commons-based infrastructure. A horizontally organized market is one where value isn’t captured by owning a vertical stack, but by participating in shared interfaces.

The proprietary nature of previous generation of software and organizations can’t carry this load. Open-source models, canonical schemas, and standards like our upcoming O2A are the only economically coherent answer to a market where every player is a partner, competitor, and integrator.

Also, if we recognize AGI as a new subjectivity and a manifestation of our knowledge commons, this revolution will simply happen, in spite of our competitive stances and strategic plans.

It will level the playing field around commons and commodities.

Where this leaves us

The word is out. Open standards, AI as integration substrate, and mounting performance pressure means “we should build a platform” is a correct but incomplete answer.

We’ve learned that the platform you bring to a market is a manifestation of the platform you are internally. Of your composability, modularity, autonomy, and legibility.

Your AI readiness is a byproduct of making capabilities composable, context explicit, and contracts machine-readable.

The costs of bespoke integrations, unmodeled capabilities, and unreadability to your teams, partners, and agents compound.

Semantic debt accumulates and will be repaid later, with interest.

Nothing significant today is feasible in a fully proprietary, winner-take-all stack: a horizontal market requires open, and possibly commons-based primitives.

Are you keen to plunge into the cold water?

Reach out to do some work together.

Curated Links

Harness engineering for coding agent users

A concrete preview of minimum viable structure in practice: how automated ‘harnesses’ could replace traditional management oversight in modular organizations, making self-governance scalable through feedforward guides and feedback sensors.

“The Building Block Economy”

Hashimoto’s observation that AI-native development favors composable building blocks over monolithic applications maps directly to organizational design. AI coordination naturally selects for modular, well-specified capabilities that can be discovered and composed without human intervention.

An Equilibrium Theory of Vertical Integration

A framework for when AI-era organizations should build vs buy vs orchestrate capabilities, using concrete criteria that predict which integrations will survive modular disruption.

Coase vs. Claude and The Future of the Firm

Haier’s micro-enterprise model provides concrete evidence for how organizational decomposition works at scale, showing that the future isn’t JUST fragmentation but ALSO intelligent recomposition around shared platforms.

The future of work is world models

Krishnan envisions centralized “CEO playing Starcraft” but a more compelling direction: when capabilities become programmable, strategic oversight transforms from exclusive role into distributed platform accessible to all organizational participants.

The Vibes Don’t Scale

A software engineer’s discovery that AI agents need the same structural context as human teams — but explicit and machine-readable — offers a concrete preview of what ‘minimum viable structure’ looks like when semantic drift becomes the primary organizational failure mode.

Inside Meta’s push to turn employees into ‘AI builders’ and reorganize teams around small pods

Meta’s Reality Labs restructuring into AI-native ‘pods’ offers a major case study of minimum viable structure in action to see what organizational architecture survives when AI eliminates traditional coordination layers.

Work Updates

We’re quite close to formalizing the first shareable version of the O2A (the organizational modularity standard we’re about to release), and we’ve been asking whether this constitutes our “published language“ in Domain-Driven Design terms or a full ontology (which is rather hard to pin down). The distinction matters more than we initially expected and represents a problem that all the organizations we’re working with face as they search for an internal language for their teams to co-build and an externalized language for partners. A published language emerges from the boundary between bounded contexts: it’s somewhat political, negotiated, and reflects the power dynamics of who controls integration points. On the other hand, an ontology claims to model reality itself, independent of organizational boundaries. The question is still open. The answer will likely be in the middle.

Get in touch

If you’re facing a platform transformation or pondering it. I’d love to hear about it. The patterns we’re seeing across industries are remarkably consistent, but each implementation teaches us something new. Reply with your context, and I’ll connect you with others working through similar transitions. Design partners for O2A implementations are particularly welcome.

In 1937, Coase asked, “Why do firms exist?”

His answer was that transaction costs make internal coordination cheaper than market negotiation. It earned him a Nobel Prize and marked the start of seventy years of applying such a theory to observe organizational development.

Ninety years and several S-curves later, we lack a usable language for describing what an organization is as an operable system.

We have ERP for resources, CRM for relationships, PM tools for tasks, and OKR frameworks for alignment. We have org charts (often describing reporting, not actual work), process maps (describing flows, not structure), and strategy decks (focusing on aspirations). None of these tells you the essential elements of an organization and their relationships.

For decades, the gap has been tolerable. Organizations compensated with layers of middle managers to carry the missing context — who does what, who owes what to whom, which products depend on which capabilities, and the constraints. The knowledge lived in people’s heads, and that was sufficient.

It’s no longer sufficient. When AI becomes the coordination technology, agents need to understand the commitment structure, dependency map, and capability boundaries. Without explicit organizational semantics, AI becomes an entropy multiplier.

Agents cannot consume the implicit context that kept organizations together for a century.

I’ve been writing for almost 20 years, leading to the Platform Design Toolkit and founding Boundaryless. I’ve been quiet for a few months, reorganizing my research questions and the work we do at Boundaryless. I feel we are passing through a boundary: between the organization we inherited and whatever comes next. So I’m writing as we cross it.

This newsletter — Through the Boundary — feels like the beginning of a new exploration, but one my work was designed for. It’s a working thesis developed in public, with genuine open questions.

The Organization, as I understand it, is four intertwined things: a topology, a taxonomy, a shared context to be engineered, and a chain of promises and dependencies.

If you strip an organization to its operative essence — below the strategy decks, org charts, and mission statements: what remains? After years of work with organizations across industries and scales, healthcare, industrial measurement, financial services, urban mobility, enterprise software,….I’ve come to think the answer is four deeply intertwined things.

The first is a topology. Who does what? The nodes, teams, units, their boundaries, domains of responsibility, and archetypes.

James D. Thompson’s 1967 Organizations in Action established a key insight in organizational theory: there’s no universally optimal organizational structure. Structure is contingent — it depends on work type, technology, and interdependencies. The implication is that topology isn’t a one-time design choice but a variable that must adapt as work, technology, and interdependencies change. In the same year, Mel Conway observed that a system’s structure mirrors the communication structure of the organization that builds it. Conway’s Law has since been validated in software engineering, and its corollary is: if your products are to be modular and composable — especially with a new coordination technology — your organization must be modular and composable.

Functional hierarchies organized by discipline rather than value produce monolithic systems and thinking. It’s too late for functional structures. The current reality demands node-based topologies: small, domain-aligned units with clear boundaries, simple to reconfigure as work changes. Simon Wardley built a mapping practice around the idea that components evolve through maturity stages and their position in the value chain determines strategy.

These perspectives converge: to understand an organization, you need to know the pieces, their dependencies, and how that structure maps onto the architecture of their output.

The second is a taxonomy. What the organization’s products are and their relationships.

A product (or service) is seldom isolated: it often runs on, extends, bundles, or componentizes into something.

These structural relationships encode the logic of portfolio coherence. A consulting service that repeatedly solves the same client problem is a candidate for productization; a software module that every integration partner needs is a candidate for platformization. Wardley describes this maturity journey as the ILC cycle: Innovate (bespoke, client-specific) → Leverage (reusable, packaged) → Componentize (standard, self-service).

Without an explicit taxonomy, the organization cannot see how the asset system is progressing; the portfolio becomes unclear to itself and any agent that could help recompose it.

The third is a shared context. The representation of the organization’s operational world, including ecosystem relationships, client problems, and domain language: the rationale behind the objectives.

This is the ontology of the value the organization produces: what are the customer needs? Who are the partners and how do they participate? It’s what traditionally lives in the heads of experienced people. The mythical domain experts, and it’s where strategic intent gives purpose and direction to the organization’s capabilities.

I often face these challenges: recently, we ran a context-mapping exercise with a large industrial client with several teams building interconnected software products. We discovered no shared understanding of dependencies across teams. Each team could describe its domain precisely, but the overlap logic was invisible, carried informally, or duplicated and misaligned. The gap was in context awareness: no shared representation of how the pieces fit together existed. The same gap is in every organization we’ve worked with recently, from industrial data measurement to financial services: the context remains implicit. It’s an institutional memory (often at the top), not a queryable artifact. This problem is evolving today as GenAI enters and transforms the space.

This is what I believe Dorsey recently called a “customer world model” in his seminal piece, “From Hierarchy to Intelligence.” In my experience, this is not a single unified language but multiple linguistic layers coexisting, each serving a different purpose within a bounded context. In these small bubbles, semantic rigor is essential, and AI can support prototyping, operations, and development. Then there is a more inter-contextual space, where language should focus on navigation and interconnectivity to enable longer, complex inter-domain workflows as stakeholders move across systems.

These ontologies shouldn’t be produced top-down with single-document specifications. Even if coherent, these upfront artifacts wouldn’t endure real-world revision.

Anyone working in agenting programming — a precursor of agentic organizing — knows that context engineering, “the work of selecting, structuring, and continuously updating the information that reaches an AI model when it performs a task”, is essential to get the agents to do what we desire.

After all, we had decades of experience in domain modeling, from Eric Evans’s DDD work in 2003 to Brandolini’s Event Storming practice, we’ve been converging on this lesson: ontological assumptions specified before operational validation are expensive to maintain. Making context usable requires it to be lightweight and validated through use. Add the rapid evolution of agentic capability, and now you’re required to progressively graduate the patterns through which users experience your solutions.

The guiding principle could be called Minimum Viable Semantics:

• First, model only what’s necessary to avoid ambiguity at the boundary between bounded contexts (for navigation, inter-domain consistency…).
• Then, validate everything else through practical use.
• Graduate to standard/specification only when the pattern is consistent.

The “customer world model” needs a connection with the organizational layer and the ontology of the organization’s capabilities: what are the units, components, service catalogs, and recombination rules that define what the organization can do and how its Lego blocks can be reconfigured. Dorsey calls it the “company world model”; we call it topology and taxonomy.

The company world model is how the company understands itself and its own operations, performance, and priorities, replacing the information that used to flow through layers of management. The customer world model is the per-customer, per-merchant, per-market representation …

From Hierarchy to Intelligence — Jack Dorsey

When these two dimensions are explicit and coherent, an organization becomes far more able to perceive change in its environment and meaningfully reconfigure itself in response.

The fourth factor is the chains of dependencies and promises. In this context, a customer outcome results from multiple nodes making and keeping commitments to one another — held together by contracts, explicit or implicit, not by hierarchy. Mark Burgess’s promise theory frames this precisely: value delivery is interdependent, and each node must have commitment-making agency. Nodes can fail, and robustness requires alternatives rather than escalation. When structuring multi-unit contract architectures for clients running complex multi-entity operations, the contracts are not mere administrative instruments: they are alignment and coordination mechanisms that encode who owed what to whom, under what conditions, and with what consequences for success and failure.

“Contracts over budgets” shouldn’t be seen as an economic efficiency argument but as a structural prerequisite for composability. They dictate the conditions for units to recombine without asking a central authority. This changes the coordination idea: from imposed by hierarchy to emerging from the network of commitments. Even if GenAI drives the recombination as in Dorsey’s vision, the rules, interfaces, and contracts needed to mobilize capabilities need to be clear and available; we’re just prototyping a situation where AIs enact organizational changes without any observability, otherwise and where humans are mere flesh-made cogs operated by an intangible intelligence.

When these four elements — topology, taxonomy, shared context, chains of promises — are explicit and operable, the organization can adapt. Any participant, whether a team, partner, or AI agent, can understand the structure, propose new combinations, and negotiate participation. When they are implicit and dispersed, the organization is fragile. AI makes it more fragile, faster, because it amplifies the consequences of semantic drift at machine speed.

If these four elements fundamentally define an organization, what does AI actually change?

Structure and superstructure

I think AI doesn’t change an organization’s key elements; rather, it shifts the balance between two things.

Something we could call superstructure, which consists of (often hierarchical) management, (often bureaucratic) processes, and middle management as context translators: this is what AI eliminates the need for. Agents can coordinate and translate context better than humans, manage information, and surface the right data at the right moment. All functions that previously required human intermediaries.

The structure, on the other hand, in the form of unit topology, product taxonomy, contract types, and shared semantics on the value that the organization produces, the skeleton itself… is made even more necessary by AI because it is the foundation for agents to operate predictably, explainably, and observably. An agent managing a contract needs to know the existing rules, nodes, and terms. An agent composing new service offerings needs to know available capabilities, unmet customer needs, dependent offerings, and viable combinations. Without this foundation, agents drift and hallucinate.

Contemporary software systems are not built by writing code, but by engineering contexts that produce correct code. I believe organizations will be built similarly, not by managing people, but by building shared contexts (organizational setups, constraints, and semantic models) that produce coherent coordination. If this holds — and the work with clients and on our products suggests it does — then the understanding of the organizational context and the engineering of it is not a support discipline but synonymous with organizing itself: if an organization is a system of people and agents converging around shared problems, then the representation of those problems, structures, and procedures is the organization’s core.

Six unanswered questions

As I launch this newsletter, I want to be transparent about what I don’t know: these are the research questions guiding my work, conversations, and product development at Boundaryless.

Each newsletter issue will explore a facet of one or more of these.

What is the minimum structure an organization needs? AI eliminates the need for superstructure but makes structure more necessary. How much is enough? Too much recreates bureaucracy in semantic form with rigid ontologies that nobody maintains. Too little, and teams and agents drift without shared reference, optimizing for their own local context. Each layer of explicit structure has a production and maintenance cost: formalizing a domain model is not a one-time investment but a continuous curation effort, because context rots as domains evolve. This means the optimal level of structure depends on the rate of domain change. Stable domains (e.g., organizational setup, contracting) tolerate more formalization because context degrades slowly. Fast-evolving domains (e.g., AI tooling, market needs, novel products) tolerate less because context degrades before it can be amortized. Finding the curve of cost versus benefit — and understanding how it varies by domain velocity — is a key design question for the next decade.

On which layers does AI favor consolidation, and on which does it favor distribution? I originally thought AI would further fragment the market: if a technology makes coordination easier, why wouldn’t it reduce the minimum efficient scale of independent capabilities in the firm? Coasean logic suggests when transaction costs fall, firms shrink as more activity moves to markets. But this framing (centralization versus decentralization, consolidation versus fragmentation) treats these as competing forces on the same axis. I think the picture is more interesting: AI makes coordination cheaper unevenly, dramatically reducing the cost of coordinating codifiable, routine knowledge, but creating contextual, domain-specific knowledge usable by AI (context engineering) remains a costly, human-intensive activity. That cost doesn’t go to zero as models improve; it regenerates at each new AI capability level, because each capability opens new use cases requiring context work. The implication is a dual motion: centralization succeeds at the infrastructure and coordination layer (shared processes, codified knowledge, standard operations) while distribution persists at the application layer (domain-specific context, customer proximity, local judgment) — which makes the case for organizations to build a dual platform-portfolio motion as I explained months ago. And there is a temporal dimension: context rots over time, limiting centralization at scale. Beyond a point, the cost of maintaining centralized context coherence grows faster than the advantage it delivers. The new boundary between firm and market will probably depend on where the boundary of a context that is relevant enough to attract and cohere, and not too expensive to maintain, sits.

Does context engineering become ecosystem engineering? If context is easy to create, what makes it valuable? The current hypothesis: the real attractor is continuous context engineering capability. In the deterministic world, ecosystems were enabled by APIs, rigid, typed interfaces. In the agentic world, ecosystems can be enabled by what I call context interfaces: semantic, non-deterministic surfaces for agents and humans to build adaptively. If this is true, context engineering evolves into ecosystem engineering, and the platform theory changes: an API-based platform has network effects tied to integrations; a context-based platform has network effects tied to shared semantic richness AND semantic shareability, but only if that richness is maintained.

How do you design for failure in a composable world? In an organization built on dynamically connected chains of promises, node failure is the norm. When a capability node in these chains cannot deliver on its commitment, the entire value chain is at risk. Can the resilience patterns of distributed systems (circuit breakers, fallback, death and rebirth) apply to organizational design? In a hierarchical organization, when something fails, management intervenes. In a composable organization based on contract chains, who intervenes when a promise breaks? Nodes can fail obviously (failing to deliver) or swiftly, delivering something that looks correct but is strategically misaligned (it’s easy to be productive!): the organizational equivalent of an AI hallucination: confident, plausible, nice…but pointless.

What should be common and what proprietary? AI needs shared context to coordinate, and shared context generates semantic network effects: the more actors adopt a common language, the more useful it becomes, and the more effective AI is at composing across boundaries. Ontological elements like languages, taxonomies, and shared models are non-rival goods (they do not “consume” and gain value as more people use them). This means that the productive logic of AI may itself select for the commons at least (and for now) at the language layer. The organization that keeps its schemas proprietary deprives itself of network effects; the organization that opens its grammar layer maximizes the surface for AI and the ecosystem. The open-core pattern emerges as the only viable one from this logic: open grammar (schemas, contracts, workflow primitives), proprietary engine (identity resolution, settlement, entity biography accumulation). But open grammars aren’t free to maintain: semantic commons need active governance; someone must curate, update, and prevent context rot in the shared standard. The friction may be between an open, static specification anyone can fork (“I’m just making it open so anyone can build on it”), versus a curated, maintained, actively governed specification that evolves with the domain and aggregates various stakeholders. The curation of the living grammar becomes a source of value and a form of institutionalized labor someone must pay for. Whether Ostrom’s principles for governing natural resource commons apply to semantic commons is an open question.

If the organization is its context, what’s its identity? In a world where agentic production makes everything composable and the cost of production approaches zero, identity may emerge from what you choose not to do or to do in a specific way. Intentional constraints (ethical, sustainability, domain-specific) may become the primary source of differentiation. Since the ontological layer (languages, taxonomies, shared models) is a non-rival common good, organizational identity cannot reside in the possession of that language. Anyone CAN use it, as many as possible SHOULD use it. Identity shall reside in the unique configuration an organization imposes on shared primitives, in the constraints it chooses, the trade-offs it accepts, and the patterns it prefers. But context rot introduces a temporal dimension: if identity is based on meaning (on semantic configurations), and context degrades, then identity requires continuous gardening. Stop that, and your identity drifts into incoherence, leaving no one able to articulate why the organization exists. A sustainability constraint declared in 2024 means something different in 2026 as supply chains shift, regulations evolve, and new materials emerge. The constraint must be continuously reinterpreted and reoperationalized. Your organization will always have to take a stance: what is your “signature” in that configuration? How do you make it legible (to yourself, to partners, to agents) when it is always in motion? Gosh…I’m already tired, and we haven’t even started.

What will this be

The newsletter starting today — Through the Boundary — won’t be a thought leadership exercise but more of a working journal. Each issue will tackle one of these questions — or a new one that emerges from conversations and practice. The method combines theory (organizational, economic, systems), client case studies from Boundaryless, conversations with thinkers and practitioners I’m learning from, and the development of models and tools.

If you work in an organization facing these tensions — the gap between strategy and operations, the absence of shared semantics, the fragility of implicit coordination — I want to hear from you. Which questions resonate? Which ones am I missing?

If you have a perspective on any of them, please reply or comment, as this isn’t meant to be a one-sided discussion.

Curated Links

I’ve been curating reads and podcasts for almost 15 years so this newsletter will often contain curated links:

From Hierarchy To Intelligence

Probably one of the most interesting pieces of organizational strategy we have read in the last decade, Jack Dorsey shares his vision of “intelligence over hierarchy” through Block’s future organizational model. It’s incredible, but the research conversation reveals two critical contradictions that actually strengthen rather than challenge our core thesis on executable organizations. Jack argues that behavioral data can replace explicit semantic alignment, but his description of Block’s “world models” reveals that if Block interprets transaction data, it will do so through implicit ontologies. Similarly, his claim that AI automation eliminates the need for contracts contradicts his own description of capabilities with “reliability, compliance, and performance targets,” which are precisely contractual specifications in machine-readable form.

Jobs and AI: Chains of work

The concept of humans moving from “in-the-loop” to “overseeing the loop” captures how AI forces organizations to redesign around three critical functions: chain design, process oversight, and output judgment.

Services: The New Software

AI transforms software tools into outcome-based services, exactly the shift from managing capabilities to orchestrating results that requires a new, more robust contractual infrastructure.

Context Engineering: Why Hayek’s Knowledge Problem Survives AI

Grab a cup and go through this: it provides an economic analysis of why context becomes the primary organizational bottleneck in an AI-native world, validating our thesis that programmable organizations need semantic infrastructure.

Company as Code

Clay Parker Jones (Org design at Airbnb) with a concrete technical vision for what happens when organizational design becomes executable infrastructure rather than just documentation the logical endpoint of programmable organizations.

Software Gets Personal For Organizations and Teams

Fabien Girardin and Lisa Gansky explore the organizational implications of AI, turning every employee into a software creator..

AI just gave you superpowers — now what?

Christian Catalini’s “Some Simple Economics of AGI” can help you imagine the potential of widespread AGI to eliminate management superstructures and transform employees into verifiers who need to use judgment more than productivity.

Work Updates

We’ve been experimenting with multi-unit contract structures to achieve strategic customer experience-related OKRs: the idea is that customer experiences could serve as the primary revenue stream, with the multiple units involved negotiating explicit revenue splits. This validates the chargeback approach we wrote about months ago: organizations can transition from bureaucratic to market-based coordination without breaking existing operations.

Another key learning we had recently is that to transition from a top-down yearly budgeting to distributed autonomy and P&L, a viable approach is to start with shared services & overheads first. The reason is that everyone uses them, and market pricing references exist. Customer-facing experiences with clear revenue attribution can help bridge the gap between bottom-up and top-down approaches.

We’re also discovering that identifying dependencies and service types often comes before implementing chargebacks: organizations need visibility before they can price internally.

Get in touch

If you work in an organization that can’t reliably answer questions about roles, responsibilities, agreements, or where the unit struggles to commit, and most services rely on personal relationships, or where product dependencies are unknown, and it’s difficult to understand how offerings overlap and connect, we want to hear from you: we’re looking for research and design partners.

Special Thanks

Special thanks to Eugenio (Neno) Battaglia, Alberto Brandolini , Chris Evans at Bayer, lisa gansky , Andrea Gioia , Marco Heimesoff, Alessandro Pirani , Matteo Roversi , Bosch MPS Team, Qi Card Team, and the Roche Platform Accelerator Team, among others.

You’ve just read the very first issue of Through the Boundary, my new Substack newsletter; if you’d like to receive future editions directly in your inbox, you can subscribe here https://through-the-boundary.simonecicero.com/

A while back, one of the organizations we work with asked us a simple question: “How should we think about innovation now?” And it made us realize something pretty obvious in hindsight: most companies still try to do innovation — programs, labs, departments — while what really works is enabling it to emerge from customers, partners, and the ecosystem.

So this piece is our attempt to answer that question. We start from three patterns we already see working in the wild — product-as-platform, innovation ecosystems, and platform operating models — and use them to argue for a shift: stop treating innovation as a separate activity, and start designing for continuous adaptation.

Three ways to create platforms for innovation

We all know it by now that innovation comes from the outside. Organizations know that and, still, struggle to accept it and try manufacture it; that’s why innovation programs fail.

Organization should now focus their effort largely on enabling innovation: create the conditions for it to emerge from customers, partners, peripheries, and ecosystems.

Three models already demonstrate this in practice. First, we’ve learned to appreciate Product-as-platforms. As with Airbnb or Uber, the product itself becomes a platform that connects external actors who create value for each other. The organization doesn’t deliver the service; it enables customers to connecet and do so. In certain cases, the organization provides an enabling system for third parties to create extensions to their core services, such as with smartphone’s app stores or extension ecosystems in SaaS (a la Hubspot). In this process, innovations are prototyped, new use cases emerge, as people hack togheter the perfect service for them. The more the product is hackable, the better. We’ve been helping people build such businesses for more than a decade now with the Platform Design Toolkit — advocating to even deliberately design for disobedience. That’s the idea behind the seminal work on Eric Von Hippel on the so-called User Innovation Toolkits: a simple recognition that users drive much more innovation than the owners of the product do.

Then we learned to appreciate and develop Innovation ecosystems — like Siemens X-celerator — that have emerged to mimic similar behaviours in a business context: organizations intentionally invested in integrating and collaborating with external partners and startups. In this way hoping for innovations to emerge from pilots and shared projects.

Lastly, some pioneers have stepped up to create a so-called Platform operating model. Companies like Haier, Amazon, and Flagship Pioneering design their entire organizations to operate as ecosystems of semi-autonomous entrepreneurial units: Haier’s micro-enterprises, Flagship’s GrowthCOs or Amazon Single Threaded Leadership are all expression of the same decentralizing pattern.

The company becomes a platform for both its own and external people to create, experiment, and respond to markets directly, structured enabling capabilities are standardized, and capital is made available to support continuous incubation: it’s the machine that builds the machine. The organization’s role shift from producing value to allowing others to create value inside, at the edge, and through it.

Yet the vast majority of organizations continue to treat innovation as something to do. They create dedicated departments, hire Chief Innovation Officers and fail. And today, for the first time, this inability is becoming fatal.

Innovation Doesn’t Exist (anymore)

Innovation, as a category, is an artifact: 20th-century management had to protect ordinary operations from change. And like all invented categories, it created the problem it claimed to solve. It artificially separated “those who innovate” from “those who execute.” It built organizational walls between exploration and exploitation. It transformed something continuous and emergent by nature into an “initiative”. It tried to measure what is inherently asymmetric, chaotic, and unmeasurable, turning the organic into something mechanical and predictable.

But if innovation is someone’s job, it’s no one else’s.

Roger Martin recently wrote that the global scenario has changed not in terms of volatility, uncertainty, complexity, and ambiguity; those have always been there. What changed is the combination of two forces: the explosion of fixed costs and radical transparency on price and value.

Fixed costs such as R&D, branding, distribution, and technology infrastructure have become dominant, and the industries with the highest fixed costs are consolidating rapidly as scale begets more scale. In the cloud services market, three companies account for more than 60% of the market. In smartphone operating systems, Android and iOS together own 99%.

On the other hand, the internet has made what used to take weeks instant and free. Comparing prices, reading reviews, evaluating alternatives: you can no longer hide behind information asymmetry. Either you’ve invested better than competitors, or you lose — and customers figure it out fast.

The result is that strategy has become somewhat… deterministic:

• You must choose a precise Where to Play.
• You must invest aggressively in a clear How to Win.
• You must win — or kill your experiments as winner-takes-most and mediocre players get eliminated faster than ever before.

But there’s a catch: most organizations, especially those that cannot play an infrastructural role, need a counterintuitive mix of capabilities to play this game: the ability to be strategic and deliberate, yet across multiple specific niches.

Why Traditional Organizations Can’t Play to Win

The problem is that traditional organizations are often built as vertically integrated silos with interconnected capabilities and a high level of dependence, and, despite this seeming to be in line with Martin’s suggestion, it’s not. What happens if your big bet fails? If everything all depend on each other and every decision requires coordination, everyone depends on everyone else’s timeline, priorities, and capacity.

When there’s excessive dependence within the system, formalized coordination becomes necessary. So you create processes: stage gates, review meetings, approval workflows, and alignment sessions.

And process is the attempt to make the uncertain predictable: institutionalized control. Checkpoints require approval, and approvals require information. The organization builds apparatus to reduce variance, eliminate surprises, and ensure that nothing unexpected happen. Tragically sometimes, that’s exactly what happens.

Each process may seem rational in isolation, but together, they can form a deadly web for adaptation and innovation: dependency breeds process, process breeds control, and Control breeds rigidity. The coordination overhead grows faster than the organization itself.

But when you need to move fast on precise niches, a rigid organization cannot:

• Pivot when a bet fails — because too many dependencies have already been locked in
• Rapidly reallocate resources toward emerging opportunities — because budgets are fixed annually and headcount is tied to existing projects
• Play multiple games in parallel — because the coordination cost of each game is so high that you can barely afford one

As a result, most of the organizations just play to play instead of playing to win. And if you’re lucky that your existing business cores grant you some defensibility (for compliance, or scale, ….) you can probably still resist a few years. But how do you play the long term game?

The Forces Making Change Inevitable

Two converging dynamics are transforming what was once a tolerable inefficiency into an existential crisis.

First: A Coasean Singularity: A group of researchers from MIT and Harvard recently described what they call the “Coasean Singularity.” Coase’s insight was that transaction costs (search, negotiation, contracting, monitoring …) determine where you draw the boundary between “make internally” and “buy from the market. But as indicated by Roger Martin in the article mentioned above, these are largely plummeting.

Among other things, AI agents are about to collapse these costs dramatically. They can search, compare, negotiate, monitor at near-zero marginal cost. They can handle complex preferences and parallel negotiations without human cognitive limits.

In short, this means that vertical bundling loses its economic rationale.

It’s not uncommon to see the early sign of this: in many organizations I know and work with, coordinating through the market costs less than coordinating through internal hierarchy. In this case unbundling is no longer a choice but an imperative. When transaction costs approach zero, the boundaries of the firm become a liability rather than an asset.

The Second: Urgent Buyers and Systemic Crisis Pressure — In parallel, we have to acknowledge that decades of underinvestment in critical capacities — energy, strategic minerals, defense, infrastructure — have created brittle supply chains that are failing to adapt. Brett Bivens and Gregory Bernstein call it the “Urgent Buyer Era“: actors with increasingly existential needs are scrambling to source capabilities and resources, they are willing to pay premiums, accept technical risk, and commit to solutions that work now.

The enduring systemic crises create an urgent need for rigid organizations to develop capabilities they have failed to develop, creating an enormous market opportunity for those who can reconfigure rapidly and orchestrate ecosystems.

Together, these forces are compressing a transition that might have taken decades into a span of years. The question is no longer “if” but “who will be ready.”

The Real Lever: Unbundle First, Recompose After

In the end, the answer isn’t “more innovation“, but rather removing what prevents it from happening: rigid dependencies. Thus, reduce dependencies rather than manage them.

This is organizational unbundling:

• Decompose the organization into autonomous units with clear ownership
• Each unit has its own P&L, its own metrics, its own decision-making capacity
• Interfaces between units are explicit contracts, not requiring continuous coordination
• Fewer dependencies mean fewer processes, which means more room for evolution

But unbundling alone isn’t enough. The point isn’t only to fragment but also to make capabilities recomposable: once you have modular units, you can recompose them vertically in different configurations to address different niches. You can create internal “ventures” that assemble existing capabilities for new markets. You can play multiple deterministic games in parallel — multiplying chances of success instead of putting all eggs in one basket.

This is what Platform Organizations like Haier or Amazon do:

• Autonomous micro-enterprises (unbundling)
• Shared platforms that provide common capabilities (infrastructure)
• Dynamic contracts that enable rapid recomposition between nodes (like Haier’s Ecosystem Micro Community Contracts)
• Investment mechanisms that align incentives between the units and the mothership

It’s not a model for “doing more innovation.” It’s an architecture that enables the organization to play to win in a deterministic world — betting on multiple niches in parallel, pivoting rapidly when needed, and reconfiguring capabilities rather than rebuilding them from scratch.

To make Roger Martin’s deterministic strategy logic workable, firms first need organizational unbundling: breaking down capabilities and making them reorganizable. Only then can you vertically integrate them within multiple promising niches. In this way, companies can play multiple deterministic games in parallel, thereby increasing their chances of success.

But why stop at organizational boundaries?

The Ecosystem as Playing Field

Once you accept the logic of unbundling and recomposition, organizational boundaries become arbitrary.

No organization has all the capabilities needed to win in every promising niche. No matter how large, how well-funded, how talented — the combinatorial space of possible innovations exceeds any single entity’s capacity to explore it. But if you know how to recompose modular capabilities, you can do it with capabilities you don’t own — from partners, suppliers, startups, customers, even competitors.

Innovation has never been a property of a single organization. It’s a property of the ecosystem.

It emerges from interactions between actors. From flows of knowledge, technology, and talent that cross organizational boundaries. From the collision of different perspectives, different constraints, different capabilities that no single entity could contain. The question isn’t “how do we innovate?” but “where do we position ourselves relative to innovation flows that already exist?”

Today’s Urgent Buyers — the Microsofts, Googles, and Amazons that are desperately seeking clean energy and capabilities they lack — are demonstrating exactly this. Organizations that can’t generate internally become premium customers of those who know how to orchestrate ecosystems. They pay whatever it takes to acquire capabilities they failed to develop. They become dependent on external innovation that they cannot control.

The pattern will only intensify. As AI agents collapse transaction costs, the boundaries between “inside” and “outside” become increasingly porous. Coordination across organizational boundaries becomes as cheap as — or cheaper than — coordination within them. The competitive advantage shifts from owning capabilities to orchestrating them.

This requires a fundamental shift in posture from control to orchestration: you can’t direct an ecosystem, you can only:

• Create conditions that attract participation — value propositions that make others want to play in your space
• Provide infrastructure that reduces transaction costs — platforms, standards, APIs that make interaction frictionless
• Define rules of the game that align incentives — governance mechanisms that ensure participants benefit from collective success
• Let emerge what you cannot predict — accepting that the best outcomes will surprise you

Those who try to control the ecosystem kill it. Excessive extraction, lock-in tactics, and winner-take-all dynamics — they all drive participants away. Those who orchestrate it make it flourish. They understand that their success depends on the success of others.

And in a world where AI agents collapse external coordination costs, those who know how to orchestrate ecosystems will have a growing structural advantage over those trapped in the logic of internal control.

Stop Innovating: The Era of Innovation Is Over

What does “stop innovating” mean in practice, then? It means stop treating innovation as a separate activity and start designing organizations capable of continuous adaptation.

Concretely:

• Dismantle (or reconvert) the innovation department: Its job isn’t “doing innovation” but building the infrastructure that enables it everywhere — reducing experimentation costs, creating safe spaces for failure, connecting those with ideas to those with resources.
• Stop measuring innovation outputs: Patents, POCs, demos — these are vanity metrics. Measure instead the capacity for reconfiguration: how fast can you reallocate resources? How many bets are you playing in parallel? How much does it cost to launch a new experiment?
• Unbundle first: Identify rigid dependencies. Reduce them. Create units with clear ownership and explicit interfaces. Not for efficiency — to be able to play to win.
• Build platforms, not programs: Platforms are permanent infrastructure that reduce transaction costs. Programs are temporary initiatives that die when the budget ends.
• Position yourself in the ecosystem: Map the innovation flows crossing your domain. Ask yourself: where can we create value by orchestrating instead of producing? What external capabilities do we need? What can we offer that attracts participation?
• Accept that control is impossible: AI is collapsing external coordination costs. Systemic crises are creating urgent demand for those who can adapt. The world is moving toward fluid ecosystems and continuous recomposition — with or without you.

You have to stop innovating, not because innovation doesn’t matter. But because the category itself has become an obstacle. A way to keep believing that change can be confined, managed, controlled. It cannot.

We’re in the era of permanent adaptation. And the forces at play — AI, systemic crises, radical transparency — are accelerating the transition beyond any forecast. The organizations that will survive won’t be those that “innovate better.” There will be those who stopped innovating and learned to reconfigure. The question isn’t whether your organization has a good innovation strategy. The question is whether your organization is designed to adapt continuously — or whether it’s still pretending that change can be delegated to a department.

If it’s the latter, the Urgent Buyers of tomorrow might be you. Desperately seeking from the ecosystem what you couldn’t build yourself. The alternative is to become the ecosystem. To stop trying to produce innovation and start enabling it.

To unbundle, recompose, and orchestrate.

To stop innovating — and start adapting.

Before You Go!

As you may know, everything we do is released in Creative Commons for you to use. In case you’re getting value out of these reads and tools, we encourage you to click the 👏 button and hold down to 20–50 claps as this will help us to get more exposure, and hopefully, work more on developing these tools.

If you liked this post, you can also follow us on Linkedin, we normally curate this kind of content.

Subscribe to our newsletter here.

The End of Innovation was originally published in Stories of Platform Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

When you build vertical SaaS, there’s a moment that often comes up. You start with one very concrete context of workflow — store operations in retail, scheduling and billing in a clinic, and compliance in a tightly regulated industry. You find a control point, a place where the work really happens and where data is created, and you build a product around it. Then, as the product matures, you realise the real leverage is not only there. It is in the neighbouring workflows that touch the same customers: procurement, planning, financing, risk, partner management, and so on.

At that point, a simple question often arises: “Are we building an ecosystem for this use case, or for that one?”

Behind that question, there is a more structural one: how much should you bundle under one product, one brand, one UX — and how much should you deliberately allow to fragment into multiple hubs and (often third-party) applications?

NOTE THAT: 👉 This post is a re-publication of an original posted on our blog, check the original here — you can also subscribe for Boundaryless’ Newsletter here where this content was published first

The world of SaaS playbook has become relatively well understood. Tidemark’s recent Vertical Saas Benchmark report is there to tell the story: control points, multi-product expansion, value-chain extension, embedded Fintech, and AI features as default. And it is happening exactly while vibe coding makes it radically easier for people to spin up new product surfaces.

In this environment, understanding “what is our product?” becomes less evident than it used to be. My sense is that we need at least three lenses at once:

• a way to reason about how many hubs to have and how to scope them;
• a way to think about how modular capabilities and APIs provided by an ecosystem of independent players can add to our product;
• and a way to understand how vibe coding affects the balance of power between surfaces and the domain’s underlying grammar.

From a single app to a system of hubs

The canonical story of vertical SaaS still starts in a simple way. You find a control point in an industry — the system a customer would shut down last if everything went wrong — and you build a system of action around it. That usually gives you your first product: a tool that owns a critical workflow and, over time, accumulates what Tidemark calls data gravity and account gravity.

Once you have that, you begin to expand. You add a second product that addresses a neighbouring use case for the same customer. If you are successful, you might eventually extend along the value chain, serving suppliers, partners, employees, and even end-customers.

On a slide, this is a clear progression: one product, then a few more modules neatly arranged, then a suite. But as soon as you go multi-product and expand your original app, you add complexity to the UX. Often, the new “experiences” target the same user, sometimes someone within the same company; however, in practice, you’re often dealing with different roles, rhythms, and mental models, so cognitive load can increase quite quickly.

The design question becomes not only “what do we build next?” but “how many of these hubs should feel like one coherent product — and where is it actually healthier to let things split?”

The question is especially relevant if you work in a portfolio company, with multiple teams operating to target a specific but ample sector.

A simple matrix: cross-fertility versus cognitive load

Whenever you decide whether multiple use cases should live inside the same product or not, two dimensions matter a lot more than all the others.

The first is customer cross-fertilization. How often is it essentially the same account — and often the same internal group of people — that spans these use cases? If you succeed in Store Operations, how easy is it, in reality, to also succeed in Replenishment and Merchandising within the same company? How much growth potential exists in reusing that relationship? If the product features marketplace and network dynamics with third-party apps or third-party inventory, the question becomes even more relevant because you generally want to keep everything together to boost network effects.

The second is cognitive complexity. How far apart are the use cases in terms of the people involved, the time scales, the language, and the metrics they care about? Daily store operations and weekly scheduling are very close; daily operations and annual risk capital planning are very far.

If you imagine a horizontal axis for cross-fertility (low to high) and a vertical axis for cognitive complexity (low to high), you get a simple 2×2 that is surprisingly helpful.

In the bottom-right corner — high cross-fertility and low cognitive complexity — you are in what I’d call the natural suite zone. This is the case where the same people, or a very small, tightly coupled team, use multiple workflows that feel like steps of one bigger job. In a small retail chain, the person who handles shifts, inventory, and in-store promotions might be the same. In this quadrant, it makes sense to behave as a single product: one hub, one UX frame, clear zones or modules inside it. The user’s brain is happy with that level of bundling, and from a business perspective, you get strong expansion and network effects almost “for free”.

If you move up — high cross-fertility but also high cognitive complexity — you arrive in the suite of surfaces territory. Now you still have the same customer spanning multiple use cases, but the work looks very different across roles and time. Think of a big omnichannel brand where store staff, merchandisers, supply chain professionals, and finance each have their own world. Here it is dangerous to pretend that one monolithic application can serve everyone well. The healthier move is to keep a strong platform identity — a single vendor relationship, a single data model, a single set of rails for identity and money — but articulate this into several distinct surfaces: a Store Console, a Merchandising Workbench, a Supply and Vendor Portal, a Finance Console, and so on. UX can diverge; semantics, permissions and cross-hub journeys must remain coherent.

In the bottom-left corner — low cross-fertility and low complexity — you are in the land of product siblings. This is when two products share technology and maybe some domain intuition internally, but not much in the customer base or go-to-market. A tool for small independent shops and a tool for wholesalers might sit here. Each can be a separate product, sometimes even a separate brand. You reuse infrastructure behind the scenes, but there is little reason to present them as “one suite” externally.

Finally, the top-left corner — low cross-fertility and high complexity — is what I think of as the Domain OS territory. Here you are dealing with different products, different customers, quite different kinds of work, that only really share the fact that they belong to the same industry, or domain. A Risk Management system and a an Investment management for the banking industry talk about the same world, but would never be bundled as a suite for a single buyer. In this quadrant, the thing you most want to keep common is not the UX but the domain language and infrastructure: the canonical entities, the events, the compliance models. On top of that, you can host many products, yours and others’, each with its own surface and commercial motion.

From product suite to modular ecosystem

To complicate things you’ve to consider that — in your vertical ecosystem — there is not just you and your customers but rather a network of independent vendors that are modular capabilities. Some industries are more mature and have ecosystems already there; in others, they are emerging and you may be the catalyst to let this happen.

In the most common pattern, a platform aims to build an app store, integrate third parties into its hub, and allow them to operate mostly within its UX. An example is how Shopify embeds apps through its famous “reverse app” framework, maintaining a consistent UX across apps. However, if you succeed in establishing a common language and motivate your third parties to release modular capabilities as APIs, the landscape shifts: while you can provide centralized dashboards and core capabilities, the product X from your ecosystem can call module Y as an API and incorporate the outcome into its own process. Over time, what a customer truly experiences is less “this hub or that hub,” and more a mosaic of interacting products. Some of these products might come from you, others from different providers — all communicating in the same language.

At that point, the role of the “platform” shifts quite radically. You are no longer just the centre of the UX universe that everyone must plug into. You become the custodian of the language that these modules implement. You design and govern the semantic contracts: what an order is, what a shipment is, how a claim moves from state to state, which events exist, and what they mean. You keep a registry of who offers which capabilities in that language, along with documentation that both humans and AIs can understand.

In practice, three patterns of platform enablement appear on top of this:

• You still keep a very visible control tower: a central application where someone can see the full picture, orchestrate work, and monitor status. Many of the actions available in that hub are, in fact, calls to underlying modules provided by you or by partners.
• You behave like a reverse application host. You define a strong UX framework — navigation, layout, design system — and ask partners to adopt it when surfacing their capabilities. Users experience one cohesive product; architecturally, you are assembling pieces contributed by multiple actors.
• You are almost invisible in the UX. You define the domain language, the security and contractual model, and the financial rails. Products from various vendors, including your own teams, speak that language and ride those rails. Customers might never log into “your” app at all, yet every meaningful interaction in the ecosystem flows through your grammar.

If you look back at the matrix through this modular lens, there is a nice alignment. In the “natural suite” quadrant, you will probably combine a strong control tower hub with modules beneath. In the “suite of surfaces” quadrant, you still want a common language and might have several control towers, one per role. In the “product siblings” quadrant, modularisation is mostly an internal efficiency play. In the “Domain OS” quadrant, the language-only ecosystem pattern dominates.

So far we have not said much about AI. But AI, and vibe coding in particular, changes the economics of all this.

What vibe coding does to surfaces and grammar

Vibe coding is a shorthand for a new way of building software: instead of carefully writing and reading code, you describe what you want in natural language to an LLM, get a first cut of code, run it, and iterate by giving feedback. Tools in this area are improving quickly; some are general-purpose, others are industry- or platform-specific.

If you assume that anyone with some technical understanding in your ecosystem — your own team, partners, sophisticated customers — will soon be able to do this, three consequences follow.

First, surfaces become cheap. The marginal cost of creating a small tool, a role-specific dashboard, a bespoke workflow step drops dramatically. You no longer have a single official UX; instead, you have many small surfaces, some operated by you, some by partners, some by customers inside their own systems. The key question shifts to ensuring that all these surfaces behave coherently.

Second, the grammar becomes the moat. When surfaces are easy to generate, what becomes valuable is a clean, expressive, stable domain language that both humans and AIs can reason about — entities, relationships, events, constraints — and a set of rails around it for money, identity, permissions, compliance, obligations. Owning that thin waist, in the middle of a diverse ecosystem of surfaces, becomes strategically more important than owning any single screen.

In other words, vibe coding raises the stakes: it makes exploration at the edge cheaper, while at the same time making convergence in the middle more essential (and harder to control).

What this means if you are building a vertical platform

All of this can sound abstract, but it has quite concrete implications for teams building vertical SaaS now.

When you consider a new product, you cannot just: you need to ask where it sits in the cross-fertility versus cognitive load space relative to what you already have. Furthermore, when you talk about “the platform”, you need to be clear what you mean: are you primarily offering a strong control tower experience that coordinates work and shows the whole picture? Are you aiming to build the gravitas needed to convince everyone to adopt a reverse application framework in which many capabilities can live under one (your) UX? Or are you mainly offering a domain language and Rails, letting others build UIs on top?

It also means you probably want to start modularising capabilities sooner rather than later. Any engine that could realistically be reused across workflows — pricing, routing, underwriting, risk checks, scheduling — is a key candidate to establish a language.

It also means you have to take incentives and governance seriously. You cannot simply decree that partners should expose their capabilities as APIs and fall in love with your domain language. You need to make it economically and operationally attractive: revenue-sharing on reused modules, distribution advantages, easier integration if they adopt your grammar, maybe even technical support and tooling that lowers their costs.

And finally, it means treating vibe coding not as a gimmick but as an inevitability.

Your documentation, schema descriptions, and API designs will increasingly be read by LLMs as much as by humans. The more regular, self-describing and consistent they are, the more likely it is that people can successfully generate and adapt code against them. Guardrails — scopes, rate limits, auditability — become part of your product, not just part of your security checklist.

From owning the app to owning the grammar

Vertical SaaS started life as “an opinionated app for a specific industry” but as you expand into multiple hubs, host other vendors, and operate in a world where anyone can spin up a new surface through AI tooling, the centre of gravity moves.

The matrix of cross-fertility and cognitive load helps you be intentional about how you structure your hubs based on context and ambition. The modular view helps you see that your job is not only to ship features, but to choreograph a network of modules with vibe coding, reminding you that the number of surfaces will explode, whether you plan for it or not.

Underneath all of that sits a quieter question: what is the grammar of this ecosystem, and who has the right (or courage) to steward it?

Before You Go!

As you may know, everything we do is released in Creative Commons for you to use. In case you’re getting value out of these reads and tools, we encourage you to click the 👏 button and hold down to 20–50 claps as this will help us to get more exposure, and hopefully, work more on developing these tools.

If you liked this post, you can also follow us on Linkedin, we normally curate this kind of content.

Subscribe to our newsletter here.

From Owning the App to Owning the Grammar: The Evolution of Vertical SaaS Platforms was originally published in Stories of Platform Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article explores how chargeback models can transform organizations from bureaucratic to market-based, user-centric structures. Drawing inspiration from Haier’s Rendanheyi model and the impact of AI on transaction costs, it argues for a decisive shift towards empowering entrepreneurial units. The piece highlights how this approach fosters greater accountability and optimizes for user value by moving away from centralized budgeting.

NOTE THAT: 👉 This post is a re-publication of an original posted on our blog, check the original here — you can also subscribe for Boundaryless’ Newsletter here where this content was published first

Many companies today feel the need to move away from a top-down approach to resourcing and strategy. Centralized annual budgeting has shown its limits, and a system in which teams run capabilities and units independently is increasingly perceived as capable of better performance, greater accountability to value, and to users. Haier’s Rendanheyi — the inspiration behind Boundaryless 3EO Framework is a testament to how being near to the customer (zero-distance as they say) and “paid by the user” is a powerful way to remove organizational debt and empower entrepreneurship.

As we’ve explained recently in “How AI Transforms the Logic of Value Creation in Markets — and Organizations“, the emergence of AI as a powerful coordination technology brutally reduces transaction costs and is going to accelerate this trend further:

“The fundamental economic promise of AI agents lies in their ability to dramatically reduce transaction costs — the expenses associated with using markets to coordinate economic activity.”

From “The Coasean Singularity? Demand, Supply, and Market Design with AI Agents”

Therefore, organizations should move decisively into a market-based, user-funded, zero-distance organizational model. Chargeback models — where organizational units exchange services and products for money also interally and not just externally — can help allocate costs and value fairly in organizations.

These approaches aren’t new, but the 3EO framework (inspired by Rendanheyi) can help apply them without generating classic drawbacks: internal competition that undermines collaboration, short-term thinking, fragmentation of the customer experience, and loss of control over aggregate performance indicators like group-level EBITDA.

From Bureaucracy to Zero Distance From The User

A few years ago, I remember we interviewed John Bunch about the Zappos experience in moving from top-down budgeting to market-based dynamics. He explained:

“Every team is like a small business,” and you can only pursue your mission if “someone is willing to pay you internally or externally for that service.”

Haier adopted a similar approach when introducing its Rendanheyi model in 2012: it transformed thousands of employees into micro-entrepreneurs. They eliminated 10,000+ middle-management positions, pushing P&L responsibility to self-managed teams that had to find paying customers or risk ceasing to exist. The legend was born.

Not everyone, though, can be so upfront about the change and say, “Starting tomorrow, if you don’t have an internal or external customer, you cease to exist.”

The goal of such a transformation isn’t to adopt “chargebacks” per se, but to achieve high accountability in the organization.

When revenue and planning are centralized, everyone optimizes for the plan and to protectthe budget. When accountability is at the edge of each unit, everyone optimizes for the user. To get there, chargebacks must become a value-splitting mechanism rather than an internal tax. If we do it right, we make three things true at once:

• everyone becomes user-paid (directly or via clear internal contracts);
• The experience remains coherent end-to-end.
• aggregate performance improves under explicit margin and brand constraints, not micromanagement.

The Concepts You Need

A good starting point for organizations seeking high accountability is to first unbundle and re-bundle. Unbundling means first separating large, existing functional units into smaller ones to make independent sub-units and teams more visible. For example, you could unbundle a large IT development unit into Software Development, DevOps, and Infrastructure Design and Development: both provide quite independent services that can be sold together to customers or separately.

When unbundling the organization into smaller units, we should consider where independence and contestability exist: can alternative suppliers (inside and outside) realistically provide that service or capability? Is such a capability independently viable?

In Rendanheyi/3EO and similar approaches, we typically have three unit types. Different companies name them differently, but the roles are invariant and map 1:1 to the three domain types in Domain-Driven Design.

• User Micro-Enterprises (UMEs) ⇄ Core Domains. Edge units that own the customer, outcomes, and profit and loss.
• Node Micro-Enterprises ⇄ Supporting Domains. Specialist capability suppliers forvarious solutions and experiences.
• Shared Service Platforms (SSPs) ⇄ Generic Domains. Enablers like HR, Finance, and IT with transparent transfer pricing.

To demonstrate that these types are invariant, let’s take Bayer’s DSO. Language lands in the same place (see Michael Lurie’s update): Customer & Product Businesses behave like UserMEs/Core Domains, Capability BusinessesresembleNode MEs/Supporting Domains, and Enabling BusinessesreflectSSPs/Generic Domains.

After unbundling,it’s always essential to consider re-bundling. If dependencies are tight between newly identified nodes, the user experience would suffer from separation. It’s then worth keeping them together in a single P&L container. Your goal isn’t extreme atomization, but rather to expose units that can autonomously create value — reasonably independent units. If we see that the DevOps team and the Infrastructure Design and Development team have continuous handoffs, use the same toolchain, make decisions together, and often serve the same customer, then we can assume they are part of the same team. It may make sense to “rebundle” them. Below you can see how the three steps go together.

How The Money Flows In The Game: Experience and Solution Contracts

Now, let’s shift to how money moves. Revenue typically enters an organization through some customer “experiences”. An experience is a go-to-market entry point (a storefront, a project offer, a bundled subscription, a tender).

Solutions, on the other hand, are replicable products and services composed through the collaboration of internal capability providers (teams, platforms).

Both experiences and solutions can be viewed as contracts that coordinate commitments to a specific promise and split revenues or profits. The split needs to be explicit and negotiable: who contributes what, who earns what.

To address this tension, the 3EO Framework, inspired by Rendanheyi, features the Ecosystem Micro-Community Contracts (EMC Contracts). EMC contracts are contract types pioneered by Haier in the late 2010s, invented to define how value is created, delivered, and shared among participants in a collaboration, establishing clear rules for revenue distribution and performance accountability across units.

An EMC Solution contract can be used to cover the obligations of the nodes involved in producing a replicable element of the product or service portfolio, ensuring a realizable product or service. On the other hand an Experience EMC Contract should support a Go-To-Market configuration that allows the solution (or multiple underlying solutions) to be composed and delivered to the customer. Solutions and Experience contracts can be considered just another type of node, used to split revenues based on certain obligations of the participating nodes.

With such contracts in place, nodes (teams/units) can operate much faster: well-defined revenue-splitting contracts, where prices emerge from negotiations over value rather than an internal cost-plus approach, are the best way to make chargebacks value-based rather than a simple tax. All with a shared contract grammar.

In this way, the org becomes a network that routes value rather than a maze requiring continuous approvals.

Maintaining these two levels allows solutions to have an internal focus on arranging the internal capabilities into a catalog of long-lived services and products, while experiences can adapt to the tune of a particular customer segment, locality, or period, and can help compose solutions into more complex customer “scenarios” also involving third parties and partners. For example, an experience could involve a third-party system integrator providing integration services, while a parking operation company offers both a software platform for parking automation and a catalog of certified hardware, such as cameras or automated parking barriers.

Example: Solution and Experience Contracts

To give a more tangible idea, let’s imagine a fictional digital health company,Healthransform, that offers imaging hardware and SaaS for ancillary functions like digital Pathology.

Let’s introduce the Intelligent Imagine Solution. It’s a ready-to-use imaging product that bundles the customer-installed hardware, digital pathology software for real-time AI image analysis, software to connect and monitor the hardware, installation, ongoing maintenance, and basic compliance/quality. For the customer — typically a hospital or lab — it behaves like a single reliable system: it’s installed, connected, and kept functioning. Internally, it’s a simple Solution EMC, a contract between a units that designs the hardware, the one that Manufactures it, The Software Development Unit, and the installation & maintenance unit: it states what all units promise (availability, response, preventive checks), who is accountable for what, how its measured, and pricing for anyone selling it to the customer — along with resource redistribution. Because it’s standard and reusable, multiple offers can “plug it in” without reinventing scope or service levels.

This solution is also sold as part of a new Experience (EMC) Equipment-as-a-Service (Renting) model. Two units participate: Sales, which identifies and cultivates demand, maintains customer relationships, and owns the sales process; and Finance, which handles contracting, credit checks, funding, and designing end-of-term options. The third component is the contract representing the solution, typically held by the “leading unit,” like the hardware design team. The negotiation stipulates that once a sale is completed, the sales team receives an upfront fee as a quota, while the finance team provides the capital to cover the hardware’s manufacturing costs. Activation and monthly payments are divided, with a portion routed to the finance team as interest and fees, and the rest allocated to the solution contract, which distributes funds to the underlying units.

Customers see clear value: a quick go-live followed by a predictable monthly fee that includes connected hardware, software, and maintenance, offering a single support contact. The Experience is designed as a collaborative effort.

Enabling Constraints That Keep The Game Healthy: Taxonomies and VAMS (Investing and Operating Contracts)

Once units can negotiate value to improve their performance through customer accountability, you’ve created a game. To make it good — avoiding internal price gouging, broken customer journeys, and the race to local optima where one unit risks the whole — you need to give nodes not just the tools, such as contracts, but also constraints, guardrails, charters for the nodes to operate within, the expression of being “part of” something bigger (the org) versus playing the game alone in the market.

A soft taxonomy

Alongside organizational structure, the organization needs to understand its customers, reference ecosystems, and product relationships. Some organizations are better seen as a “portfolio” of unrelated products, while others are more like “platforms” of composable options (see this article for reference). Especially in the former case, agreeing on a lightweight taxonomy of products, capabilities, and services (and a shared way to describe customer needs) can be crucial for facilitating bundling. A composability map helps teams discover each other, compose solutions faster, and avoid reinventing parts of their solutions. See some of our prior writings on the topic here: 1,2,3.

P&L clarity, including shared-services “taxes.”

Revenues from EMC contracts constitute the node “inflows”. Salaries, input costs, and payments for shared services typically make up the negative side of the P&L. In our experience, companies use several methods to account for Shared Services (usually provided by Shared Services Platforms). These services — which are general and used by everybody — don’t provide a competitive advantage. SSPs rarely negotiate directly with micro-enterprise counterparts. It’s usually more efficient to apply a capacity levy based on headcount for HR services, or other indicators that serve as reasonable proxies for the service (like office space as a proxy for facility management). Sometimes, Shared Services are funded through a revenue tax, with the downside that positive behaviors, such as headcount optimization, are not incentivized. The important thing is to make the rules explicit and benchmarkable — and establish clear guidelines for cases when SSP services do not meet specific expectations and MEs want to source alternative services from the market.

The picture is simple: Revenue comes in → flows into Experience & Solution Contracts (with Split Rules) → and eventually flows into Nodes.

Experiences collect customer money, apply the split rules (percentages, thresholds, waterfalls), and route value to solutions that fulfill them or other capability nodes (like GTM). Solutions then route to contributing nodes. Shared services take their fee per published transfer prices or levies directly from the nodes.

A VAM-style charter from the parent node.

Finally, to stabilize the system, the “parent” organization (industry platform or holding) must set the enabling guardrails: access to the brand and sales channels, compliance boundaries, alignment cadences, andoperating margin targets need extensive definition and negotiation in a basic operational agreement on top of which Value Adjustment Mechanism contracts are negotiated.

A VAM is a contract that allows entrepreneurial employees to negotiate the upside of their work in taking over or creating a unit with the mothership. Every unit, in addition to relying on contracts to negotiate revenue or value splits, must do everything that ventures do: talk to users, hire, innovate, build new capabilities, and enter the market. Such units have to request capex and opex and set objectives.

In our experience, a VAM contract negotiation centers on requesting investments, clarifying expected OPEX, and seeking financial support, like cash flow allowances and solutions for managing stock creation in hardware-related endeavors. A key negotiation point is the unit’soperating margins.

The operating margin target becomes the stance units use when negotiating contracts. If I know I need a 30% operating margin by year-end, I’ll negotiate contracts accordingly. During negotiations, I’ll balance improving my operating margin with staying within the bandwidth of value extraction that then cascades into an acceptable end-user price. Units must manage this tension, typically created by setting rules in the VAM that allow profit retention if minimum operating margin objectives are met. This usually means the unit retains profits exceeding the VAM targets, provided they exceed a minimum and a certain operating margin percentage.

To prevent the organization from becoming hostage to a single unit, it’s wise to either duplicate the units that provide specific services internally or minimize constraints on sourcing alternative customers and suppliers, both within and outside the organization.

Example: Transforming the Software Development Unit into a Micro-Enterprise (Healthransform)Scenario: The leader of Healthransform’s Software Development Unit wants to turn it into a Micro-Enterprise (ME) via a VAM agreement.

The new ME will launch an ambitious project: an App Marketplacefor third parties to build and distribute apps on Healthransform’s connected imaging hardware.

The ME owners want to negotiate a few essential aspects:

• Revenue rights. The ME retains 85% of Marketplace revenues (developer fees, app listing fees, in-app revenue share); 15% goes to the Parent as brand/IP royalty for the first three years. All other revenues from integration projects continue to be 100% retained by the ME.
• Operating discipline. The ME will target a long-term 65% Operating Margin after paying salaries, infrastructure costs, and all other operating costs with transparent pricing for shared services (benchmarked; contestable if >10% over external equivalents). For the first two years, the Operating Margin target will be dropped to 50%.
• Level-up trigger. If the ME onboards 20 certified third-party apps, and achieves +25% Marketplace GMV for two consecutive quarters, the royalty drops to 10% (i.e., 90% retention); pricing levers (developer tiers, listing fees) become ME-controlled within Parent guardrails.
• Investment & gates. The Parent will allocate €1.2M CAPEX over 24 months, released in three tranches tied to: MVP (developer portal + billing), Pilot (first external developer cohort live), GA (compliance review and moderation workflow). Missing a gate by >90 days triggers VAM re-discussion.
• Spin-out option. If the Marketplace generates €4M incremental revenues above the starting floor while meeting quality/compliance targets, the ME is incorporated as a NewCo; ME owners receive 20% of NewCo equity.

A More Thoughtful Approach Than “find a customer or we’ll fire you”

Such a shift toward a user-paid organization can fracture culture, strategy, and customer experiences if it is not grounded in the correct principles and staged appropriately.

The provided concepts and elements (MEs, P&L, Solution and Experience EMC Contracts, VAMs) and the Portfolio Map Canvas can aid in-depth analysis — visualizing domain continuity among teams and units and suggesting how to unbundle and rebundle into independent units. The Canvas can help identify where contracts should be adopted to create revenue splits, corresponding with user-facing experiences that combine go-to-market capabilities and solutions.

We usually suggest a phased approach, moving in steps.

Phase 1 (Virtual P&L)

The first phase is about identifying nodes, creating initial virtual P&Ls, and enabling showback. There are many ways to do this: start with an overview from someone who can govern the finances, aided by existing unit identification, solutions, and experiences. Then, start a competitive game where teams negotiate the fine-tuning of their value share, even if they’re still not accountable to P&L.

Phase 2 (Live contracts)

In phase two, we typically construct and publish the experience and solution catalogs, negotiate the agreements and splits with the holding’s support, and begin paying for shared services in accordance with the agreed-upon rules.

Phase 3 (VAM and upsides)

In phase three, MEs can negotiate VAMs that exchange autonomy for targets and transparency, often with meaningful upside. Units step into entrepreneurial mode — within a coherent, benchmarked internal market. This phase is gradual, with new MEs emerging and old units transitioning. During this stage, units can engage in more contracting to create new solutions and experiences. This is when you’ll start to feel the need for the underlying technology. At Boundaryless, we’re developing a shared, open standard for implementation and our own SaaS application for easy integration with your ERP system. Reach out if you’re interested in piloting.

Some firms will go radical (think Haier’s elimination of middle management). The phased route achieves similar outcomes with less shock and better customer alignment. The result is a gentle transition onto an internal market that pays for value creation while preserving the experience.

What Architects and Leaders Should Watch For

Four design levers keep this approach efficient:

• Contestability. Avoid 1:1 internal monopolies. If a service is externally available, keep a credible make/buy option, publish benchmarks, and require exit clauses.
• Avoid one-on-one dependencies.Avoid two nodes with separate P&Ls but highly dependent capabilities. If neither makes sense on its own, group them.
• Avoid constraints on captive choices. Avoid constraining one node’s options to serve or be served only by a specific internal node. Openness keeps the system on track and prevents debt.
• Credible Operating Margin targets. Set credible VAM-set operating margin constraints; it would be irrational for any node to “go rogue” on price — overpricing makes bundles uncompetitive and destroys their long-term returns.

Getting Started

This article offers a clear lexicon and a credible approach to tackle this without major disruptions: understand, unbundle, and rebundle the units, map the entry-point experiences, and draft contracts; outline the solution catalog and revenue splits; establish a soft taxonomy; open virtual P&Ls; publish contract templates; and draft initial VAM charters. Run pilots and learn from the data. This is the only credible way to transform a bureaucratic monolith into a network where value flows naturally.

Before You Go!

As you may know, everything we do is released in Creative Commons for you to use. In case you’re getting value out of these reads and tools, we encourage you to click the 👏 button and hold down to 20–50 claps as this will help us to get more exposure, and hopefully, work more on developing these tools.

If you liked this post, you can also follow us on Linkedin, we normally curate this kind of content.

Subscribe to our newsletter here.

From Bureaucracy to Market was originally published in Stories of Platform Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

In the emerging agent economy, organizational advantage shifts from headcount and scale to modular capabilities with clear interfaces. As AI agents become a powerful coordination infrastructure and transaction costs collapse, the platform becomes ‘whatever you can automate’ — a thin waist of reliable automation where contracts, roles, and semantics are hardened enough to trust. Organizations must navigate a trilemma between effectiveness, cost, and programmability, optimizing resource by resource rather than with slogans. The future belongs to firms with programmable clarity at the waist and entrepreneurial range at the edges.

We’ve argued before that AI doesn’t just tweak digital workflows; rather, it rewires the value thesis across markets and organizations. The advantage shifts from “more headcount and scale” to modular capabilities with clear semantics, clear outcomes, and executable interfaces — operational clarity you (and your customers and ecosystem partners) can actually build on.

In parallel, a new kind of squeeze is hitting all industries — beyond digital. In the “Urgent Buyer Era” (check the articles in this week’s curation) even hard tech incumbents are being forced to reorganize faster than their governance can manage:

“The coming industrial realignment will reward companies, and investors, specifically built to thrive amid disruption, not those struggling to adapt legacy operations to new structural realities.”

On top of this, AI agents promise to become a powerful negotiation infrastructure, a coordination technology like our good friend Sangeet Paul Choudary posits in his latest book Reshuffle.

In that perspective the costs of discovery, bargaining, and enforcement of agreements collapses: it’s what we call Coasean bargaining… at scale. When those costs fall, coordination migrates from policy and hierarchy to contracts — and then to contracts that machines (agents) can understand and leverage.

The practical implication in our organizations may not be to “decentralize everything,” but create the basis to harden what matters so people and agents can compose fast and safely.

That brings us to two key ideas from this week’s recordings (shortly coming up on the podcast): two new Boundaryless Conversations, one with PostShift’s Lee Bryant, and another with Hat’s Protocol’s Spencer Graham & Nick Naraghi.

During our conversation, Lee raised a key point in this context:

“the platform is whatever you can automate.”

Your platform is the surface area of reliable automation — a thin waist where contracts, roles, and semantics are clear enough so you can build your product portfolio on top.

Below it, Shared Service Platforms can provide repeatable capability (compliance, security, quality, procurement, finance, data). Above it, entrepreneurial cells (what we call micro-enterprises, with P&L) compose those capabilities into offers aligned to customers and, increasingly, to… urgent buyers (including agents).

The narrower and clearer that waist, the easier it is to move from intention to impact without losing control.

But then, in decentralizing and enabling, you also have another problem: that of executing on a reasonably coherent strategy and governance, known as the principal-agent problem.

NOTE THAT: 👉 This post is a re-publication of an original posted on our blog, check the original here — you can also subscribe for Boundaryless’ Newsletter here where this content was published first

As Nicholas put it during the conversation, there’s a trilemma you can’t escape in organizations when effectiveness (or efficiency at outcomes), cost, and hardness (i.e. predictability and programmability) have to coalesce:

• High effectiveness + high hardness ⇒ often means higher costs (more controls, more contract engineering).
• High effectiveness + low cost ⇒ hardness tends to decrease (you have to trust social processes, delegate — thus more risk of bureaucratic buildup, debt and opacity).
• High hardness + low cost ⇒ sometimes effectiveness decreases (because you need rigid rules and you’ll need to limit agents’ autonomy, and require humans-in-the-loop, etc.).

Nick provides a good example: putting an AI agent in a role reduces execution costs, but introduces capture risk (prompt injection anyone?) or diminished effectiveness on some tasks.

You optimize resource by resource, role by role — with explicit trade-offs about where to add finality, auditability, and enforcement, and where to remain agile for speed and learning.

Roles can become programmable bundles: treat a role as a unit that explicitly carries outcomes, permissions, eligibility, decision rules, and payout/penalty logic. Make that legible, and an AI agent can safely “sit in the hat” of that role.

Put differently, the shape of organizing to come is fewer walls and more contracts with milestone acceptance and telemetry; role registries that state, in machine-readable terms, who can do what with which assets; and risk-tiered controls that match the criticality of the process. Get that right, and you can invite autonomous agents in — because you’ve given them constraints worth adhering to.

Why move now? Because markets are already starting to select on these features, buyers are facing existential timelines in energy, compute, defense, and critical materials, and seek easily leverageable capacity. Organizations that remain ambiguous about interfaces and do not decentralize roles will be out-transacted by those with programmable clarity at the waist and entrepreneurial range at the edges.

The prize goes to firms that can say straight, “here is our contract standard, here is our service catalog — plug in” — and mean it.

Before You Go!

As you may know, everything we do is released in Creative Commons for you to use. In case you’re getting value out of these reads and tools, we encourage you to click the 👏 button and hold down to 20–50 claps as this will help us to get more exposure, and hopefully, work more on developing these tools.

If you liked this post, you can also follow us on Linkedin, we normally curate this kind of content.

Subscribe to our newsletter here.

Recently, we’ve written about how successful organizations essentially balance a portfolio, diversification strategy with a platform one that ensures cohesion and a strategic capability to leverage cross-product synergies, targeting a complex ecosystem of customers.

This article examines a recurring positive organizational pattern that we’ve identified in companies that successfully balance portfolio diversification with platform cohesion. Through our work with multiple clients, we’ve observed how leading organizations structure their offerings around horizontal platforms and vertical solutions, while implementing continuous innovation cycles that capture value from their ecosystems.

The Horizontal-Vertical Taxonomy

As we explained previously on the blog, an essential piece of running a cohesive strategy and a composible portfolio lies with having an intentional, well-understood product taxonomy: the way offerings are not only organized but also combined.

Practically, in the B2B situations we observe, most of the time, there’s a distinctly horizontal offering component. These horizontals are often technology platforms that can be of various types:

• high-level design of modular hardware components and systems
• advanced technology and research elements,
• firmware, operating systems that provide the foundation for a whole series of other developments
• design system components for user interfaces
• enabling data structures and software foundations.

These enabling technology platforms need long-term maintainability, and they typically make choices that don’t respond to short-term needs but rather to prevalent needs in the organization’s reference ecosystem, even across industries. For example, in a company that builds aerospace technology, these basic “platforms” may focus on avionics, software systems, sensor integration, or propulsion architectures. Similarly, in healthcare technology companies, horizontal platforms might encompass lab technology infrastructure, diagnostic algorithms, and patient portal technology. All modules serve as foundational elements across multiple product lines.

What distinguishes these horizontal platforms is their deliberate abstraction from specific use cases. They’re designed to be flexible enough to support diverse applications while maintaining consistency and reliability. This abstraction typically requires long cycles, significant upfront investment in architecture and design, and relatively low fluctuations to respond to specific customer needs. Still, it pays dividends through reduced complexity and increased manageability, and baseline performance across the organization’s entire portfolio.

On top of these horizontals are the verticals: sometimes formalized organizationally as micro-enterprises or product units, product areas, these units cater to more specific customer needs. They perform productization activities, seeking to respond to the experiences and typical needs of a more specific market segment compared to horizontal solutions, approaching this through the creation of specific solutions to customer problems and needs.

While platforms aim to create enabling capabilities, there’s often collaboration between different verticals to create bundles — integrations that respond to specific customer needs. Verticals indeed have often remarkable system integration capabilities, and learn from clipping pieces together in the particular context of the customer, with various levels of system integration required, depending on the context.

Different Levels of Integration

This customer-facing bundling and integration occur at varying levels of depth. For example, HubSpot has separate products, and its bundle integration primarily involves activating different self-service packages on the platform. A company doing more complex and niche services, instead, goes through a heavier enterprise sales process to create a bundle, with system integration work.

The activity of combining products and services from different verticals is often where emerging customer needs are addressed. When we have a more mature platform, where third-party solutions also exist, that’s precisely where future customer needs are identified and value is created.

NOTE THAT: 👉 This post is a re-publication of an original posted on our blog, check the original here.

Subscribe here: https://boundaryless.io/newsletter_subscription_page/

The Common Shape of the Reference Market

Examining the market landscape, especially in B2B, we typically see some recurrence in how markets are structured. Typically, organizations target core enterprise customers, which are reference customers from 2–3 different industries or types that share common elements in their business processes, typically resonating with the core modular offering components. For example, an industrial printing company may target both commercial printing operations and packaging manufacturers, as they share similar production workflows, quality requirements, and equipment needs. These core customers often represent 60–80% of revenue and drive the primary platform development roadmap.

Often, across or adjacent to the core targets, emerging segments represent future growth opportunities that require more significant platform evolution or entirely new vertical solutions to address effectively. Perhaps they share a subset of the needs of the core targets (e.g, operate factories, logistical needs, run subparts of key processes, research, …). They’re united by general needs rather than the industry they operate in.

Beyond the core, B2B ecosystems also feature a whole series of players acting as mediators, integrators, enablers, machine producers, OEMs, and eventually entities that produce resources which are consumable in industrial processes, or infrastructure players, such as commodities providers.

The Three Pillars of the Offering

As a conseguence the offering often develops along three macro directions:

• Operate/Innovate for core customers: this can involve an offering focused on the operational efficiency of the customer’s base workflows (operate) or an offering for deep innovation use cases (innovate). An e-commerce might be more operational, while a research tools producer may be more focused on enabling innovation-related use cases.
• Integrate: everything that extends and integrates core solutions — system integration, third-party extensions, partners — this part of the offering facilitates the adoption of key ancillary solutions to cover ancillary use cases: here’s where we typically see developer portals, partner programs….
• Optimize: optimization component, like infrastructure optimization, data, and, very often, lately, artificial intelligence-related adoption.

The ILC Model: Innovate, Leverage, Componentize

Now, if you look at your organization as a portfolio product set and platform strategy, why do you use a platform strategy? It mainly serves to maintain cohesion in products and services, guaranteeing the ability to leverage platform positioning.

The ultimate goal for a platform is to innovate continuously, create evolutionary tension with its ecosystem, and anticipate future needs, build them, and innovate continuously.

The ILC model, formalized by Simon Wardley, is a very clear and powerful explanation of how this mechanism can actually happen. According to the ILC model — a playbook that companies like Amazon have mastered — platforms evolve through three phases. First, they innovate by creating new capabilities that address emerging customer needs. Next, they Leverage these innovations across multiple products and customer segments to maximize value extraction. Finally, they Componentize mature capabilities into reusable, modularized platform services that both internal teams and external partners can consume.

This cycle enables platforms to continuously evolve while maintaining stability for existing users and creating opportunities for ecosystem expansion.

Therefore, according to the playbook, a good strategy for a platform-portfolio company in B2B is to:

• Modularize its offering as much as possible, starting from the platform-orizontal side, exposing it through clear interfaces to the whole ecosystem, and not only internal product verticals, and simplify access to innovative solutions, perhaps by standardizing them
• Allow the ecosystem to create higher-value solutions on top of the enabling systems.
• Capture what happens in the ecosystem and translate it into new products and services;
• Create a new round of innovation on top of newly modularized solutions

This is, for example, what Amazon did not only with AWS but also with Amazon Basics: they systematically identified top-performing third-party products in their marketplace (enabled by the platform services), analyzed the underlying customer needs, and then created their own streamlined versions. The key insight is that platforms must balance being both enabler and competitor — providing infrastructure for innovation while selectively internalizing proven concepts. This dual role creates healthy tension that drives continuous platform evolution and ensures the ecosystem remains dynamic rather than stagnant.

Organizational Implementation

From an organizational perspective, there must be a process that progressively transforms innovative use cases, produced by product units or partners, into more standardized components, then into organizational products, and finally into platforms — gradually bringing technological innovation to a componentization level, making it a module, an API on which to build more innovative things.

The mature implementation of this pattern would require platforms to modularize and open access to capabilities not only to internal companies but progressively to the entire ecosystem. Suppose I open my internal platforms to the ecosystem beyond my product areas. In that case, I’ll increase consumption of internal capabilities, capture more insights, and leverage external capacity — which is most important because we must always start from the assumption that the best is outside the organization, not inside.

The Challenge of Opening Up

Products, too, will need to modularize and open to third parties over time, because they’ll be the platforms of the future. Modularization for innovative products means making them accessible and open.

This is often not viewed favorably by companies, as they fear it will enable competitors. But this response doesn’t hold: if you don’t do this, you maintain your technology platforms in a genesis state in their entirety, effectively preventing them from evolving.

If you do this, you don’t put your capabilities under the challenge of external player demands; you don’t do platform-as-a-product work, which is crucial. This way, it’s easier to accumulate technical-organizational debt in internal enabling modular platforms, which don’t open to the outside, don’t capture evolution signals, and risk falling behind — becoming victims of competitors who instead open their ecosystems and embed themselves in customer use.

Before You Go!

As you may know, everything we do is released in Creative Commons for you to use. In case you’re getting value out of these reads and tools, we encourage you to click the 👏 button and hold down to 20–50 claps as this will help us to get more exposure, and hopefully, work more on developing these tools.

If you liked this post, you can also follow us on Linkedin, we normally curate this kind of content.

Subscribe to our newsletter here.

Horizontals, Verticals, and the ILC Model was originally published in Stories of Platform Design on Medium, where people are continuing the conversation by highlighting and responding to this story.

In our work with organizations aiming to improve their operating models for growth and adaptability, we’ve been working with organizations that look nothing alike on the surface.

Industrial manufacturers with diverse product portfolios, digital players chasing “super-app” ambitions, or radically open B2B service platforms face the same structural tension. Markets demand multiplicity: more segments, bundles, business models, and ecosystem plays, while, on the other hand, customers also seek consistency and trust.

Modern organizations must balance variety in offerings and coherence in customer experience, alternating them in their strategy.

The core idea is that you’ve to run a Portfolio and a Platform strategy, balancing these approaches based on market dynamics and organizational goals.

NOTE THAT: 👉 This post is a re-publication of an original posted on our blog, check the original here — you can also subscribe for Boundaryless’ Newsletter here where this content was published first

Why Having Both: a Portfolio Strategy and a Platform Strategy

When we say “portfolio strategy,” we mean pursuing diversification through different business units, products, or market segments, each operating with relative autonomy. This allows organizations to create optionality (by keeping multiple paths available), spread risk, and capture various market opportunities, also enabling employees to express their creativity.

The key force behind a portfolio strategy is Decoupling. Decoupling reduces or standardizes dependency interfaces and allows the organization to create options. When product teams can evolve their roadmaps independently and when technical and service components are modular, the organization can run several bets in parallel and reallocate attention and capital toward what pulls customers. That’s the portfolio engine: disciplined exploration without freezing the system.

Coherence helps customers turn their interactions with the brand into structured, impactful outcomes. It operates not through uniformity between services, but ensuring operational compatibility, shared underlying meaning, and ontologies between portfolio elements.

A “platform strategy” drives coherence across a complex offering: it focuses on creating shared capabilities, data, and infrastructure for seamless integration and consistent experiences. A platform strategy allows the organization to leverage network effects by creating virtuous cycles/flywheels targeting multiple stakeholders, including key end-users and third parties.

In B2B settings, partners can add value to an offering by complementing a company’s value proposition through compatible extensions, service integrations, local deployment, and more. The concept of a partner ecosystem is well-known, particularly in software-centric B2B (think of Salesforce’s AppExchange). As of 2024, the State of Platforms Report, essentially everyone doing Business SaaS has a platform strategy involving third parties.

Structured initiatives to coalesce partner ecosystems are emerging in complex industries like manufacturing or electronics (think Siemens Xcelerator marketplace, for example), and intentionality is essential for your strategy’s success.

A platform backbone — providing consistent identity, data, semantics, policy and compliance, observability, composability — enables the organization to “rebundle” its offerings, ensuring the experiences compose cleanly for the customer and combine with third-party offerings, creating innovative vertical experiences, allowing each customer to enjoy a fully customized experience.

The idea is simple: decouple (portfolio) to explore, recouple (platform) to scale.

The four archetypes (a simple 2×2)

Not every company needs the same approach to balance these two motions. The landing point depends on two aspects: the coherence required in the customer experience and the coupling among shared capabilities. For example, a company aiming for a “super app” experience has a high bar in customer experience coherence. In contrast, an organization with a high manufacturing footprint typically has high coupling among manufacturing, logistics, and often R&D.

If we put Required Experience Coherence on the horizontal axis and Shared Capability Coupling on the vertical axis, we have a useful 2×2 matrix to assess and strategize our company’s position: the map doesn’t prescribe one correct model, but clarifies trade-offs.

1) Highly Shared-Capability Organizations

Experience coherence is moderate; the portfolio spans verticals, but the coupling of core capabilities is high because they are typically capital-intensive. Think portfolios where units share heavy assets — R&D, manufacturing, supply chain, channels. You want to keep roadmaps reasonably autonomous (and product lines accountable to their customers) while using internal contracts for accessing capabilities and shared technology, ideally favoring recontribution of innovations to the shared core. When this works, shared services and technology platforms accelerate time-to-market; when it fails, central functions dictate roadmaps, and autonomy becomes a formality along with adaptability. The primary risk is losing perceived neutrality within the ecosystem if the core competes in too broad a range of verticals.

A good example is Haier. They’ve inspired and collaborated on our 3EO Toolkit for the Platform Organization. Haier has transformed from a traditional appliance manufacturer into a platform-based ecosystem organization. They maintain strong shared capabilities in manufacturing and R&D (for example, their “refrigeration platform” or “washing platform”) while allowing individual micro-enterprises to operate autonomously. Their model enables rapid innovation and market responsiveness across diverse product lines, from smart homes to IoT solutions, all while leveraging common core competencies. This balance between decentralized decision-making and centralized capabilities has become a blueprint for industrial transformation.

2) Platform + Integrated Experiences

In this context, the experience coherence and capability coupling required are extremely high, typical in software-as-a-service platforms serving complex business processes. A robust shared platform (design system, data model, policies) underpins a seamless user experience across features. Vertical teams can be relatively autonomous, but business outcomes and growth objectives need to be distributed with a systemic view. The North Star is the whole product experience, not single unit optimization.

Example: A good example is HubSpot. HubSpot balances integrated user experiences across its marketing, sales, service, CMS, and operations hubs while maintaining a unified platform architecture. Their design system, shared data model, and workflow model, along with a consistent API approach, enable seamless transitions between products, including third-party ones. Third-party developers can extend functionality through their App Marketplace, yet the core experience remains cohesive. This model demonstrates how companies can maintain high experience coherence while supporting ecosystem innovation through standardized platform capabilities.

3) Loose Portfolio / Holding

Experience coherence is low here because all verticals operate in their own business context; shared capability coupling is also low. The organization may have shared IP or labs, but doesn’t need to orchestrate access to centralized capabilities with minimal bandwidth. Businesses operate independently with minimal governance, and capital allocation becomes the primary strategy: choosing where to invest is the mechanism of strategic coherence. This is a legitimate strategy when synergies are weak or when you want diversified exposure. The risk is having a shallow thesis, leading to the organization spreading itself too thin; the remedy is a clear strategic direction in business sectors where the organization can leverage additional value drivers, such as shared distribution or a strong brand, and a focus on results.

A notable example is Flagship Pioneering, a hybrid venture creation and investment firm managing a diverse portfolio of biotech companies aiming to be “enabling platforms.” They have a process to incubate new ventures that operate independently, with their own management and go-to-market strategy. While sharing some foundational insights and methodologies, companies like Moderna and Indigo Agriculture pursue distinct markets with minimal overlap. This approach enables flexibility while maintaining a focus on breakthrough innovations in life sciences and sustainability.

4) Orchestrator / Marketplace

In this quadrant, experience coherence is high, but capability coupling is low within the firm because partners deliver most of the capability and inventory, while the organization provides enabling constraints and compliance. The core owns the brand trust, standards, policies, identity, payments, and experience guardrails. Partners create the variety; the orchestrator guarantees a consistent journey and resolves disputes.

Example: A notable example is Airbnb. Airbnb provides a standardized platform where hosts can list properties and guests can book accommodations, maintaining strict quality standards and user experience consistency, including customer support. The company, despite not owning properties, focuses on creating trust through verified reviews, secure payments, and standardized communication protocols.

Organizational mirroring: what must exist inside

If your company’s outside value proposition is a mix of a Portfolio and Platform strategy, the inside needs to be structured, architected, resourced, and managed to mirror and execute it.

To function effectively, a portfolio engine must comprise entrepreneurial units and effective capital allocation. Depending on your archetype, nodes can have real P&L and roadmap ownership, be bound by explicit contracts for shared services, or be responsible for specific business outcomes. These units are closer to markets and GTM channels, and carry the burden of choice: what to build, bundle, or stop. From a brand architecture standpoint, the stronger the portfolio strategy, the more the brands need flexibility. When the platform engine is key, the organization should avoid direct brand competition for its end-user product brands to avoid chilling partner adoption.

In companies where experience coherence adds value, the platform engine needs to be a standalone product with Product Management leadership. It owns APIs and SDKs, data contracts, identity, policy, risk, payments, design tokens, and governance for healthy interfaces. In such contexts, Third parties/Developer Relations — internal and external — shouldn’t be an afterthought.

All the archetypes above need to juggle three major capabilities:

• Autonomy in delivering customer-facing value
• A Platform capability to support internal/external value providers and third parties on a shared set of modules and services, and generate compounding value through scale and network effects.
• A capital allocation capacity to continuously seed innovation.

Why does knowing your quadrant matter?

Misidentifying the quadrant is one of the most expensive mistakes we see. A company wanting to run as an integrated platform that behaves like a loose holding, fragments UX, and gets bypassed by teams.

An organization that wants to tackle diversity of opportunity but strangles teams with adherence to standards, platform services, and reliance on internal peers will never deliver, as it competes with competitors with fewer execution constraints.

Understand that the choice isn’t always yours: the market context and competitive dynamics often dictate your organization’s quadrant. Markets with strong network effects evolve towards platform models, whereas fragmented markets with diverse customer needs and legacy third-party presence may require a portfolio approach. The key is recognizing these forces early and aligning your organizational structure, processes, and capabilities accordingly.

A quick self-check helps: what level of experience coherence do customers notice and value; which capabilities to share; how much perceived neutrality to attract partners; and how much offer variance to generate in the next planning cycles. If these answers are fuzzy, conflicting playbooks will surface inside the same company.

Closing

A modern organization shouldn’t have to choose between variety and order. They should design a cycle that expands optionality through decoupling and converts it into coherent experiences through a platform backbone. The four archetypes make the choice explicit for each business; the organizational mirror turns it into practice. When the quadrant is clear and the mirror is in place, conversations get simpler, priorities sharper, and trade-offs intentional.

Before You Go!

As you may know, everything we do is released in Creative Commons for you to use. In case you’re getting value out of these reads and tools, we encourage you to click the 👏 button and hold down to 20–50 claps as this will help us to get more exposure, and hopefully, work more on developing these tools.

If you liked this post, you can also follow us on Linkedin, we normally curate this kind of content.

Subscribe to our newsletter here.

The Four Archetypes of Platform Organizations was originally published in Stories of Platform Design on Medium, where people are continuing the conversation by highlighting and responding to this story.