Everyone knows that we have a funny ecosystem of innovation here in the Valley — big companies are supposed to be somewhat slow-moving, small startups are supposed to provide a lot of the new ideas, and innovation from startups gets incorporated into the industry in at least three ways: acquisition by a larger company (common), independent survival to become a big company (rare), and completely cratering (common), leaving nothing behind except the original idea and perhaps a validation of the market.
This valorizing of startups and innovation leads larger companies to want to encourage startup-like behavior, whether by acquisition and semi-integration of the purchases, or by trying to artificially create a start-up atmosphere in small innovation-focused teams. I work for a company like this, and I’m glad that people are trying this stuff out.
At the same time, trying to create this kind of startup-within-the-big-company atmosphere leads to a funny feeling for those of us who are _not_ working on a small-scale startup-style project. There are times when I almost feel … well, _scolded_ for not working in a “war room” with a small group on a fast-cycle project. And it makes me want to stress again what I think is *the* fundamental paradox of medium-scale or large-scale software dev:
o The most productive environment for rapid software development is a team of at most ten developers (ideally all sitting in the same room)
o Some products require more than ten developers
This very basic tension is well known, and goes all the way back to the Mythical Man-Month. But pro-startup ideology sometimes overemphasizes the former (small teams are the most productive) and forgets the latter (some problems need large teams).
As an example, let’s take the problem that I myself work on: web search. It would be unwise for me to disclose exactly how many people Yahoo! has working on web search, but I think it’s uncontroversial to admit that it’s more than 10×10. So if we adopt the war-room model, we’ll need a minimum of ten ten-person rapid-development war rooms to get this product out the door, which in turn raises the question: how will we coordinate those rooms? Surely we don’t want to fall back on big-company org tactics like hierarchical management, cross-group meetings, and all those other suspect practices that we know get in the way of startup energy… But otherwise those rooms are all going to charge ahead in their enthusiastic startup way, all working on the _same_ product. Hmm…
But wait, I hear you cry — how do we know that we _need_ all those people? Isn’t there some startup waiting around the next bend who is going to eat the respective websearch lunches of Google, Yahoo!, and MSN, with just eight people sitting in some crappy room together and collaborating in a very-high-bandwidth and effective manner?
My guess is no. I could be wrong, of course, but I would not at this point advise getting involved in a small startup whose mission is to compete with these companies at _general_ web search. It’s just too complicated and requires too much capital. Sure, you might start a company that innovated in some particular technique, enough so that it was worth it for one of these companies to buy you, thereby ensuring your financial security in your golden years. And also the game might change under the feet of these companies (say, by general web search becoming less important) in such a way that they are flat-footedly left chasing a changing market. But a new startup eating this very websearch lunch? I don’t think so. If you have any doubt, imagine such a perfect small-scale websearch startup hosted out of someone’s garage in the U.S., and then ask them this unexpected question: is your relevance better in Traditional Chinese or Simplified Chinese? How about your comprehensiveness? And how exactly do you know? (Yes, by “general” web search I did of course mean “global” as well…)
The funny thing is that I see any number of startups (both true startups and company-internal projects) that in that good Web 2.0 mashup kind of way _assume_ back-end services like web search that they are built on top of. And in a funny way, it’s easy for these products to forget their dependence. Imagine that you have written a web app all by yourself, including back end, front end, and Apache config files. If someone asks whether you did it all by yourself, you will of course proudly say yes. If your interviewer then asks whether you ran the power generator, you will of course say no — you plugged into a power grid (whether in your apartment or in your data center). Was your team small and agile? Yes. Was the team that provided your electric power small and agile? Probably not.
Analogously, services like web search are becoming commoditized in one sense (that they provide a good used by many people) but not in the other sense (that the services are interchangeable —- in fact, fiercely competitive battles rage over differentiation and relative quality). And this is what I think you will increasingly see in the webservices-oriented world that we all imagine is coming: visible front-end product innovation (possibly by small teams) built on top of very large-scale back-end services (that may themselves be innovating, but it will be harder to tell from the outside). The most visible part is easy to describe with reference to startup ideology; the whole enchilada, though, is a lot bigger and a lot more complicated.
Tim Converse 