What's it like to work at GitHub?(opensoul.org)
opensoul.org
What's it like to work at GitHub?
http://opensoul.org/blog/archives/2012/06/05/whats-it-like-to-work-at-github/
15 comments
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.
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.
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
also, "second coming" by yeats, but i am not sure it is true - i have been lucky enough to work with some very good people, and some of the best were like this.
as j_baker says, it seems like it's just one of those "life is complicated" things...
as j_baker says, it seems like it's just one of those "life is complicated" things...
"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.
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".
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?
Sounds a bit like Valve. http://news.ycombinator.com/item?id=3871463 http://news.ycombinator.com/item?id=3838880
Or the free 20% at Google.
I get the feeling that if you have a group of highly talented people around, it really pays off to give them much freedom.
From the view of the employee, it is also probably a much more motivating, challenging and interesting setting.
Or the free 20% at Google.
I get the feeling that if you have a group of highly talented people around, it really pays off to give them much freedom.
From the view of the employee, it is also probably a much more motivating, challenging and interesting setting.
> 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...
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 :)
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 :)
>hire a Civic if that is the kind of work you are going to give it
I think people don't necessarily understand the motivations of many people in management positions. They do not care at all about performance or getting to the destination. They want to be seen in a Ferrari. Many didn't earn their positions, suck at their jobs, and will spend the company's money freely to promote their careers. They are like lottery winner who are just hiring expensive top people without a plan or experience to put one together. All they want of the world, all they want, is to impress their bosses and get promoted. Nothing else matters to them, period. To them, software is simply one part of the business that is a means to move up the corporate ladder. Excessive restrictions and bureaucracy don't matter in this environment because the developer's job is simply to boost the profile of their PHB.
I think people don't necessarily understand the motivations of many people in management positions. They do not care at all about performance or getting to the destination. They want to be seen in a Ferrari. Many didn't earn their positions, suck at their jobs, and will spend the company's money freely to promote their careers. They are like lottery winner who are just hiring expensive top people without a plan or experience to put one together. All they want of the world, all they want, is to impress their bosses and get promoted. Nothing else matters to them, period. To them, software is simply one part of the business that is a means to move up the corporate ladder. Excessive restrictions and bureaucracy don't matter in this environment because the developer's job is simply to boost the profile of their PHB.
What is interesting is that Valve and Github were both self-funded/bootstrapped.
Free of influence from investors/meddlers.
> 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.
> 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.
These appear to be the main points, so there is a kind of pressure to work on things that benefit the company.
My question is, how does overall strategy get set then? There are probably 1,000 things you could do to benefit the company, but only a small number of them have a huge effect, some of them require coordination to really help, and some of them might be diametrically opposed to each other.
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?
> 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.
These appear to be the main points, so there is a kind of pressure to work on things that benefit the company.
My question is, how does overall strategy get set then? There are probably 1,000 things you could do to benefit the company, but only a small number of them have a huge effect, some of them require coordination to really help, and some of them might be diametrically opposed to each other.
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 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.
> 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.
As the director of an engineering team myself, this is an extremely insightful article.
Bossing people around and utilizing extreme micromanagement might work in retail (though, honestly, I doubt it), but being a drill sergeant is not the way to get things done with very intelligent and headstrong individuals in a technical capacity.
The trick of excellent technical management, to me, is the ability to balance the business requirements of management with the technical passions of the engineers. If this balance is off in either direction, the company as a whole suffers greatly.
Engineers need to be intellectually engaged, and need to feel that they can make decisions for themselves (even if it's just within the code base). At the same time, products and services need to ship to keep everyone employed.
It's a tough but rewarding job.
Bossing people around and utilizing extreme micromanagement might work in retail (though, honestly, I doubt it), but being a drill sergeant is not the way to get things done with very intelligent and headstrong individuals in a technical capacity.
The trick of excellent technical management, to me, is the ability to balance the business requirements of management with the technical passions of the engineers. If this balance is off in either direction, the company as a whole suffers greatly.
Engineers need to be intellectually engaged, and need to feel that they can make decisions for themselves (even if it's just within the code base). At the same time, products and services need to ship to keep everyone employed.
It's a tough but rewarding job.
I absolutely love the service that we are building. But even more than that, I love the company we are building.
I think this is one of the strong points of GitHub. Everyone I know who has gone to work there has a real love for the company as much as the team. I'm not convinced as many of the many Rubyists heading to, say, LivingSocial (which has an amazing, all star team) feel the same way.
The egalitarian approach clearly has some significant plusses, but a downside IMHO is salary (it has been stated people generally have the same base salary at GitHub - https://github.com/holman/feedback/issues/150). Egalitarian salary structures work for some but also have their downsides.
I think this is one of the strong points of GitHub. Everyone I know who has gone to work there has a real love for the company as much as the team. I'm not convinced as many of the many Rubyists heading to, say, LivingSocial (which has an amazing, all star team) feel the same way.
The egalitarian approach clearly has some significant plusses, but a downside IMHO is salary (it has been stated people generally have the same base salary at GitHub - https://github.com/holman/feedback/issues/150). Egalitarian salary structures work for some but also have their downsides.
I think Github is a special case because at Github they are their own customers.
Developer/hackers know what other developer/hackers want because they want it themselves.
It's a great place to be as a developer and as a product company, but I don't think it's attainable everywhere.
Developer/hackers know what other developer/hackers want because they want it themselves.
It's a great place to be as a developer and as a product company, but I don't think it's attainable everywhere.
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.
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 wonder if they face the challenge of who has to deal with the less popular things that need to get done. And at what point resentment might kick in. The whole thing seems like it can work until there's one bad apple or one miscommunication.
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.
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.
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.
Thanks for the detailed response. At my current work place everyone rotates through support as well (dev, sales, ops), and I agree with you: the only way to make these kinds of things work is with an exceptionally strong culture, and not compromising.
Github developers and designers are all big users of the product. I hope they change how the world works on developer tools. But a different (or at least very modified) vision is going to be needed at a company working on products that their developers don't use.
The reason why this environment works at GitHub is because they're profitable -- extremely so. Money rolls in regardless of what their engineers are working on. If they were in a pre-revenue state I doubt they would be organized in the same way.
I find posts like this disheartening. I'm sure this strategy works great for the upper echelon of developers and quite possibly the vast majority of self-selected readers of this very site. But there are many companies and developers that are way down the bell curve that probably could not survive in this type of environment.
I wish more posts would take into account more factors like sub-optimal talent or office politics.
I wish more posts would take into account more factors like sub-optimal talent or office politics.
They say people work on what they want but they still advertise for specific jobs (https://github.com/about/jobs), so surely there is some level of direction there. i.e. If you're hired as a Data Miner then you are expected to spend your time mining data, what happens when that engineer decides he wants to work on something else?
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.
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.
One question comes to mind after reading this, as did with the Valve handbook, how do you tackle when it is time to "shovel shit"? Meaning that doing things that are, quite frankly, boring.
I wonder how this would shake out in a consulting company?
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...
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...
Wow..just read your post. A couple questions...
How many people are in the company?
Usually being the owner and founder you get more money. How do you avoid "The boss takes all the money" comment. Not saying you are, but I think this comes up even if your making only a little more then everyone else.
What happens when a developer asks for more money then your willing to give?Some orgs just hit the sweet spot for a certain kind of mentality; if this is reasonably accurate I'm not surprised the most frequent kind of post on the Github blog is "<your name here> is a Githubber".
[deleted]
i hear this often. and i've worked with some people like that, many of whom i admire (in some ways).
yet i am not at all opinionated (as far as i can tell). when people ask me for advice, i often find it very hard to guide them because there are so many options, and what will work best seems to depend so much on non-technical factors.
and i am not sure what to do about this. i have tried being more opinionated, and there are times when a decision affected my work and i have fought for what was right, because i am doing the work. but often other people, opinionating, just seem like noise (worse, sometimes i suspect people confuse being opinionated with understanding something).
no real conclusion here, sorry. sometimes i wonder if people are too opinionated; sometimes i wonder if i am not opinionated enough (or if i am not that talented - although i do take re-assurance from the d-k effect). but that part of the post, and a related comment by the author here, disturbed me a little. i am not sure a place full of opinionated people is that pleasant (or optimal).
i was wondering if this touches a chord with anyone else?