Scaling GitHub's Employees | Hacker News Reader

Scaling GitHub's Employees

zachholman.com

224 pointsjonmaddox39 comments

People work on what they want to work on. Product development is driven by whoever wants to drive product.

That is the surest way to reduce your startup's odds of survival. In this case, it would become a prototypical case study in survivor bias.

GitHub is lucky that they are building a product that is tailored for developers. It makes their survival rate doing this slightly higher because the developers are (only vaguely) similar to their customers. The further these two points are from each other, the worse this advice becomes.

A startup needs somebody who understands how to drive products into markets. Whether this is the CEO or a product manager hired off the street doesn't matter, but they need somebody doing it who has the real authority to turn those learnings into a product fit for a market.

FWIW, I've lived the flip side of this coin: building a tool for developers driven by what we thought would be cool to build instead of having a product guy hitting the street to understand the real customer. After burning through more than $20M, the lights got turned off.

I'm not entirely sure what you mean by "only vaguely." The fact that passionate developers are building developer tools has a lot to do with why we've been successful.

Chris, the CEO, has spoken at length about this topic. He and I built another site prior to GitHub where there was very little correlation between our interests and the product we were building. Not surprisingly, our hearts weren't in it and we threw in the towel.

All of this said, just because you're working on something you're passionate about doesn't immediately mean you're bound for success; it just helps tremendously.

I say only vaguely because what you want to use may or may not have any correlation with what people want to buy, and it is extremely risky to assume that correlation exists.

just because you're working on something you're passionate about doesn't immediately mean you're bound for success; it just helps tremendously.

It helps immensely (in fact, if you don't have that, you are doing it wrong, IMO :), as long as you don't let your passion get in the way of figuring out what your customer wants.

Like I said, dev tools are a special breed that have more wiggle room for this, but as my experience shows, it is not immune from failure (in fact, developers are notoriously cheap because there are so many good, free dev tools out there, but I bet developers aren't your primary customer, but rather their managers).

My response can be summed up in one sentence: with all startup advice, beware survivor bias!

The interesting thing about GitHub is that they are in the unusual (and fortunate!) situation whereby they are their own prototypical user...

I wonder how they keep the product focused with a do whatever you want product development schedule. Rather sounds like a good way to end up with an elephant with a long neck and a short nose.

I think the idea they're pushing is, why force a centralized structure for product development/design decisions, when your programmers are intelligent and independent enough to do it themselves? It's not just a free-for-all where people work on shiny toys; developers should be allowed to think about the customer too! It's quite a different energy when the same guy is recognizing what needs work (i.e, what a 'product manager' would do) and developing it.

Think about the Linux kernel - contributions are distributed and asynchronous, and most of the authority figures arise organically rather than by decree. I don't think you need product managers, they just relieve the developers of having to do that work themselves.

And yeah, it definitely helps that github uses github to write github. But dogfooding really isn't that unusual or difficult.

Don't get me wrong, I love GitHub and I love the processes they are using - I wish we did more of it at my current employer. But all of this back-patting feels a bit premature. They've really only scaled a single order of magnitude. Growing from 4 developers to 40 developers is excellent, but hardly "scaling" at all. Would the same flow work at Amazon, Netflix, or Apple?

I'd argue that how you go from 4 to 40 developers is much more important than how you go from 100 to 200 developers. What's more, I find this area fascinating to discuss since many users in our Hacker News community tends to be in the 1-10 developer area. How you can grow past that initial team is really important.

I do actually mention at the end of the post that this likely doesn't scale up to hundreds and employees. But we'll see how it does work over time. So far so good. :)

Ya I agree; 4 to 40 is more interesting than 100 to 200.

I was the fifth employee at my current employer, been through two acquisitions, now sitting at 220+ (not all developers). Scaling has been a difficult but rewarding and fun problem to tackle.

And damn, somehow I missed the last paragraph where you covered your ass ;) Thanks for pointing that out.

> I do actually mention at the end of the post that this likely doesn't scale up to hundreds and employees. But we'll see how it does work over time. So far so good. :)

Well from what I know Valve operates on pretty much the same principles (employee-driven, very flat hierarchy, high inter-team mobility and teams as interest groups more than boxes to put people in), so if you can keep the culture in and manage to only hire good cultural fits it scales at least to 260 (approximative valve headcount when Portal 2 was released)

the last paragraph of the article is an adequate response to this:

"Is this workflow going to work for us when we’re 500 employees? Likely not. But core values and ideas last. Figure out what your core values are, and adapt and refine them as you grow."

Is scaling an order of magnitude really such a non-achievement? I mean, have you done that? Most of us would be delighted with that kind of growth. Besides, if they’re smart enough to get all this right so far, they’re probably smart enough to modify their policies when they stop working so well—sorry, if they stop working so well.

I've never heard of Graphite. Is this it? http://graphite.wikidot.com/start

If so, can anyone care to explain how it would be used to "graph application exceptions" as per this post? thanks!

Sure [1]

[1] - http://codeascraft.etsy.com/2011/02/15/measure-anything-meas...

these series of posts about how they do stuff is great, i love it.

however, dreaming up the end result is a lot easier than figuring out what seeds to plant when you are a team of 1 or 2. after reading these i'm always left with the question "great, but what should i be doing now to be able to have this kind of process later?"

maybe the answer is in the article: figure out your core values and start applying them at whatever scale you are at. alas, that's not a list of actionable items.

Guz! I worked on HN Office Hours with you! How are you doing?

I think the actionable takeaway here is eliminating all friction that prevents an individual pushing the product forward. For GH, this meant automating everything possible, and providing accessible visibility into their data. How Hubot contributes to speeding up the onboarding of new engineers is worth thinking about too.

some days our CEO ships more code than the rest of us do

Now that is impressive for a 40-people startup.

They picked the right userbase. They don't have to put on suits and suck up to random douchebags with a lot of money. They just need to convince other programmers like them to shell out $7 a month. (Although I'm sure they make some money on FI, too :)

That leaves plenty of time for programming.

The more they explain, the more Github's organisation sounds like valve: very flat hierarchy, loose interest-based teams and ease of moving between them, etc...

If only they could scale their sales department. We've received no response for 2 weeks using 3 different methods of contacting them.

Doesn't look like anything's two weeks behind on our end; might've gotten lost in the mix. I assume you already did this, but can you shoot us an email at support@github.com (or sales@github.com for FI sales) and we'll make sure to get on it. You can cc zach@github.com too, just in case, and I'll keep tabs on it personally.

I haven't had to contact sales, but I can vouch for your responsiveness at support@github.com

I've emailed you guys a few times and received 1 hour turnaround with complete resolution, day or night.

Thanks!

Thanks for the feedback! We've tried calling the sales phone number, filling out the web form and emailing sales@github.com, all with no response, so we were starting to give up hope ;)

https://plus.google.com/115587336092124934674/posts/BkM6o2cg... support@ is one guy right now and while I had great experience in the past, right now it's not great. I had sent a question 10 days, repeated 5 days ago. nothing.

I'm guessing you'll get a response now since more of their 40 employees probably check HN than they do the sales email :)

Saying that automation "reduces institutional knowledge" seems a bit misleading in that the knowledge is still kept by the institution but is somewhat inaccessible because the information is held by only a few employees. Perhaps saying that automation "records institutional knowledge" would be more accurate.

I'd be much more impressed if they don't "scale" their employees at all. Github can not possibly need 40 employees at this point. Nothing ensures eventual mediocrity like hiring masses of people.

GitHub actually has a lot of systems with a lot of features, and a lot of competition. Not everyone uses all of their major systems other than repos (teams, issues, wikis, sites, GitHub:FI) but many do. If GitHub only worked on their core product, many valuable customers would leave for competitors.

What's the designer culture at github? Do you make them use git?

No doubt that's part of the motivation behind the excellent http://mac.github.com/

I love their philosophy of automating tasks to make them as simple as possible, so that anyone in the company can do them. It's really frustrating and time consuming to play sys admin every time you need to work on or deploy something, especially when you aren't at all a sys admin.

"make them use git" - given that the entire business is built around git, I should hope so. Git isn't the most user-friendly VCS, but why shouldn't a competent designer be able to pick it up? I've even got our designer working with branches.

I love the way you're running github.. deep appreciate. Please keep posting as it grows, so we can learn. Many thanks.

God I wish my team had a Hubot.

I coded up a HipChat bot in < 100 lines of CoffeeScript. It leverages the existing module system to make plugin writing hilariously easy:

  if msg[0] == '!'
    [cmd, args...] = msg.slice(1).split(' ')
    require("commands/#{cmd}").exec(chat, args)

Just add a coffee file to the commands directory and export an `exec` function which callc `chat.reply` -- couldn't be easier!

Hmm, would you have any pointers on where to start with CoffeeScript to do something like this?

https://gist.github.com/940969

Thanks!

These sorts of posts make me want to work at GitHub, which might very well be the objective. Taking a shot at a position there might even be worth learning Rails. (I have a primarily Python oriented background.)

Are there any other companies that have a culture/process like this?

I would say Tripadvisor. Check the culture paragraph here http://highscalability.com/blog/2011/6/27/tripadvisor-archit...

Reply on news.ycombinator.com