Technical debt voelt vaak als het onbesproken familiegeheim van organisaties. Iedereen weet dat er iets speelt, maar niemand begint erover totdat er een incident is of een audit binnenkomt met een rapport dat leest als een horrorverhaal. Het gebeurt regelmatig dat IT-afdelingen proberen te signaleren dat systemen verouderd zijn, support is verlopen of hardware op zijn laatste benen loopt, maar de boodschap blijft hangen in een tunnel van jargon en interne aannames. Het resultaat is dat de business de urgentie niet voelt en IT gefrustreerd raakt, terwijl er in de praktijk wel degelijk zakelijke risico’s ontstaan die direct invloed hebben op continuïteit en innovatie.
De sleutel is niet harder roepen, maar anders communiceren. Dramatiek wekt weerstand op. Een zin als “we gaan eraan als we nu niets doen” werkt misschien goed in de technische bubbel, maar bij management klinkt het als een poging om budget af te dwingen met angst. De stap is om niet te praten over het probleem op zichzelf, maar over de impact die het heeft op wat de business wil realiseren. Dat betekent de taal verschuiven van technologie naar waarde. Stel niet “dit OS is end-of-life”, maar “het risico op onverwachte downtime neemt toe, wat direct onze leveringsbelofte aan klanten raakt.” Daarmee wordt technical debt niet gepositioneerd als een technisch defect, maar als een strategische blokkade.
Een nuttige aanpak is om scenario’s te schetsen in plaats van waarschuwingen uit te spreken. Wat gebeurt er als er niets verandert? Wat betekent uitstel voor kosten op de lange termijn? Kun je uitleggen hoe een migratie of vervanging binnen drie maanden minder kost dan reparaties onder tijdsdruk binnen een jaar? Niet als wiskundige spreadsheet, maar als begrijpelijk verhaal. Het gesprek verschuift daarmee van “dit moet” naar “zo ziet de keuze eruit.” Mensen kunnen pas verantwoordelijkheid nemen als die keuze expliciet is.
De context is belangrijker dan de code. De business hoeft niet te weten welke libraries verouderd zijn of welke serverline uit productie is. Ze moeten begrijpen dat investeren in modernisering niet alleen een technische exercitie is, maar een manier om flexibiliteit te behouden. Technical debt vertraagt nieuwe initiatieven omdat elke innovatie eerst door een achterstallige laag heen moet breken. Als innovatie gezien wordt als groeimotor, dan is technical debt een rem. Dat moet je laten zien zonder verwijtend te klinken. Niet “jullie luisteren nooit”, maar “als we dit nu aanpakken, kunnen we nieuwe diensten in weken in plaats van maanden uitrollen.”
Het gesprek gaat soepeler als je open bent over onzekerheid. Niet alles is te voorspellen. Niet elke update heeft een exact rendement. Je kunt prima zeggen dat je het niet zeker weet, dat sommige risico’s lastig te kwantificeren zijn of dat de timing afhangt van afhankelijkheden. Transparantie wekt vertrouwen. De boodschap dat uitstellen waarschijnlijk duurder is dan aanpakken, mag bestaan met nuance. “Als we nu niet kiezen kost het later dubbel” is geen dreiging, maar een economische realiteit die je kunt ondersteunen met een concreet voorbeeld uit het verleden of een geschaalde schatting.
Relevant hierbij is eigenaarschap. Technical debt is geen IT-probleem maar een organisatiekeuze. Zodra de business begrijpt dat niets doen óók een keuze is met kosten, wordt het gesprek gelijkwaardiger. Het helpt om samen af te spreken welke risico’s acceptabel zijn en welke niet, in plaats van een eenzijdig verzoek om budget. Zo ontstaat niet alleen een plan om achterstallige technologie af te bouwen, maar ook een gedeelde taal om toekomstige schuld te voorkomen.
De uitdaging is niet om mensen te overtuigen dat er een probleem is, maar om ze te betrekken bij de oplossing. Dat begint niet met ontwerpen of projectplannen, maar met gesprekken waarin IT en business elkaar vinden in gedeelde doelen. De vraag is niet “mag ik upgraden” maar “hoe beschermen we onze wendbaarheid, betrouwbaarheid en groei.” Als die vraag op tafel ligt, wordt technical debt geen verwijt, maar een agendapunt. Geen drama, maar bestuur.