Progressive decentralization: a high-level framework

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.

***

Jad Esber is the co-founder and CEO of koodos labs (DBA koodos) and an Affiliate at Harvard’s Berkman Klein Center for Internet & Society and The New School’s Institute for the Cooperative Digital Economy. He builds, writes, and speaks on the topic of social spaces and creative tools and the intersections with decentralized technologies. Previously, he was at Google and YouTube, where he worked with and built for creators and artists in emerging markets.

Scott Duke Kominers is a Professor of Business Administration at Harvard Business School, a Faculty Affiliate of the Harvard Department of Economics, and a Research Partner a16z crypto. He also advises a number of companies on marketplace and incentive design; for further disclosures, see his website.  

***

Acknowledgments: The authors thank Brandon Baraban, Dmitriy Berenzon, Cam Brand, Apurva Chitnis, Sonal Chokshi, Andy Hall, Miles Jennings, Valet Jones, Steve Kaczynski, Elena Mikhaylova, Kirill Noskov, Tim Roughgarden, SAFA, Kevin Shay, Jennie Silber, and Porter Smith for helpful ideas and comments. Special thanks also to our editor, Tim Sullivan.

***

The views expressed here are those of the individual AH Capital Management, L.L.C. (“a16z”) personnel quoted and are not the views of a16z or its affiliates. Certain information contained in here has been obtained from third-party sources, including from portfolio companies of funds managed by a16z. While taken from sources believed to be reliable, a16z has not independently verified such information and makes no representations about the enduring accuracy of the information or its appropriateness for a given situation. In addition, this content may include third-party advertisements; a16z has not reviewed such advertisements and does not endorse any advertising content contained therein.

This content is provided for informational purposes only, and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisers as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. Furthermore, this content is not directed at nor intended for use by any investors or prospective investors, and may not under any circumstances be relied upon when making a decision to invest in any fund managed by a16z. (An offering to invest in an a16z fund will be made only by the private placement memorandum, subscription agreement, and other relevant documentation of any such fund and should be read in their entirety.) Any investments or portfolio companies mentioned, referred to, or described are not representative of all investments in vehicles managed by a16z, and there can be no assurance that the investments will be profitable or that other investments made in the future will have similar characteristics or results. A list of investments made by funds managed by Andreessen Horowitz (excluding investments for which the issuer has not provided permission for a16z to disclose publicly as well as unannounced investments in publicly traded digital assets) is available at https://a16z.com/investments/.

Charts and graphs provided within are for informational purposes solely and should not be relied upon when making any investment decision. Past performance is not indicative of future results. The content speaks only as of the date indicated. Any projections, estimates, forecasts, targets, prospects, and/or opinions expressed in these materials are subject to change without notice and may differ or be contrary to opinions expressed by others. Please see https://a16z.com/disclosures for additional important information.