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
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
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
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
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
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
Based on my experience at GitHub so far, there are two big exceptions to this:
Figuring out broad vision and strategy, setting big goals. You really need to
lock people in a room to figure this stuff out. Async, electronic
communication has too much latency or something.
Celebrating. This is a crucial part of the process of shipping quality
products and only works in meatspace.
I'd like to double down and predict the decline of the office as the center of
planning, coordination, and communication for software development
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 SPOILERSSPOILERS 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.
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.