a16z: Advanced Framework for Progressive Decentralization

Author: Jad Esber and Scott Duke Kominers

Compiled by: DeFi Dao

Image source: Generated by Maze AI
Decentralization is a pressing priority for Web3—it is also useful in other business contexts. In Web3, the goal is to abandon centralization for security, openness, and community ownership, while in more traditional enterprises, decentralization aids stakeholder engagement and more informed decision-making. For example, decentralization is key to executing the popular concept of "self-managed organizations."
However, achieving complete decentralization from the outset can be difficult, if not entirely unrealistic. Early design elements of a project or business often require a more centralized vision and control. Centralization in the early stages can facilitate coordination, release, and rapid iteration to adapt to product-market fit.

Starting with some degree of centralization does not necessarily force you to remain that way. Here, we will explain a high-level framework for pre-setting future decentralization and provide some guidance on when and how to do so. These guidelines apply to both Web3 projects and more traditional organizations.
Our aim is to help those interested in decentralization think about how to tackle this challenge. However, there is no one-size-fits-all approach, as the exact mechanisms of decentralization are largely determined by the specific business context. Therefore, this is merely an introduction—it is not a playbook for making decisions from components, but rather a framework for how to start thinking about the overall issue.
If there is one thing to remember, it is that decentralization is not necessarily "all or nothing." With proper planning, you can decentralize over time. To plan effectively, it is important to understand the different aspects of your business that can be decentralized and how to do so at the appropriate time.
To use an analogy from the experience of many of us, progressive decentralization is akin to an organization becoming fully remote. Initially, holding in-person meetings in a single central office is helpful for coordination, but over time, it makes sense to become more decentralized. However, to manage distributed work, investments must be made in remote communication technologies, as well as careful documentation of business practices and architecture. Knowing that one day your work will be remote will make the future state easier to achieve. The same goes for progressive decentralization.

Decentralization is Valuable

Decentralization refers to the transfer of control and decision-making authority from a centralized entity—a specific individual, organization, or group—to a distributed network. This can apply to many elements of a business, including content creation, organizational governance, and processes, as well as the technology stack.
Decentralization is often functional. For example, an organization may aggregate opinions from a decentralized network of individuals. In fact, value creation in Web3 largely leverages shared ownership to incentivize many people to participate and contribute simultaneously. (In a previous article, we wrote that "building open platforms that share value directly with users will create more value for everyone, including the platform.")
In other cases, decentralization can provide security—such as against censorship (though to achieve this, a governance structure must be built correctly). Additionally, Web3 platforms seeking to leverage their digital assets may need to decentralize for regulatory reasons.
Perhaps most importantly, decentralization can serve as a commitment to build products in the best interest of users—similar to how co-governance guides cooperatives to emphasize a healthy culture and long-term fair distribution of resources and benefits among members. Furthermore, there is a group of people more likely to self-select into projects that plan for decentralization, both out of principle and because they believe such projects will be more valuable in the long run.

Decentralization is Not Easy

While decentralization is valuable—even necessary—for businesses, starting out can be challenging. Many pressures drive centralization in the short term, even for companies committed to long-term decentralization.

Consider the challenge of launching a product or rapidly iterating to achieve product-market fit without a core central team or centralized decision-making process. Additionally, decentralization in Web3 often comes with expectations of composability, which introduces the risk that others may "fork" your product before you reach scale. Relying on decentralized governance or other forms of crowdsourced input without properly designed support structures—including those that drive participation—can expose the platform to risks of fraud or bribery.

These forces encourage early centralization. But it is important to ensure they do not lead to design decisions that make future decentralization more difficult. That is to say, even if there are good reasons to be more centralized in the early stages, you should design for future decentralization.

Progressive Decentralization

Here are some guidelines to help you actively plan for future decentralization.

First, you must identify the different dimensions along which your business can achieve decentralization. For example, a platform may be able to decentralize content curation while still maintaining a relatively centralized technology stack. A specific product can be divided into "minimum decentralized units" (MDUs), which are largely independent of each other, and then decentralized along these dimensions separately. MDUs may include core teams, external contributors, technology stacks, and more—we will discuss each dimension in detail below.

Even within a specific MDU, you do not have to jump from 0 to 100 all at once. A platform may gradually decentralize curation rights, for instance, starting by soliciting content suggestions from the community before ultimately transferring content decision-making authority entirely.

Visually, we think of this as a set of sliders—perhaps a "decentralization equalizer," with different adjustments for each MDU. You can slide each slider at your own pace, with the difficulty of sliding each one depending on the organization’s readiness for change in that dimension. In this sense, while considering that the upfront costs of a decentralized architecture may be high, it can become a key source of competitive advantage, as it makes the process of decentralization easier in the long run.

MDU Description

It is important to maintain consistency on how to decentralize and what to decentralize, which requires some high-level coordination and often some oversight of the "decentralization equalizer." MDUs will vary across different businesses and product categories, and here are a few examples, along with explanations of how to set up for successful decentralization:

1. Core Team. Hire individuals who can set up work so that external members can potentially take on some responsibilities—for example, a community manager to allow members to start designing the community in a self-managed and self-governing way. Additionally, invest in upskilling your team, making decentralization a long-term goal, and supporting these efforts with new technologies and best practices.

2. External Contributors. The more you move toward complete decentralization, the more your community can participate in the development and management of the product. Adjust according to the level of decentralization you desire, building in an inclusive manner that encourages community involvement in building shared infrastructure, contributing content, and/or managing systems. This is not just about inviting community participation—you must design the organization in a way that enables people to contribute and reward them for doing so. That is to say, establish strong feedback and participation channels, along with corresponding structures and processes.

At the same time, in terms of rewards, introducing reward points or digital tokens to track and reward community contributions can help incentivize community activity (for more information on reputation system design, see our ++article++). For example, you might start by attracting external developers to test your core infrastructure—by allocating rewards to those developers who kickstart activities based on building on the protocol.

3. Technology Stack. The stack can be built in a modular way, allowing you to swap centralized services for decentralized versions at the outset—for example, starting by storing content on AWS and transitioning over time to decentralized storage services like Arweave or IPFS.
4. Finance. You should plan for decentralization in how you initially fund the business and how you allocate resources internally and externally. In particular, you should build finances in a flexible manner to sustain the organization without central control—for instance, consider how your investors would react to exiting community control (which we might call "decentralized exit") and consider making regular financial allocations to the community.

5. Internal Processes. It is important to invest time upfront to think about what your decentralized parts of the business and business processes may require—for example, you may need rich documentation to help community members understand the precedents or context for specific governance decisions.

Clearly listing your organization's MDUs may be helpful to provide a clear perspective that you can share with your team and community regarding the various "sliders." Sharing the roadmap not only aligns with the spirit of decentralization, but the community can also help you achieve your goals. Once you have a set of MDUs, figure out where the sliders currently sit on each dimension and start forming a vision of how you want them to evolve over time. Of course, you should also have a meaningful operational sequence, and if things go wrong, the team might want to start with the MDUs that have less negative impact.

Which Slider to Move, and When?

Finally: how do you know when to slide the slider up—that is, when to increase the decentralization of one or more dimensions?

Zooming out, it is first important that your entire system is relatively stable. But what does this mean? In an early article from a16z, Jesse Walden encouraged teams to assess their position on the journey to and beyond product-market fit: how many more iterations do you need to go through, and how quickly? This is important because any form of organizational change will slow down operational speed; you want to time the movement of the sliders so that the long-term benefits of slowing down outweigh the short-term costs. Ideally, you would make a move when the social and economic dynamics of your platform are stable enough that you can confidently predict how adjusting the level of decentralization will affect community behavior and outcomes.

Next, you should evaluate each MDU in turn. Each dimension will have its own set of factors to weigh when deciding whether to adjust the slider.

You may be driven to decentralize on a specific dimension—for example, you may have too much user-generated content to manage on your own, making it crucial to involve more of the community in curation. Alternatively, you may choose to increase decentralization entirely at your discretion—one example is seeing the long-term commercial value of storing content in a decentralized manner, prompting you to proactively choose to start using such services.

Again, this is not all or nothing. Decentralization occurs at different speeds along each MDU. For instance, you might start planning your finances from day one, keeping the option to "exit to community"; then establish a community treasury six months later; and finally transition to fully decentralized financial management.

Meanwhile, you can maintain a centralized technology stack while iterating to develop a stable product before seeking more peer-to-peer options.

***

Decentralization is powerful, but it is not easy. Especially in the early stages, the need for rapid iteration, quality control, and security often necessitates centralized development (though this may change with improvements in decentralized development technologies).

If your goal is to keep your business decentralized in the long term, the key is to plan well upfront to avoid losing track during the building process. We may see the roles of CEO or COO evolve to accommodate the "decentralization equalizer"—even introducing a new position like "Chief Decentralization Officer."

Thinking from the perspective of MDUs can help you clarify where and how to decentralize different aspects of the business. As the product evolves, when the time is right, you can gradually decentralize along each MDU.