Primitives of Contract-based and Unit-based organizing for better Agility and Engagement
In this post, we explain how a framework based on nodes and agreements, where the performance in executing those agreements can be related to the distribution of outcomes, can be used to implement any kind of organizational structure and why adopting this approach is beneficial in terms of superior organizational agility, engagement, and capacity to execute in complex settings.
It’s been a while – at Boundaryless – we have been working to understand how an organization could be described and run as a set of nodes committing to mutual contracts and agreements.
We’re doing so because such a pioneering organizing approach has recently gained popularity. The most recognizable one is certainly Haier’s Rendanheyi, which we covered widely on this blog and that inspired our work on the 3EO framework. But while the Rendanheyi is very explicit about nodes, contracts, and agreements – other organizations have toyed with the same ideas being less explicit on the terminology or the formalization.
In previous installments, we covered how – for example – companies like Zappos, Fujitsu, Kyocera, and Morningstar adopted a structure based on nodes and agreements, but similar architectures can be seen operating also in giants such as Amazon, where divisions own their own P&L (unit-based), and cascade a set of systemic KPIs inside themselves (performance agreements). KPIs and OKRs – attached for example to particular salary benefits – can be definitely seen as “agreements”: a board could be imagined as a node that agrees with other nodes (divisions) about how – in response to the achievement of certain tangible objectives – salary upsides could be unlocked. Things such ESOPs and VSOPs can also be considered “contracts” between boards and employees (i.e., nodes in the system) to nudge better performance and a sense of belonging.
In this post, we’ll argue how a framework based on nodes and agreements, whose performance goals unlock the distribution of value, can be successfully used to implement any kind of organizational structure. We’ll also partially explain why adopting such a structure is beneficial in terms of superior organizational agility, engagement, and capacity to execute in complex settings.
The case for modular organizations
At Boundaryless we believe there’s a massive case in seeing the organization as a set of interoperating nodes coordinated by agreements. Recent trends in technology development have given autonomous teams great leverage: Li Jin spoke about the unbundling of the Fordist bundle in a seminal piece from 2020 (“Unbundling Work from Employment”) where she pointed out how organizational functions are increasingly available as products and sometimes utilities (think cloud infrastructure). Therefore the first point is: teams are powerful and liberating them from bureaucratic control structures can have huge positive impacts. Secondly, we believe that such a structure helps to transcend the traditional conceptualization in favor of ecosystemic outcomes. Once organizational nodes are unbundled, the company boundary tends to blur and the node can freely enter into agreements and thus collaborate with an unlimited number of external entities. This is the key mindset change we’re preaching here: departing from the idea of an organization as an isolated, static hierarchy and embracing a “heterarchical” perspective where the only thing that counts is the web of agreements that the units (the nodes) have in place with each other, and customers.
In this new syntax, nodes are to be seen as made of properties, assets they own, and member nodes (other nodes) – in a fractal system. People can also be seen as nodes and nodes can belong to multiple supernodes.
Each node takes decisions – through decision-making templates – about how to manage its assets. A node “wallet” that contains the funds that the node can use and distribute is an example of an asset. Other types may include equity-like properties (e.g., crypto tokens, virtual shares), rights (to use other assets), credentials, policies (rules binding the node for the future), and more. One could simply think of a node as a set of members (themselves being nodes), making decisions according to certain policies, about the assets and capabilities the node owns. Decision-making templates can range from power being centralized in one of the member nodes, to democratic, majority decision with voting powers distributed to all member nodes, or even to finding consensus to enact a certain action.
Besides decision-making primitives, nodes could also use “distribution” ones to govern how the assets that the node obtains should be shared among sub-nodes: an example could be the distribution of value according to a certain parameter (e.g., how much equity of the node the members own), by retrospective contribution accounting based on peer to peer votes, by reputation, or by any other mean.
What happens “inside” a node is certainly of interest as much as what happens between nodes. When assets are gained collaboratively, how are decisions over these assets taken? How are the assets that are present in a certain node “treasury” managed and distributed? The tooling that is characterizing web3 – helping make digital assets easily programmable and distributable – could power the transition towards such a model. It’s probably not a case we are caught using terms such as “wallet” or “treasury”, typically coming from a blockchain-enabled space.
Although the tooling of web3 lends itself to be adopted, one could possibly think about a wallet just as a separate P&L in an existing organization, something that could be achieved through a digital banking solution not necessarily forged in web3. On the other hand, we have to be wary about heralding web3 as a solution to the whole problem of organizing: to date, web3 does not offer all the necessary capabilities for the functioning of a team or an organization and it’s not necessarily a good idea to look through human interactions – for example in decision making – through the lenses of algorithms.
Nodes also have to engage in what we call agreements or contracts. For the sake of this, post let’s define an agreement as involving two or more parties where there is:
- the commitment of certain resources;
- for the obtainment of certain outcomes;
- in exchange for a certain distribution of outcomes across the member of the agreement.
Agreement templates could cover a surprising set of elements that keep organizations together today, from the most advanced, such as investment contracts based on performance, to simpler options mimicking a hierarchy where a board of directors or a division allocates budget for a business unit that commits to delivering certain SLAs/KPIs/OKRs to the rest of the organization.
We can think of a contract (agreement) as a mix of:
In general, if we assume that a particular contract can be premised on the commitment of certain assets and is set to produce some outcomes, we can think that the distributable elements can take the form of
- access to capital/budgets/grants committed from investing nodes;
- revenues produced by the execution of the agreement;
- other outcomes/wealth produced by the execution of the agreement? (for example, services or products that can be consumed)
- equity created as a result of the agreement (in case the agreement involves the creation of a new node)
- other types of rights such as governance rights
These are what we sometimes call “skin in the game drivers” (SITG Drivers). What do we mean by SITG drivers? SITG drivers are elements of value that can be used to motivate a party to generate value within a collective agreement. Two types of wealth can be leveraged to foster outcomes in line with an agreement: those pre-existing to the agreement – such as the funds that a founder can invest in creating a new venture, or project – and the ones that the execution of the agreement will likely create, for example, equity of a newly founded venture, revenues produced by a new product, and more.
At the end of the day, SITG drivers represent templates to regulate access to wealth outcomes deriving from the cooperation covered by the agreement. Such wealth can later be allocated to the parties involved through distribution primitives.
A systemic overview
What are the pieces then, that make up the primitives of organizing? The first things we need are the core set of functionalities that: (a) define what sub-nodes are part of the node and (b) manage the node’s assets. Secondly, this ontology has to cover the definition of the contract types and contract obligations that the different nodes can agree to join: objectives, outcomes, participating nodes, and their commitments, etc…
A contract/agreement itself can also be seen as a node in certain conditions (imagine the contract for the foundation of a new node). Contracts can be of different types, and any created ontology should be adaptive to change.
Nonetheless, we can already identify at least:
- direct contracts (between two nodes),
- pooling contracts (contracts that pool different nodes in creating another contract/node)
- funding contracts (contracts used to give birth to new nodes through investing).
These types of contracts should also be characterized by conditional logic based on outcomes and should be able to regulate how the contract execution impacts the distribution of the drivers of Skin in the Game through salaries, revenues, equity, and virtual shares…. These drivers, in turn, should be distributed to the subnodes that participated in the node. Of course, contracts/nodes are also subject to decision-making logic and thus decision-making is another part of this ontology of primitives of unit-based organizing.
In this picture we tried to depict the landscape and the relationship between the single subparts (colored clouds in the background) of the ontology, also mapping some of the existing tools in the market. As the first piece of evidence, no tool currently on the market is able to provide exhaustive support to contract execution. Furthermore, we can see how many newcomers to the space come from web3 thanks to its programmatic access to finance, credentials, and rights – as digital assets. Third, the picture shows how beneficial a shared protocol connecting all the emerging software modules could be, also in terms of the potential network effects “across” different products.
Click here to access a PDF detailed version of the illustration above.
Let’s make a few practical examples to illustrate how the elements we mentioned above integrate into the process of creating an agreement:
Corporate Venture Building agreement
Innovation in Service Delivery – Partnership agreement:
Development of a Restaurant Chain
Separation of units and self-managed P&L
The vision we present in this blog – and in our previous work – relies heavily on the vision of self-managed, independent teams and has a strong bias for the idea that units should manage their resources, wallets, and – at the end of the day – their profit and loss statements.
Adopting self-managed P&L inside organizations certainly bodes for less specialized, and more generalist teams: besides very basic services that we could consider “commodities” we could expect that P&L-owning units must develop a certain level of plasticity and integrate most of the capabilities they need to run their business/product/service model. Enforcing positive P&L at small unit levels will make a strong case for highly adaptable, unspecialized teams that aim at having internally general capabilities, such as product/service design, engineering, etc…
These teams will then rely heavily on sourcing specialized capabilities at market rates to complement the high-level, core ones, either internally or externally.
Enforcing P&L at the small unit level would require the organization to behave more like a venture builder and set loose strategic direction. This makes the case for a set of technologies such as software solutions that allow the creation and execution of agreements between organizational nodes, in a way that is similar to what we’re describing in this piece.
Some companies may want to ensure more control over the outcomes, giving less freedom to teams, and wanting to integrate more elements “vertically” by, for example moving, the enforcement of positive P&L to the division (or higher) level. This choice will allow the organization to define clearer outcomes, ensure the pursuit of a stricter “purpose”, and allow more control of the end customer experience. These “upsides” can be reached at the expense of efficiency, and adaptability: any shared service that exists bounded inside such a space will have to be optimized for “responsiveness” toward its internal customers because they do not have the possibility to source its capabilities externally. In this case, a lagging, stuck, non-responsive service unit inside the organization (being it a platform team or a shared service provider) would generate cascading inefficiencies on the units that rely on its services.
In contexts that embrace P&L separation at bigger scales (division), intermediate specialized types of teams (those that are often called platform teams) may emerge to provide some key, high value-add, element horizontally throughout the division for their internal customers to consume. Most likely, these high value-add services that are to be consumed widely by “customer facing” teams in the division (that are responsible to “rebundle” capabilities into products) will heavily depend on the industry context. As an example, a platform team in a company that produces software may be in charge of running key internal platform elements, such as authentication, etc…while in a company that makes cars platform teams may be the ones that run a wind tunnel, or design services.
The broader the division that has the responsibility of running its own P&L statement, the more specialization of teams can emerge internally (generally between product teams vs “platform” teams) because the division can manage to have an internal loss of efficiency (in favor of responsiveness for shorter time to market) because the product that the division brings to the market can be more heavily differentiated and therefore gain a premium from customers that compensate for the internal inefficiency or lack of modularization.
Even in such a setting, technologies like the one we describe in the piece would still be essential, to define how division-disbursed budgets shall integrate with incentive mechanisms and OKRs/KPIs in a way to ensure that all the players in the sub-system work aligned for the aspired outcomes and are still motivated to be entrepreneurial, even if they’re not directly in touch with customers.
Increasingly, the emergence of standardized, cross-org interfaces, that can help formalize agreements, define SLAs, and performance, and distribute skin in the game to the parties involved will likely pose a challenge to vertically integrated organizations, making it more difficult to bear the inefficiencies, because excellent customer experiences will be more easily producible by leveraging on agreements between largely independent providers, and product/module composability, as we explained in our recent piece “Towards Modular and Composable Markets”.
In this piece, we provided a first breakdown of the several dimension of “primitives” needed for an organization to embrace and give space to what we could call a semiautonomous contract-based and unit-based organizing model. Such a mode of organizing is taking hold globally and – at Boundaryless – we are promoting it, and helping organizations adopt it. We believe such an organizational setting provides superior adaptability and creates environments that favor employee initiative and actualization.
Unit-based organizing often comes with a separate P&L and with an implementation of strategy and execution based on heteronomy instead of hierarchies. In unit-based contexts, the influence between nodes is achieved mainly through contracts and agreements and it generates emergent coherence versus the typical top-down “control”.
Therefore, in the transition towards unit-based heteronomy, organizations will need much finer control and much richer functionality around unit creation, (self) management of a unit’s assets, and most of all, the ways units (nodes) create conditional agreements that impact how the resources and the outcomes created are shared among the nodes.
If you are interested in doing this inside your organization please check – if you feel like researching with Boundaryless, and investing in the creation of a strategic initiative that addresses the holes in terms of tooling and shared ontologies, as an investor, adopter, or promoter please reach out to us through this form, as we’re picking up work these very days. boundaryless.io/3eo-toolkit/
Do you need help to understand how to apply this framework to your organizational structure?
An Entrepreneurial, Ecosystem Enabling Organization
What’s emerging from understanding Haier Group: an Entrepreneurial Ecosystem Enabling Organization, Rendanheyi, and the Ecosystem Micro-Community...
What’s emerging from understanding Haier...
August 23, 2019
Converging towards a Common Protocol of Organizing
Why the Entrepreneurial Ecosystem Enabling Organization may be a breakthrough in organizational development. In this essay, we will go through...
Why the Entrepreneurial Ecosystem Enabling...
May 17, 2021