Using RAPID models and Pareto thinking to improve DAO decision making

How should DAOs handle decisions such as the levels of voter participation and length of time to conduct a vote?

There is a general recognition that a single sliding scale for all decisions won't work. We can all think of circumstances where we should do something quickly that is useful, but isn't that important to most voters, and vice versa. Thus, there is no real question that we need more than one approach to do this well.

For important decisions, we need to use a consistent model for decision making. That sounds great in theory, but how do we actually determine what decision models to use?

In tradorgs, I typically see 2 approaches - "what's a decision model" and "let's take forever to perfectly define the models we can use forever". Both of these approaches are stupid and don't work.

What does work is to apply a variation of Pareto's principle. Many of you are familiar with it, but the essential notion is that a few things are disproportionally vital.

For our purposes, what we want to do is identify the type of decision that is giving us the most trouble. Start with that one, and ignore other decision types for now.

In my experience, all of the negatives with decision making can be boiled down to 3 factors:

  • It takes too long to make the decision

  • We don't make the right decision often enough

  • The decision requires too many scarce resources (including attention, expensive information, or coordination).

All of these of course are subjective to some degree, but the ideal is that everyone agrees that the right decision is made instantly, every time, and requires no resources.

With this in mind, we take the first decision type we identified and we figure out how long it typically takes, how often it yields the right decision, and how many resources it takes to make it. Typically one of these areas will be the most glaring, but all 3 may be a problem if things are really messed up.

With this baseline in place, we can now brainstorm alternative methods for making the decision and evaluate how they would likely impact each of these 3 factors.

Taking too long: In my experience, this tends to be the easiest to make progress on . We often have delays where nothing is happening, and if we find ways to take those out, we'll have a faster decision, be right the same amount, and require no more resources. Winning!

Too many scarce resources: This is also typically easy to improve. If we go back to the RAPID model, we may be requiring input from folks who don't actually help us make a better decision, or perhaps we have approval requirements that don't actually improve decision quality.

We may just be able to remove these people and approvals from the decision, but sometimes we can't for other reasons (politics!). In that case, we can often at least find ways to reduce their involvement without excluding them entirely. This of course where pods can help a lot, as we can push some decision types to a pod rather than a full DAO. That helps reduce delays as well, which is yet another reason why pods are compelling.

Wrong choices: This tends to require the most work, but is still often straightforward to improve. We start by examining past decisions to determine why they went wrong. Perhaps there is an upper limit on how often we can make the right choice? After all, if we are trying to decide whether a flipped fair coin will come up heads, the best we can do is be right 50% of the time!

Assuming that in theory we could be making the right decision more often, we would then look for information gaps. What info could have in theory been available at the time the decision was made to improve its quality? How would we get that info to the right people at the right time in the right format so they could use it?

The problem here is that often, filling an information gap requires us to spend resources and delay the decision in order to gather the information and make sense of it. There are often tradeoffs, which we would make based on how much benefit towards the adventure-vision we would get from a better decision, compared to the resource costs it would incur and the risks due to delays in the decision.

Even if we make these improvements, though, we might reach a point where the tradeoffs are difficult, but we still need to make things better. Are we stuck then? NO!

We have another options we have ignored until now - decomposing the decision into smaller chunks. Rather than making 1 big decision now, we make a small decision now on just the bit required to meet the immediate need and postpone the rest until necessary.

For instance, rather than try to plan a 3 month task all at once, we just figure out what to do for the next week and schedule time in a week to assess progress and plan the next week. To misquote E.L. Doctorow, making big decisions through decomposition is like driving a car at night. You can see only as far as your headlights, but you can make the whole journey that way.

Once we have made progress on one decision type, we then pick the next most problematic decision type and do the same approach. Of course, we'd ideally like to track each decision we model on these 3 factors over time - how long, how often we are right, how many resources are involved. That makes it easier to identify further improvements and act on them.

One important point - the goal is not to have 100% of decisions made fit within a defined model. We only do this for the decisions that occur often enough and cause enough headaches to warrant the effort. After all, creating a decision model is a value decision in and of itself. It has a certain amount of resource cost, so we should only do it when there are enough benefits to justify it!

** This series of posts is heavily based on a series of messages I originally posted in the Orca Protocol Discord server on 2021-12-24, with modifications to improve clarity and reflect (hopefully!) improved thinking since then. Thanks to all in the Orca Protocol community who provided input, feedback, and support regarding these concepts.