Dtravel was conceived by a core group who came together with a shared vision and developed the whitepaper, initial tokenomics and a v1 product. As more contributors and community members became involved in the project, it became clear that the organizational structure and operating system at the time wasn’t the best way for Dtravel to scale in a distributed way while staying lean.

This article discusses the problems with the original structure, how the structure has evolved to align with a web3 ethos and what it means for the community.

Despite being focused on building a web3 native ecosystem, it was challenging not to fall into a web2 operating model due to the familiarity and comfort with traditional org structures.

There were three main overarching problems that caused various issues:

1. Lack of clear, shared and prioritized direction, resulting in some misalignment across functions and individuals

2. Ownership, authority and accountability were not clearly defined, at times resulting in uncertainty over roles and responsibilities

3. Internal communication methods were inefficient, leading to unclear strategies

These are not easy problems to solve. Luckily, there are many incredibly talented people testing and experimenting with internal and external governance models in the web3 space. We leaned on their learnings and resources to understand how they might apply to us and how we would adapt them to our unique needs.

There were a few articles we referenced when rethinking our operating structure:

• Evolution of the FWB DAO by FWB DAO

• KPI Sub-DAO Structure by pet3rpan

• How to SubDAO by Coopahtroopa

SubDAOs were determined to be the best option to organize around specific initiatives that we wanted to focus on for 2022. Where Dtravel functions as the overarching parent DAO, SubDAOs function as self-governing working groups that operate on their own terms while still ultimately providing value to the parent DAO. This structure would allow us to focus efforts on specific problems and involve the right people with the expertise to best solve that problem efficiently without the red tape associated with web2 structures.

We decided to put together Trips with a Trip Lead who would act as the facilitator and project manager, synthesizing information and ensuring everyone in the Trip was aligned and focused on the problem. The Trip Lead would ultimately be accountable for the results of the Trip, with the intention being that they would act more like the person integrating efforts from the Trip rather than a manager.

A helpful metaphor for Trips is to think about Trips as individual business units, with the Trip Lead running the Trip as if it were a mini business with KPIs, goals and a budget. Each Trip would write a proposal clearly outlining:

(1) the problem

(2) how it connects to Dtravel’s vision, mission, strategy and goals

(3) the proposed solution

(4) the strategy to achieve the goals

(5) the contributors/resources needed

(6) the parties responsible, accountable, consulted and informed (RACI model)

(7) the Trip Lead; and

(8) the timeline and key milestones the Trip would be held accountable to.

With Trips defined, the new horizontal organizational structure was beginning to take shape — but there was still work to be done to guarantee the longevity of the overall setup.

Despite the positive shift in morale and output, it quickly became clear that codification of the bigger picture was required to ensure the high-level alignment of the Trips to avoid each Trip becoming too separated from the parent DAO.

Two main questions arose following the implementation of the Trip structure:

1. Who would determine the quarterly goals and initiatives that Trips would focus on?

2. Who would hold the Trip accountable for results and ensure that the set strategy is being executed?

To address the first question, it felt directionally right that the early contributors — the people with the most experience and expertise who joined Dtravel early and set the mission and direction — should be the ones to set the goals and oversee that the team remained focused on achieving the mission and vision of Dtravel. We called this group the Map Group.

The Map Group is responsible for quarterly, semi-annual and annual goal and strategic direction setting, including assessing whether the project's key outcomes and goals should change. For the Map Group to always remain in a strong position, contributors within the group can move on and new members who demonstrate significant value to the strategic direction and thinking can be nominated to the Map Group.

To address the second question, it was decided that a DAO board — called a Compass Council — would work in conjunction with the Map Group and be responsible for aligning Trips. The Compass Council ensures that Trips are working towards a cohesive goal that will further Dtravel’s mission by executing on the strategy set by the Map Group. The Compass Council initially comprises internal team members and advisors, but over time will also include community members.

In addition to the operational issues that our original org structure caused, it was also important for us to “dog food” our own DAO structures (i.e. to use the structures we create) to understand if it is feasible to use these models for community participation.

The goal has always been to involve community members and have subDAOs that would propose and execute on initiatives that further Dravel’s growth. However, without testing the proposal and subDAO mechanisms and processes internally first, it would have been chaotic and detrimental to our community to introduce it and expect it to be successful without working out the kinks.

The intention is that, by testing and iterating on these subDAO models, we can gradually open up initiative calls to the community who will put together proposals and subDAOs and execute on them.

We welcome community feedback on the structure and look forward to continuing sharing organization design learnings with the web3 ecosystem in the future.

Website | Twitter | Telegram