A veneer of organization

When all you have is a hammer, everything looks like a nail. In much the same way, when your background is in organization, everything looks like a process need. While open source projects do need process and organization (otherwise I wouldn’t have written a book!), the amount of process needed grows with the size of the community.

Too often, I’ve seen (including from myself) community leaders build out way more process than is necessary. This isn’t necessarily harmful, but it does distract from getting more meaningful work done. It’s a way to look busy without accomplishing anything. Process can be the scaffolding to build and grow community, but if you have scaffolding you’ll never use, it was a waste to set it up.

I’ve recently found myself tempted to re-organize some of the governance documentation for GUAC. Not improving or streamlining processes, just shuffling it into a different place. But while I have no doubt that I am right in my opinion, the current state is sufficient. I could put the work in to reorganize the content and convince the maintainers to approve my pull requests. That seems like a waste of everyone’s time, when I could instead be trying to recruit new contributors, write blog posts, find reference users, and generally just do the hard work that pays off.

In a previous role, my manager and I were working on a corporate style guide for the marketing team to use. I asked her “should I put this in Jira or would that just be a coat of paint?” In other words: would the effort to set up a board to track the work be worth the coordination benefit we’d get?

Finding the right level of organization

There are a few things you need to have right away. You need a:

• basic governance structure so you know who makes decisions and how
• code of conduct
• process for removing people

Once you have those things, get building! Wait to solve problems until you have them. You can’t know for sure which problems you’ll have first anyway. Communities are not code: you don’t have to anticipate every possible exception.

People will typically follow processes that they 1. know about and 2. understand. So if you can’t make the case for why the process is necessary right now, you probably don’t need it. In Program Management for Open Source Projects, I wrote about looking for the places people cut corners on a process to figure out where you need to improve it. Improvement can also be “remove the process.” If you discover you’ve been over-enthusiastic about process creation, it’s not to late to take a step back.

One guideline I like to use to check myself: whose life does this make easier? If the answer is only “mine!”, then it’s probably not worth imposing on the rest of the community.

Finding the right level of organization is a trial-and-error process. Even if you’ve done it before, no two communities are exactly alike. And, if you’re lucky, once you’ve found the right level, the community will grow and you’ll have to adjust again.

This post’s featured photo by Alvaro Reyes on Unsplash