What's it like to work at GitHub? (opens in new tab)

We hit the "opinion overload" problem at dotCloud about a year ago, at 10 employees. It took us a while to fix it. We could feel the beginning of a vicious circle where an eloquent opinion brought the same peer recognition as a working piece of code. The symptoms were more talking, less coding, recurring debates which everybody was sick of but nobody could put to rest, and worst of all, a tendency to say "I told you so" and blame each other for oversights. We noticed this when junior hires started mimicking the most verbose "opinionaters" instead of the most prolific doers. The wrong "genes" were reproducing in the company's dna!

Fortunately we found a solution and the group self-corrected wonderfully. The team is now 20 strong and an awesome no-bullshit engineering culture. We found that the key to a constructive conversation is to have an owner: someone in charge of the subject at hand, who is held responsible for the result, and in return has authority on how to go about it. Everyone else in the conversation is a peer, voicing their opinion non-authoritatively and acknowledging that the owner has the final say. Rule of thumb: ask "who's the owner?". If there's no clear answer, you're not getting work done.

In a group of smart and trusted people, this creates a culture where you earn your spurs with what you do, not what you say. Opinions become more like washing the dishes: useful and necessary, but not something that will get you pats in the back either. In fact if you take your dishwashing skills too seriously you might find yourself a source of amusement.

We later found out that Pixar uses a very similar peer feedback system for its productions.

Having strong opinions is different from having an opinion on everything.

Being in a place full of opinionated people is nice, so long as those people are able to discuss their opinions rationally and are okay with not getting their way every time.

"The fundamental cause of the trouble is that in the modern world the stupid are cocksure while the intelligent are full of doubt." - Bertrand Russell

"Have strong opinions - weakly held" is probably what he meant: http://www.codinghorror.com/blog/2008/05/strong-opinions-wea...

One should be able to hold multiple conflicting ideas in one's head (double think), each with varying amounts of evidence depending on the current situation. Furthermore, one should be able to switch between said ideas quickly and easily depending on what is needed to successfully complete the task at hand.

For example:

If you want high perf/dollar when doing a data analysis across billions of rows you know that you should run on a commodity cluster and with bare metal high performant C++.

You also know that if you want to get something done really quickly (elegant - not performant/efficient), you stick to what you know (Python/Ruby/Perl etc.) and get it done today. You know that if need be, you can just scale it out later with a more performant architecture.

Both opinions are strong. Both are weakly held. The best one wins depending on the situation.

Everyone's different, and that makes for a great number of different strengths and weaknesses. The biggest problem you run into with opinionated people is that they're frequently more interested in offering their opinion than doing anything about it. On the other hand, that means there's no shortage of constructive criticism when you want it.

In short, opinionated people are just another type of person you have to deal with. If you can't make yourself be as opinionated, that's no big deal. If this is a significant problem for you, perhaps it's best to figure out what skills you have that would complement "opinionation".

Have you ever taken an MBTI test before?

> I get the feeling that if you have a group of highly talented people around, it really pays off to give them much freedom.

Reading in economics once, I hit the phrase 'all economics is coordination problems', and it seemed exactly true to me: why do businesses have all these managers and infrastructure and stuff? Because of principal-agent problems and similar issues, all of which can be construed as coordination problems. Why do we need them? Because there are so many heterogenous people involved, all differing in various ways with different interests, and they need to be hammered into a coherent force.

Why not just select similar people, eliminate this massive overhead of coordination, and just let them work on stuff? Well... there's only so many energetic skilled young techies. But when you can cluster enough of them in one homogenous company, you get something like Github.

Until it keeps growing, heterogenity builds up, and problems with coordination start happening...

I was about to say the same thing about Valve before I got the comments section :) Also, very much agree with letting the talented do their thing as long as wisdom is also apparent. Allow them to infect each other with their enthusiasm and they will innately work together to build something great. Someone who is chained to something is not going to have that enthusiasm and will typically make that known through their mood and action, if not through complaining. A poor mood is just as infectious as enthusiasm.

My sentiment is that hiring talent and then weighing them down with excessive restrictions and bureacracy is like buying a Ferrari and driving it 55mph during the daily commute. Why waste the money on that HP, when you can get a cheaper vehicle. Let the Ferrari's drive; hire a Civic if that is the kind of work you are going to give it :)

What is interesting is that Valve and Github were both self-funded/bootstrapped.

We have the advantage of using GitHub to build GitHub (http://zachholman.com/talk/how-github-uses-github-to-build-g...), so we all know what needs worked on. There is certainly some vision casting from a few core people, but everyone takes responsibility for figuring out what needs done and coordinating how to do it.

> Who makes these decisions, when there are multiple viable ways of going forward, but someone just has to put their foot down and decide which one?

We all do, but whoever submits the first pull request usually sets the tone of the conversation. Occasionally, a pull request will get abandoned, but usually it is the starting point and we build from there.

There are often intense conversations about how something should work. I've learned to just try one way and see if you like it. Not everyone will, but you can form some consensus.

Exactly my point. I think what they are doing is great and there is a lot to learn from it. However, they have very talented developers whose job is to build tools for other developers. Scratching your own itch is much more likely to benefit the organization at GH than it is at, say, a corporate IT department or any other company whose customers aren't developers.

A big part of what makes their culture possible is the product they are building and the customer that they are building it for. Change those things, and unfortunately, you are very likely to have to change the culture a bit.

I think this depends on what you mean by "the less popular things that need to get done." In my experience, things that were less popular at other places I've worked, are often tackled with enthusiasm at GitHub. When the company culture leads you to feel passionately about building something lasting, going back to clean up old rotting code or fix tests that were not written well or debug obscure issues become things to be proud of.

Also, I believe that often the less popular work corresponds to things that are subtly judged to be less valuable work. At GitHub, I see people praised for tackling the types of things that have been less popular at my other jobs, and everyone here, even the most prominent GitHubbers, participate in most every aspect of maintaining the product. Internally, the message is pretty clear - doing the things that "need to get done" is a huge part of what makes everyone else here proud of you and is valued highly.

This is not to say that people don't tire of working on particular areas, but that's a somewhat different issue and probably a large enough topic for a writeup of its own.

That's a question I hear often, or another form of it: "How do you get people to do things that nobody wants to do?" I usually answer this with two questions:

1. If everyone deeply cares about the culture and longevity of the company (which is a prerequisite), and nobody wants to do it, does it really need to get done? The answer is often no. But if the answer is yes…

2. How do you turn that into a celebrated task where everyone wants to do it?

One example of this at GitHub is support. Developers hate doing support. But we have decided that it is absolutely vital to our company to both provide good support and to have developers involved in it so we are constantly getting feedback about what is working and what is not.

So we created the "King of Developers", which is a position that is held by a developer for one week at a time, in which that developer's primary responsibility is support. Along with that comes a pimped out desk at our HQ in San Francisco and tons of street cred. We even have a ridiculous internal website to go along with it (http://dribbble.com/shots/554836-GitHub-King-of-Developers). There are currently 9 developers signed up waiting to be the King.

GitHub has been organized this way since it was in a pre-revenue state.

We've been splitting up into teams (or roles) a bit more as we've grown- it just helps to keep the focus on things that matter.

That said, the most important part about this is that those teams are extremely weak. In other words, you should feel strongly able to float between teams, work on different repositories, or take a week or month off and pursue a different problem if the problem seems important or if it keeps you happy and productive.

The difficulty in a consulting company is that (unlike a SaaS company) there is typically a 1:1 ratio between hours worked and money earned.

Our company does many of the same things, but in the end, we're still tied to the billable hour. I talked about it briefly here: http://lincolnloop.com/blog/2012/may/31/lincoln-loop-everyon...