I have noticed an interesting pattern when some new projects and initiatives get started: they have an excessive application of governance, in many cases to deliver an impression of “completeness” or project independence. I want to share a few words on how to avoid this over-complexity.

I understand why this happens. Generally, successful collaborative communities strive to be very objective environments, with process, workflow, and governance clearly documented as a means to ensure anyone and everyone can contribute. The governance piece plays a key role in affirming objective leadership and avoiding conflicts of interest.

These are valiant goals, but there needs to be a careful balance of this process and governance, where it is blended with a robust focus on simplicity and efficiency. I have seen many projects unwittingly sacrifice agility and the plain joy of participating with an overly bureaucratic machine that a few governance nerds obsess over.

There are countless examples (that shall remain anonymous here), such as a new advocacy group of around 10 people who had 2 boards to govern them (everyone was on a board) and had excessively long meetings. There was the concensus-based board with 18 members that could never make decisions. There was the community that required excessive commitments from their members to overly bureaucratic governance mantra handed down from high. In all of these cases those communities were worsened, not strengthened by governance.

Start Simple

The solution here is start small and simple, and then observe and iterate.

Just like how a chef applies salt to a dish, you should apply the smallest amount possible and adjust to taste. Start by putting in place the thinnest layer of governance possible to accomplish your goals.

To start with this we need to understand what our governance goals actually are. Again, simplicity is key here. I generally recommend you strive to build an environment in which formal governance is kept out of the day to day of participation in the community and instead focused on the rules and policies that underlay the project. Don’t bottleneck your community by requiring governance approval on decisions unless absolutely necessary (e.g. community-wide policy is a great governance-target, but not pull request approvals). Effective governance is as much about knowing where governance boards should steer clear of as well as where they should focus their attention.

Governance can of course be as long as a piece of string. The simplest start in many cases is no governance at all. See how the project runs and if there is even a requirement for a governance function. In many, many cases you simply don’t need any governance: just a communicative set of community participants who can make decisions collaboratively.

If there is a need for something more expansive, I recommend you start with a simple board of 3 – 5 people whose charter is focused on general community matters (e.g. handing sponsor funds, how the community is moderated, publishing policy etc). For technology communities, the board would not have any technical authority: that is for the developers to decide (this avoids impacts on engineering agility). You could grandfather in the initial board members, have them meet every month on a public channel, and log outcomes on a wiki. After a set period of time, open up nominations, and form the first independently elected board.

We did this in Ubuntu. We started with some core governance boards (the Community Council, focused on community policy and the Technical Council focused on technical policy). The rest of the extensive governance structure came as Ubuntu grew significantly. Our goal was always to keep things as lightweight as possible.

Iterate and Improve

I am a firm believer that the way in which we collaborate should be as much of a collaborative product as the output of a community project. Just like an open source project, we should review, iterate, and review the performance of our iterations. We should constantly assess how we can optimize our governance to be as simple and thin as possible. We should build an environment where someone can file a metaphorical or literal pull request with pragmatic ways to optimize how the project is governed. This assures the project is pulling the best insight from members to ensure it is as efficient and as lightweight as possible.

To do this, honestly observe how the governance performs. Is it accomplishing the goals it is designed for? Are governance members enjoying their work and fulfilled in the delivery? Is it supporting the success of community members? Evaluate how the meetings are run, if actions are followed up on, and whether people are late.

On a regular basis (e.g. once a quarter) plan some adjustments and changes based on these observations and track if these changes improve overall performance.

Throughout this process, deliberately practice muntzing (as I wrote about here) to remove anything that isn’t neccessary. This keeps your governance to a minimum and ensures there is a culture of challenging current norms and optimizing how the project works. This ultimately results in healthier more pragmatic communities that still benefit from the many benefits of well-structured governance.