Team GitHub's Agility Feb 21

Scott Chacon was interviewed recently at The Geek Talk. Afterwards, Ryan Tomayko commented on their development process. They’ve divulged information about their development process at GitHub. This is the environment that I’ve been searching to work for but have failed to find. I believe the reason that their development process works is because of deep passion for the company and trust they have for one another.

All GitHub team member interviews I’ve read shows they are extremely passionate on making GitHub awesome. Just look for the number of times they use “awesome” in regards to GitHub in any of their interviews. It’s all about making it more awesome. But, it’s not just the product as stated by Ryan:

You want to ship. You want to make money. You want people to love the shit you put out. You want to kick ass. You want your coworkers to kick ass. You want the site to be stable and fast and reliable.

It’s all aspects of the company. Team GitHub bleeds awesome.

Then there’s trust. As Scott said, GitHub is like an open source project. Everyone uses the product and there is a vision of what the product should be. The founders could have introduced ideas on a product management tool and assign features to developers like every other company out there. Or, the founders could just hire people they can trust with their vision and let them run loose with whatever suits their fancy. Since everyone believes in the vision, they all are also willing to take sacrifices from their projects to help out for the greater good of GitHub. You can see this from what Ryan posted:

As for working on stuff that’s tedious or maybe not immediately gratifying, that happens all the time. Again, the goal isn’t always to just work on what’s intellectually interesting. Things can be interesting for all kinds of reasons. Money is certainly interesting. Helping somebody out in a jam on a support request is interesting, even though the work might not be all that fun. Plugging a security vulnerability 20 minutes after it was reported is interesting. Fixing a bug that’s flooding your exception notification system is interesting.

From what I’ve seen, it’s worked out brilliantly.

My favorite part is their lack of traditional management. Instead, they rely on everyone around them, like social management. That’s a horrendous term, but stick with me. Given how hard the founders have worked, if I were their employee, I know I’m not going to slack while they kick all types of ass. I would throw down so that I don’t let them down. It’s an extremely powerful motivator knowing everyone around you is on their A-game. In the end, everyone tries hard not to let anyone down. This is the type of management I would die to work for. Put a grand vision on the table, know that everyone around me understands and wants the same vision, and have at it.

I’m very happy that Scott and Ryan mentioned their way of working since I believed it wasn’t possible in a business setting. I’m happy they’re having success with it and gives me hope. When I began programming, I turned to processes and to make a team efficient. I wanted to put in place the different methodologies from Agile Programming. I’ve found companies followed these methodologies. Sometimes it worked and sometimes it didn’t, but I found it doesn’t fit the way I wanted to work. There was always a deadline to meet and always someone telling me what to do and when. It made me feel like a drone. I’ve always been curious about all aspects of the company and product. At my current company it shows – I’m the only developer there that has developed on all three applications we’ve built. It maybe due to my INTP nature, but I like being a part of the whole process and having the freedom to inquire and enhance parts of the process that aren’t satisfactory. I love developing the company and product as a whole, and not just as a part of engineering.

I’ve experienced GitHub’s process in another setting – in my college theatre troupe – and it was one of the best experiences developing ideas with a team. The only plan we had was to perform all our written pieces in a showcase at the end of the school year. That was it. We came to this conclusion organically in our first year. Everything anyone in the troupe did was to better the troupe and the show at the end of the year. We didn’t have a big plan ordering who should write a comedy piece, a drama piece, or a spoken word piece. They came about because people were passionate about our mission and trusted everyone in the group.

Hopefully, I’ll be able to be a part of or run a company like GitHub!