I have a friend who is currently working at AdMob, and it looks like to me they’re doing some good work over there. They are using, what I would call, the “Bottom Up” method of building a company and platform. They started small, let the business grow according the existing market conditions, and now are on the cusp of being massively successful. I don’t know how much money was used to found AdMob, but I’m judging by the blog that the business started out with a relatively small amount of investment, and has been bootstrapping its efforts with profits. This is the same method I would use.
I, on the other hand, work for a company that would take what I call the “Top Down” approach. This means, that my company would start out by finding large advertising partners, begin long term studies and revenue projections, and then begin building the product from the existing advertising partners and revenue projections. There are reasons why we have to do it this way, and I fully understand the reasons. In some cases, we have no choice.
However, it seems clear to me that “Top Down” is almost always slower to innovate than “Bottom Up”. Entrenched corporate polices prohibit my company from really starting something like AdMob (not that we’re interested). It would be hard to convince the appropiate board members, sales staff, and IT managers to take a flyer on a product like AdMob.
I think this all points to a certain sweet spot for a size of the company, and it’s ability to innovate. If I had to guess, I’d say the perfect sized company for innovation would be made up like this:
- 1 Founder/CEO who has the vision
- 1 Marketing guy who also handles most of the general business functions
- 3 Senior developers with copious amounts of skills
- 4 Junior developers who could innovate the designs of the senior developers
- 1 Sysadmin to handle setting up servers, etc.
What do you think?
Hey Shane, thanks for the comments and kind words. Interesting that you put down three senior developers. That’s where I draw the sweet spot for that as well. One is too few, you need someone else with a deep understanding to throw ideas around with. With two however you run the risk of frequently deadlocking on issues if you hit a major idealogical rift with respect to what to work on and how to do it. With three however all issues tend to tip toward some kind of resolution, but the size is small enough that everyone can be directly involved.
Another pattern that seems to emerge frequently around here (Silicon Valley) is the surgical team style group like that described in The Mythical Man-Month (http://www.dfpug.de/loseblattsammlung/online/workshop/design_patterns/sonstiges.htm) It doesn’t follow the same exactly layout as described there, but tends to be a group of folks that move around as a group and tend to have relatively consistent roles. One person is the tools person that puts together the parts needed to build with, two will be builders concentrating on what the user facing parts look like, another will be the overall architect concentrating on scaling and performance issues.
Don’t forget a sales person in your mix however. Marketing is one thing, but having a closer who has a rolodex of people to call and the skills to negotiate deals with them is another thing entirely. I think 4 junior developers is a bit heavy at the early stages too. Junior developers need oversight and guidance normally, and that needs to come from the senior developers unless you want to put a dedicated manager in there. Maybe one or two particularly good junior developers who can pick stuff up around the edges on their own. Otherwise you’re putting unnecessary load on the senior guys with minimal return.