Hoe leg je technical debt uit aan een niet-technisch publiek?

Question

Accepted Answer

**Ik vertaal tech debt naar de taal die het publiek al gebruikt: geld, snelheid en risico.** Een niet-technische stakeholder geeft niet om coupling of test coverage; ze geven erom dat features trager en duurder worden om te shippen. Dus ik framet debt als een financieel en delivery-probleem, geen code-probleem.

## De framing die ik gebruik

- **De financiële metafoor, zorgvuldig gebruikt.** "We namen een shortcut om snel te shippen, zoals het afsluiten van een lening. Het werkte, en nu betalen we elke sprint rente erover. Elke nieuwe feature in dit gebied kost meer vanwege die rente." Dit landt omdat iedereen schuld en rente begrijpt.
- **Maak het concreet met hun metrieken.** Niet "de code is rommelig" maar "deze feature kostte drie weken; twee jaar geleden kostte dezelfde omvang er één. Het verschil is de onderhoudsoverhead die we hebben opgebouwd."
- **Koppel het aan uitkomsten waar ze om geven.** Tragere levering, meer bugs die klanten bereiken, lastigere onboarding voor nieuwe medewerkers, stijgend risico op een outage. Verbind debt aan omzet, reputatie en roadmap-snelheid.

## Hoe ik er een beslissing van maak, geen klacht

- Presenteer het als een **trade-off met opties**, geen eis: "We kunnen features blijven shippen in het huidige vertragende tempo, of nu twee sprints investeren om de toekomstige feature-kosten met ongeveer een derde te verlagen."
- Kwantificeer waar ik kan: verloren tijd per sprint, incidentfrequentie, het percentage capaciteit besteed aan brandjes blussen.
- Wees eerlijk dat **sommige debt prima is.** Niet alle debt moet worden afbetaald; het punt is om de debt af te betalen die de levering actief belast.

## Valkuilen

- **Jargon gebruiken** ("refactor," "coupling," "de architectuur is verkeerd"). Het laat je klinken alsof je de code wilt gold-platen.
- Het framen als engineers die schone code willen om zichzelf; dat leest als zelfingenomen.
- Wolf roepen — alles debt noemen ondermijnt geloofwaardigheid wanneer er iets werkelijk urgents opduikt.

## Waarom het belangrijk is

Als je tech debt niet in businesstermen kunt uitleggen, wordt het nooit gefinancierd, en komt het team langzaam tot stilstand terwijl het leiderschap zich afvraagt waarom de velocity daalt. Het framen als kosten, snelheid en risico is wat je de tijd geeft om het te repareren voordat het een crisis wordt.