31–38 of 38 posts
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.
"Talented people with a lot of experience have strong opinions." 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…
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.
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.
GitHub has been organized this way since it was in a pre-revenue state.
"Talented people with a lot of experience have strong opinions." 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…
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.
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.
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…
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 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.
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.
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.
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 wh…