Groei voelt vaak als vooruitgang. Meer klanten, meer mensen, meer projecten, meer ideeën.
Tot het moment dat snelheid een strategisch thema wordt ("we moeten sneller!") maar je organisatie in de praktijk trager begint te bewegen.
HBR noemt dit een speed gap: het verschil tussen hoe belangrijk leiders snelheid vinden en hoe snel de organisatie effectief beweegt. HBR
En het verraderlijke is: dit ontstaat zelden door een grote fout. Het groeit organisch, jaar na jaar, terwijl iedereen "gewoon" probeert te leveren.
1) Hoe je hier ongemerkt in terechtkomt
In een bedrijf tussen pakweg 100 en 500 medewerkers zie je vaak dezelfde ingredienten:
a) Het bedrijf draait op menselijk geheugen
Er is een kern van mensen die "het systeem" kent:
- uitzonderingen
- klantafspraken die nooit echt ergens stonden
- historische keuzes ("zo doen we dat nu eenmaal")
- impliciete afhankelijkheden
Lang werkt dat prima. Tot je wil versnellen en opschalen.
b) Upstaffen voelt logisch, maar verhoogt tijdelijk de druk
Nieuwe mensen hebben context nodig. En die context zit net bij de mensen die al maximaal belast zijn.
Gevolg:
- experts worden een helpdesk
- overleg vervangt documentatie
- beslissingen worden genomen met onvolledige informatie
- projecten moeten opnieuw vastgepakt worden (rework)
c) Teams worden eilanden
Niet omdat mensen niet willen samenwerken, maar omdat de organisatie groter wordt en het aantal afhankelijkheden exponentieel stijgt.
En dan krijg je dit patroon:
- Product beslist een wijziging ("commerciele impact!")
- Release management moet de planning herschikken
- Projectteams moeten scope en timing herzien
- Ops/support krijgt extra varianten en tickets
- Sales heeft opnieuw uitleg/enablement nodig
De feature "werkt" misschien, maar de internal change cost slorpt de beoogde business value op.
2) Wat LEGO hier (pijnlijk) goed illustreert
In de LEGO-case (zoals mooi samengevat door Mariya Valeva) ging het niet om een zwak merk of minder vraag. Het probleem was dat LEGO "ja" zei tegen te veel ideeen—los bekeken geweldig, samen destructief:
- duizenden extra SKU's en onderdelen
- inefficiente fabrieken
- tragere supply chain
- meer inventory en langere cash cycles
Ze "verzopen" in complexiteit. Het systeem werd trager en duurder, terwijl de creativiteit bleef.
Dat is exact wat je in groeibedrijven ook ziet, maar dan in processen, software, releases, varianten, uitzonderingen en "kleine" wijzigingen die samen een moeras worden.
3) Waarom dit zo gevaarlijk is als je digitaliseert
Digitalisering is een versneller. En dat is het probleem.
- Als je een helder proces digitaliseert, krijg je snelheid en schaalbaarheid.
- Als je een impliciet, eiland-gedreven proces digitaliseert, krijg je… geautomatiseerde complexiteit.
Dan stijgt je change volume, maar daalt je netto snelheid.
4) Wat je kunt doen (preventief, voor het pijn doet)
Dit is de kern van mijn waarschuwing: wacht niet tot het kraakt. Bouw tijdens groei vaste reflectiemomenten in, net om te voorkomen dat je later drastisch moet ingrijpen.
Hier zijn concrete ingrepen die werken, zonder dat je een "bureaucratisch bedrijf" wordt:
1) Maak "impact zichtbaar" voor je beslist
Installeer een lichte routine bij elke relevante change:
- Wie raakt dit nog behalve Product/IT?
- Wat betekent dit voor release, testing, support, enablement, operations?
- Welke afhankelijkheden zijn er?
Niet als papiermolen, maar als standaardvraag: "Wat breken we zonder het te willen?"
2) Reken met "Total Cost of Change"
Stop met business cases die alleen development effort tellen.
Neem minstens mee:
- test & release overhead
- coordinatie- en afstemmingstijd
- documentatie/training
- supportimpact
- rework-risico
Vaak is het niet de bouwkost die je vertraagt, maar de change-randkosten.
3) Verminder variatie (bewust "nee" leren zeggen)
LEGO won door te standaardiseren (onderdelen, kleuren, productie) en SKU's te schrappen.
In jouw context vertaalt dat zich naar:
- minder varianten in processen
- minder uitzonderingsflows
- minder "one-off" klantdeals die een standaardproces breken
- strictere product- en platformprincipes
Schaalbaarheid is vaak: minder uitzonderingen, niet meer mensen.
4) Externaliseer kennis als strategische investering
Niet "als er tijd is", maar gepland:
- shadowing door process/BA profielen
- runbooks / beslisbomen
- Definition of Done met documentatie/impactcheck
- ownership van end-to-end flows (niet alleen team-silo's)
5) Plan "slow down weeks" tijdens groei
Een van de beste preventieve praktijken: periodiek vertragen om te versnellen:
- processen opschonen
- afhankelijkheden expliciteren
- legacy-afspraken normaliseren
- release- en change governance licht aanscherpen
Je betaalt dan bewust een kleine kost om een toekomstige grote kost te vermijden.
5) Afsluiter
De meeste bedrijven komen niet in de problemen omdat ze te weinig ideeen hebben. Ze komen in de problemen omdat complexiteit sneller groeit dan duidelijkheid.
Als je sneller wil gaan, is "meer doen" zelden het antwoord. Eerst moet je zien waar het systeem trager wordt—en daar tijdig op ingrijpen.
Vraag: Waar ontstaat in jouw organisatie het grootste snelheidsverlies: bij kennis in hoofden, eilandbeslissingen, of verborgen change costs?
Bronnen: HBR, LinkedIn-post LEGO