

Scaling GitHub's Employees - jonmaddox
http://zachholman.com/posts/scaling-github-employees/

======
SoftwareMaven
_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.

~~~
pjhyett
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.

~~~
SoftwareMaven
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!

------
eignerchris_
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?

~~~
holman
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. :)

~~~
masklinn
> 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)

------
apsurd
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!

~~~
yuvadam
Sure [1]

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

------
rguzman
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.

~~~
alnayyir
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.

------
DanielRibeiro
_some days our CEO ships more code than the rest of us do_

Now that is impressive for a 40-people startup.

~~~
jrockway
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.

------
masklinn
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...

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

~~~
holman
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.

~~~
snprbob86
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!

------
iffius
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.

------
staunch
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.

~~~
benatkin
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.

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

~~~
kaffeinecoma
"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.

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

------
brown9-2
God I wish my team had a Hubot.

~~~
snprbob86
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!

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

~~~
snprbob86
<https://gist.github.com/940969>

~~~
brown9-2
Thanks!

------
alnayyir
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?

~~~
cirotix
I would say Tripadvisor. Check the culture paragraph here
[http://highscalability.com/blog/2011/6/27/tripadvisor-
archit...](http://highscalability.com/blog/2011/6/27/tripadvisor-
architecture-40m-visitors-200m-dynamic-page-view.html)

