These are hard times in the crypto space, and in the startup world broadly. Both funding and traction is harder to obtain than before. That means it’s incredibly important to ensure one executes efficiently with the people you have on the team. Mats and I ran Dune as a two person operation for over 2 years and we did a unicorn round at only 16 employees, so seemingly we’re somewhat efficient executors. We believe in efficient execution through clear ownership. Here’s what we mean by that and how we do it at Dune.

In many workplaces there is this cozy idea that the more people you have on a problem the better. Gather the troops around the campfire and bring out the post-it’s: “let’s brainstorm”. Not at Dune. One of our values at Dune is ownership. We always strive to be explicit and make it clear which exact person is responsible for a problem we’re trying to solve. We think this is key to ensure quality of execution, speed and empowerment of each team member.

We think bringing in a ton of folks and opinions early in the process of creating something is usually incredibly time consuming and inefficient. Early on there’s a lot of ambiguity and many potentially viable paths one could go down to solve a problem. In general people are pretty good at just having an opinion and saying something when they are asked to do so. That does not mean that the specific insight that comes out is too useful; just look at most conference panels.

So one might explore X paths with Y team members and spend Z time on each, while the solution can only be one path. So if you have many potential paths, involve many people and they all spend some time on it; X * Y * Z = way too much time spent across the company.

Assuming there are many very important problems to solve at all times, we think this is an undesirable use of resources. Instead, once a problem is identified we give a single person full ownership and trust them to run with it. That does not mean that we can’t or won’t work together on many problems, it just means that the responsible person explores the most viable solutions and loops in others when needed for their feedback, pushback or contribution to the project.

Once a clear proposal is formed others can give feedback and scrutinize the proposal. It’s way easier to work efficiently as a group when there’s something specific to discuss. In our equation above the potential solutions (X) are reduced to only the most viable ones and the number of team members (Y) can likely be reduced as you have a better sense of who can give useful feedback. Since there’s a more specific thing to discuss, time per team member (Z) will also go down, or at least be concentrated on viable solutions.

The fewer people involved early, the faster the execution. If you’re confident that you have the right solution you can go far alone. If you are not, you can loop in others earlier. There can be many reasons for looping in people earlier or later. For more ambiguous and complicated projects asking for feedback when you are only 30% done could make sense. For projects that are more defined and easier to solve, maybe one person can define an 80% solution before it’s shared or even execute entirely on their own. A more junior team member might bring in others earlier, while a more senior will go further alone. Maybe there are a lot of dependencies and that means you need to involve more people early.

The key here is that we trust the owner of each problem to loop people in when they are the most useful. This does not mean that people won’t be working together as a team. It just means whenever many people are involved we’re ensuring that what is asked from them is clear, and their time is well spent. You’re not being asked to just “say something”, you are asked to review specific parts of a specific proposal for a specific reason.

At Dune the way we usually go about the above process for bigger efforts is via written design documents in Google Docs. Problems to be solved typically arise from company OKRs or user requests. After we’ve defined a problem to be solved the owner lays out the scope of the document, the relevant background information, proposed solutions and tradeoffs made. Whenever the owner deems it relevant the other team members can comment and give feedback and approval in the document. There are usually no meetings needed to do this. It’s all living in docs where one can discuss and decide asynchronously. The process can take one iteration in a day or several months depending on the complexity of the problem at hand.

Previously in my career I’ve seen a lot of “work” being done, but when there was a lack of speed and quality of execution there was only endless spider mans pointing fingers in all other directions. No-one dared to say “you are going to be responsible here and own this”. While being an assigned owner can be a bit intimidating it’s also incredibly empowering and liberating for each team member. When someone is responsible they have the freedom to move forward and responsibility to create lasting solutions. What better feeling than knowing that this is my responsibility? I can pull on my prefered superhero suit, roll up my sleeves and have the power and ability to make this happen faster and better than anyone thought was possible, lfg!

🫡