What is a Decentralized Autonomous Organization (DAO) and How Might this New Organizational Structure Impact Collaboration?
Decentralized Autonomous Organizations (DAOs) are gaining traction as a competitive organizational structure, separate from traditional companies and nonprofits. DAOs are a new organizational paradigm enabled by crypto-currency and blockchain technology. Replacing traditional boards of directors and executive teams, they are governed by a community of people that own the “governance token” of the DAO. Some tout that DAOs are more collaborative, move faster, and create better products, but is there evidence to support these claims?
This case study provides anecdotal evidence from one organization shifting from a centralized company to a DAO. It also offers some insights along the way about how DAOs operate and how they differ from traditional centralized companies. As a key player in the transformation described in this case study, I suggest that the collaborative power of “individuals as equals” is one significant aspect that sets DAOs apart from traditional hierarchical organizations, disrupting the traditional practices of management in decision-making.
My DAO Story...
My story is about ShapeShift DAO. It provides an account of tension between the internal actors in the formation and execution of the DAO, as well as the tension between these same actors in its hierarchical predecessor. The situation revolving around the software release cycle is compared to similar situations that occurred inside ShapeShift, Inc - the centralized company that operated until July, 2021. The same people were involved in the described situations, it is only the organizational context within which they were involved that changed.
For the three years prior to transitioning to the DAO, I was the Director of Engineering at ShapeShift, Inc. As of this writing, I am the Engineering Workstream Leader in the new ShapeShift DAO. I will share more about what a workstream is and how DAOs work in a bit. First, let’s peek at the tension that existed around the software release cycle at ShapeShift, Inc. before the transition.
A Challenged Release Process
As part of a centralized company, the engineering team performed the design, development and testing of software toward a customer release. That process included breaking down the work for understanding and clarity as well as the ability to estimate our time to completion. At times during this process, upper management would push our team to release new features by a specific date, regardless of our analysis and estimates. External events such as conferences and planned public announcements drove these deadlines.
Driven by the sped up targets, engineering would evaluate options including corners that could be cut and scope reductions they could negotiate to fit this new timeline. Internally on our team, deeper discussions among engineers emerged about whether or not it was worth it and the negative consequences of such actions. However, engineering leadership, including myself, felt little authority to overrule these new targets. Corporate leaders added incentives to help motivate engineering to meet the new targets including bonuses and extra days off.
Individual engineers were mixed on the impact of the aggressive delivery targets: some engineers were upset by the external influence and potential negative impacts on the people and product, others would tolerate it, and a few were outspoken supporters. The general sentiment was that engineers were at the mercy of “the business” as represented by senior leadership, partly because employee jobs, security and salaries depended upon senior leadership approval. The sentiment was that the engineering team did not have enough sovereignty to make sure the product was engineered well enough to support a high enough quality product.
The ongoing tension between engineering and leadership over time and multiple releases resulted in compromised designs and reduced quality practices, eroding the overall stability and performance of the platform. As the list of problems grew, the confidence in the platform suffered.
DAO Context
DAOs run under a fundamentally different set of principles, policies and structures from their centralized counterparts. While there are differences among how DAOs are executed, most — including ShapeShift DAO — do not have a CEO, an executive team, or a board of directors. The traditional construct of upper management driving priorities, timelines, and financial decisions does not exist in DAOs.
Rather, most DAOs run using a proposal and voting strategy. Proposals are required to identify and spend funds from the DAO’s treasury. Proposals are created and posted by anyone within the DAO. Proposals are then approved or rejected by vote. Which raises the question, who gets to vote?
How one obtains the right to vote on proposals is by holding the “governance token” for that specific DAO. Open decentralized exchanges exist where most DAO governance tokens are available. Some knowledge of how to hold and transfer crypto-currency and an internet connection is all that is required for anyone to buy a DAO’s governance token and participate in the governance process. The governance token for ShapeShift DAO is the FOX token. Therefore, anyone who owns the FOX token can vote on any open proposal.
Another question that many DAOs, including ShapeShift, have answered in a similar way, is who controls the funds that proposals approve. For funding requests that are meant to be spent over multiple months, the concept of a workstream and the role of workstream leader were created. Basically, a workstream is formed when a group of individuals come together that want to provide a specific functional value to the DAO. This usually includes the individuals working full-time to perform that function, and then require pay commensurate with full-time work. A workstream leader emerges who then creates a funding proposal. If the proposal succeeds in the governance process, the requested funds are sent to a wallet that is controlled by the workstream leader, and they are entrusted to spend the funds in accordance with the proposal.
For example, there was this proposal to create the ShapeShift DAO Engineering Workstream and assign me as its workstream leader. To fund the Engineering Workstream there was also this proposal. These were both approved by the holders of the governance tokens. There is transparency related to DAO proposals, so ShapeShift DAO proposals are visible to anyone interested, including the general public. Even an overview of the ShapeShift DAO governance process is publicly available, as are the other documents linked in this section.
It is relevant to note that the DAO tokens are not just for governance purposes. Tokens frequently also have utility in the product that is created. Governance tokens are also worth money, and are actively traded. When a DAO releases new features or takes other action that is beneficial to customers and community members, you often see the governance token for the DAO increase in value.
We saw this when ShapeShift announced our decentralization plans and concurrently executed the biggest “airdrop” in history. Airdrops are generally one-time events in the history of a DAO, and mark a milestone in the DAOs development. It usually signifies a measure of success has already been achieved and it is common to see a price increase following an airdrop.
The ShapeShift airdrop consisted of giving over 1,000,000 previous customers and community supporters the opportunity to claim an amount of FOX tokens for free. How many FOX tokens each person was granted depended on how active of a customer or community supporter they have been in the past. The price then started to decline in value, and has settled around $0.40 as of the time of this writing. In this way, the governance token behaves like stock of a traditional publicly traded company. However, the way the token gives those who hold it the power to vote is a key differentiator. Tokens also provide some utility for those who hold it. For example, FOX tokens are used for customer incentive programs.
ShapeShift’s Transition
As Shapeshift transitioned to a DAO, we considered what this meant for our technology stack. After debate in engineering and with other teams in the then centralized company, there was organization-wide agreement that we needed to make our code open-source and to support delivery via decentralized infrastructure. At the time, the code was not open source and was heavily reliant on centralized systems to run. The belief is that how we deliver our product to our customers should reflect the new organizational system. It is also important to us that our product mirrors the decentralized nature of blockchains and not be dependent on one service provider.
Therefore, as a DAO, we needed the current codebase to be ultimately changed or replaced. We decided to replace it and set out to build the next generation crypto wallet and portal to decentralized finance. ShapeShift has always differentiated our products by supporting multiple blockchains, and we would keep this important aspect in the new version. The Engineering Workstream, the group of engineers that was elected via proposal to maintain and build upon the open-source codebase, had been at it for a few months, juggling priorities as all engineering teams do.
Pushing in the DAO: A Bounty Experiment
Connecting us back to our earlier story of senior leaders pushing for faster delivered functionality in the centralized company, we now explore an experimental approach under the structure of the DAO.
The former centralized company founder and CEO experimented on a method to speed up delivery of the next generation platform in the new DAO, which we refer to as V2 internally. Since the only way to spend money in a DAO treasury is through token-holder vote on a proposal, he offered a bounty from his own personal funds to speed the release of V2. He identified features that he knew were already started or next up in the development queue, and proposed a best guess at a seemingly attainable, yet aggressive, target release date.
The Engineering Workstream discussed the proposal. The general consensus was that the identified features and seemingly aggressive date would require too much corner-cutting, and thus would create so much clean-up work after the release as to not be worth it. Thus the bounty was rejected, even though there was a significant amount of money offered — many multiples of the incentives offered by the centralized company before the transition. Pushing back to this degree had never occurred when operating as a centralized company.
The DAO’s budget proposal to pay the Engineering Workstream through the end of February had already been approved, so no one was feeling like their jobs required them to say yes to "the boss". Everyone had a substantial amount of FOX tokens in their personal portfolios, so engineers have a greater sense of ownership than when ShapeShift was a centralized company. That ownership mentality created a "the long term cost to get this release out on this timeline will be detrimental to the long term value of FOX" response to the bounty.
As a centralized company, with the CEO in a position of power over the engineers (who had less ownership), the response likely would have been “the long term cost to get this release out on this timeline will be detrimental to the long term value of FOX, but you are the boss and this is your company so we’ll do it (but we don’t like it)”. Over time, these types of experiences may lead to feelings of resentment, as they had for some of our engineers.
A New Balanced Discussion
To make sure everyone knew everyone else's position, we held a group discussion including the engineers, the former leadership team and CEO, and people from the Product and Operations workstreams. This discussion felt unique to me. I have never experienced so many people meeting as equals in a corporate setting as this meeting of various FOX token holders. I believe this led to more listening, more understanding, and more collaboration across the entire organization.
The former leadership heard the date would cause more harm than good and generally agreed sacrificing the foundation of the new platform to that degree was not worth it. The former CEO was still willing to offer a bounty to speed up the work, and asked the Engineering Workstream to suggest a date that was attainable, and yet still uncomfortable.
The engineers heard directly from the former leadership about their perception of the market, and their sense of urgency to deliver value to customers. The team saw that in a new light, and it engendered a new sense of urgency. Those spoken to afterwards agreed it was one of the most empowering conversations they have had as a part of ShapeShift. Without the traditional organizational hierarchy of a centralized company, we could listen to each other's perspectives as equals, which lowered internal defenses and made it easier to better hear and connect to others’ points of view.
The DAO Bounty Experiment, Take 2
The discussion ended with the Engineering Workstream agreeing to complete the planning of this next feature set and communicate an uncomfortable, but attainable date. A week later, the Engineering Workstream said that the date was attainable, as a “dev done” date, still needing QA and bug fixing before going live. The date was just three weeks into the future, so we were okay making this prediction for being complete with feature development. The original bounty was for the features to be live in production. The following day, the former CEO offered a bounty for the same feature set live in production, but three weeks later than the originally proposed date, effectively doubling the amount of time to complete the work. The bounty amount was also more than doubled.
The Engineering Workstream discussed the new bounty offer. Some concerns still existed about cutting corners to hit the date, and in the end everyone agreed it was possible to release the new product with these features by this date, and any quality compromises that would be made were manageable and worth the benefit that would be gained by getting a working product in the hands of customers for feedback more quickly.
A New Culture of Collaboration
Since the bounty experiment discussion, we have created new processes to monitor quality to ensure that standards are maintained during times of increased velocity. The team has galvanized around how best to organize ourselves to get the work done. When operating as a centralized company and pushing for a date, the conversations to collaborate on how we would achieve the desired outcome could be tainted by resentful remarks like “I can’t believe we are in this situation again” and “‘the business just doesn’t get it”. There existed an unhealthy tension throughout the remainder of prior projects. In this process that has enfolded with us as a DAO, that tension is no longer present.
I have reached out to other workstream leaders whose efforts will be needed to achieve the desired outcome, and agreements have been made about how to include them in the work and the bounty payout. There is a greater focus, alignment and sense of urgency with all stakeholders.
The process of the bounty, from original offering, through the conversations that ensued, to the final offering and accepting of the challenge, was discussed openly on a community call. The transparency of this process, and the empowerment of DAO workstreams to make decisions without the traditional hierarchical structure, has led to better collaboration and individuals feeling greater autonomy.
While anecdotal, this case represents a fundamental change in workplace relationships when it comes to DAOs versus centralized corporations. It illustrates profound and rapid shifts in culture that fundamentally change our governance and structures, how we collaborate and organize, and how we determine what value gets delivered and when. It's still early in this story and as of the time of this writing, we are weeks away from the target delivery date. The proof is in the pudding, and the ultimate measure of the success of these internal changes that has occurred as a DAO will be if the product is delivered on time, meets all requirements, and — most importantly — increases our daily active users.
A retrospective with all stakeholders in the weeks following delivery will be conducted. The retrospective will cover the time from original idea formation for open source and decentralization of the codebase until the new product is live. At that point, I plan to follow up on this post with what went well, what did not go well, and what we would do differently next time. The retrospective will be open to the community, please join our community on Discord if you would like to monitor progress and be informed.
