The rules of this experiment
May 14, 2024
Here’s some minimal viable governance to get this community going.
The rules of Joshua & Community
Don’t reveal names. You agree to keep to the Chatham House rule when it comes to the conversations and communications shared here. That means: feel free to disclose and use any information shared here, but do not reveal the name / affiliation of its source or the name / affiliation of any other participant in the project.
Give credit. You agree to give appropriate credit when sharing or adapting information from the project by linking or citing the project along with this attribution rule, but not in a way that suggests endorsement.
These rules may change.
The rationale
I want to build with community. But if I want busy, successful people to contribute, it has to be easy to contribute. I have to incentivize them to contribute. And I want contributions to be relatively open-ended—including advisor-type advice, connections, and introductions as well as contributor- and partner-type products and executions.
As one of my collaborators likes to say: “You can’t just build the product. You have to also build the organization that builds the product.”
Ease / UX
DAO models with many contributors exist, and work… at least, sometimes. But the “community” in a DAO doesn’t always or even usually come at the very beginning, during ideation. In my observation, they come into being either as part of a big marketing push (e.g. around a token) or as a product starts to scale (i.e. organic growth). The exceptions are community-launched cases like Juno, which had no seed investments, no private or public sales of tokens, and not even any founders per se (of course, there were still effectively “founders”).
Another way of modeling the dynamic in community-launched is that between founder(s) and advisors. It’s pretty unusual to have 50+ advisors though, and trying to do that requires a change in how founders usually interact with advisors—thus this blog-style structure. I studied the FAST agreement when thinking about the rules above, but ultimately decided that it was better to organize the relationship through norms rather than through contracts. I didn’t want to bang people over the head with a contract, even a short one. And in many settings, norms are easier, more efficient, and more productive over time.
Incentives
A very different way of modeling the dynamic in this blog is that of a closed-door event. In that context, the Chatham House rule is essentially a mutual privacy clause designed to foster honest conversations. Since I’ll be writing up portions of many private 1-to-1 conversations, I think this privacy rule is necessary. And it’s useful for me to think of this entire project as an extended hackathon bringing 50+ awesome people into a room together.
There’s a separate story for how I want to compensate / reward people for their time. Long story short, I plan on adopting a SourceCred-like approach based on the data generated through this blog and other platforms. The actual algorithm is very still very TBD, so in the meantime I’m asking people to trust me.
Openness
The first rule already states that you can use the information here for whatever you like. The second rule, about referencing or citing the project, is directly inspired by common open source licenses that include an attribution clause, e.g. CC BY. Getting attributed on its own is nice, but I think the real thing here is setting a norm. I want people to feel and treat this like project an open source project, even as we tinker with what it means for a project like this to be open source.
You’ll notice that there’s a tension between the Chatham House rule, which is about keeping things closed, and the disclosure rule, which is about keep things open. I hope this will be a productive tension. We’ll see how it evolves.
The background
A Bank for DAOs is a business. But it’s also part of an experiment in how to build businesses and organizations of any sort. For lack of a better phrase, I’ll refer to this larger experiment as Joshua & Community. The research question of J&C: how do we build businesses and organizations faster?
The research question of J&C: how do we build businesses and organizations faster?
Note, I’m not asking how to build better, more profitable, more equitable, or more scalable businesses.
So my goal in J&C is to build a sustainable organization—in this case, a financial institution—in as fast a time as possible. More precisely, I want to speed-run the initial seed stage or bootstrapping phase of a startup or business, where we take a notionally-good idea or business plan, launch it, and get it to either (1) marginal sustainability or (2) failure. Ideally, we would take a bunch of milestones that would take a normal startup team about 2-3 years to hit and execute them in about 3 months—let’s say, from June 1 to August 30, 2024.
Another way of phrasing the question: very rarely, a startup or business will go from 0 to 1 in a very, very short period of time. How can we do that consistently?
My hypothesis: this is possible with digital, “open-source” organizations. It requires some careful information management, new forms of incentives, contributions from a pool of the right people, and slightly radical forms of automation. And obviously, it’s only possible with certain kinds of business models (no 10 year research horizons).
The bigger picture
My immediate goal is to get B4D from 0 to 1. From an idea on paper to a real thing.
Stepping back, my broader goal is to increase the velocity of organizational creation. Breaking it down, this includes:
Team formation,
Financing,
Production of goods or delivery of services,
Market testing,
Iterating until product-market fit,
Adjusting or pivoting.
Stepping back from even that goal, I want to increase the velocity of innovation in collective intelligence, institutional design, and organizational / management studies, broadly understood. This is a methodological point about how research is done and knowledge generated in the social sciences; I’ll write more about it later.
Ultimately, I want to advance human knowledge.
Why Substack?
The choice of technical platform is important. This project is organized as a blog because I need a consistent and familiar way to engage with a large (but not super large) community. I had considered Slack or Discourse, but I feel a more broadcast-oriented pattern that hits people’s emails will be easier.
It’s built on Substack because I’m familiar with Substack. Compared to Wordpress, Substack has an (apparently) larger or more accessible reader base, subscriptions are easier, it has a nice editor, and it’s faster to set up. Wordpress is more customizable, which may be important later if I need to segment posts to different groups or audiences. I would be amenable to moving it to a different platform at some point. What do you think?