Your team should work like an open source project

Earlier this year I wrote about “management style” based on my experience as an early employee on GitHub’s product team. We were given tremendous freedom in designing process and communication from the ground up with the goal of building an organization optimized for producing new high quality products over raw efficiency in repeatable process.

Shortly after, Redmonk’s Stephen O’Grady asked that I give a talk on the topic at Monktoberfest 2012, a conference focused on how technology is changing business, how people work together, and beer.

Not gonna lie, I do not enjoy the process of developing talks or presenting them. But I do like beer. I like it a lot. And so a week’s worth of work, a quiet hotel room to do that work in, and a flight across the country later and I gave my talk to a receptive and nearly sober audience of friends and long time internet buddies.

By far the most important part of the talk — the thing I hope people experiment with in their own organizations — is the idea of borrowing the natural constraints of open source software development when designing internal process and communication.

This basic idea isn’t presented until about half way through the talk but more and more I consider it to be its most important aspect.

Natural survivability of process

At first blush, process and communication in open source software development would seem to have severe limitations compared to software development processes in traditional organizations. People are spread out both geographically and across timezones. There’s no way to quickly jump in a meeting room and work something out on a whiteboard. There’s no daily standup meetings to create team cohesion. You don’t sit next to your team members all day long.

Indeed, most types of interaction in open source development are reduced to the basic feature set of email.

What we’re learning at GitHub is that opting in to open source project constraints often results in better natural survivability characteristics for many types of business, product development, and operations activities. That is to say, processes designed to conform to open source constraints results in a project that runs well, attracts attention, and seems to be self perpetuating where the same project structured more traditionally requires much more manual coordination and authoritative prodding.

It’s important to note that while following open source constraints creates the possibility of cooperation without coordination, it of course doesn’t guarantee it.

Adopting open source process constraints

What concretely are these “open source constraints”? Probably not what you think. To be honest we’re still developing terminology and understanding but we’re approaching something cogent enough for me to want to share.

The following is taken directly from “The github.com product development documentation”, an internal guide on the software development process and technologies used to build github.com.

The processes and basic rules for communication on github.com projects are roughly the same as those of an open source project. Mainly, that development and operations follows these constraints where sensible:

  • Electronic: Discussion, planning, and operations process should use a high fidelity form of electronic communication like email, github.com, or chat with transcripts wherever possible. Avoid meatspace discussion and meetings.

  • Available: Work should be visible and expose process. Work should have a URL. It should be possible to move backward from a piece of product or a system failure and understand how it came to be that way. Prefer git, issues, pull requests, mailing lists, and chat with transcripts over URL-less mediums.

  • Asynchronous: Almost no part of the product development process requires that one person interrupt another’s immediate attention or that people be in the same place at the same time, or even that people be in different places at the same time. Even small meetings or short phone calls can wreck flow so consider laying it out in (a thought out) email or sending a pull request instead.

  • Lock free: Avoid synchronization / lock points when designing process. This is DVCS writ large. We don’t have a development manager that grants commit bit to repositories before you can do work, or a release manager that approves deploys, or a product manager that approves work on experimental product ideas. Work toward a goal should never be blocked on approval. Push approval/rejection to the review stage or automate it, but surface work early to get feedback.

I have some issues with this list still: some things seem redundant, the key words could be improved. It does provide a concrete set of basic evaluation criteria, though. You can look at your organization’s processes and approaches to communication and measure them against this list.

Check out the later part of the talk for examples of internal GitHub processes and tools that have been built following these constraints.

R.I.P. The Office

One of the more controversial ideas put forth in the talk is that traditional office culture is a major cause of violating these open source constraints and leads to process that can be detrimental to software development projects over time. In my opinion, it is impossible to design process around meatspace interaction while also reaping the substantial benefits of cooperation without coordination.

Based on my experience at GitHub so far, there are two big exceptions to this:

I’d like to double down and predict the decline of the office as the center of planning, coordination, and communication for software development organizations.

I’m not saying offices will go away entirely. They just won’t be required or useful for most aspects of the software product development lifecycle. Processes with better survivability characteristics will slowly but inevitably creep in and win out.

Where’s the humanity?!

Do these concepts make you a little queasy? Are you picturing the future described in Pixar’s Wall-E, where all human interaction is reduced to virtual / electronic communications resulting in deep systemic sadness and the eventual extinction of the entire human race?

I believe this to be a (perfectly warranted) overreaction. Let me explain.

GitHub has an office and we spend a lot of time face to face or in groups. Probably as much time as most other companies. We just do this for activities that are radically different than most organizations.

The GitHub office has two primary roles:

Lastly, working face-to-face in meatspace has proven extremely valuable in matters of strategic thinking and, obviously, for developing personal relationships, two things which are vital to a company’s success.

So far we’ve also not seen the benefits found in product development process show up in matters of defining broad vision or coming up with coherent high level product design. In fact, those things seem to be negatively impacted by following open source constraints. I’ll save that for another day, though.