Why enterprise companies are sinking in the flood

There's a question enterprise companies ask about startups. "How are we being beaten by ten guys in a loft in Shoreditch? We've got so many more resources than they have!" And more often than not when challenged they double down on more - more planning, more market research, more project management and more lines of code.

"We'll beat them," they say, "by using what the startups don't have".

Well, here's what ten people in a loft in Shoreditch don't have:

• A lengthy pre-validation stage producing nothing but glossy diagrams, charts, and overly precise financial estimations.
• A dozen disparate stakeholders arguing over how things will cannibalise or complement their existing products.
• An indoctrinated belief on how products should look and work.
• A company-wide edict on choice of language, framework and development practice that is at least 5 years out of date.
• A seemingly bottomless pit of badly-documented legacy software that needs to be worked around, integrated with or extended.
• A swarm of blamestorming meetings when the messy process of developing real software fails to agree with the shiny Gantt charts and agreed budgets.
• A drawn-out approval and deployment process for the finished software.
• A refusal to pivot based on customer feedback.

This is how we're getting to this situation where the established players have several thousand employees, while the challengers are barely into the double digits... but it's the latter who are running riot wherever they wish carving whole chunks out of the former's market share.

The traditional functional organisation cannot compete in this world, because as that list shows it's spending too much time concentrating on things that aren't getting software into customers' hands and looking at their reactions. You're seeing reactions to purely internal stimuli; there's a big project management element to keep the PMO busy, a spurious database to give the DBAs something to do, a ponderous Java API just because the Java team were kicking their heels in the break room, and turf wars all over the place where things could fit in more than one function. It's Conway's Law in full effect.

What the small startups do have that the enterprise usually doesn't is this: A clear outcome everyone in a group is working toward

This outcome-oriented approach is what you see in successful small companies: everyone aware of what the goals are and contributing in any way they can. In my experience, one of the biggest dangers for a small company is when it grows large enough to feel like it can specialise into functional teams... and suddenly everything blows up because it's not a developer's job to figure out what customers want, or product marketing are treading on ideation's turf, and so on. It's an art to keep things outcome-oriented when you start getting big enough to concentrate on more than one outcome at a time.

My opinion is that the successful large organisations of the future will be cellular: comprised of autonomous, outcome-oriented units co-operating together on their own terms. Each unit with its own goal, but also working towards an overall goal that unifies the whole company and sets the framework for co-operation. Think about the way fire ants form a raft to protect themselves from a flood. There's no manager telling the ants how to work together, no clearly defined flotation team or core team or navigation team - each ant just clings to the nearest lump of ants it can find because that's what self-preservation says is sensible. Outcome: survive the flood.

Alternatively you can try being top-down; the individual ants on the bottom refusing to interact with each other while supporting a tower of ants and process above them... and go crashing through the surface tension and sink like a stone at the slightest perturbation.

_{Image by Leandro Gomes Moreira}