Je beste expert vertrok in maart. Je voelt het in september.

Anna nam ontslag in maart. Vier jaar geleden bouwde zij je integratielaag. Ze wist welke klant een aparte instelling had, en waarom. Als er een vreemde bug opdook, was zij degene die zei: "kijk eerst eens naar de retry queue".

Je deed alles juist. Je plande overdrachtsgesprekken in. Ze schreef de deploystappen op. Ze nam een schermvideo op van het releaseproces. Op haar laatste vrijdag stond er taart, en iedereen tekende de kaart.

Alles leek in orde. Maar een vertrek voel je niet op de eerste dag zonder die persoon. De schade bouwt zich traag op.

Wat er echt met haar meeging

Martin Robillard interviewde 27 ontwikkelaars en managers bij drie softwarebedrijven. Hij vroeg wat er gebeurde nadat een collega vertrok. De mensen spraken niet over verloren procedures. Ze spraken over verloren redenen.

Niemand miste de stappen, want die stonden opgeschreven. Wat mensen misten, was het antwoord op "waarom staat dit hier?". Waarom die ene klant een andere instelling had. Waarom het team twee jaar geleden nee zei tegen een idee. Welke waarschuwing je gerust mocht negeren. Anna wist dat allemaal. Ze schreef het nooit op, omdat niemand haar ooit een vraag stelde waardoor ze het hardop moest zeggen.

De mensen uit dat onderzoek vertellen wat ze nu doen. Ze spitten oud werk door. Ze vragen rond tot ze iemand vinden die bij dat gesprek zat. Ze puzzelen de redenering opnieuw in elkaar. Het werkt, maar het gaat traag. Jouw team doet dit vandaag waarschijnlijk ook. Het staat in geen enkel rapport, want het lijkt precies op gewoon werk.

De schade komt traag, dus niemand legt het verband met het vertrek

Twee onderzoeken tonen wat dat kost. Audris Mockus zag dat de kans op een fout die een klant later meldt, stijgt wanneer er kort daarvoor mensen uit het team vertrokken. In zijn model steeg die kans met 26 procent wanneer er dubbel zoveel mensen vertrokken als normaal. Nieuwe mensen die erbij kwamen, hadden bijna geen effect. Het vertrekken is wat je geld kost.

Mathieu Nassif en Martin Robillard keken daarna hoelang dat blijft duren. In acht projecten markeerden ze het werk waarvan alle makers weg waren. In elk project was twee jaar later nog minstens een kwart van dat werk onaangeroerd. In vijf van de acht projecten was het meer dan de helft.

Dat zijn grote projecten, dus neem die cijfers niet zomaar over voor je team van twintig. Neem de les over: kennis die vertrekt, groeit niet vanzelf terug. Ze blijft liggen in de hoeken waar niemand graag aan komt.

In september meldde een klant een probleem in de integratielaag. De oplossing kostte vier dagen. Normaal was dat een halve dag geweest. Niemand schreef "Anna is in maart vertrokken" in dat ticket.

Je tweede beste medewerker wordt het nieuwe knelpunt

Er is een tweede effect, en dat komt sneller dan het eerste.

Na het vertrek van Anna gingen de moeilijke gevallen naar Tom. Hij was de volgende in lijn, dus op dat moment was dat de snelste weg. Elke keer leerde Tom er iets bij. De rest van het team leerde niets. Zes maanden later was hij de enige die de integratielaag nog kende. Zijn dagen zaten vol vragen, en het werk waarvoor je hem aannam, bleef liggen.

Nu heb je hetzelfde risico als daarvoor, bij één persoon. En die persoon is moe. Zo wordt één vertrek er twee.

Een overdracht lost dit niet op

Een overdracht legt vast wat iemand zich herinnert wanneer je het vraagt. Dat is maar een klein deel van wat die persoon weet.

De rest komt pas boven als iemand een echte vraag stelt. Anna dacht nooit uit zichzelf: "ik zou eens moeten opschrijven hoe de retry queue werkt". Ze dacht eraan op het moment dat een collega haar een foutmelding liet zien. Vier weken overdrachtsgesprekken kunnen geen drie jaar echte vragen vervangen.

Doe die overdracht dus, en doe ze goed. Begin er de eerste week na de opzeg aan. We schreven daar een apart artikel over: kennis vastleggen voor je sleutelmedewerker vertrekt. Maar zie het als schadebeperking. De kennis die je overhoudt, is de kennis die je al vastlegde toen ze nog gewoon aan het werk was.

Hoe Sarrai hiermee omgaat

Sarrai antwoordt op basis van je eigen documentatie, en ze toont de bron. Als ze twijfelt, gokt ze niet. Dan stuurt ze de vraag door naar de persoon die het wel weet.

Die persoon antwoordt één keer, zoals altijd. Daarna stelt Sarrai één vraag: mag hier een artikel van komen? Eén klik, en de volgende collega met dezelfde vraag krijgt het antwoord meteen. Je expert geeft elk antwoord één keer, en daarna kan het hele team het terugvinden.

Zo groeit je kennisbank op gewone werkdagen, vraag na vraag, terwijl je expert er nog is. Er komt geen paniek en geen gehaaste opzegperiode aan te pas. Hoe we dat aanpakken, lees je op onze pagina over beter kennisbeheer. Voor een softwarebedrijf speelt dit vooral in de technische hoeken van je product. Dat geval beschrijven we in Sarrai voor softwarebedrijven.

Wat je maandag kan doen

Begin niet met een grote documentatieronde. De kennis die telt, is net de kennis waar niemand aan denkt om naar te vragen. Zo'n ronde heeft dus dezelfde blinde vlek als een overdracht.

Meet eerst je risico. Neem je teamlijst en ga ze af, persoon per persoon. Stel bij elke naam één vraag: als deze persoon morgen vertrekt, wat gaat er trager, en wat valt helemaal stil? Schrijf het antwoord naast de naam. Doe dit ook voor de mensen die je niet als expert ziet. Daar zit soms de verrassing.

Je houdt een korte lijst over met namen waar het antwoord ongemakkelijk voelt. Die lijst is je risico. Als één naam te veel draagt, of meerdere namen, dan heb je een manier nodig om kennis bij te houden die niet afhangt van iemand die eraan denkt om ze op te schrijven. Daar dient een systeem voor kennisbeheer voor. Een geautomatiseerd systeem doet net het stuk waar mensen nooit aan toe komen.

De rekening van een vertrek komt laat. Het werk dat ze kleiner maakt, kan je alleen nu doen.