Growth often feels like progress. More clients, more people, more projects, more ideas.
Until the moment speed becomes a strategic theme ("we need to move faster!") — while in practice, your organization starts moving slower.
HBR calls this a speed gap: the difference between how much leaders value speed and how fast the organization actually moves. HBR
And the treacherous part: this rarely happens because of one big mistake. It grows organically, year after year, while everyone is "just" trying to deliver.
1) How you end up here without noticing
In a company of roughly 100 to 500 employees, you usually see the same ingredients:
a) The company runs on human memory
There's a core group of people who "know the system":
- exceptions
- client agreements that never really existed on paper
- historical choices ("that's just how we do it")
- implicit dependencies
For a long time, that works fine. Until you want to accelerate and scale up.
b) Adding headcount feels logical, but temporarily raises the pressure
New people need context. And that context sits precisely with the people who are already maxed out.
The result:
- experts turn into a helpdesk
- meetings replace documentation
- decisions get made with incomplete information
- projects have to be picked back up (rework)
c) Teams become islands
Not because people don't want to collaborate, but because the organization gets bigger and the number of dependencies rises exponentially.
And then you get this pattern:
- Product decides on a change ("commercial impact!")
- Release management has to rework the planning
- Project teams have to revisit scope and timing
- Ops/support gets extra variants and tickets
- Sales needs explanation/enablement all over again
The feature might "work", but the internal change cost eats up the business value it was supposed to deliver.
2) What LEGO illustrates (painfully well)
In the LEGO case (nicely summarized by Mariya Valeva), the problem wasn't a weak brand or falling demand. The problem was that LEGO said "yes" to too many ideas—each one great in isolation, destructive together:
- thousands of extra SKUs and parts
- inefficient factories
- a slower supply chain
- more inventory and longer cash cycles
They "drowned" in complexity. The system got slower and more expensive, while the creativity kept flowing.
That's exactly what you see in growth companies too — just in processes, software, releases, variants, exceptions, and "small" changes that together become a swamp.
3) Why this is so dangerous when you're digitalizing
Digitalization is an accelerator. And that's the problem.
- Digitalize a clear process, and you get speed and scalability.
- Digitalize an implicit, island-driven process, and you get… automated complexity.
Your change volume goes up, but your net speed goes down.
4) What you can do (preventively, before it hurts)
This is the core of my warning: don't wait until it cracks. Build regular reflection moments into your growth phase, precisely to avoid having to intervene drastically later.
Here are concrete moves that work, without turning you into a "bureaucratic company":
1) Make "impact visible" before you decide
Install a light routine for every relevant change:
- Who else does this affect besides Product/IT?
- What does this mean for release, testing, support, enablement, operations?
- What dependencies exist?
Not as red tape, but as a standard question: "What are we breaking without meaning to?"
2) Calculate with "Total Cost of Change"
Stop building business cases that only count development effort.
At minimum, include:
- test & release overhead
- coordination and alignment time
- documentation/training
- support impact
- rework risk
Often it's not the build cost that slows you down, but the peripheral cost of change.
3) Reduce variation (learn to consciously say "no")
LEGO won by standardizing (parts, colors, production) and cutting SKUs.
In your context, that translates to:
- fewer process variants
- fewer exception flows
- fewer "one-off" client deals that break a standard process
- stricter product and platform principles
Scalability is often: fewer exceptions, not more people.
4) Treat externalizing knowledge as a strategic investment
Not "when there's time", but planned:
- shadowing by process/BA profiles
- runbooks / decision trees
- a Definition of Done that includes documentation/impact checks
- ownership of end-to-end flows (not just team silos)
5) Plan "slow down weeks" during growth
One of the best preventive practices: periodically slowing down in order to speed up:
- clean up processes
- make dependencies explicit
- normalize legacy agreements
- lightly tighten release and change governance
You then deliberately pay a small cost to avoid a much larger one later.
5) Closing thought
Most companies don't get into trouble because they have too few ideas. They get into trouble because complexity grows faster than clarity.
If you want to go faster, "doing more" is rarely the answer. First you need to see where the system is slowing down—and act on it in time.
Question: Where does your organization lose the most speed: knowledge stuck in people's heads, island decisions, or hidden change costs?
Sources: HBR, LinkedIn post on LEGO