By Jad Esber and Scott Duke Kominers
Compilation: The Way of DeFi
Image source: Generated by Maze AI
Decentralization is a Web3 imperative — and it’s useful in other business contexts, too. In Web3, the goal is to give up centralization for security, openness, and community ownership, while in more traditional businesses, decentralization facilitates stakeholder engagement and more informed decision-making, for example, decentralization is key to executing the popular concept of “self-managing organizations.” However, achieving full decentralization at the outset can be difficult or even downright unrealistic. Early design elements of a project or business often require more centralized vision and control. Centralization in the early stages can make it easier to coordinate, release, and iterate quickly to achieve product-market fit.
However, starting with some degree of centralization does not necessarily force you to stay that way. Here, we will explain a high-level framework for presupposing future decentralization and provide some guidance on when and how to do so. These guidelines apply both to Web3 projects and more traditional organizations.
Our intention is to help those interested in decentralization think about how to approach this challenge. However, there is no one-size-fits-all approach, as the exact mechanics of decentralization are largely determined by the specific business context. As such, this is just an introduction -- it is not a playbook for making decisions from the components, but rather a framework for how to start thinking about the overall problem. 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 it when appropriate. To use an analogy from the experience many of us have, incremental decentralization is like an organization becoming fully remote. In the beginning, in-person meetings in a single central office are helpful for coordination, but over time it makes sense to become more distributed. But to manage distributed work, it is necessary to invest in remote communication technology, as well as carefully document business practices and architecture. Designing an organization knowing that one day all your work will be remote makes it easier to navigate that future state. The same is true with incremental decentralization.
Decentralization is valuable
Decentralization is the transfer of control and decision-making power 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, and even the technology stack.
Decentralization is often functional. For example, an organization might aggregate opinions from a decentralized network of individuals. Indeed, much of Web3 value creation is about leveraging shared ownership to incentivize many people to participate and invest simultaneously. (In a past post, we wrote that “building open platforms that share value directly with their users will create more value for everyone, including the platforms”). In other cases, decentralization can provide security — such as protection against censorship (although governance structures must be built correctly to do this). Alternatively, Web3 platforms seeking to leverage their own digital assets may also need to be decentralized for regulatory reasons. Perhaps most importantly, decentralization can serve as a commitment to building products in the best interest of their users — similar to how co-governance guides cooperatives to emphasize healthy culture and fair distribution of resources and benefits among members over the long term. In addition, there is a group of people who are more likely to self-select into projects that plan to decentralize, 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, it can be difficult to get started. Many pressures drive centralization in the short term, even for companies committed to long-term decentralization.
Imagine the challenges of launching a product or iterating quickly to reach product-market fit without a core central team or centralized decision-making process. Furthermore, decentralization in Web3 often comes with the expectation of composability, which creates 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 — has the potential to expose platforms to the risk of fraud or bribery.
These forces encourage early centralization. But it’s important to make sure they don’t lead to design decisions that make future decentralization more difficult. That is, even if there are good reasons to be more centralized early on, you should still design for future decentralization.
Progressive Decentralization
Here are some guidelines to help you proactively plan for a decentralized future.
First, it’s important to identify the different dimensions along which your business can be decentralized. For example, a platform might be able to decentralize content curation even while still having a relatively centralized tech stack. A particular product can be split into “minimum divisible units” (MDUs), which are mostly independent of each other, and then decentralized along each of these dimensions. MDUs might include the core team, external contributors, the tech stack, and more — we’ll discuss each dimension in detail below.
Even within a given MDU, you don’t have to jump from 0 to 100 all at once. A platform might gradually decentralize curation, for example, by soliciting content suggestions from the community before eventually handing over full control of content decisions.
Visually, we think of this like a set of sliders — perhaps a “decentralization equalizer” with different adjustments for each MDU. You can slide each slider at your own pace, and the difficulty of sliding each slider depends on the enterprise’s readiness for changes in that dimension. In this sense, while decentralized architectures are more expensive upfront, they can be a key source of competitive advantage because they make the process of decentralization easier in the long run.
MDU Description
It’s important to be aligned on how and what to decentralize, which requires some high-level coordination and usually some oversight of the “decentralization equalizer.” MDUs will vary across businesses and product categories, but here are a few examples and instructions on how to set them up for decentralization success:
1. Core Team. Hire people who can set up the work so that it is possible for outside members to take over some responsibilities - for example, a community manager to allow members to start designing the community in a self-managed and self-governed way. Also, invest in improving the skills of your team, with decentralization as a long-term goal, and new technologies and best practices to support these efforts.
2. External Contributors. The further you move toward full decentralization, the more your community can be involved in the development and management of the product. Depending on how much decentralization you want, you build in a participatory way, fostering community involvement in building shared infrastructure, contributing content, and/or governance systems. This goes beyond just inviting community participation -- you have to design the organization in a way that enables people to contribute, and rewards them for doing so. That means building in strong channels for feedback and engagement, and the structures and processes to do so.
Meanwhile, on the rewards side, introducing reward points or digital tokens to track and reward community contributions can help incentivize community activity (see our article for more on reputation system design). For example, you could start by attracting external developers to test your core infrastructure by allocating rewards to developers who kick-start activity by building on top of your protocol.
3. Technology stack. The stack can be built in a modular way, allowing you to swap out decentralized versions of centralized services when you start out—for example, starting out by storing content on AWS and over time transitioning to a decentralized storage service like Arweave or IPFS.
4. Finance. You should plan for decentralization in terms of how you will initially fund the business and the way you allocate resources internally and externally. In particular, you should structure your finances in a resilient way to sustain the organization without central control, for example, by considering how the investors you bring on would react to an exit from community control (what we might call a “decentralized exit”) and considering making regular financial disbursements to the community. 5. Internal procedures. It’s important to invest time upfront to think about what you might need to decentralize parts of your business and business processes — for example, you might need rich documentation to let community members know the precedents or context for specific decisions about governance.
It may be helpful to explicitly lay out your organization's MDUs in order to provide a clear view of the various "sliders" that you can share with the team and community. Sharing a roadmap is not only in the spirit of decentralization, but the community can also help you get there. Once you have a set of MDUs, figure out where the sliders are currently on each dimension and start to form a view of how you want it to evolve over time. Of course, you also want to have an order of operations that makes sense, and if things go wrong, the team should probably start with the MDU with the least negative impact.
Which slider to move, and when?
Finally: how do you know when to move the slider up -- that is, when to increase decentralization in one or more dimensions?
Zooming out, it’s important that your entire system is relatively stable. But what does that mean exactly? In an early a16z article, Jesse Walden encouraged teams to assess where they are on the journey to and beyond product-market fit: How many more iterations do you need to go through, and how fast? This is important because any kind of organizational change will slow down operations; you want to time the slider so that the long-term benefits of slowing down outweigh the short-term costs. Ideally, you’ll make the move when the social and economic dynamics of your platform are stable enough that you can robustly 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 might be driven to decentralize on a particular dimension - for example, you might have too much user-generated content to manage yourself, making it critical to involve more of the community in curation. Alternatively, you might choose to increase decentralization completely on your own accord - an example would be that you see long-term business value in storing content in a decentralized manner, so you actively choose to start using such a service.
Again, this is not all or nothing. Decentralization happens at different speeds along each MDU. For example, you might start planning your finances from day one, keeping the option to “opt out of the community”; build a community treasury after six months; and then move to fully decentralized financial management.
In the meantime, you can maintain a centralized tech stack while iterating towards a stable product before looking into more peer-to-peer options.
***
Decentralization is powerful, but it’s not easy. Especially in the early days, the need for rapid iteration, quality control, and security often requires centralized development (although this may change as decentralized development technology improves).
If your goal is to decentralize your business long term, it’s critical to plan for it upfront so you don’t lose track while building. We may see the role of the CEO or COO evolve to take care of the “decentralization equalizer” — or even introduce an entirely new position like “Chief Decentralization Officer.”
Thinking in terms of MDUs can help you figure out where and how to decentralize different aspects of your business. As your product evolves, you can incrementally decentralize along each MDU when the time is right.
