One of the main things that drew me to RabbitHole six months ago was the opportunity to lead content initiatives in a decentralized manner. It was something I had never done before but had been thinking a lot about, and I was excited to take on the challenge.

Why decentralize content?

The reason I think it’s important to decentralize content is simple: If we want to build a future version of the web that serves everyone around the world, then we need to understand the perspectives of the different representative groups we want to benefit from this.

No matter how objective we try to be as writers and journalists, there are inherent biases within all of us - many of which we are not even aware exist. Our personalities, lived experiences, and upbringings all contribute to our conscious and unconscious biases. Since there is no way for us to remove our personalities, lived experiences, and upbringings from our conscience, the only way to “solve” for these biases is to give everyone an opportunity to speak and be heard.

Challenges to decentralizing content

Decentralizing any job function is a challenge. Managing contributions, goal-alignment, ops, scheduling, compensation, and autonomy requires a strong mix of research, strategy, and experimentation.

On top of that, decentralized content faces an additional set of unique challenges, like

• establishing standards to ensure quality of content
• making sure contributors are submitting content regularly (consistency in publishing is crucial to success)
• coordinating content growth/distribution efforts
• staying organized with a content calendar
• balancing creative freedom with measuring content KPIs

Lessons learned from 6 months of building a decentralized content engine

Here are five key lessons I learned from the last six months of building a decentralized content engine:

1. Two pizza teams

"We try to create teams that are no larger than can be fed by two pizzas. We call that the two-pizza team rule."

As painful as it is to quote Jeff Bezos, he’s right. I would say on average two pizzas can feed about five people. That’s close to the exact number of people I’ve had the most success working on specific content initiatives with over the last six months.

• newsletter team: 3-4 people
• articles team: 5 people
• podcast team: 4-5 people
• video team: 3-4 people

As you scale your content engine, those numbers will have to increase. However, I would hypothesize that the more effective way to scale is to 2x, 3x, 4x the teams above rather than adding on 2, 3, 4 people to the existing team (e.g. if you have a team of 20 writers, break them off into 4 teams of 5 writers each).

2. Seasons

I’m a big proponent of using seasons to experiment with decentralizing any function, especially content. Seasons provide an opportunity for the team to set specific goals and KPIs together, lock in more active contributions, and give the experiment enough time to run.

Depending on your team size and goals, anywhere from 1-3 months is a reasonable time frame for a season.

3. Guidelines

The one thing that took me the longest time to figure out was how to find the ideal balance between giving contributors autonomy to create vs providing guidelines for their contributions.

I’m someone who prefers a high level of autonomy in my work, so I think my natural instinct is usually to give others that same level of autonomy. However, I realized that most people prefer more instruction and guidance than I need or am used to giving.

Specifically, the following are a few things I observed contributors appreciated guidance on:

• content goals
• content KPIs (generally, how do we know if our content is successful?)
• content creation guidelines, both substantively and stylistically
• specific examples of content that would be useful to create
• specific examples of ways to contribute to content other than creating the content itself

4. Document everything

In the early days of decentralizing any function, it is extremely important to document everything. This includes:

• taking meeting notes on every call
• documenting day-to-day work (e.g. keeping a journal or log of everything you’re doing each day to look back and reflect on at the end of the season)
• documenting work processes (e.g. process for publishing an article, editing a podcast, etc)

There are a couple of reasons why documenting everything is so important.

First of all, it helps communicate what everyone is working on so contributors located in different time zones or who had to miss a call can still have context of what’s happening in real time.

Secondly, it helps you remember everything that happened over the last 1-3 months when the season is over and it’s time to reflect and plan for the next season.

5. Preset comp

Compensation is a tricky topic in any DAO and one that most people feel at least slightly uncomfortable talking about publicly.

That’s why it’s important for leaders in a DAO to intentionally make space for conversations around compensation to take place. The happier contributors are with the way they are being compensated, the more likely they are to actively contribute and do the best job they can.

Another important piece of feedback I received from our contributors is that they prefer to know how much they’ll be paid for their work before they begin working. This could be in the form of a stipend or hourly rate; the important thing is to communicate ahead of time the level of compensation contributors can expect from the work they plan to perform.

This is just a glimpse into the lessons I learned from the last six months of running a decentralized content pod. If you disagree with anything I wrote, have questions, or just want to chat more, please tweet your thoughts to me @ddwchen. I would love to hear from you.