Er is een moment in bijna elk groeiend engineering-team waarop iets kantelt.

Niet ineens. Niet zichtbaar op een dashboard. Maar voelbaar in de manier waarop gewerkt wordt. Projecten stapelen zich op, prioriteiten verschuiven, en wat ooit overzichtelijk was, begint langzaam te schuren. Teams blijven leveren, maar het kost meer moeite. Meer afstemming. Meer energie.

En dan ontstaat de reflex die logisch voelt.

We hebben meer capaciteit nodig.

Nog iemand erbij. Nog een paar handen. Nog wat extra ruimte om alles rond te krijgen.

Maar wat als het probleem niet in capaciteit zit?

Wat als het zit in hoe het werk georganiseerd is?

In veel organisaties worden projecten gezien als iets wat je “erbij doet”. Een uitbreiding van het bestaande werk. Iets dat je verdeelt over het team dat er al zit. Want daar zit de kennis, daar zit de ervaring, dus daar moet het gebeuren.

Op papier klopt dat.

In de praktijk begint daar vaak de vertraging.

Want een project is geen verlengstuk van een team. Het is iets fundamenteel anders. Waar teams draaien op continuïteit, vragen projecten om focus. Waar teams bouwen aan stabiliteit, vragen projecten om snelheid. En waar teams functioneren binnen bestaande structuren, trekken projecten die structuren juist uit elkaar.

Door die twee werelden samen te voegen, ontstaat er frictie.

Niet omdat mensen het niet aankunnen, maar omdat het systeem eromheen tegenwerkt.

Je ziet het terug in kleine signalen. Engineers die steeds vaker van context wisselen. Werk dat “bijna af” is, maar blijft liggen. Beslissingen die wachten op afstemming, omdat niemand expliciet eigenaar is. Alles is belangrijk, dus alles krijgt aandacht, en daarmee verliest het team precies dat wat het nodig heeft: focus.

Wat volgt, is herkenbaar.

Deadlines schuiven, projecten lopen uit en teams werken harder, maar niet per se sneller.

En vaak wordt dat nog steeds gezien als een capaciteitsprobleem.

Terwijl het in essentie een organisatievraag is.

Want hoe je werk organiseert, bepaalt hoe snel je beweegt.

De organisaties die hier beter mee omgaan, stellen zichzelf een andere vraag. Niet alleen: wat moet er gebeuren? Maar ook: waar hoort dit thuis?

Sommige projecten passen prima binnen een team. Ze sluiten aan op bestaand werk, bouwen voort op wat er al is, en versterken de structuur. Maar andere projecten doen het tegenovergestelde. Ze vragen volledige aandacht, trekken mensen uit hun context en brengen afhankelijkheden met zich mee die het hele team raken.

Die projecten vragen iets anders.

Niet meer mensen, maar een andere inrichting.

Een plek waar focus geen uitzondering is, maar de standaard. Waar duidelijk is wie beslissingen neemt, waar de scope bewaakt wordt en waar voortgang niet afhankelijk is van hoe druk het team toevallig is. Waar eigenaarschap niet gedeeld wordt tot het verdwijnt, maar expliciet is belegd.

Dat betekent soms dat een project niet in het team thuishoort, maar ernaast.

Niet als losse activiteit, maar als bewuste keuze in hoe je organiseert. Zodat teams kunnen blijven doen waar ze goed in zijn, en projecten de aandacht krijgen die ze nodig hebben om daadwerkelijk vooruit te komen.

Het vraagt om een andere manier van kijken.

Niet elk probleem los willen opvangen binnen dezelfde structuur. Niet automatisch kiezen voor meer capaciteit, maar eerst begrijpen waar de frictie ontstaat. En vooral: durven erkennen dat niet alles past in het systeem dat je al hebt.

Misschien is dat wel de kern van schaalbaarheid.

Niet hoeveel werk je aankunt.

Maar hoe bewust je kiest waar het landt.

Want uiteindelijk zit vooruitgang zelden in harder werken.

Het zit in slimmer organiseren.

En soms begint dat met één simpele vraag: hoort dit project hier eigenlijk wel thuis?