Designing Better Organizations

Designing Better Organizations

Our ability to solve big problems as a human race is only limited by our ability to collaborate with each other. Everything comes down to coordination and we have the chance to do better.

You might be familiar with the opaque, somewhat arbitrary, and bureaucratic budget routine corporations go through every December. I certainly am — I’ve worked in corporate finance for over a decade. A small team of executives with limited context reviews a spreadsheet to make sure that expenses are only increasing by a little. Afterall, nobody gets fired for approving a mere 4% budget increase.

The traditional corporate operating structure was perfect for manufacturing teapots in 1925, but we’ve outgrown it. The more centralized an organization is the more organized it can be — but only to a point. Structures that rely on a complex chain of command aren’t conducive to innovation and adaptability at a larger scale. Each time information passes from person to person, valuable information is lost before finally reaching a decision maker (if ever). And decision makers lack more and more context as their organization grows larger and more complex. Companies also struggle as the personal incentives of executives fall out of alignment with the whole. It’s why a tiny centrally planned village run by a chief can work great, while a centrally planned nation-state cannot.

If you’re deep into web3, you might also be familiar with the way Decentralized Autonomous Organizations (DAOs) raise proposals to fund work streams. While they’re at least transparent, they’re far from perfect. Voters almost never deeply understand what they’re voting on and they struggle to monitor the impacts of various voting decisions. Curve and Yearn are both phenomenal projects and have inspired aspects of DIMO’s design, but their proposal to give a combined two million dollars to a group of lawyers to advocate on behalf of the industry is crude compared to a traditional work contract you’d see at a corporation. And the community collaboration and voting process has room to improve. It’s progress, but we’re not there yet.

The more decentralized and flat an organization is, the more scalable and resilient it is — but such systems require robust infrastructure and incentives to combat coordination failure. For example, a decentralized, market-based economy works great for countries. For a self-sufficient village of twenty people, the risk of market failures and the cost of establishing contract laws, court systems, and monetary systems isn’t worth it.

Enter DIMO

DIMO intends to take organization design to the next level. There are many excellent teams building new software for DAOs, and we’ll both use those tools and contribute to their development. However, for now, we expect our contributions to mainly focus on improving human-centered operating processes.

To optimize for effectiveness, alignment, and scalability, we will delegate authority and responsibility broadly; operate with full transparency; use token-based staking, credentialing, and contingent funding systems; and use proactive performance monitoring.

Org structure matrix inspired by Index Coop materials

The Process

As explained in our docs and blog, DIMO will be governed by the holders of the $DIMO token. Token holders will either be able to vote on matters directly or will be able to delegate their vote to another person in a liquid democracy.

Liquid democracy illustration (inspiration for the graphic from Horizen Academy)

Any person who has been delegated 10,000,000 or more $DIMO is a DIMO Steward and will automatically be added to [d]Stewards. Stewards, both individually and collectively, have special authorities and responsibilities, including the ability to introduce proposals for full community voting and the responsibility to advise and occasionally intervene with other [d]Teams.

It’s not reasonable to expect voters and even stewards to get into the weeds and vote frequently on small ad hoc decisions. Proposals voted on by the community, called DIMO Improvement Proposals (DIPs), will most often be proposals to delegate resources and authority to a [d]Team. Certain consequential decisions will also need ratification from the full community (e.g., [d]TokenRewards would still need to bring a proposal back to the voters to officially adjust the $DIMO rewards formula).

What is a [d]Team?

A [d]Team is a specialized team that the DAO votes to give resources and/or authority to in order to fulfill a specific purpose. They’re like a department or team in a traditional company. In other DAOs, they’re often called a guild or subDAO.

We’ll have [d]Teams focused on building decentralized data storage architectures, tweaking token incentives, producing content, designing the mobile app, and more. Some may appoint a leader, some may operate using Teal principles, and others might even go as far as to operate as their own DAO, maybe even with their own governance tokens.

It’s DAOs all the way down

In a way, [d]Teams are actually less like departments in a company and more like an external agency contracting with the company. While DIMO may invest in infrastructure to support them (e.g., accounting and HR support), [d]Teams will operate relatively independently so long as they operate within the constraints set forth by the community.

However, unlike external agencies, [d]Teams will have: ownership of DIMO and aligned incentives as made possible by the $DIMO token; specific authority and responsibility; and full visibility into the operations of DIMO (just like everyone else).

Today, our [d]Teams are relatively informal and unstructured, but that is changing. We have employees and contractors working on brand design, back-end, front-end, token design, back-office, etc. but they’re not formally organized, scoped, and funded like [d]Teams (yet). We need to get these teams prepped and ready for the full DIMO community to join in and contribute at scale, and we’ll do so by taking them through the process outlined in the next section. And while teams will work to define their onboarding process, those interested in contributing can easily apply for a contributor role in our Discord.

Examples of [d]Teams

How is a [d]Team created and funded?

The simplest way a new team can get started is to receive a small grant from [d]Seed for research and pro-typing, get hired by another team that already has funding, or to forgo funding altogether. For others, the following describes how to get funding and authority directly from DIMO.

The DIMO community will fund [d]Teams like an investor funding a startup. This means that teams will present what they do, make an ask, negotiate funding and deliverables, and unlock tranches of resources based on hitting agreed upon milestones.

While voters can adjust this process at any point, our initial design will resemble one that was piloted while I was at ConsenSys. Let’s call it the [d]Team Funding Process for now — and here’s how it’ll work, soup to nuts:

1 A [d]Team will emerge to accomplish a given purpose (e.g., to write DIMO content to raise awareness). Anyone can form a team, but it will require the support of 10,000,000 $DIMO worth of voting power (1% of tokens) to formally initiate the [d]Team Funding Process. Once that threshold is cleared, the applicant will coordinate with [d]Stewards to schedule their pitch to the community.

2 This [d]Team will prepare a written proposal as well as a slide presentation covering their: purpose and mission; realistic operating goals; execution plan; financial plan; key risks; team composition and qualifications; team governance structure (how they make decisions); process for onboarding and offboarding contributors; funding request; and their request for specific authority if applicable (e.g., [d]Hardware may request the power to whitelist new hardware miners). It’s recommended that they seek guidance and feedback from at least a couple of stewards.

3 On a dedicated community call, the team will take one hour to deliver the presentation and another hour to answer questions. During the Q&A, stewards will be invited to ask questions live on the call while anyone else may submit questions via, which will be asked in the order of most upvoted. The meeting itself will be recorded and posted for anyone who wants to watch later.

4 Everyone, especially stewards, are welcome to provide feedback openly to the petitioning [d]Team. [d]Stewards will work with the team to incorporate feedback and publish a proposed coordination contract in Discourse where community members can continue to deliberate.

A template coordination contract is viewable here. This document will define:

Scope: Outlining the high-level purpose of what the [d]Team team exists to accomplish;

Funding terms: Including amounts and conditions (such as timelines or development milestones);

Operating commitments: For example, [d]Support committing to providing 24/7 customer support;

Cultural commitments: Clarifying how the [d]Team must act within DIMO (e.g., participate in specific community calls and treat everyone with respect and kindness);

Reporting commitments: Laying out what regular reporting the [d]Team must provide weekly, monthly, and/or quarterly as applicable (e.g., financial detail, site uptime, support tickets, app changelogs);

Authority & domain: Detailing what unique powers and rights the [d]Team has; and

Oversight: Detailing how the team is to be held accountable (more on this in #6 below).

5 After one week of open deliberation, a vote will go live whereby $DIMO holders are able to vote. These votes will be conducted on Snapshot with a seven day voting window.

6 If the vote passes, the [d]Team is then managed and evaluated per the oversight conditions set forth in the agreement. Similar to the way a venture fund checks-in with portfolio companies, an analyst is appointed by [d]Stewards to periodically consolidate all reporting materials, build scorecards detailing how the team did in meeting their various commitments, and conduct reviews with the team to dig deeper into the subjective measures of performance. These outputs will be shared with the community.

But wait… there’s more!

We hope you agree that this type of internal protocol can go a long way in keeping DIMO organized, effective, and aligned. But please know this is only a piece of what we have planned. This post doesn’t go into any real detail on the usage of internal market dynamics, reputation systems, and incentive structures we plan to deploy at DIMO to unlock even more scale, alignment, speed, and collaboration. Check back here, join our Discord, or follow us on Twitter to stay tuned. In the meantime, sign up today so you can start earning $DIMO soon!

Disclaimer: The $DIMO token does not exist yet. This blog post is making no guarantees about the nature of the token or its distribution, which are subject to change based on continued legal, tax, and other design considerations.