10 Rules for DAO Construction
How to condense over 1000 years of organizational design theory into 10 simple memes.Author: Owocki, DAOSquare
Rule 1: Gall's Law
Gall's Law states that an effective complex system always evolves from an effective simple system (rather than starting as a complex system with unknown effectiveness). How to use this law: leverage it when designing a minimum viable product.
Rule 2: The Pareto Principle
The Pareto Principle (or the 80/20 rule) suggests that approximately 80% of effective results come from 20% of key efforts. How to use this law: leverage it when designing a minimum viable product.
Rule 3: Parkinson's Law
Parkinson's Law states that work expands to fill the time or budget available for its completion. How to use this law: use it to set deadlines that are far enough away (but not too far).
Rule 4: Goodhart's Law
Goodhart's Law states that when a measure becomes a target, it ceases to be a good measure. How to use this law: strictly adhere to this law when building systems designed to accomplish difficult tasks (such as public goods fundraising or resisting false identities).
Rule 5: Brooks' Law
Fred Brooks pointed out in his book "The Mythical Man-Month" that adding manpower to a delayed software project makes the delay worse. How to use this law: keep team sizes small.
Rule 6: Moore's Law
Moore's Law, proposed by Intel co-founder Gordon Moore in 1965, observes that the number of transistors on a chip doubles approximately every two years while the cost is halved. How to use this law: we are all organically riding the wave of Moore's Law. This is part of creating huge returns in the tech field!
Rule 7: Metcalfe's Law
Metcalfe's Law states that the value of a telecommunications network is proportional to the square of the number of connected users in the system (n^2). How to use this law: build for exponential value creation!
Rule 8: Dunbar's Number
Dunbar's Number indicates that there is a cognitive limit to the number of stable social relationships one can maintain. How to use this law: keep team sizes small unless necessary! If you need to scale the team, be mindful of the optimal trust patterns at each level.
Rule 9: The Unix Philosophy
The Unix philosophy is: 1) let each program do one thing well, 2) let the output of each program be the input to another program, 3) write programs to work together. How to use this law: build modular software!
Rule 10: Conway's Law
Conway's Law states that the design of a system will reflect the communication structure of the organization that designed it. How to use this law: design your organization in a way similar to software development. Note that the overall structure cannot scale!
