5 signalen dat je organisatie technisch leiderschap mist

Je IT-project loopt weer uit. De developer zegt dat het “complexer is dan verwacht.” Je leverancier stuurt een meerkosten-voorstel. En jij knikt, want je hebt geen idee of dat klopt. Je kunt het niet beoordelen. Niet omdat je dom bent, maar omdat er niemand in je organisatie zit die de brug slaat tussen wat het bedrijf nodig heeft en wat er technisch gebeurt.

Dat is geen IT-probleem. Dat is een leiderschapsprobleem. En het kost je meer dan je denkt. Volgens de Standish Group faalt 69% van alle IT-projecten of loopt significant uit. McKinsey becijferde dat grote IT-projecten gemiddeld 45% over budget gaan. Niet door slechte developers. Door het ontbreken van iemand die richting geeft.

Hieronder vijf signalen die je helpen herkennen of dit ook in jouw organisatie speelt.

1. Je IT-projecten lopen structureel uit en worden duurder

Niet incidenteel. Structureel. Elk project duurt langer dan afgesproken. Elke oplevering bevat minder dan beloofd. En de factuur is altijd hoger dan de offerte.

Het patroon is herkenbaar: het project begint enthousiast, na een paar weken komen de eerste “tegenvallers”, de scope verschuift, en uiteindelijk lever je een versie op die 60% doet van wat je wilde, voor 140% van het budget.

Waarom dit een leiderschapsprobleem is: zonder iemand die de technische haalbaarheid vooraf beoordeelt, realistisch plant, en tijdens het project bijstuurt, zijn uitloop en budgetoverschrijding geen verrassing. Ze zijn onvermijdelijk. Een technisch leider stelt de juiste vragen voor het project begint. Niet: “wat wil je bouwen?” Maar: “wat is het kleinste dat je kunt bouwen om te bewijzen dat dit werkt?”

2. Je bent volledig afhankelijk van je IT-leverancier

Je leverancier beheert je systemen, adviseert over keuzes, en bouwt de oplossingen. Dat voelt handig, tot je beseft dat dezelfde partij die adviseert ook de partij is die factureert. Ze adviseren hun eigen oplossingen. Ze schatten hun eigen uren in. En jij kunt niet beoordelen of het klopt.

De signalen: je kunt niet wisselen van leverancier zonder alles opnieuw te bouwen. Je weet niet waar je broncode staat, of je die bezit. Je leverancier bepaalt het tempo, niet jij. En bij elke contractverlenging stijgt de prijs, maar je voelt dat je niet weg kunt.

Waarom dit een leiderschapsprobleem is: een technisch leider is je onafhankelijke sparringpartner. Iemand die leveranciersvoorstellen beoordeelt, architectuurkeuzes bewaakt, en ervoor zorgt dat je altijd kunt overstappen. Niet om wantrouwig te zijn tegenover je leverancier, maar om een gelijkwaardige gesprekspartner te zijn.

3. Je team is druk, maar je ziet weinig resultaat

De developers werken. De sprints draaien. De standups worden gehouden. Maar als je vraagt wat er de afgelopen maand is opgeleverd, is het antwoord vaag. “Technische verbeteringen.” “Refactoring.” “We hebben de basis gelegd voor…” En het product dat je klanten gebruiken? Dat ziet er hetzelfde uit als drie maanden geleden.

Wat er aan de hand is: zonder technisch leiderschap ontbreekt de prioritering. Developers doen wat zij belangrijk vinden, niet wat het bedrijf nodig heeft. Dat is niet hun schuld. Developers zijn opgeleid om technische problemen op te lossen. Ze bouwen wat je ze vraagt, maar als niemand de vertaalslag maakt van bedrijfsdoelen naar technische prioriteiten, verdwijnt de energie in de verkeerde richting.

Onderzoek van Stripe toont dat 42% van de werkweek van developers opgaat aan het bestrijden van technische schuld en slechte code. Dat is bijna de helft van de beschikbare tijd die niet naar nieuwe functionaliteit gaat. Zonder iemand die bewust stuurt op de balans tussen bouwen en opruimen, wint de technische schuld altijd.

4. Technische schuld stapelt zich op en niemand slaat alarm

Technische schuld is het opgebouwde achterstallig onderhoud in je software. Snelle oplossingen die nooit netjes zijn afgemaakt. Verouderde technologie die nog draait “omdat het werkt.” Code die niemand durft aan te raken omdat niemand meer weet wat het doet.

De gevolgen zijn concreet: een feature die in een schone codebase twee weken kost, kost in een codebase vol technische schuld vier tot zes weken. Volgens Gartner gaat 40% van het gemiddelde IT-budget naar het onderhouden van legacy-systemen. Bij sommige organisaties is dat 60-80%. Je betaalt de rente op een schuld die elk kwartaal groeit.

Waarom dit een leiderschapsprobleem is: technische schuld is onzichtbaar voor niet-technische mensen. Het staat niet op de balans. Het heeft geen dashboard. Het enige wat je merkt is dat alles langzamer gaat, duurder wordt, en vaker kapotgaat. Een technisch leider maakt technische schuld zichtbaar, kwantificeert de impact, en plant structureel tijd in om het af te lossen. Zonder die persoon groeit de schuld tot het systeem onhoudbaar wordt.

5. Elke technische beslissing voelt als gokken

Moeten we naar de cloud? Welk framework is de juiste keuze? Is deze leverancier betrouwbaar? Moeten we dit zelf bouwen of een bestaande tool gebruiken? Investeren we in AI of is dat hype?

Je hoort vijf verschillende meningen van vijf verschillende partijen. Elke leverancier adviseert zijn eigen oplossing. Elke consultant heeft een ander framework. En jij moet beslissen zonder de technische kennis om de argumenten te wegen.

Dus doe je een van twee dingen: je stelt de beslissing uit (en de kosten van niets doen lopen op), of je kiest op gevoel (en hoopt dat het goed uitpakt). Geen van beide is een strategie.

Waarom dit een leiderschapsprobleem is: een technisch leider vertaalt technische opties naar bedrijfsconsequenties. Niet “we moeten naar Kubernetes” maar “als we nu €15.000 investeren in deze migratie, besparen we €3.000 per maand aan hosting en kunnen we 10x meer gebruikers aan.” Dat is een bedrijfsbeslissing die je kunt nemen. Geen technische gok.

De rode draad: het ontbrekende vertaalpunt

Alle vijf de signalen hebben dezelfde oorzaak: er is niemand die de vertaling maakt tussen bedrijfsdoelen en technische realiteit. Iemand die aan de ene kant begrijpt wat het bedrijf nodig heeft, en aan de andere kant kan beoordelen of de technische aanpak daar de juiste weg naartoe is.

Dat is niet de rol van je developer. Die is opgeleid om te bouwen, niet om strategie te bepalen. Het is ook niet de rol van je leverancier. Die heeft een commercieel belang. En het is niet jouw rol als directeur of manager. Je hebt andere prioriteiten en (terecht) geen technische achtergrond.

Die rol heet technisch leiderschap. In grote organisaties is dat een CTO. Voor de meeste bedrijven is een fulltime CTO niet nodig en niet betaalbaar (reken op €100.000+ per jaar). Maar de behoefte aan die rol is er wel.

Wat technisch leiderschap in de praktijk betekent

Concreet doet een technisch leider drie dingen die je organisatie nu mist:

Richting geven. Welke technologie past bij onze doelen? Waar investeren we in, en waar bewust niet? Hoe zorgen we dat onze systemen meegroeien met het bedrijf? Dat is geen eenmalige exercitie, maar een doorlopend proces van keuzes maken en bijsturen.

Bewaken. Is wat de leverancier voorstelt de juiste oplossing, of hun meest winstgevende? Bouwt het team aan de juiste dingen, in de juiste volgorde? Groeit de technische schuld, of wordt die beheerst? Zonder iemand die dit bewaakt, merk je problemen pas als ze crises zijn.

Vertalen. Technische mogelijkheden en beperkingen vertalen naar taal die het management begrijpt. En bedrijfsdoelen vertalen naar technische prioriteiten die het team kan uitvoeren. Die vertaalslag is het verschil tussen een IT-afdeling die “iets met computers doet” en technologie die je bedrijf vooruit helpt.

Een fractional CTO vervult precies deze rol: strategisch meedenken en operationeel meesturen, zonder de kosten van een fulltime directielid. Typisch een tot twee dagen per week, afgestemd op wat je organisatie nodig heeft.

De kosten van niets doen

Het is verleidelijk om door te gaan zoals het gaat. De projecten lopen uit, maar ze worden uiteindelijk wel opgeleverd. De leverancier is duur, maar hij kent je systemen. De technische schuld groeit, maar het systeem draait nog.

Tot het niet meer draait. Tot de leverancier de prijs verdubbelt en je niet weg kunt. Tot je beste developer vertrekt en niemand de code begrijpt. Tot een beveiligingsincident je €270.000 kost (het gemiddelde voor het Nederlandse MKB). Tot je concurrent wel investeert in technologie en jij marktaandeel verliest.

Het probleem met technisch leiderschap is dat je het pas mist als de schade er al is. De signalen hierboven helpen je het eerder te herkennen. De vraag is wat je ermee doet.

Herken je drie of meer van deze signalen? Plan een vrijblijvend gesprek en ik help je in kaart brengen waar de grootste risico’s zitten en wat de eerste stap is.