Large companies often admire startup speed: fast decisions, fast experiments, fast execution. That sometimes leads to attempts to "think like a startup" — innovation labs, hackathons, agile transformations. The problem is that much of this imports the form without the substance. You cannot legislate your way to startup speed. It comes from something else. Many try — most fail.

What startups actually do differently

What drives the speed in a startup is rarely culture alone. It's resource scarcity. When you can't afford to be wrong for long, you're forced to test assumptions quickly, gather feedback early, and — most importantly — kill what isn't working before it becomes too expensive to stop.

That last point is what I most often see missing in larger organisations: clear kill criteria. A project that doesn't meet predetermined criteria by a predetermined point should be stopped — not extended because of what's already been invested in it. Without that discipline, experiments turn into perpetual projects that never quite fail, but never quite succeed either.

Often, it's because the people running the projects inside large organisations don't have real startup experience. It's typically capable people from within the organisation who get put in charge — but genuinely successful entrepreneurs are a rare breed, and hard to gain access to. Sometimes it comes down to the innovator's dilemma: the organisation doesn't really prioritise innovation, because it's comfortable with the business it already has, and its best people are rarely freed up to drive something new. That can become the beginning of the end, because the company fails to move fast enough — read more in Boards need to see change before it hits the numbers.

Where the analogy breaks down

A large company is not, and shouldn't try to be, a startup. It has employees, customers, suppliers and obligations a startup doesn't have. Its risk tolerance is different, and it should be. Trying to recreate startup chaos inside an organisation with thousands of employees isn't agile — it's irresponsible.

What can be imported isn't the speed itself. It's the discipline behind it: clear hypotheses, fast tests at a bounded scale, and the courage to shut something down when it isn't working.

What I've learned from standing in both camps

I've built companies from scratch, where resource scarcity was a daily reality, and I've sat on boards where the question instead was how to preserve that sharpness once resources were no longer the constraint. The answer is rarely more process. It's fewer, better-bounded experiments — with an honest answer, decided before you start, for what it would take to make you stop.

A board that wants more startup energy in the organisation shouldn't ask "how do we get faster everywhere." It should ask: "where do we have projects that are never allowed to fail — and what would it take to give them permission to?"

— David Hald