Hoe beheer je technische schuld op organisatorisch niveau?

Question

Accepted Answer

Op organisatorisch niveau is technische schuld een **portefeuille die moet worden beheerd**, niet een backlog die moet worden opgelost. Het doel is niet nul schuld; het is schuld op een niveau houden waar dit snelheid, betrouwbaarheid of het vermogen om strategie uit te voeren niet bedreigt.

## Hoe erover nadenken

```text
MAKE DEBT VISIBLE AND PRIORITIZED
- Inventory the debt that actually hurts (slows delivery, causes incidents)
- Classify: strategic (deliberate) vs accidental vs decay/rot
- Quantify impact in business terms (velocity, downtime, churn risk)
- Allocate a steady % of capacity to paydown (commonly 15-25%)
```

Niet alle schuld is het waard om af te lossen. Schuld in een stabiel, zelden veranderd systeem kan achtergelaten worden; schuld in een heet, snel veranderend gebied moet eerst afgelost worden.

## Concreet voorbeeld

Een CTO stelt een regel in dat 20% van de capaciteit van elk team naar betrouwbaarheid en schuld gaat, en richt dit vervolgens op de drie systemen die 80% van de incidenten veroorzaken, in plaats van het overal dun uit te smeren.

## Afwegingen en valkuilen

- **Valkuil:** een "grote herschrijving" om alle schuld op te heffen, wat meestal uit de hand loopt en schuld opnieuw creëert.
- **Valkuil:** het nooit aflossen, totdat de snelheid instort.
- Schuld alleen als een technisch probleem framen faalt; koppel het aan bedrijfsresultaten om instemming te krijgen.

## Waarom het belangrijk is

Onbeheerde technische schuld accumuleert zwijgend totdat functies maanden duren en incidenten toenemen.

Het als een bewuste portefeuille beheren houdt de organisatie jarenlang snel en betrouwbaar, en verandert een abstract technisch zorgen in een gekwantificeerde zakelijke afweging waar leiding over kan nadenken.