Virulent Word of Mouse

November 12, 2010

Why large firms can’t innovate: Don’t generalize

Recently Robert Scoble published a provocative essay about why Google has difficulty innovating. His answer was provocative, but unbalanced. His answer stressed that Google, like any large firm, has a problem with innovation linked to small teams. The post raises many interesting points, and I recommend reading it.

Perhaps the best feature of the post is Scoble’s incessant piling on of stories. He brings in a few Microsoft stories to bolster the notion that Google’s problems resemble the problems found at other large software firms who had a history of innovation but lost it.

I will admit that it suckered me in. Comparing Google to Microsoft is a bit of a team sport in high tech blogging these days. I have engaged in it myself in these very pages. That does not make the observation valid, however.

More to the point, Scoble’s observations do not generalize. Large firms have difficulty innovating in some contexts. This should come as no surprise, since, after all, firms are built for some sets of problems and not all problems. Hence, no firm is good at everything. Google is large, so it faces challenges in some contexts. What else is new?

(By similar reasoning, by the way, small firms have a hard time innovating in some contexts too. Nobody ever gets exercised over that. But when a large firm faces problems….oh, what hand wringing!)

So here is the big point. While it is very interesting to hear about one rich firm’s problems competing with start-ups, that observation, by itself, does not give anything like a complete picture. This post will consider in what sense Scoble’s observations were incomplete.

Why care about incomplete analysis? Perhaps you will want to read this before you go and short all your Google stock.

Rules of thumb

Scoble offered several rules of thumb, inferred from watching issues at Google. In summary, he stressed the following rules and how these distort outcomes:

* At Google teams get too big to be functionally optimal.

* Large teams get too ambitious too quickly, facing internal pressure to not reduce the scope of a project.

* Early success breeds too much internal attention, which distracts from further success.

* Google’s infrastructure is standardized for certain types of applications, but not all types, and it particularly missing the right tools for problems today.

* Google asks its internal start ups to support its existing business, and make costly attempts to follow firm philosophy.

* At Google a small project cannot fly under the radar screen for long, testing its beta version with outsiders.

* Lacking crucial feedback from outsiders, the iterations for a team at Google are truncated.

* Large firms scale first, then find demand, instead of the other way around, and the latter suits most early innovation.

That is a short summary, and does not capture the article’s depth. So do not take my word for it. It is an insightful and provocative article. Take a look.

The article has only one big problem, IMHO. It needs to bring a little spice to the problem, because everything Scoble says needs to be taken with a grain of salt.

He does point out that large firms have inherent advantages in resources. That allows them to buy innovators in the event that their own internal efforts fail. In addition, large firms can innovate in areas that no small firm would ever dare to attempt.

That is a good list, but far from balanced.

The yin and yang of it

Look, I love listening to firms describe their issues. It is possible to learn a lot. Scoble does a good job communicating some of the issues faced by employees inside Google.

But context matters, especially when making generalizations.

Virtually every one of the disadvantages identified by Scoble are advantages under the right circumstances. Scoble’s observations remind me of Tigger’s declarations that “This is what Tiggers do best!” As any Winnie the Pooh reader should recall, such declarations change with context.

To emphasis the point, I will try to offer rules based on the same premises. Most of these are based on observations I have heard during many years of field work (without ascribing these to anybody in particular). Here the same rule and in the same order.

* Teams need to be big in order to make functional software that integrates with multiple operating systems or performs the functions of enterprise middle ware.

* Large teams need internal pressure to resist the temptation to reduce the scope of a project, so they solve problems that generate value for stockholders.

* Early success needs to attract attention, so upper management knows which projects to protect from internal fights over turf.

* Standardized infrastructure supports easier integration with existing software (which, *um*, excuse me, really matters for the functionality, reliability, and cost of software in mass markets).

* An internal start up can build applications that help extend the life of a platform, creating firm wealth far beyond anything possible with any start up.

* A small project cannot fly under the radar screen for long, nor should it, because it helps upper management find out if a little internal enthusiasm bubble has been wasting internal firm resources.

* Lacking feedback from outsiders, an internal project avoids the fad of the moment, instead following the path laid out by a careful analysis of existing customer needs.

* Large firms make sure that the software can scale from the outset, so the transition to a mass market goes much smoother than any hastily written spaghetti-code found at a start-up.

What context is missing from Scoble’ observations?  He describes the problem faced by a  large firm who creates for early adopters. It should come as no surprise that a large firm will lose many head-to-head fights in such a situation. In other words, it should come as no surprise that Google finds this situation challenging to manage.

Let me rephrase. Google’s problems creating software for early adopters may or may not overlap with the issues faced by firms who create for mass markets, which is another customer base that Google cares about. Without describing the customer, the installed base of existing software, and the business approach, Scoble’s rules of thumb do not necessarily generalize.

Any generalities?

First conclusion: do not generalize from one firm’s problems. That exercise too easily leads to cliche’s that do not generalize.

If this post leads to any cliche’, then consider this one: Markets and users are best served by a variety of firms, because in settings with evolving demand and new market opportunities it will not be apparent which organizational form best suits the situation.

Variety fosters experiments in new products, new organizational forms, and competition between them. It is a mess to behold, and an incredibly challenging environment in which to manage a firm.

So I take one other thing from Scoble’s post. Google finds itself in a competitive setting, and some of the time it loses. That seems great. We are all better off because Google is mortal. They cannot succeed in all innovative settings, nor with all innovative problems.

Leave a Comment »

No comments yet.

RSS feed for comments on this post.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at

%d bloggers like this: