What's the designer culture at github? Do you make them use git?
Scaling GitHub's Employees
21–30 of 40 posts
Re: Scaling GitHub's Employees
#22God I wish my team had a Hubot.
Re: Scaling GitHub's Employees
#23I love the way you're running github.. deep appreciate. Please keep posting as it grows, so we can learn. Many thanks.
Re: Scaling GitHub's Employees
#24If 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.
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.
Re: Scaling GitHub's Employees
#25People 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.
Re: Scaling GitHub's Employees
#26God I wish my team had a Hubot.
I coded up a HipChat bot in
if msg[0] == '!'
[cmd, args...] = msg.slice(1).split(' ')
require("commands/#{cmd}").exec(chat, args)
Re: Scaling GitHub's Employees
#27I'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.
Re: Scaling GitHub's Employees
#28I'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.
Re: Scaling GitHub's Employees
#29People 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 va…
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.
Re: Scaling GitHub's Employees
#30Don'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 employee…
> 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)