by Jad Esber and Scott Duke Kominers
Decentralization is an imperative in web3 – and it can also be useful in other business contexts. In web3, the aim is to eschew centralization for security, openness, and community ownership, while in more traditional businesses, decentralization can help with stakeholder engagement and more informed decision making – for instance, decentralization is key to executing the popular concept of a “self-managed organization.”
Yet starting out entirely decentralized can be difficult or even totally impractical. Early design elements of a project or business often require more centralized vision and control. And centralization at early stages can make it easier to coordinate, launch, and rapidly iterate toward product-market fit.
Starting out with some degree of centralization, though, doesn’t necessarily force you to stay that way. Here, we’re going to explain a high-level framework for designing for future decentralization up front, and offer some guidance about when and how to do so. The guidelines apply to both web3 projects and more traditional organizations.
Our intention is to help those interested in decentralization think about how to approach the challenge. There is, alas, no one-size-fits-all approach because the precise mechanics of decentralization are very much a function of the specific business context. So this is intended as an introduction – it isn’t a playbook for making decisions component-wise but rather a framework for how to start thinking about the overarching problem.
If there’s one thing to remember, it’s that decentralization needn’t be “all-or-nothing.” With proper planning, you can decentralize over time. And to plan effectively, it’s important to understand the different dimensions along which your business can decentralize, and how to do so at the proper times.
To make an analogy to an experience many of us have had, progressive decentralization is like an organization becoming fully remote. Starting out in a single central office with in-person meetings is helpful for coordination, but over time it can make sense to become more distributed. But to manage distributed work, it’s essential to invest in remote communications technology, as well as in carefully documenting business practices and architecture. Designing an organization knowing that one day you’ll all be remote makes the future state easier. The same is true with progressive decentralization.
Decentralization can be valuable…
Decentralization is the transfer of control and decision-making 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 tech stack.
Decentralization is often functional. For example, an organization might aggregate opinions from a decentralized network of individuals. Indeed, value creation in web3 is in large part about using shared ownership to incentivize participation and engagement from many people at once. (In a past article, we wrote about how “building open platforms that share value with users directly will create more value for everyone, including the platform.”)
In other contexts, decentralization can provide security – for instance against censorship (although for this to work, it’s important to structure governance correctly). And separately, web3 platforms seeking to make use of their own digital assets also need to decentralize for regulatory reasons.
Perhaps most importantly, decentralization can serve as a form of commitment to build the product in users’ best interests – similar to how shared governance leads cooperatives to emphasize healthy cultures and a long-run equitable distribution of resources and proceeds across members. There’s also a group of people who are more likely to self-select into projects that have plans to decentralize both on principle – and because they believe that such projects will be more valuable in the long run.
… but decentralization isn’t easy.
While decentralization can be valuable for a business – necessary, even – it can be difficult to start out that way. Many pressures push toward centralization in the short run even for companies that are committed to decentralization in the long run.
Think of the challenge, for instance, of initiating a product or conducting the type of quick iteration required to get to product-market fit without a core central team or a centralized process for decision-making. Furthermore, decentralization in web3 also typically comes with an expectation of composability, which introduces the risk that someone else might “fork” your product before you achieve scale. And relying on decentralized governance or other forms of crowdsourced input without the properly designed support structures – including those that drive engagement – can potentially expose a platform to risks of fraud or payola.
These forces encourage centralization early on. But it’s important to ensure that they don’t lead to design decisions that make future decentralization even harder. That is, even if there are good reasons to be more centralized early on, you should design for future decentralization.
Progressive decentralization
Here is some guidance to help you actively plan for future decentralization.
First, it’s essential to identify the different dimensions along which your business can become decentralized. For instance, a platform might be able to decentralize content curation even while there is still a relatively centralized tech stack. A given product can be segmented into “minimum decentralizable units” (MDUs) that are mostly independent from one another, and then decentralized along each of these dimensions separately. MDUs might include the core team, external contributors, the tech stack, and so on – we discuss various dimensions in more detail below.
And then even within a given MDU, you don’t have to go from 0 to 100 all at once. A platform might gradually decentralize curation, say, by first soliciting content recommendations from the community, before eventually turning over content decisions entirely.
Visually, we think of this as like a set of slider bars – a “decentralization equalizer,” perhaps, with a different adjustment for each MDU. You can slide each bar up at its own pace, and the difficulty of sliding each bar is dependent on the business’s readiness for change on that dimension. In this sense, while architecting with decentralization in mind is more costly upfront, it can become a key source of competitive advantage because it makes the process of decentralization easier in the long run.
Characterizing MDUs
It’s important to stay aligned around a vision for how and what to decentralize, which requires some high-level coordination and usually some oversight over the “decentralization equalizer.” MDUs will vary across different business and product categories, but here are a few examples, along with illustrations of how you might set them up for decentralization success:
1. Core team. Hire people who are able to set up their work so that it might be possible for external members to take over some of the responsibilities – for example, a community manager who designs the community in a way that allows members to start to self-manage and self-govern. Additionally, invest in upskilling your team with an eye toward decentralization as a long-term target, and of the new technologies and best practices that support those efforts.
2. External contributors. The further you slide toward fully decentralized, the more your community gets involved in how the product evolves and is governed. Calibrating based on how decentralized you want to be, you’ll want to build in a participatory way and cultivate the community that’s going to take part in building on top of shared infrastructure, contributing content, and/or governing the system. And it’s not just about inviting community participation – you have to design the organization in a way that enables people to contribute and rewards them for doing so. This means building robust feedback and engagement channels, together with the accompanying structures and processes.
On the reward side, meanwhile, introducing reward points or digital tokens to track and reward community contributions can help incentivize community activity (see this article of ours for more on reputation system design). For example, you might start off by engaging external developers to test out your core infrastructure – perhaps by allocating rewards to developers who kick-start activity by building on top of the protocol.
3. The technology stack. The stack can be architected in a modular way that allows you to swap in decentralized versions of the centralized services that you start out with – for example, by starting out storing content on AWS and over time transitioning to decentralized storage services, such as Arweave or IPFS.
4. Finance. You should plan for decentralization both in terms of how you fund the business initially and the ways you allocate resources internally and externally. In particular, you should structure finances in a resilient way that can sustain the organization without central control – for instance, consider how the investors you are bringing on would react to an exit to community control (which we might call a “decentralexit,” perhaps), and think through regular allocations to a community treasury.
5. Internal processes. It’s important to invest the time upfront to think through what might be needed for you to decentralize parts of your operations and business processes – for example, you might need rich documentation that allows community members to understand precedent or context for specific decisions for governance.
It may be helpful to explicitly lay out your organization’s MDUs so as to provide a clear view of the various levers that you can share with the team and community. Not only would sharing the roadmap be in the spirit of decentralization, the community can also help you get there – and hold you to account. Once you have a set of MDUs, figure out where the slider currently sits on each of the dimensions and start to form a view of where you’d like it to go over time. There is also an order of operations here that will make sense, and teams should probably start with the MDUs that have less of a negative impact if things go wrong.
Which slider to move, and when?
Finally: how do you know when it’s time to move the slider up – that is, when can you increase decentralization of one or more dimensions?
Zooming out, it’s first important that your overall system is relatively stable. What exactly does this mean? In an earlier article for a16z, Jesse Walden encouraged teams to assess where they sit on the journey to and past product-market fit: How many more iterations do you still need to go through, and how quickly? This is important because any form of organizational change will slow down the operation; you want to time moving a slider so that the long-run benefit of slowing down outweighs the short-run cost. Ideally, you would also make the move at a time when the social and economic dynamics of your platform have stabilized enough that you can robustly predict how adjusting the level of decentralization will affect community behavior and outcomes.
Next, you should assess each MDU in turn. Each dimension will have its own set of factors to weigh when deciding whether to adjust the slider. You might get pushed to decentralize on a specific dimension – for example, you might have too much user-generated content to manage on your own, making it critical to start involving the wider community in curation. Alternatively, you might choose to increase decentralization entirely of your own volition – one instance could be that you see long-term business value in storing content in a decentralized way, and so you make the active choice to start using such a service.
And once again, it isn’t all or nothing. Decentralization happens at a different pace along each MDU. For example, you might start to plan your finances in a way that keeps the option of “exit-to-community” open from day 1; establish a community treasury six months in; and then later switch to fully decentralized financial governance. And in parallel with that, you might maintain a centralized tech stack while iterating toward a stable product before looking for more peer-to-peer options.
***
Decentralization is powerful, but it isn’t easy. Especially early on, the need for fast iteration, quality control, and security often drive toward centralized development (although this might change as the technology for decentralized development improves).
If you aim for your business to be decentralized in the long run, the key is to plan for that upfront, and not lose track of it as you build. We might see the role of a CEO or COO evolve to take care of the “decentralization equalizer” – or even the introduction of an entirely new position, like a “Chief Decentralization Officer.” Thinking in terms of MDUs can help you figure out where and how to decentralize different aspects of your business. And then as the product evolves, you can decentralize along each MDU progressively, when the time is right.