What's it like to work at GitHub?
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.
29 Comments
Do you happen to know how many githubbers work remotely vs those working on site in SF? Since you live in MI, I assume you’re not visiting the HQ too often?
@Pawel- I get asked this all the time, so I finally decided to look it up instead of making up answers. It’s about half and half right now (although we usually have a handful of non-SF’ers working in the office every day at this point).
Paweł: I haven’t counted recently, but last I checked, almost 1/3 of GitHubbers are remote. I’ve been to HQ twice in the last 6 months. We have two summits per year where everyone gets together for a week.
I hope to write another post some time about working remotely.
It seems so counter to everything that every business person tells you. “You need managers”, “People need priorities”, or whatever. The transparency that GitHub shows through their employees sharing the atmosphere is inspiring. It’s amazing to see that this can actually work, and thus far, scale.
You said as an employee you have the freedom to work on whatever you want, and for the most part those are things that benefit the company. Since there are no “managers”, is that completely employee generated ideas or is there anyone saying “we need to do this, who wants to?”
Also, how much freedom do employees have to spend their time learning new things? Designers diving into javascript, front-eneder’s diving into ruby, etc?
As PJ Proudhon put it “Anarchy is Order”, the anarchist symbol A with a O around.
It must feel great to be a part of team that does such a great job :) Do you hire consultants/employees outside of US? How do you know which projects/tasks benefit github, you have to have some list to choose from.
Thanks for writing this Brandon. It’s helping bring some clarity around some things, I’m thinking through for Elevator Up. Would like to do them a little differently and this gives me from framework :-)
Any thoughts on this model working for project work instead of product work?
I love reading about the github development process, I learn a lot from each post about the way you guys work.
I have a questions
- What is your QA process like? How do you guys ensure that a feature to ship has been properly tested?
- As a developer, how do you get a designer to work on you with something? I imagine that you’d have to get them interested in what you’re trying to do … but wouldn’t that lead to a bit of a cliquish situation where people would only work with people that they are ‘friendly’ with?
Do you guys really think this can work on a great portion of small tech companies? I’m not sure if it’s just here in Brazil but there are people that just won’t work if they aren’t told to.
How would you deal with that guy that guy that doesn’t feel guilty? How do you protect your own company against these people?
For the most part. There is certainly some vision casting from some core people, but it’s mostly employee driven. We have the advantage of using the software we build everyday, so we know its weaknesses.
There aren’t really guidelines. Use your own discretion.
Yep, we have people all over the world, but mostly in the US and Europe.
We test it ourselves. We usually ship features internally first, and if we don’t run into any problems, then we ship them to the world.
Designers are just like developers, they like to create. Asking a designer to polish something after you finish it is like asking a chef to clean the kitchen after you cook a meal. Involve designers from the beginning and create things together (and clean up the mess together).
I don’t know Brazil’s culture, but I have yet to meet anyone that doesn’t want to do something constructive with their life. They just might not know what that is yet. You can help them figure it out, or ask them to figure it out somewhere else.
I have only one question, where do I apply?!
Considering the crazy rate that GH is hiring at I would have thought having so many new people joining so quickly would be disruptive and slow things down, but it seems that GH is managing this very well.
This is certainly a challenge. We occasionally have to tap the brakes occasionally, but usually because we can’t keep up with the hiring process. Once someone is hired, they seem to come up to speed pretty quickly.
Start by watching the job board. But more effective than that would be to get to know a GitHubber, work with them on some open source projects, or meet them at a drinkup (but don’t stock them, that’s just creepy). Most of our hiring these days are from referrals.
I think @github has a beautiful organizational structure. I often praise it as a business to emulate whenever I discuss startups, or building a company. It’s a company by hackers for hackers. It’s like the ultimate nexus of the universe. I don’t necessarily think it can be applied to all companies, but I would love to build a company that can utilize it’s ethos.
To be honest, I would love to work there. I built even built http://stachehub.heroku.com/ as an homage to the fine folks who work here.
When it comes time for a raise, how is it determined?
I’m not responsible for that, so I can’t tell you for sure. It is my understanding that most people at GitHub have the same base salary. I’m assuming those will just rise at the standard 3-5% each year.
I had no idea that working at github worked like this. In fact I didn’t know any company was organized like this. Thanks for sharing.
Is there any place where non githubers could contribute ideas for githubers looking for a new project to work on?
Well, this anarchy model won’t just work anywhere. You need to have lots of competent and constiencious people around, that would really feel bad when not shipping.
Very interesting post. I’m curious about you solve the internal controversies. In a new feature which involve developers, designers, business, who has “last word” about how it needs to be done? or the partecipants have to vote to chose the preferred scenario?
You’re describing a carrot & stick motivation.
GitHub support is the best place.
We just work through it until we have a resolution that most people agree on. When you don’t have a single authority, then we have to win each other over with persuasive argument.
There is no “last word”, but there are GitHubbers who have earned more respect and thus their opinion naturally carries more weight.
This reminds me, somewhat, of what I saw in early days of Occupy MN (and read about Occupy Wall Street). I’d be interested to see a conversation between GitHubbers and members of those groups.
I’ve introduced and now strongly encourage pull-request oriented collaboration in my small team, along with peer code review before merging.
For this to work you have to be sure your pull-request will get reviewed in reasonable time and won’t delay shipping too much. This means someone has to interrupt their work, which is hard thing to do. I believe it will be easier when people see that in turn their code is reviewed promptly too.
Until we internalize this I committed to go through all pull-request in the morning before starting my work. Then I check them again when I feel low energy level and need a break. Then I check them again from home in the evening (we’re spread across the time zones and have odd working hours, so pull-requests may come at any time of day).
How do you deal with this? Do you assign your pull-request to a specific person? Do you have to hunt around the chatroom for someone who has time, or you just send it knowing someone will review it?
Do you somehow track and measure this effort and consider it when assessing employee performance?
Brandon, how did it start?
Did they notice you online? From your projects? From your contributions to github itself?
Or did you apply to a job offer?
Just curious :)
I joined GitHub via a very non-standard way: our company got acquired.
Has anybody tried to fork the main github project internally? I feel that without a strong hand guiding the ship, you might get something akin to an insurrection by a charismatic coder who doesnt like the trajectory of things.
If you put enough smart people in a room, somebody is going to take charge. It’s human nature. The question is how big you have to get before you run into that person.
It might be a cool throw down match against the CEO ;)
Not that I know of. If someone doesn’t like the trajectory of things, then they have the obligation to persuade everyone to their way of thinking (usually with mockups or pull requests). If you can’t persuade people with argument, then maybe your way of thinking isn’t really superior.
I’m not sure that I agree with that. Like I said before, there are certainly people in the company with more clout whose opinion often carries more weight; they’ve earned it. When you trust the people you work with and are all striving to build the best product, nobody has to take charge.
Hey Brandon, great post!
I just wanted to ask – I’ve seen on the web some of Zach Holman’s slides stating that Github hasn’t lost one single employee since the day it began. Is that true? How does a distributed company manage to keep attrition at a zero level?
Thanks
It is.
Complete autonomy, great pay & benefits, and all of the reasons above are huge factors. GitHub’s primary goal is to be the best place to work.