opensoul.org

What's it like to work at GitHub?

June 5, 2012 life 6 min read

Update: A lot has changed at GitHub over the past couple years, so most of this post is no longer accurate. Many things are better, some things are worse, and some things are just different. It’s still the best job I’ve ever had. Some day I’ll write more about it.

I have been traveling a lot lately, and everywhere I go, I get this question: What’s it like to work at GitHub The simple answer: it is amazing!

Is it true that you work on whatever you want?

Yes. On a few occasions, someone may suggest that I check out a project that could use my help, but nobody tells me what to do. Everyone is encouraged to work on something that interests them and also benefits the company.

Our “Director of Engineering” Ryan Tomayko writes:

I don’t scale. If I tell someone what to do and they do it, then what? Do I have to tell them another thing to do? What happens when I have to decide what to do for 20 people?

Actually, you should just just go read his whole post right now. I will wait…

How is that not anarchy?

It is. Anarchy is a system of governance “that goes to lengths to avoid the use of coercion, violence, force and authority, while still producing a productive and desirable society”.

Anarchy works wonderfully in a small group of individuals with a high level of trust. Everyone at GitHub has full access and permission to do whatever they want. Do great things and you earn respect. Abuse that freedom and you violate everyone’s trust.

How do you decide what to work on?

Several people have asked in the comments and on twitter about this, so I though it was worth addressing.

We have the advantage of using GitHub to build GitHub, so we are intimately aware of the strengths and weaknesses. We use GitHub Issues to keep track of bugs and feature requests that we would like to implement. We also have an internal ideas board for grander ideas that don’t fit into one issue. Anyone can post to it and comment.

The founders and other core people certainly help set a vision for where we are going, but we all take responsibility for deciding what to work on.

What if the thing you want to ship does not benefit the company?

Each person at GitHub has the responsibility to sell their ideas to the rest of the company. I quickly learned that if I can’t get anyone else interested in the project that I want to work on, then either I poorly articulated my vision, or more likely, it does not benefit the company. You can still work on it, but you will likely be working alone.

What if someone is not doing their fair share?

Then they feel insanely guilty because they let everyone down. We are all motivated more by our intrinsic desire to create than by carrots and sticks. The joy of shipping is the greatest motivator. Nobody wants to feel like they are not pulling their own weight.

What are your biggest challenges?

There have been a few.

Overcommitment

The Venn diagram of what interests me and what benefits GitHub looks like two circles getting freaky. There are so many amazing things going on and it is tempting to try to be a part of all of them. I constantly overcommit myself and as a result have not lived up to my own productivity standards for the last several months.

Our benevolent leaders recently called on all of us to focus all our time on shipping one thing. Not allowing myself to commit to something until the current thing I am working on has shipped is teaching me to say “no”.

Signal vs. Noise

With almost 80 people, no hierarchy, and so many amazing projects going on, there is a lot of noise. And I mean a lot. For the first few months, I tried to keep up with what all was going on. But I quickly found myself paralyzed. I was spending half my day just keeping up with what my coworkers were thinking and doing.

I have learned to ignore it all unless it is directly related to what I am shipping.

Opinion overload

Talented people with a lot of experience have strong opinions. With experience comes baggage, and we all have baggage. We swear off tools or techniques because they failed in one situation, without realizing it simply was not a good fit for that situation. Now imagine 55 70 80 experienced people all trying to build amazing things together. There are a lot of intense discussions about what tools we should or should not use and how features should or should not work. Most of it is productive, but it can become tiring.

I have learned that nothing solves an argument like a pull request with working code. Working code moves the conversation forward, and changes are made from there. If you don’t like someone’s pull request, then go create your own and lobby for its acceptance.

Compared to what people have to deal with in other work environments, these are all first world problems.

Where will this lead?

My time at GitHub has been the best six months of my career. I absolutely love the service that we are building. But even more than that, I love the company we are building. If GitHub has only one lasting impact on the world, I hope we can inspire other companies to change how they work.

Do you have more questions about GitHub? Feel free to ask in the comments, and I will do my best to answer them.

This content is open source. Suggest Improvements.

@bkeepers

avatar of Brandon Keepers I am Brandon Keepers, and I work at GitHub on making Open Source more approachable, effective, and ubiquitous. I tend to think like an engineer, work like an artist, dream like an astronaut, love like a human, and sleep like a baby.