Being wrong often is the only way to be right – especially when you’re dealing with complex systems.

This – in a nutshell – is the evolutionary organization thesis.

Premature optimization is a sin when it comes to building software and it’s the best way to stunt learning and growth in DAOs.

Premature optimization isn’t just expensive up-front, it’s also costly in the long run. When you design systems that try to anticipate how complex organizations will act, you make a set of assumptions. Some of those assumptions will be correct, and some will be wrong.

Ultimately, it’s the constant testing of those assumptions that allow systems to evolve into sophisticated, well-oiled machines.

And so, when you prematurely optimize DAOs, you end up with a system that’s often anticipating the wrong problems and thus creating complicated solutions to address problems the DAO does not yet have. This anticipation and problem-solving introduces new sets of assumptions into a system.

When you introduce more assumptions, it becomes increasingly difficult to pinpoint why a system is failing – is it because of assumption A or assumption B? The more assumptions you have, the harder it is to figure out which assumptions are wrong and which are right.

So why do we prematurely optimize?

Fear of failure. We think if we anticipate problems now, we can design our way out of those challenges.

But often the opposite is true. In fact, it is this fear of failure that costs time and money in the long-run, as we lose the data and learnings that come from constantly testing assumptions (learning which assumptions are wrong and which are right).

The key to building complex systems is not designing complexity from the start. Instead, it’s about building simple systems, allowing them to fail, and iterating on those systems based on what works and what does not work.

This is Gall’s Law in action.

One important note: in these systems, failure isn’t just inevitable – it’s actually helpful. By constantly testing assumptions and maximizing learning, these systems become evolutionary organizations.

But evolutionary organizations don’t just optimize for learning – they also optimize for flexibility. Flexible systems allow organizations to leverage learnings and make incremental improvements (constantly testing assumptions!).

When it comes to DAOs (and anything on-chain for that matter), flexibility is rarely designed into systems.

But it really should be.

Modularity is the name of the game in this regard. Unlike monolithic DAO implementations, modular DAO implementations allow for quick testing and iterations, which ultimately allow organizations to evolve quickly and efficiently.

Often when we think about flexibility in systems design, it comes with trade-offs – typically around things like security. But flexibility doesn’t necessarily require sacrificing security. Using tools like pods, DAOs can build modular systems, which maintain security at the local pod level, while enabling flexibility at the DAO level.

So you want to build an evolutionary organization, anon?

Start simple. Stop trying to design the most sophisticated governance system. Start with something simple and evolve from there.

Fail intentionally. Make assumptions. Test those assumptions. Repeat.

Build modular. Think about your organization as a car. You can swap out parts and it’ll still run just fine.

Pod-pilled? Ready to go modular? Well you’re in luck – we’ve got some big announcements coming up. Follow us on Twitter to stay updated on all things pods.

Big thanks to Jon Hillis, Cam, Richie Bonilla, Chalice Stroebe, Caryn and Adrian Ricardo for a wonderful chat on Gall’s Law and constant evolution in DAOs. And thanks to Julia Rosenberg and frogmonkee for endless DAO conversations and always giving the best feedback.

Being wrong often is the only way to be right – especially when you’re dealing with complex systems.

This – in a nutshell – is the evolutionary organization thesis.

Premature optimization is a sin when it comes to building software and it’s the best way to stunt learning and growth in DAOs.

Premature optimization isn’t just expensive up-front, it’s also costly in the long run. When you design systems that try to anticipate how complex organizations will act, you make a set of assumptions. Some of those assumptions will be correct, and some will be wrong.

Ultimately, it’s the constant testing of those assumptions that allow systems to evolve into sophisticated, well-oiled machines.

And so, when you prematurely optimize DAOs, you end up with a system that’s often anticipating the wrong problems and thus creating complicated solutions to address problems the DAO does not yet have. This anticipation and problem-solving introduces new sets of assumptions into a system.

When you introduce more assumptions, it becomes increasingly difficult to pinpoint why a system is failing – is it because of assumption A or assumption B? The more assumptions you have, the harder it is to figure out which assumptions are wrong and which are right.

So why do we prematurely optimize?

Fear of failure. We think if we anticipate problems now, we can design our way out of those challenges.

But often the opposite is true. In fact, it is this fear of failure that costs time and money in the long-run, as we lose the data and learnings that come from constantly testing assumptions (learning which assumptions are wrong and which are right).

The key to building complex systems is not designing complexity from the start. Instead, it’s about building simple systems, allowing them to fail, and iterating on those systems based on what works and what does not work.

This is Gall’s Law in action.

One important note: in these systems, failure isn’t just inevitable – it’s actually helpful. By constantly testing assumptions and maximizing learning, these systems become evolutionary organizations.

But evolutionary organizations don’t just optimize for learning – they also optimize for flexibility. Flexible systems allow organizations to leverage learnings and make incremental improvements (constantly testing assumptions!).

When it comes to DAOs (and anything on-chain for that matter), flexibility is rarely designed into systems.

But it really should be.

Modularity is the name of the game in this regard. Unlike monolithic DAO implementations, modular DAO implementations allow for quick testing and iterations, which ultimately allow organizations to evolve quickly and efficiently.

Often when we think about flexibility in systems design, it comes with trade-offs – typically around things like security. But flexibility doesn’t necessarily require sacrificing security. Using tools like pods, DAOs can build modular systems, which maintain security at the local pod level, while enabling flexibility at the DAO level.

So you want to build an evolutionary organization, anon?

Start simple. Stop trying to design the most sophisticated governance system. Start with something simple and evolve from there.

Fail intentionally. Make assumptions. Test those assumptions. Repeat.

Build modular. Think about your organization as a car. You can swap out parts and it’ll still run just fine.

Pod-pilled? Ready to go modular? Well you’re in luck – we’ve got some big announcements coming up. Follow us on Twitter to stay updated on all things pods.

Big thanks to Jon Hillis, Cam, Richie Bonilla, Chalice Stroebe, Caryn and Adrian Ricardo for a wonderful chat on Gall’s Law and constant evolution in DAOs. And thanks to Julia Rosenberg and frogmonkee for endless DAO conversations and always giving the best feedback.