The short version is that we learned YC in its then form was O(n^2). As the batch size grew, it was hard for every partner to know exactly what each startup was doing. Especially since things often change fast at startups.
To grow bigger we have to (a) make it easier for each partner to know what each startup is doing, or (b) make it unnecessary. The answer will probably be a bit of both.
The symptom was not startups having trouble raising money (that seems to be working about like it usually does) but us partners always feeling confused. We were not ahead of the aircraft in the way we'd been in the past.
As the batch size grew, it was hard for every partner to know exactly what each startup was doing. Especially since things often change fast at startups.
You could be running up against Dunbar's number (http://en.wikipedia.org/wiki/Dunbars_number) for the more social (as opposed to purely technical) aspects of what is going on at each startup. 66 startups with an average of a little more than 2 people per startup is hitting the upper limit (150) of what the human brain can handle socially. 84 startups with the same average exceeds it.
In my own experience, once a company or social grouping exceeds 50 to 150 people (the more tightly bound the social group, the lower the count), things change noticeably, so I'll be watching with interest what YC does to get around this.
That is certainly one of the hypotheses. The reason I'm skeptical is that it seems such a fashionable wall to hit that it's almost tacky. Which I admit is not a valid reason to be skeptical.
This would definitely make for interesting reading if/when you choose to share details.
Also, it sounds like at least part of the Y Combinator size issue is a version of Dunbar's Number, applied to business rather than social relationships.
We wouldn't want to share everything on our list of predictors of failure, because some would stop working if applicants knew about them. Some though are things applicants could only fix by actually making their startups better, so I should probably write something about any of those I haven't already talked about.
A brief bullet-point list of the ones you can talk about (both those you have and haven't written up already) which have been statistically validated at YC sounds overwhelmingly valuable.
Including the Ns would be even more overwhelmingly valuable. I.e. I can calculate a Bayesian likelihood ratio and get some idea of the confidence from e.g.:
* Founder has green hair: Successes 10/80 Failures 40/122
However I would much rather have the brief bullet-point list than not have the bullet point list with lovely numbers attached.
Somehow I am afraid that this sets the stage for an endless discussion about the "hidden" ycombinator acceptance criteria. I am already looking forward to the "how I uncovered x of pg's criteria" posts.
Implying that there are secret rules to "a game" make it a highly attractive subject to try to discover these.
Yeah I was just going to point out Dunbar's number. At that point you have to introduce more layers of management, rather than everyone just knowing each other.
I was part of the YC batch at 66 and felt all the partners knew a lot about our start-up and could speak to us really easily, asked for updates, etc. Felt like a small group even though it was large.
Paul, of course, it's far easier to write out a suggestion than to
actually do it, and free advice on the Internet is seldom worth what you
pay for it. Anyhow, my idea might help...
I might be misunderstanding your "ahead of the aircraft" statement, but
personally, I think it's unreasonable for you to expect YC partners to
be "ahead" of the startups in a batch. In fact, if YC partners are not
behind in understanding a startup, then that startup is in trouble. The
startups may not have the benefit of experience possessed by the YC
partners, the startup founders should always know the state of their own
business and market better than the YC partners do.
I believe one of the reasons why you regularly advocate being concise is
due to your own personal overload problems as well as the stated problem
of all YC partners not keeping up with all of all of the issues in all
of the startups in a given batch. It's the classic many-to-many
communication problem where the ability of partners to assist and advise
startups is limited by their ability to stay informed.
Even if you're never able to isolate every single metric a YC partner
should know, identifying as many of these metrics as possible and having
a reporting mechanism would still reduce the load on YC partners. Though
its not publicly known, I'd bet you do already do something along these
lines, either formally or informally. Your "growth.html" essay seems to
hint in this direction. None the less, making improvements to your
identification, collection, and reporting of useful metrics should still
be a worthwhile investment.
I sincerely doubt you would want my help implementing a startup metric
collection and communication system, but I'll offer to help anyhow. It's
a fascinating problem and it seems like a really fun challenge.
I think they cheat initially by remembering the company name, e.g. calling an entire team "the Airbnbs" or something, until they get to know the people individually. So it's at least 66 groups vs. 150 people. The company names or nicknames are usually also way more distinctive than the ~10 guys named John or Jack or Mike in every group.
the O(n^2) thing sounds reasonable until i start to think about it. but then i get confused. that's some kind of cost, but my naive interpretation (number of partners scales with applicants, so total interactions is n^2) spreads that cost across O(n) partners, so the cost per partner is O(n).
what am i missing? am i just being too literal, or have you identified some real process that is O(n^2) per person, or is the total cost more important than i think? or am i just being dumb?
or maybe even handling O(n) per partner is too much. i guess that may be all it is. my initial reading was that O(n^2) explained why 66 and 84 were so different (when linearly, they're pretty similar).
The way I read it, he's referring to communication channels needed for everyone to be on the same page (see Metcalfe's law, for example: http://en.wikipedia.org/wiki/Metcalfes_law). Traditionally, with a homogeneous group of people, the count of communication channels will be O(n^2), as you can see in the images at the top of the wikipedia article, because everyone needs to talk to everyone else.
In this case, it's not homogeneous; there are n startups and m partners, but if every partner needs to know what's going on with every startup, you still have O(mn) communication channels. If, for example, you assigned n/m startups to each partner, the total communication channels needed would reduce to O(m+n). I believe pg is referring to something along those lines when he says he'd like to make it unnecessary for each partner to know what each startup is doing.
So it's not so much the batch size that matters. It's the quality of the investor.
From the about page:
> All venture investors supply some combination of money and help. In our case the money is by far the smaller component. In fact, many of the startups we fund don't need the money.
This is intriguing, because investor as I imagine would like to spread there bets as much as possible.
From an investors point of view, isn't it counter intuitive to solidify around a smaller number of start ups.
Although, I agree that they should invest more time, as a path to success. Showing care for your investments seems all around wise.
Just food for thought, I'm not sure if I have a point most of us don't already realize.
To grow bigger we have to (a) make it easier for each partner to know what each startup is doing, or (b) make it unnecessary. The answer will probably be a bit of both.
The symptom was not startups having trouble raising money (that seems to be working about like it usually does) but us partners always feeling confused. We were not ahead of the aircraft in the way we'd been in the past.