Decentralization needs to improve efficiency.
DAO operators are already feeling the pain of coordination, communication, and execution failures. Is this the future we imagine? Are we really on the way to building a new digital realm? Many experienced operators would even point out that DAO construction is inherently inefficient.
Decentralization is compatible with efficient execution, but efficiency is not free. It must be achieved through careful organizational design. In this article, we dissect these claims and what they mean. We will then review the possibilities of such designs and try to apply them all in a DAO context.
Features for Efficient Design
Efficiency is decentralized
Decentralization needs to improve efficiency. We can infer this truth from multiple independent fields of science.
In cybernetics, the Conant-Ashby theorem states that every system regulator must have an internal model of the system it regulates. A natural consequence of this is the principle of darkness, which states that every element in a system is necessarily ignorant of how the system behaves as a whole. The academic response to both of these observations has been to acknowledge that self-organizing systems must delegate control to subsystems that are closer to the information needed for control. Complex adaptive systems require distributed control to function properly.
In economics, the Local Knowledge Problem refers to the fact that the data required for rational economic planning is distributed among individual actors, so it inevitably exists outside the cognition of centralized institutions. Likewise, if we try to centralize control over a system of free agents, we will fall into the inevitable "ignorance". Here too, efficiency requires decentralized decision-making.
Political philosophy has a subsidiarity principle. This principle asserts that the smallest, lowest, and least concentrated force should handle as much business as possible.
All of the above concepts communicate the same message. They both suggest that the individual closest to the problem should make the decision. This principle is a central axiom of sociotechnical design, which holds that the ultimate design of work systems must be done by the people who do the work. Otherwise, they fail to account for critical system components that are often invisible to those not directly involved at that level.
Decentralization isn't one way of doing things - it's the only way in complex adaptive systems. This is edge computing for efficiency.
Efficiency must be designed
Efficiency is the result of careful organizational design. This is implied by the term "organization" and is a consequence of "Theory of the Firm" and "Conway's Law". The premise is that individuals must organize themselves, interactions, and outputs to produce complex and satisfying goods. This is difficult, but many DAOs expect to be more efficient through decentralization alone. Productivity is not bursty. The only thing we get for free is entropy, coordination failure.
Since Web3 thinkers often compare DAOs to biological organisms, it's easy to assume that optimal structures and processes will emerge themselves in a Darwinian fashion. This natural selection may work for the ecosystem, but not for any particular DAO. The coffers will be emptied faster than we can cycle through all possible combinations of organizational designs.
Designs are often componentized (even hierarchical!)
Efficient designs are often layered, specialized, and sometimes even hierarchical. The memes of DAO destroying all hierarchies are probably too strong and appealing to qualify them with nuance. But the inescapable reality is that great design is often layered. This is a natural phenomenon, not just a product of human society.
We can use other terms like namespace, scope and abstraction to express the same concept. Organizations need to limit focus to reduce cognitive load and coordination overhead. This fact does not equate to command and control.
I mention this because if we exclude this pattern from the start, we may inadvertently shorten our efforts at good design. It is important to avoid exploiting entities. Each level of abstraction should add value, not extract value from the system.
We must remember that the web is decentralized; not every single individual or organizational unit makes it up. Ignoring this is a trap, and it has led to the end of many good projects that never delivered because they got bogged down in immature recursive decentralization efforts.
Efficient Design Inspiration
These design properties might shed some light, but what about real-world examples? Haier is such an example.
Haier, a $35 billion home appliance company, now has 4,000 micro-enterprises. Each micro-enterprise is free to form and grow with little central control, and can be classified into one of three functional archetypes:
-
Transformers serve the existing Evergreen product line.
-
Incubators serve emerging business lines.
-
Node sells component products and services to two other customer-facing lines of business, such as design, manufacturing, and human resources.
Together, this structure produces an incentive-aligned, customer-facing, decentralized platform. Let's look at each property of this setting.
independent motivation
In Haier, all micro-enterprises succeed or fail on their own merits, and they are free to interact as they see fit. If the execution fails, the main line of business can choose another supply node. If a line of business ceases operations, its service node will lose a customer. If a microenterprise thinks its needs can be better met by external suppliers, it can seek services from outside.
What does this have to do with DAOs? Relying entirely on shared tokens is not enough to incentivize consensus. We cannot rule out that competition and survival instincts have serious negative consequences. But without these incentives, teams base their budgets on historical spending rather than expected return on investment.
customer-oriented
Haier's organizational units mainly revolve around customer-facing service lines. Everyone is directly accountable to their customers. Haier has a strict policy of not funding new business until customers have validated the product. The Haier CEO likes to say that they no longer pay employees because they are paid directly by customers.
We can learn a lot from it. The DAO treasury is not a client. The ultimate success metric for a DAO is not the proposals allocated, but the number of products launched with paying customers that lead to capital inflows and increased network value.
We talk a lot about democracy in Web3, but one of the purest forms of democracy is a free market where individuals vote with their resources. The customer's "vote" should be the ultimate priority. The dangerous alternative is a kind of Santanomics where everyone votes yes on everyone's budget proposal because they want everyone to vote yes to their own proposal.
decentralized platform
Haier functions more like a networking and publishing platform than a single company. Small autonomous teams make decisions, and Haier focuses on creating the best conditions for these teams to start. Haier's CEO describes the structure as "small pieces, loosely connected together." This principle is a well-known IT and organizational design pattern that DAOs should internalize.
From this perspective, we can think of DAOs as app stores and economies. We can think of them as network incubators rather than individual businesses. This framework has a huge impact on strategic prioritization because it allows us to focus on identifying big opportunities and project launch experiences rather than predefined product spaces.
One venture capitalist described Haier as "a giant search function that scans the battlefield and finds the most promising opportunities." DAO can amplify this functionality if we utilize DAO as a launch platform. Think of DAO as the new search engine.
Apply Efficient Design to DAO
These observations may be interesting, but how do you implement and apply them to an already running DAO? The good news is that this is not a challenge unique to DAOs. There's a research facility called Team Topologies, and there's a technology called Inverse Conway Maneuver that we can all apply for.
This approach and advice is built on the premise that your organization's output will reflect your organizational configuration (Conway's Law), and you can internally reorganize around desired outcomes to create greater efficiencies.
These illustrations are based on my previous work detailed in Rethinking the DAO Contributor Funnel. The bottom half of the diagram looks at the DAO from the side, while the top half looks at the DAO from the top.
Step 1: Strengthen existing value streams
Determine how the DAO makes money, then individually incentivize these product teams based on their success. We can do this through revenue sharing.
I don't believe many DAOs have answered this question, but the answer is key. Who the customer is and what they need determines everything else. Once you have identified value streams, solidify them through on-chain or off-chain agreements. Solidification means establishing an on-chain revenue distribution or legal agreement to enforce financial agreements. To some, this explicit concrete step in the workflow might sound like overkill, but without a clear contract, money can replace good vibes.
Step 2: Optimize the Contributor Experience
The second product of any DAO is the DAO platform itself. The DAO is an innovation engine whose clients are contributors. Therefore, we should distinguish DAO platforms from the value streams they support. As countries vie for business registry, DAOs vie for technical contributors and promising projects.
What is the quality of the startup experience? How do you source new talent from existing value streams? If current value streams are not profitable, we must prepare for future value streams that will.
Step 3: Bring in a team of enablers
Bring in teams of enablers to deliver commoditized services around key workflows. In the last two steps, we differentiate the platform from the value stream. In this step, we identify opportunities for scale and address them with integrated services teams. These might be web design, legal services or social media management.
This step recognizes the reality of economies of scale and the principle of core competence. These service teams will free up teams to do what they do well without being weighed down by other issues. All value streams benefit greatly from these commoditized in-house services delivered in a scale-efficient manner. A team of facilitators who make a website for an incubation project or build a legal wrapper are invaluable.
Step 4: Practice Timebox Iterations
Finally, operate across multiple reporting, funding, delivery and governance cycles. These should be weekly, bi-weekly, monthly and quarterly iterations. There is no perfect structure now, only iterations that fit the times and circumstances. This reality requires DAOs to continually evolve and experiment, so establishing rapid feedback loops and creating more opportunities to inspect and adapt is critical. Here, we again take Haier's CEO as an example.
“..designing a complex system from top to bottom is impossible. It has to emerge in an iterative process through imagination, experimentation and learning. When asked how Haier has accelerated its transformation, he has a simple answer : Conduct more experiments and replicate the most successful methods faster, because revolutionary goals are best achieved through evolution." - Zhang Ruimin, CEO of Haier
The easiest way to do this is to use weekly demos, where all working groups show their progress and problems encountered, and practice "DAO seasons" with a limited budget and specific goals. These events are set as times for inspection and adjustment. These assumptions and practices build on Gower's Law, which holds that complex systems build upon previously efficient simple systems.
in conclusion
DAOs need architects, not just operators, more structure, not less. This is not a violation of decentralization. The almost universally accepted idea that all complex work can be broken down into small, paid tasks and distributed to the masses is just one example of a design anti-pattern we desperately need to get rid of.
Failure to execute and deliver effectively could pose a greater threat to DAOs. Resources will be wasted and contributors will lose confidence.
The DAO is "allergic" to anything that feels familiar. This is relatively childish. We cannot design a DAO's superstructure in a historical or academic vacuum. We are fortunate to have thousands of years of experience to draw upon.
The rules of Chesterton fences warn us not to tear them down until we understand why they were built in the first place. Our task is to amplify what has historically worked and minimize what has not, through coordinated planning and incentive engineering.
I believe our most promising sources of design inspiration may come from Agile, Lean philosophies and methodologies.
With these resources and the emerging DAO structure, we may finally have the means to usher in a whole new era of human intelligence. We are truly on the path to a second renaissance, which may end in a technological singularity dominated not only by artificial intelligence, but by humans with the power of artificial intelligence.