How GitHub Works: Creativity is Important

August 18, 2011
You're reading part three of How GitHub Works, a three-post journey into how we work at GitHub. They're all separate posts on different topics, but if you're interested you can also read the other two: Hours are Bullshit and Be Asynchronous.

We want to foster a creative environment. We love it when employees hack on side projects. It gets people excited. Excitement is contagious, and spreads easily from one project to another. Even if we'll never make money on that side project, the excitement generated from it can bleed into things that will make us money.


It's no secret that there's more than a few people at GitHub who like to drink. I mean, we have four beers on-tap at the office in our kegerator. But alcohol is more important than just intoxication.

We meet people. Through our sponsored drinkups, we meet a ton of people in San Francisco and all over the world. This gets people excited about our product, and gets people excited about working for GitHub. (It's a lot safer to hire someone after you've had a few beers with them in a non-threatening environment rather than create a large, stressful interview process.)

We meet each other. We all work together, but we're not just coworkers; we're friends. We bleed friendship and work together, so it's hard to tell when we're discussing work and when we're chatting over beers. This is not just for a fuzzy feel-good feeling. When you're close to someone, you can be much more honest with them. If they have an idea, tell them about it straight, help them improve it, and move on. Going out socially is part of that. Alcohol's called a social lubricant for a reason.

We brainstorm. Bars are a great environment to ask "what if". Don't stay concrete- talk about industry direction, how it can apply to your product, what we might be building three years from now. So many of our existing features stem from vague sessions at San Francisco bars.

Encourage different

GitHub's primarily a Ruby shop: most of the developers use Ruby full-time and most of our projects use Ruby. But you shouldn't be limited by your existing workflow.

We're setting up an Arduino shop in the office for those of us who have never done meatspace programming projects. GitHub sponsors monthly gym memberships. We have intense philosophical debates on who can gain the most followers on Twitter. We encourage employees to give internal talks on everything from arcane programming languages to mountain climbing.

The point is to get people interested in a lot of different areas of life. Get people excited. Get people exposed to completely different ways of thinking. Improve the person, and it improves the company.

Creativity means self-direction

One of the initial questions Chris asked that led to this blog post was I'm sure anyone can't just write whatever they want. That's actually the case.

There are certain things that are more pressing — overhauling our events table before it crashed the site is a bit more important than a new footer, for example — but for the most part GitHub is self-directed. If you're interested in working on something, then work on it. The best work is done by those who are genuinely interested in finishing that project.

We're able to do this because we talk a lot about our product, so everyone's on the same page. Things like Pull Requests give us playgrounds to try out new ideas before shipping them publicly. We thrive on experimentation and shun grandstanding. If you're interested in something, just do it. We can iterate on top of your prototype from that point forward. It's a great way to build a product. Kyle has written extensively on this process at GitHub from a design standpoint.

We're hiring

Okay, I didn't mean for this to be one huge plug for GitHub; I just think this is a great way to build products. That said, we're always looking for new talent; follow @holman and @github on Twitter and we'll let you know when we have openings.

If not, I hope this interests you. A large company like IBM may need to enforce a lot of overhead, but in the startup world we can avoid all of that. You don't need to mandate hours. You don't need to mandate meetings. Your code review can be ad-hoc. You can build fun companies that get shit done. It's not mutually exclusive.

Don't let your company get in the way of building your product.