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.

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.

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!

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.

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)

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.

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

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

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

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.

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.

Now that is impressive for a 40-people startup.

That leaves plenty of time for programming.

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

Thanks!

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.

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

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