How to apply efficient design to DAO?

DAO operators have felt the pain of failure to coordinate, communicate, and execute. Is this the future we imagine? Are we really on the road to building a new digital realm? Many experienced operators will even point out that DAO constructs are 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 will dissect these claims and what they mean. Later we will review the possibilities of such designs and try to apply them all in the context of DAOs.

Features of 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 dark principle, which states that each element in a system must not understand the behavior of the system as a whole. Academia’s response to both observations is an acknowledgement 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 attempt to centralize control of a system of free agents, we will fall into inevitable “ignorance.” In this regard, efficiency also requires decentralized decision-making.

Political philosophy has the principle of subsidiarity. This principle asserts that the smallest, lowest, least concentrated force should handle as many things as possible.

All of the above concepts convey the same message. They both suggest that the individual closest to the problem should make the decision. This principle is a central axiom of socio-technical design, which holds that the final design of work systems must be done by the people who do the work. Otherwise, they fail to account for key system components that are often invisible to those not directly involved at that level.

Decentralization is not one way of doing things – it is 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 what the term “organization” implies, and is a consequence of “Corporate Theory” 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 efficiency gains through decentralization alone. Productivity is not sudden. The only things we get for free are entropy, coordination failures.

Since Web3 thinkers often compare DAOs to biological organisms, it’s easy to assume that optimal structures and processes will emerge on their own in a Darwinian fashion. This natural selection may work for the ecosystem, but not for any particular DAO. The vault 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 hierarchical, specialized, and sometimes hierarchical. DAOs destroying all hierarchies may be too strong and appealing to qualify them with nuances. But the inevitable reality is that great design tends to be 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 their 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 in good design. It is important to avoid exploitative entities. Each level of abstraction should add value, not extract value from the system.

We must remember that the network is decentralized; not every individual or organizational unit composes it. 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 premature recursive decentralized work.

Efficient Design Inspiration

These design properties might shed some light on us, but what about real-world examples? Haier is one such 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 or no centralized control, and can be grouped 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 incentive

At Haier, all micro-enterprises succeed or fail on their own merits, and they are free to interact in the way they see fit. If execution fails, the main line of business can choose another supply node. If the line of business goes out of business, its service node will lose a customer. If a micro-enterprise believes that its needs can be better served by an external supplier, it can look outside for services.

What does this have to do with DAOs? A complete reliance on a shared token is not enough to incentivize consistency. We cannot rule out that competition and survival instincts have serious negative consequences. But without these incentives, the team’s budget will be based on historical spend rather than expected return on investment.

customer facing

Haier’s organizational units mainly revolve around customer-facing service lines. Everyone is directly accountable to their customers. Haier has a strict policy not to fund new business until the customer has verified the product. The Haier CEO likes to say that they no longer pay their employees because their salaries are paid directly by customers.

We can learn a lot from it. The DAO vault is not a client. The ultimate success criterion for a DAO is not the allocation of proposals, but the number of products launched with paying customers that lead to inflows and an increase in network value.

We talk a lot about democracy in Web3, but one of the purest forms of democracy is the free market, where individuals vote with their resources. The customer’s “vote” should be the ultimate priority. The dangerous alternative is a kind of Santa economics, where everyone votes for everyone’s budget proposals because they want everyone to vote for their own.

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. The Haier CEO described the structure as “small pieces, loosely connected”. This guideline is a well-known IT and organizational design pattern that DAOs should internalize.

From this perspective, we can think of the DAO as an app store and economy. We can think of them as network incubators rather than individual businesses. This framework has a huge impact on strategic priorities as it allows us to focus on identifying huge 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.” The DAO can amplify this functionality if we utilize the DAO as a launch platform. Think of DAOs as the new search engine.

Applying Efficient Design to DAOs

These observations may be interesting, but how can they be implemented and applied to a DAO that is already running? The good news is that this is not a DAO-specific challenge. There’s a research facility of Team Topologies, and there’s a technology called Inverse Conway Maneuver that we can apply for.

This approach and advice is built on the premise that your organization’s outputs will reflect your organization’s configuration (Conway’s Law) and that you can restructure internally around desired outcomes to create greater efficiency.

These illustrations are based on my previous work detailed in Rethinking the DAO Contributor Funnel. The bottom half of the diagram views the DAO from the side, while the top half views the DAO from the top.

Step 1: Consolidate existing value streams

Determine how DAOs make money, then motivate those product teams individually based on their success. We can do this through revenue sharing.

How to apply efficient design to DAO?

I don’t believe many DAOs have answered this question, but this 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 protocols. Solidification means establishing an on-chain revenue distribution or legal agreement to enforce financial agreements. To some, this explicit workflow concrete step may sound like overkill, but without a clear contract, money can take the place of good vibes.

Step 2: Optimize the contributor experience

The second product of any DAO is the DAO platform itself. DAOs are innovation engines, and their clients are contributors. Therefore, we should differentiate the DAO platform from the value stream it supports. As countries vie for corporate registries, DAOs vie for technical contributors and promising projects.

How to apply efficient design to DAO?

What is the quality of the startup experience? How do we find new talent from existing value streams? If the current value stream is not profitable, we must prepare for future value streams that are profitable.

Step 3: Bring in a team of facilitators

Bring in a team of enablers to commoditize services around key workflows. In the last two steps, we differentiate the platform from the value stream. In this step, we identify opportunities for scaling and address them with an integrated services team. These might be web design, legal services or social media management.

How to apply efficient design to DAO?

This step recognizes the reality of economies of scale and the principle of core competitiveness. These service teams will free up teams to do what they are good at without being bogged down by other issues. All value streams greatly benefit from these commoditized internal services delivered in an efficient manner at scale. A team of facilitators who make a website for an incubation project or build a legal package is very valuable.

Step 4: Practice Timebox Iteration

Finally, operate across multiple reporting, funding, delivery and governance cycles. These should be weekly, biweekly, monthly and quarterly iterations. There is no perfect structure, only iterations that fit the times and circumstances. This reality requires DAOs to continuously evolve and experiment, so it is critical to establish rapid feedback loops and create more opportunities to examine and adapt. Here, we again take Haier’s CEO as an example.

“. . It is impossible to design a complex system from the top down. It has to emerge in an iterative process through imagination, experimentation and learning. When asked how Haier can accelerate the transformation, he gave a simple answer : Carry out 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 present their progress and problems, and practice “DAO Season” with a limited budget and specific goals. These events are set to check and adjust times. These assumptions and practices are based on Gower’s Law, which states that complex systems are built upon previously valid simple systems.

in conclusion

DAOs need architects, not just operators, and need 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 then 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 may pose a greater threat to DAOs. Resources will be wasted and contributors will lose confidence.

DAOs are “allergic” to anything that feels familiar. This is rather childish. We cannot design the superstructure of DAOs in a historical or academic vacuum. We are fortunate to have thousands of years of experience to draw upon.

The rules for Chesterton Fences warn us not to tear them down until we understand why they were built in the first place. Our mission is to amplify historically effective approaches and minimize ineffective ones by coordinating planning and incentive engineering.

I believe our most promising source of design inspiration may come from agile, lean philosophies and methods.

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, and it may end in a technological singularity that will be dominated not only by AI, but by humans with the power of AI.

Posted by:CoinYuppie,Reprinted with attribution to:
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.

Like (0)
Donate Buy me a coffee Buy me a coffee
Previous 2022-09-05 10:29
Next 2022-09-05 10:31

Related articles