1. Introduzione

Per attrito del personale intendiamo la perdita continua di collaboratori attraverso le uscite, volontarie o meno, e in questo articolo ciò che conta è la sua composizione, non il suo tasso. Il costo dell’attrito nell’IT è ben documentato; il momento in cui viene riconosciuto non lo è. Le stime del costo di sostituzione nella letteratura professionale vanno da circa il 90% al 200% della retribuzione annua, una volta conteggiati reclutamento, inserimento e produttività perduta. Eppure la maggior parte dei reparti IT monitora l’attrito attraverso un unico numero ritardato: il tasso di turnover annuo. Quel numero risponde alla domanda quanti se ne sono andati, non chi se n’è andato o che cosa se n’è andato con loro.

Il divario conta perché il lavoro IT concentra conoscenza tacita in poche teste. Un’integrazione legacy, un rituale di deployment non documentato, uno schema di backup da cui un solo amministratore ha mai eseguito un ripristino, o una relazione con un fornitore, vivono spesso in una o due persone. Quando quelle persone se ne vanno, il reparto non fallisce subito. Si degrada lentamente, e il degrado è invisibile alle metriche che il management legge.

Webster (2008) ha dato un nome allo schema selettivo che sta dietro a questo fenomeno: nelle grandi organizzazioni IT il personale tecnico più forte è quello che ha più probabilità di andarsene, e resta il meno mobile. Lo ha chiamato effetto Mar Morto. Il suo saggio è ampiamente citato dai professionisti, ma non è mai stato sviluppato in un modello, e dice poco su quando l’effetto diventa visibile.

Questo articolo affronta quel vuoto con una sola domanda: perché le organizzazioni IT riconoscono l’effetto Mar Morto solo dopo il punto in cui può ancora essere invertito, e che cosa consentirebbe loro di riconoscerlo prima?

Due popolazioni e un mercato. Un reparto IT ha due popolazioni tecniche che questo articolo tiene distinte dalla prima all’ultima pagina: gli ingegneri del software, che costruiscono e modificano i sistemi e il cui lavoro lascia una traccia nel controllo di versione, e gli amministratori di sistema, che gestiscono infrastruttura, reti, database, storage e operations, la cui conoscenza è procedurale e lascia traccia soprattutto nei ticket, nei turni di reperibilità e nella memoria. Entrambi i gruppi sono soggetti all’effetto Mar Morto. Non vi sono soggetti allo stesso modo: se ne vanno a ritmi diversi e per vie diverse, la loro conoscenza si perde e si recupera in modo diverso, e gli strumenti che rileverebbero la loro perdita sono diversi. Fonderli in un’unica categoria, come fanno il saggio di Webster e gran parte della letteratura professionale, nasconde esattamente le differenze che decidono quanto dura il ritardo. Dove questo articolo fornisce una cifra, un risultato o una raccomandazione, li fornisce per ciascun gruppo, e dice dove i due coincidono.

L’articolo è scritto per la situazione del mercato olandese. Quattro suoi tratti incidono direttamente sull’argomentazione e ricorrono per tutto il testo. La maggior parte dei grandi datori di lavoro olandesi e l’intero settore pubblico fissano le retribuzioni tecniche tramite contratti collettivi (CAO) con scale fisse e scatti annuali, per cui la crescita salariale di un ingegnere forte che resta è lenta e prevedibile, che è la condizione in cui le persone ad alte prestazioni se ne vanno (Sezione 2.2). Il diritto del lavoro olandese richiede per il licenziamento una verifica preventiva da parte dell’UWV o del giudice cantonale e un’indennità legale, per cui il personale che resta è difficile da spostare una volta radicato. I consigli aziendali hanno un diritto di consenso sui sistemi che monitorano il personale e sul trattamento dei dati del personale, il che vincola il modo in cui gli indicatori della Sezione 6 possono essere costruiti. E il mercato del lavoro ICT olandese è stato classificato come molto rigido nel quarto trimestre del 2024 per tutti e tre i gruppi professionali ICT che l’UWV distingue (UWV, 2025) e da allora si è raffreddato, con i posti vacanti scesi dal picco del 2023 a circa 18,900 nel secondo trimestre del 2026 mentre la disoccupazione tra i lavoratori ICT è aumentata (UWV, 2026); la ripresa dei controlli contro il falso lavoro autonomo nel gennaio 2025 ha nel frattempo ristretto la via del lavoro autonomo che entrambi i gruppi, e gli amministratori in particolare, usavano come uscita e che i datori di lavoro usavano come sostituto dell’assunzione (Minister van SZW & Staatssecretaris van Financiën, 2026). Nessuno di questi tratti è unico dei Paesi Bassi, ma la loro combinazione lo è, e l’articolo non sostiene che le sue cifre si trasferiscano immutate ad altri mercati.

L’argomentazione procede come segue. La Sezione 2 passa in rassegna l’effetto Mar Morto, la letteratura di ricerca che ne sostiene l’affermazione centrale, i costrutti vicini con cui viene spesso confuso e le due popolazioni così come il mercato olandese le presenta. La Sezione 3 individua i meccanismi che ritardano il riconoscimento. La Sezione 4 propone un modello a cinque fasi e la Sezione 5 deriva, da un modello minimo di copertura della conoscenza, sia il punto di lock-in sia la durata del ritardo. La Sezione 6 deriva gli indicatori anticipatori, la Sezione 7 segue un reparto stilizzato attraverso le cinque fasi, la Sezione 8 discute gli interventi e la Sezione 10 espone i limiti e un’agenda di ricerca empirica. L’Appendice A fornisce definizioni operative per ogni indicatore.

2. Contesto

2.1 L’effetto Mar Morto

Webster (2008) ha osservato che la distribuzione delle competenze di un grande reparto IT dovrebbe, a parità di condizioni, rispecchiare quella delle sue assunzioni, ma in pratica scivola verso il basso nel tempo. Gli ingegneri più in grado di trovare lavoro altrove se ne vanno quando incontrano disfunzioni organizzative; quelli che restano tendono a radicarsi come manutentori di sistemi critici, diventando difficili da rimuovere. Ha chiamato lo schema con il nome del Mar Morto, dove l’acqua esce solo per evaporazione e resta il sale. Webster lo ha esplicitamente presentato come una tendenza, non come una legge: non tutti quelli che restano sono «residuo», e i gruppi ben gestiti evitano del tutto lo schema. Il saggio è apparso sul suo blog come bozza di capitolo di un libro mai pubblicato, e da allora il concetto si è diffuso soprattutto attraverso i canali professionali.

2.2 Chi se ne va: la letteratura su prestazioni e turnover

L’affermazione centrale, che chi se ne va non è un campione casuale della forza lavoro, ha un sostegno empirico consistente. Jackofsky (1984) ha proposto che il turnover volontario sia curvilineo rispetto alle prestazioni: chi rende poco viene spinto fuori, chi rende molto viene attratto fuori da offerte esterne, e chi rende nella media resta. Trevor, Gerhart e Boudreau (1997) lo hanno confermato su 5,143 dipendenti di una sola azienda e hanno trovato che l’estremo della curva relativo agli alti rendimenti è guidato dalla crescita salariale: dove la crescita salariale restava indietro, il turnover tra i migliori era estremamente alto. Salamin e Hom (2005) hanno replicato la forma a U nel settore bancario svizzero. Williams e Livingstone (1994) hanno condotto una meta-analisi di 55 studi e hanno trovato che il turnover si concentra tra chi rende poco solo dove la retribuzione è legata alle prestazioni; dove non lo è, la relazione si indebolisce o scompare.

Ne seguono due implicazioni per l’IT. Primo, l’effetto Mar Morto è il ramo degli alti rendimenti di una curva ben consolidata, non una teoria popolare. Secondo, le condizioni che lo producono sono specifiche: crescita salariale piatta e debole differenziazione in base alle prestazioni, entrambe comuni nei grandi reparti IT aziendali e del settore pubblico.

2.3 Turnover funzionale e disfunzionale

Dalton, Todor e Krackhardt (1982) hanno sostenuto che un tasso di turnover grezzo è fuorviante perché combina il turnover funzionale (l’uscita di chi rende poco, che aiuta l’organizzazione) con quello disfunzionale (l’uscita di chi rende bene e avrebbe potuto essere trattenuto). La loro tassonomia anticipa il problema di misurazione centrale che questo articolo esamina: una cifra aggregata di turnover può apparire sana mentre la sua composizione è distruttiva.

2.4 Che cosa se ne va: la perdita di conoscenza

DeLong (2004) ha documentato come le organizzazioni ad alta intensità tecnologica perdano conoscenza tacita critica attraverso i pensionamenti e le uscite inattese a metà carriera, e ha mostrato che la perdita emerge di norma mesi o anni dopo l’uscita, quando si presenta una situazione che solo il dipendente uscito sapeva gestire. I lavori professionali dello stesso periodo hanno inquadrato il problema esplicitamente come attrito del personale; Kaplan (2009) e Manpower (2010) hanno entrambi riferito che una quota consistente di datori di lavoro non aveva alcun processo per raccogliere la conoscenza dei dipendenti in uscita.

2.5 Costrutti affini

L’effetto Mar Morto sta accanto a diverse idee più note, e vale la pena dire con precisione in che cosa si distingue da ciascuna.

Bus factor. Il bus factor di un sistema è il numero di persone che dovrebbero andarsene prima che il sistema non possa più essere mantenuto. La ricerca in ingegneria del software lo ha operazionalizzato a partire dalla storia del controllo di versione (Cosentino, Cánovas Izquierdo & Cabot, 2015; Avelino et al., 2016). È un’istantanea della concentrazione della conoscenza in un dato momento, e le sue misure consolidate sono costruite sul controllo di versione, che registra ciò che fanno gli ingegneri del software ma non ciò che fanno gli amministratori; l’Appendice A lo estende ai sistemi amministrati. L’effetto Mar Morto è il processo che spinge il bus factor verso il basso; il bus factor è una delle sue migliori misurazioni (Sezione 6), non una spiegazione concorrente.

Legge di Brooks. Brooks (1975) ha osservato che aggiungere persone a un progetto software in ritardo lo ritarda ulteriormente, perché il costo di inserimento e di comunicazione supera la capacità aggiunta. La legge riguarda un progetto in difficoltà di tempo. La Sezione 8 generalizza il meccanismo a un team in difficoltà di composizione: un team che ha perso i suoi membri più forti manca della capacità di inserire nuove persone, per cui aggiungerne fallisce per la stessa ragione, in modo permanente anziché per la durata di un progetto.

Turnover funzionale e disfunzionale. Dalton et al. (1982) hanno fornito la tassonomia; l’effetto Mar Morto è il caso in cui il turnover è sistematicamente disfunzionale e la cifra aggregata lo nasconde. Il contributo qui è l’argomentazione temporale: perché l’organizzazione viene a sapere della disfunzione in ritardo.

Oblio organizzativo. De Holan e Phillips (2004) distinguono l’oblio intenzionale da quello accidentale e, all’interno del secondo, la mancata acquisizione di nuova conoscenza dal decadimento della conoscenza già posseduta. La perdita di conoscenza per attrito è decadimento accidentale. L’effetto Mar Morto aggiunge a questa letteratura un meccanismo di selezione: non è una conoscenza casuale a decadere ma, in misura sproporzionata, la conoscenza detenuta da chi è più in grado di andarsene.

Capacità di assorbimento. Cohen e Levinthal (1990) hanno sostenuto che la capacità di un’organizzazione di riconoscere, assimilare e applicare nuova conoscenza dipende dalla conoscenza affine che già possiede. Il meccanismo della Sezione 3.5 è la capacità di assorbimento applicata alle persone anziché alle informazioni: la capacità di un team di trattenere un’assunzione forte dipende dai colleghi forti già presenti. Nella Sezione 5 ciò compare come il semplice fatto che il trasferimento di conoscenza ha bisogno di una fonte: una volta che non resta nessuno che conosca un sistema, nessuno può più insegnarlo.

Teoria del turnover. Un secolo di ricerca sul turnover (Hom et al., 2017) si è concentrato sugli antecedenti a livello individuale: perché una data persona decide di andarsene. Nyberg (2010) mostra che per chi rende molto la crescita retributiva e la velocità di promozione moderano quella decisione. Il presente articolo assume i risultati a livello individuale come dati e pone una domanda a livello di team: che cosa fa la sequenza di tali decisioni alla composizione di ciò che resta, e quando qualcuno se ne accorge.

2.6 Due popolazioni, due mercati del lavoro

La letteratura su prestazioni e turnover tratta i dipendenti come un’unica popolazione classificata per prestazioni. Per l’argomentazione qui svolta il personale tecnico di un reparto IT va diviso in due, perché l’effetto Mar Morto agisce attraverso tre cose che differiscono sistematicamente tra ingegneri del software e amministratori di sistema: la forma che assume la loro conoscenza, la via per cui se ne vanno e la traccia che lasciano dietro di sé ai fini della misurazione.

Conoscenza. La conoscenza degli ingegneri è in parte codificata negli artefatti che producono. Codice, test, schemi e pipeline sopravvivono al loro autore, mal documentati ma leggibili. La conoscenza degli amministratori è procedurale: come eseguire il failover di un cluster, in quale ordine riavviare i servizi, qual è la dipendenza non documentata tra il firewall e la finestra batch, perché il ripristino va fatto dalla seconda snapshot più vecchia. Si acquisisce facendo e si conserva nella memoria, e si esercita su sistemi il cui guasto ferma l’intera azienda anziché una sola funzione. Nei termini della Sezione 5, un amministratore forte è più difficile da sostituire con un’assunzione forte di quanto lo sia un ingegnere forte, perché c’è meno da leggere e più da farsi mostrare.

Vie di uscita nel mercato olandese. Nel quarto trimestre del 2024 l’UWV ha classificato tutti e tre i gruppi professionali ICT che distingue, sviluppatori di software e applicazioni, specialisti di database e reti, e supporto agli utenti ICT, come esposti a un mercato del lavoro molto rigido (UWV, 2025); da allora il mercato si è raffreddato, con i posti vacanti ICT in calo costante dal 2023 e il numero di lavoratori ICT con indennità di disoccupazione salito a circa 6,400 nel luglio 2026, in parte per le riorganizzazioni nel settore bancario (UWV, 2026). All’interno di questo quadro comune i due gruppi escono da porte diverse. Gli ingegneri forti di un reparto IT aziendale sono attratti dalle aziende di prodotto software, dalle scale-up e dalle società di consulenza, dove la retribuzione è fissata dal mercato anziché da una scala CAO e dove il lavoro consiste nel costruire anziché nel mantenere. Gli amministratori forti sono attratti dai fornitori di servizi gestiti, dalle aziende di cloud e hosting e, fino a poco tempo fa, dal lavoro autonomo: la via zzp è stata per anni il modo standard con cui un amministratore olandese esperto raddoppiava il proprio reddito facendo lo stesso lavoro per lo stesso datore di lavoro. La revoca della moratoria sui controlli il 1° gennaio 2025 ha reso i committenti cauti nell’ingaggiare liberi professionisti per ruoli integrati (Minister van SZW & Staatssecretaris van Financiën, 2026), il che ha chiuso in parte quella porta e, come discute la Sezione 8, ha chiuso allo stesso tempo parte della via di fuga del datore di lavoro.

Il lato che resta. Il contesto istituzionale olandese modella anche chi rimane. Le scale CAO con scatti annuali fanno sì che un ingegnere o un amministratore forte che resta raggiunga il vertice della propria scala in pochi anni e poi non veda più alcuna crescita, esattamente la condizione in cui Trevor et al. (1997) trovano che il turnover degli alti rendimenti è estremamente alto. La tutela contro il licenziamento fa sì che il personale che si è radicato non possa essere spostato facilmente; la verifica preventiva e l’indennità di transizione prevista per legge rendono il residuo della metafora di Webster un fatto durevole anziché una scelta di gestione. Entrambi i tratti valgono per entrambi i gruppi. La differenza è che un amministratore radicato detiene le password di root e i turni di reperibilità, per cui il radicamento è operativo oltre che organizzativo.

Traccia. Infine, i due gruppi differiscono in ciò che lasciano dietro di sé ai fini della misurazione. Ogni modifica che un ingegnere apporta è attribuita nel controllo di versione, per cui la concentrazione della conoscenza può essere calcolata dalla storia (Appendice A). Il lavoro di un amministratore è attribuito, se lo è, nei ticket di cambiamento, nei registri degli incidenti e nei turni di reperibilità, che sono più scarni, tenuti con meno costanza e spesso registrano chi ha aperto il ticket anziché chi ha fatto il lavoro. La conseguenza pratica attraversa il resto dell’articolo: l’effetto è più difficile da vedere per gli amministratori, e gli indicatori per loro devono poggiare più sul chiedere e meno sul calcolare.

Nel loro insieme, queste letterature stabiliscono chi se ne va, che cosa se ne va e quali idee vicine sono già in uso, e questa sezione ha esposto perché le due popolazioni vanno seguite separatamente. Nessuna parte della letteratura affronta quando l’organizzazione lo scopre. Questo è il contributo delle sezioni seguenti.

3. Perché l’effetto è ritardato

L’effetto Mar Morto è ritardato perché ogni segnale che il management riceve è neutro o falsamente rassicurante finché il danno non è strutturale. Nashua individua sei meccanismi. Non sono indipendenti; insieme formano un sistema di misurazione cieco proprio alla variabile che conta.

3.1 L’organico cala, ma lentamente. L’attrito viene compensato solo in parte da nuove assunzioni, per cui l’organico scivola verso il basso anziché crollare. Un reparto che perde tre ingegneri e ne assume due riporta una perdita netta di uno, una cifra abbastanza piccola da essere assorbita nel ciclo di bilancio o letta come efficienza. Il tasso di turnover, l’unica metrica di attrito che la maggior parte dei responsabili IT vede, è un conteggio. Non può distinguere l’uscita della persona che capiva l’integrazione della fatturazione dall’uscita di qualcuno sostituibile in una settimana, e un conteggio che si riduce lentamente nasconde il fatto che ciò che se n’è andato era in misura sproporzionata la parte alta della distribuzione. Dalton et al. (1982) hanno fatto questa osservazione in generale; nell’IT, dove la competenza varia di un ordine di grandezza tra individui, il mascheramento è estremo. Per gli amministratori c’è una maschera ulteriore: una quota maggiore delle loro uscite assume la forma di pensionamenti programmati o di trasferimenti interni a un ruolo di service management, che nessuna metrica di turnover conta come perdita.

3.2 I sistemi continuano a funzionare. Il software in produzione non si ferma quando il suo autore se ne va. Il vuoto di conoscenza diventa visibile solo quando il sistema deve cambiare o si guasta, il che può accadere mesi o anni dopo (DeLong, 2004). Fino ad allora il reparto sembra consegnare come prima. Per i sistemi amministrati il punto è ancora più netto: un backup da cui non si è mai eseguito un ripristino, un rinnovo di certificato fatto a mano una volta l’anno, un insieme di regole del firewall che nessun altro ha letto, continuano tutti a funzionare fino al giorno in cui non lo fanno più, e quel giorno può arrivare anni dopo l’uscita della persona che li capiva. La stabilità operativa viene letta come salute organizzativa quando in realtà è inerzia. Per gli ingegneri la latenza è fissata dal calendario dei cambiamenti: il vuoto si manifesta quando il sistema deve cambiare la volta successiva. Per gli amministratori è fissata dal calendario dei guasti: il vuoto si manifesta quando il sistema si rompe la volta successiva, il che è più raro e più tardivo.

3.3 Il radicamento del residuo sembra lealtà. Webster ha notato che chi resta tende ad assumersi le responsabilità che nessun altro vuole e a diventare esperto di manutenzione dei sistemi critici. Dalla poltrona del management ciò si legge come impegno e basso rischio: sono le persone che conoscono i sistemi e non se ne vanno mai. La dipendenza dell’organizzazione da loro cresce esattamente mentre si riduce la sua capacità di valutarli, perché le persone che avrebbero potuto giudicare il loro lavoro se ne sono andate. Per gli amministratori il radicamento è letterale oltre che organizzativo: l’amministratore rimasto detiene gli account privilegiati, i contatti con i fornitori e i turni di reperibilità, e secondo il diritto del lavoro olandese non è comunque facilmente spostabile. Per gli ingegneri assume la forma della proprietà esclusiva di sistemi che nessun altro sa costruire.

3.4 Sopravvivenza nella rendicontazione. Le informazioni sulla qualità dell’ingegneria risalgono verso l’alto attraverso gli ingegneri. Dopo l’uscita degli ingegneri più forti, le persone che riferiscono sullo stato dei sistemi, del backlog e del team sono quelle rimaste, che non hanno alcun incentivo e spesso alcun punto di riferimento per segnalare il declino. I colloqui di uscita, l’unico canale che raccoglie il punto di vista di chi se ne va, sono di norma condotti dalle risorse umane, aggregati e letti come lamentele individuali anziché come uno schema. La sopravvivenza è peggiore per gli amministratori, il cui canale di rendicontazione è la dashboard degli incidenti e della disponibilità: un team operativo che ha perso le persone migliori riporta verde fino al giorno in cui riporta rosso.

3.5 Il feedback dalle assunzioni arriva tardi e viene attribuito male. Quando il reparto prova infine a coprire i vuoti con assunzioni forti, accadono due cose. I candidati forti notano l’ambiente durante i colloqui o nei primi mesi e se ne vanno di nuovo, producendo attrito precoce. Quelli che restano vengono assorbiti nel modo di lavorare del residuo. Il management attribuisce di norma tutto questo a un mercato del lavoro rigido o a un reclutamento scadente, non allo stato del team in cui i nuovi assunti entrano. I due gruppi falliscono qui in modo diverso. Gli ingegneri forti vengono trovati e poi persi: accettano, vedono l’ambiente e se ne vanno entro l’anno. Gli amministratori forti più spesso non vengono trovati affatto: il bacino olandese è più sottile, i più forti sono già presso i fornitori di servizi o erano lavoratori autonomi, e la posizione resta aperta per mesi, il che il management legge come un segnale di mercato anziché come un segnale di composizione.

3.6 Il circuito di retroazione si autoalimenta. Ogni uscita di un ingegnere capace rende l’ambiente meno attraente per il successivo, aumenta il carico su chi resta e abbassa l’asticella di qualità rispetto alla quale i nuovi assunti vengono giudicati. L’effetto accelera mentre ogni indicatore che il management legge sembra tollerabile. Quando le metriche di delivery si muovono, il reparto ha già superato quello che chiamiamo punto di lock-in: lo stato in cui il team rimasto non è più in grado di assorbire o trattenere un’assunzione forte.

Il ritardo, dunque, non è una mancanza di attenzione. È il prodotto prevedibile del misurare l’attrito come conteggio, del leggere la stabilità come salute e dell’affidarsi ai sopravvissuti per le informazioni su ciò che si è perso.

La Figura 1 disegna i sei meccanismi come due circuiti di rinforzo e segna dove sono collegati gli strumenti dell’organizzazione. Entrambi i circuiti passano per l’uscita degli ingegneri forti. Il primo (R1) passa per il carico di lavoro: ogni uscita aumenta il carico su chi resta e riduce l’attrattiva del restare. Il secondo (R2) passa per la valutazione: ogni uscita toglie qualcuno in grado di giudicare il lavoro e di inserire i nuovi arrivati, il che abbassa l’asticella di qualità e fa andare via presto la successiva assunzione forte. Gli strumenti che il management legge, tasso di turnover, organico e metriche di delivery, sono collegati alla periferia dei circuiti, nei punti che si muovono per ultimi. Le variabili al centro, la quota di ingegneri forti e la concentrazione della conoscenza, non hanno alcuno strumento collegato.

4. Un modello a stadi dell’effetto Mar Morto ritardato

I meccanismi della Sezione 3 si dispiegano in una sequenza riconoscibile. Noi di Nashua la descriviamo come cinque fasi, distinte in base al divario tra ciò che il management osserva e ciò che accade nel team (Figura 2). Le fasi sono ordinate, non temporizzate: la durata di ciascuna dipende dall’organizzazione, e deliberatamente non attribuiamo loro alcuna durata.

La Fase 4 è il perno. Prima di essa il reparto può ancora recuperare con le ordinarie misure di retention e di assunzione. Dopo di essa, le norme, il carico e i vuoti di conoscenza del team rimasto impediscono alle assunzioni forti di attecchire, per cui le stesse misure falliscono e vengono lette erroneamente come un problema di mercato. Il primo segnale inequivocabile per il management (Fase 5) arriva un’intera fase dopo l’ultimo punto in cui un intervento convenzionale avrebbe funzionato.

I due gruppi attraversano le stesse cinque fasi ma mostrano in ciascuna firme diverse, e il ritardo tra ciò che accade e ciò che si vede è più lungo per gli amministratori in ogni fase (Tabella 1). La differenza è massima nelle Fasi 2 e 5. Nella Fase 2 la concentrazione della conoscenza di un team di ingegneria è almeno visibile nel controllo di versione a chiunque guardi; quella di un team operativo è visibile solo al team. Nella Fase 5 un team di ingegneria fallisce su un cambiamento, che è pianificato e quindi si vede arrivare; un team operativo fallisce su un incidente, che non lo è.

Il modello avanza due affermazioni verificabili. Primo, il punto di lock-in esiste ed è identificabile: per ogni sistema critico è il momento in cui non resta nessuno in grado di modificarlo o ripristinarlo, dopo il quale la conoscenza può essere ricostruita solo dagli artefatti, se ce ne sono. Secondo, gli indicatori osservabili nella colonna sinistra della Figura 2 restano entro limiti tollerabili fino alla Fase 5, mentre le proprietà misurabili del team nella colonna destra (concentrazione della conoscenza, qualità delle uscite, attrito dei neoassunti) si muovono dalla Fase 1 in poi. La Sezione 5 mostra che entrambe seguono da un modello con una sola variabile di stato.

5. Una trattazione formale

Il modello a stadi è verbale. Per verificare che il ritardo sia una conseguenza dei meccanismi e non un espediente retorico, scriviamo il modello più piccolo che li contiene. Ha una sola variabile di stato, il bus factor di un sistema critico, e quattro tassi. Tutto ciò che l’articolo misura (Sezione 6) e tutto ciò su cui ruota il caso (Sezione 7) si può leggere direttamente da esso, e la differenza tra i due gruppi entra come differenza in che cosa è la conoscenza e in come se ne osserva la perdita, non come differenza nei parametri scelti per adattarsi ai dati.

5.1 Impostazione

Si consideri un sistema critico e sia $k(t)$ il numero di persone in grado di modificarlo o ripristinarlo: il suo bus factor. A $k$ accadono quattro cose, ciascuna legata a un meccanismo della Sezione 3.

1. Uscita. Ogni conoscitore se ne va con hazard $\lambda$ all’anno e porta con sé la conoscenza: $k \to k-1$ a tasso $\lambda k$. Questo è l’effetto Mar Morto in sé; $\lambda$ è l’hazard di uscita delle persone che detengono conoscenza critica, che sono, per l’argomentazione di Webster e la Sezione 2.2, le più forti.

2. Trasferimento. Ogni conoscitore forma un collega a tasso $\tau$ all’anno: $k \to k+1$ a tasso $\tau k$. Il trasferimento ha bisogno di una fonte. Quando $k = 0$ non c’è nessuno da cui imparare, che è il punto di lock-in della Sezione 4, ora esatto: un sistema è in lock-in quando il suo bus factor raggiunge zero, perché da quello stato il trasferimento interno è impossibile.

3. Ricostruzione dagli artefatti. Quando $k = 0$, un nuovo arrivato può ricostruire la conoscenza da ciò che il sistema ha lasciato dietro di sé, a tasso $\alpha$. Per il software, codice, test e schemi rendono $\alpha$ apprezzabile; per i sistemi amministrati, la cui conoscenza è procedurale, $\alpha$ è vicino a zero. Questa è l’unica differenza strutturale tra i gruppi.

4. Osservazione. Il sistema viene colpito, a tasso $\mu$ all’anno, da un evento che richiede conoscenza profonda: una richiesta di cambiamento che ne tocca gli interni, o un incidente che richiede più di un riavvio. Se $k = 0$ quando l’evento arriva, il guasto è visibile al management; altrimenti viene assorbito e non si vede nulla. Per gli ingegneri $\mu$ è il tasso dei cambiamenti profondi, per gli amministratori il tasso degli incidenti profondi, e il secondo è più basso.

Solo i primi tre tassi muovono $k$; il quarto decide quando il management lo scopre. Con $\alpha = 0$ il processo è un processo lineare di nascita e morte, e la probabilità che un sistema con $k_0$ conoscitori abbia raggiunto zero entro il tempo $t$ ha una forma chiusa,

e, una volta a zero, il tempo atteso prima che il management veda un guasto è semplicemente

L’equazione (1) dice che un sistema con un proprietario unico ($k_0 = 1$) viene perso con probabilità $\lambda(1-e^{-(\lambda-\tau)t})/(\lambda - \tau e^{-(\lambda-\tau)t})$, che sale verso uno ogni volta che le uscite superano il trasferimento; un sistema con due conoscitori viene perso con il quadrato di quel valore, ed è per questo che l’indicatore della Fase 2 nella Sezione 6 è il conteggio dei sistemi a bus factor uno. L’equazione (2) è il ritardo del titolo dell’articolo in un solo simbolo: il divario tra la perdita e il suo riconoscimento è fissato dalla frequenza con cui la conoscenza perduta serve, e da null’altro. Un reparto può accorciarlo solo avendo bisogno della conoscenza di proposito, che è esattamente ciò che un test di disaster recovery è.

5.2 Risultato: prima la perdita, poi il riconoscimento, e ancora più tardi per gli amministratori

La Tabella 2 fornisce tassi illustrativi per i due gruppi e la copertura iniziale del reparto del caso della Sezione 7: dodici sistemi critici di ingegneria, tre dei quali con un proprietario unico, e otto sistemi amministrati, uno dei quali con un proprietario unico. I valori sono scelti per essere tondi e per rispettare tre ordinamenti argomentati nella Sezione 2.6: gli ingegneri forti se ne vanno più in fretta degli amministratori forti; il codice può essere letto dopo l’uscita del suo autore ma una procedura no; e un cambiamento che richiede conoscenza profonda di un dato sistema arriva più spesso di un incidente che la richiede. La Figura 3 mostra ciò che ne segue, dalla forma chiusa per $\alpha = 0$ e dalla simulazione negli altri casi.

Il pannello A è il quadro della Fase 2. La copertura si erode dal primo anno in entrambi i gruppi, e la quota di sistemi con un proprietario unico, l’indicatore che una dashboard di composizione mostrerebbe, supera la metà dopo 0.9 anni per gli ingegneri e 1.8 anni per gli amministratori. La quota senza più nessuno sale più lentamente, e qui i gruppi si incrociano: gli ingegneri perdono sistemi fino a zero più in fretta ma ne recuperano alcuni dal codice, per cui la loro curva si appiattisce a circa tre sistemi su dieci; gli amministratori perdono più lentamente ma, non avendo nulla da cui ricostruire, continuano a perdere, e dal quarto anno hanno più sistemi a zero degli ingegneri.

Il pannello B è il quadro della Fase 5, e l’affermazione centrale dell’articolo in una sola figura. Per gli ingegneri il tempo mediano fino al primo sistema a copertura zero è 0.6 anni e il tempo mediano fino al primo guasto visibile è 1.5 anni: un ritardo di riconoscimento di 0.9 anni, durante i quali la dashboard di composizione avrebbe mostrato la perdita e la dashboard di gestione non avrebbe mostrato nulla. Per gli amministratori il primo zero arriva a 1.4 anni e il primo guasto visibile a 3.0: un ritardo di 1.6 anni, e un guasto visibile che arriva un anno e mezzo dopo quello degli ingegneri. L’erosione più lenta degli amministratori, che li fa sembrare il gruppo stabile, è esattamente ciò che rende il loro guasto più tardivo, e il loro tasso di osservazione più basso è ciò che lo rende ancora più tardivo.

Dal modello seguono altri tre risultati che hanno rilievo per la Sezione 8.

1. Il trasferimento protegge lo stock, non i proprietari unici. Raddoppiare il tasso di trasferimento $\tau$ rallenta l’erosione della copertura del reparto (la soglia della metà si sposta in avanti di un anno o più), ma sposta appena il tempo fino al primo zero, perché un sistema con un solo proprietario è in una corsa tra un’uscita e un passaggio di consegne, qualunque sia la media del reparto. La distribuzione della conoscenza funziona nella Fase 2, sui sistemi che hanno ancora due o più conoscitori; non può salvare i sistemi già a uno.

2. La retention guadagna tempo ovunque, ma meno di quanto si spererebbe. Ridurre di un quinto l’hazard di uscita sposta ogni traguardo in avanti di due-dieci mesi. Non cambia la forma delle curve e, in particolare, non cambia il ritardo di riconoscimento, che dipende da $\mu$ soltanto.

3. L’osservazione è una leva, e solo gli amministratori ne hanno bisogno. Eseguire un test di disaster recovery su ciascun sistema amministrato una volta l’anno porta il loro $\mu$ effettivo da 0.4 a 1.4. Non rallenta la perdita di un solo giorno, ma riduce il ritardo di riconoscimento mediano da 1.6 anni a 0.7, per cui il team operativo viene a sapere del suo primo sistema perduto nell’anno 2.0 anziché nell’anno 3.0, quando c’è ancora tempo per agire sugli altri (linea tratto-punto nella Figura 3B). Gli ingegneri non hanno bisogno di questa leva, perché il calendario dei cambiamenti mette alla prova i loro sistemi al posto loro.

La Tabella 3 raccoglie questi risultati.

5.3 Che cosa il modello non afferma

Il modello è uno schizzo, non una calibrazione. I tassi sono scelti per essere tondi e ordinati correttamente, non stimati; i sistemi sono trattati come indipendenti, mentre in un reparto reale le stesse persone ne possiedono diversi e una sola uscita ne svuota più di uno; e «conosce il sistema» è binario dove la competenza non lo è. Ciò che il modello stabilisce non dipende dai valori. Dato che i conoscitori se ne vanno, che il trasferimento ha bisogno di una fonte e che la conoscenza perduta serve solo occasionalmente, tre cose seguono per qualsiasi valore: la perdita precede il suo riconoscimento di un divario la cui durata attesa è l’inverso della frequenza con cui la conoscenza serve; i sistemi con un proprietario unico sono quelli che si perdono, per cui il loro conteggio è l’indicatore anticipatore; e un gruppo la cui conoscenza è procedurale e i cui guasti sono incidenti anziché cambiamenti verrà riconosciuto più tardi di uno la cui conoscenza sta negli artefatti e i cui guasti stanno sul calendario dei cambiamenti. Il contesto olandese entra attraverso $\lambda$, che la scala CAO innalza per i più forti e che il diritto del licenziamento non fa nulla per abbassare per gli altri, e attraverso la recente chiusura della via del lavoro autonomo, che ha tolto l’unico modo che un datore di lavoro aveva di riportare $k$ a uno dopo che aveva raggiunto zero.

6. Indicatori di allerta precoce

Se il modello regge, il reparto dovrebbe smettere di guardare il tasso di turnover e cominciare a guardare la composizione e le conseguenze delle uscite. Ogni indicatore della Tabella 4 corrisponde a un meccanismo della Sezione 3 e si muove nella fase indicata, ben prima delle metriche di delivery.

Gli indicatori sono gli stessi per entrambi i gruppi; le loro fonti e la loro affidabilità non lo sono (Tabella 2). Per gli ingegneri i due indicatori di composizione che contano di più nella Fase 2, bus factor e concentrazione della conoscenza, possono essere calcolati dalla storia del controllo di versione senza chiedere nulla a nessuno. Per gli amministratori vanno assemblati dai registri dei cambiamenti e degli incidenti e confermati chiedendo, il che li rende al tempo stesso più costosi e più facilmente elusi. Per contro, gli indicatori della Fase 1 sono più difficili per gli ingegneri sotto un aspetto: una quota maggiore delle loro uscite va verso datori di lavoro che pagano secondo il mercato, per cui il divario dell’offerta in uscita è informativo, mentre per gli amministratori pensionamenti e trasferimenti lo diluiscono e la domanda sulle perdite rimpiante va posta su uscite che il tasso di turnover non conta affatto.

Le definizioni operative, le fonti dei dati e le insidie note di ciascun indicatore sono riportate nell’Appendice A. Tre osservazioni sull’insieme. Primo, la maggior parte degli indicatori è economica: diversi richiedono solo un taglio diverso dei dati che le risorse umane già possiedono. Secondo, gli indicatori delle fasi 1 e 2 sono quelli che contano, poiché alla fase 4 il punto di lock-in è già stato raggiunto. Terzo, gli indicatori sono di composizione, non aggregati: chiedono chi e che cosa, non quanti. È il cambiamento che Dalton et al. (1982) invocavano quattro decenni fa e che la rendicontazione del management IT in larga parte non ha compiuto.

7. Un caso costruito

Il caso che segue è costruito, non osservato. Esiste per mostrare come appaiono le cinque fasi dall’interno di un’organizzazione e per dare al modello della Sezione 5 un’ambientazione concreta. Non è un resoconto su alcun datore di lavoro, e le sue cifre sono illustrative anziché misurate; il suo valore sta nel fatto che ogni evento in esso è uno che chi ha lavorato nell’IT aziendale riconoscerà.

7.1 Ambientazione

Il Dipartimento R è il reparto IT interno di un’azienda manifatturiera olandese di medie dimensioni. Nell’anno 0 ha 60 dipendenti tecnici: 36 ingegneri del software in tre team (integrazione ERP, sistemi di logistica e magazzino, una piattaforma dati) e 24 amministratori di sistema in due (infrastruttura e rete; database, storage e postazioni di lavoro). Mantiene circa venti sistemi in produzione che l’azienda considera critici, dodici di proprietà dei team di ingegneria e otto delle operations. Il turnover si è attestato per un decennio tra il 10 e il 13% l’anno, in linea con gli altri reparti dell’azienda. La retribuzione segue il CAO aziendale: scale fisse con scatti annuali, per cui un ingegnere senior e un amministratore senior che restano raggiungono il vertice della propria scala entro quattro o cinque anni e poi non vedono più alcuna crescita. Le valutazioni delle prestazioni esistono ma non hanno alcun effetto sulla retribuzione. Diversi amministratori hanno più di cinquant’anni.

7.2 I sei anni

La Tabella 6 riassume ciò che la dashboard di gestione del reparto ha mostrato in ciascun anno e ciò che una dashboard di composizione, se fosse esistita, avrebbe mostrato. Le fasi della Figura 2 sono indicate.

I due gruppi attraversano le fasi sfasati, gli ingegneri circa una fase avanti per tutto il percorso, e il management del reparto vede una crisi dove ce ne sono due. La cronologia è un percorso plausibile attraverso il modello della Sezione 5 ai parametri della Tabella 2: gli ingegneri del Dipartimento R vedono il loro primo guasto nell’anno 5, ben oltre la mediana del modello di 1.5 anni, e i suoi amministratori nell’anno 6, il doppio della mediana di 3.0. Nell’anno 1 due degli ingegneri più forti del reparto se ne vanno a quattro mesi di distanza l’uno dall’altro. Ogni uscita ha la propria spiegazione e ciascuna viene accettata nei suoi termini; nessuno si chiede che cosa abbiano in comune. Entrambi erano nel quartile superiore delle prestazioni, entrambi erano nella stessa fascia retributiva da quattro anni ed entrambi se ne sono andati per un aumento di circa un quarto. Il tasso di turnover sale di un punto percentuale.

L’anno 2 è tranquillo. L’organico è sceso di uno, il turnover è tornato nel range e i sistemi costruiti dai due usciti continuano a funzionare. I sistemi che possedevano vengono riassegnati all’unico ingegnere senior rimasto nel team di integrazione, che ne possiede già altri tre. Sul lato delle operations l’anno sembra ancora più tranquillo. L’amministratore senior dello storage va in pensione nei tempi previsti, un’uscita che nessuno rimpiange perché era pianificata; le procedure di backup e ripristino che ha eseguito a mano per quindici anni vengono passate all’amministratore di rete in una riunione di due ore, e non vengono mai esercitate. L’amministratore di rete senior si dimette per mettersi in proprio e viene riassunto il lunedì seguente a tariffa giornaliera per lo stesso lavoro, che il reparto contabilizza come un risparmio di organico e l’amministratore come un raddoppio del reddito; nessuno dei due compare nella cifra del turnover come perdita rimpianta. Due sostituzioni in ingegneria vengono fatte a livello junior, perché il budget consente due junior o un senior e due sembrano più sicuri. Il numero di sistemi critici con una sola persona competente sale da sei a otto sul lato ingegneria e da uno a quattro sul lato operations.

L’anno 3 sembra, dalla dashboard, l’anno migliore del periodo. Il turnover è il più basso in cinque anni perché le persone che se ne sarebbero andate se ne sono già andate. Il nucleo di lunga anzianità viene elogiato nella revisione annuale per la stabilità. Un ingegnere senior viene assunto nel team della piattaforma dati e se ne va dopo sette mesi, citando l’impossibilità di far cambiare alcunché; il colloquio di uscita viene archiviato sotto «compatibilità culturale». Nessuno fuori dal reparto ne ha rivisto l’architettura da quando l’architetto dell’integrazione se n’è andato. A gennaio l’ufficio legale dell’azienda, in risposta alla ripresa dei controlli sulla Wet DBA, chiude il contratto dell’amministratore di rete autonomo; questi rifiuta un’offerta di rientro a uno stipendio CAO pari a circa la metà della sua tariffa giornaliera, e il parco firewall che lui solo capiva passa a un collega che non vi ha mai modificato una regola. Nessun test di disaster recovery è stato eseguito da due anni; la disponibilità è al 99.9% e il team operativo viene additato come modello di stabilità.

Nell’anno 4 il management si accorge che assumere è difficile, e se ne accorge prima per gli ingegneri. Tre ingegneri senior vengono assunti; due se ne vanno entro l’anno. La spiegazione offerta e accettata è il mercato del lavoro, e viene ingaggiato un recruiter esterno. Dentro il reparto, ai due che se ne sono andati era stato affidato a ciascuno un sistema che nessun altro capiva, senza nessuno in grado di rivedere il loro lavoro o rispondere alle loro domande. I team di ingegneria hanno superato il punto di lock-in: non riescono più a trattenere le persone che potrebbero invertire il loro declino. I team operativi mostrano la stessa fase in modo diverso. Una posizione di amministratore senior resta aperta tutto l’anno; due candidati rifiutano l’offerta, uno accetta e si ritira prima di iniziare dopo una conversazione con il team. Poiché nessuno viene assunto, nessuno se ne va presto, e la posizione vacante compare nel report di reclutamento come problema di mercato anziché in una qualsiasi cifra di attrito.

Nell’anno 5 il declino degli ingegneri diventa visibile. L’aggiornamento ERP, che dipende dal livello di integrazione il cui architetto se n’è andato quattro anni prima, slitta di nove mesi. Una richiesta di cambiamento sul motore di pricing non può essere pianificata perché l’unico ingegnere in grado di modificarlo è quello che porta altri sei sistemi. La questione arriva al consiglio di amministrazione, al quale viene detto che il reparto ha un problema di attrito. Il problema di attrito ha quattro anni; ciò che è cambiato è che ha finalmente prodotto un segnale che il management legge. I team operativi, la cui cifra di disponibilità è ancora al 99.8%, non fanno parte della conversazione.

L’anno 6 porta la risoluzione predefinita della Sezione 8 per gli ingegneri: il lavoro di cambiamento passa a un fornitore, il team di ingegneria interno si riduce, e il costo del fornitore supera di un ordine di grandezza ciò che un budget di retention differenziato nell’anno 1 sarebbe costato. Porta anche la Fase 5 dei team operativi, un anno indietro. Durante una migrazione dello storage il database del magazzino deve essere ripristinato; il ripristino fallisce, perché la procedura lasciata dall’amministratore dello storage quattro anni prima descrive un array sostituito tre anni prima, e l’unica persona che avesse mai eseguito un ripristino sul nuovo array era l’amministratore di rete autonomo il cui contratto era stato chiuso nell’anno 3. Il magazzino resta fermo per due giorni. Al consiglio di amministrazione, che pensava di aver affrontato il problema di attrito l’anno prima, viene detto che ne ha un secondo.

7.3 Il controfattuale

Si supponga che il Dipartimento R avesse utilizzato la dashboard di composizione della Sezione 8 dall’anno 0, con i livelli di soglia lì proposti, separatamente per i due gruppi. Il tasso di perdite rimpiante del 60% nell’anno 1 avrebbe superato la soglia di un terzo nel primo trimestre dopo la seconda uscita, imponendo una revisione congiunta da parte della direzione ingegneria e delle risorse umane di ciò che i due usciti avevano in comune. La revisione avrebbe trovato il divario dell’offerta in uscita e la fascia retributiva comune, e l’intervento più economico disponibile a quel punto, un adeguamento di retention per gli ingegneri del quartile superiore rimasti, sarebbe costato circa un decimo di una sostituzione senior. Se sarebbe stato approvato è una questione separata; il punto è che la decisione sarebbe stata sottoposta a qualcuno nell’anno 1 anziché nell’anno 5.

Se la prima soglia fosse stata ignorata, il conteggio dei bus factor avrebbe superato la soglia di un quarto nell’anno 2, momento in cui la distribuzione forzata della conoscenza sugli undici sistemi a proprietario unico era ancora possibile, perché i proprietari unici erano ancora lì. Entro l’anno 3 l’assunzione senior andata via dopo sette mesi si sarebbe registrata come attrito dei neoassunti del 50% in una coorte di due, una cifra abbastanza piccola da far dubitare ma abbastanza grande da sollevare la domanda sul perché il reparto non fosse riuscito a trattenerlo. Sul lato delle operations le soglie sarebbero scattate più tardi e più silenziosamente: la domanda sulle perdite rimpiante, posta sul pensionamento e sull’uscita verso il lavoro autonomo nell’anno 2, avrebbe portato i team operativi al 100% di perdite rimpiante in un anno in cui la cifra del turnover non mostrava nulla; la soglia di un quarto sul bus factor sarebbe scattata lo stesso anno a 4 su 8; e una soglia sui test DR, che questo articolo aggiunge per i sistemi amministrati nell’Appendice A, sarebbe scattata nell’anno 3. Ogni soglia fa guadagnare all’organizzazione una fase. Il caso illustra l’affermazione centrale del modello: le informazioni necessarie per agire esistevano in ogni momento, e gli strumenti dell’organizzazione semplicemente non erano puntati su di esse, e per uno dei due gruppi non venivano nemmeno raccolte.

7.4 Che cosa mostra il caso

Quattro caratteristiche del caso si trasferiscono ai reparti reali. Primo, ogni segnale nella colonna di sinistra della Tabella 6 era vero ed è stato letto correttamente per quanto arrivava; il fallimento stava in ciò che non veniva misurato. Secondo, l’anno che sembrava il migliore (l’anno 3) è stato l’ultimo in cui un intervento ordinario avrebbe funzionato per gli ingegneri, e l’anno 4 l’ultimo per gli amministratori. Terzo, la colonna di destra era calcolabile dai dati che l’azienda già possedeva per gli ingegneri, dal controllo di versione, dalle valutazioni e dai registri delle assunzioni, ma per gli amministratori doveva essere assemblata e richiesta, ed è per questo che nel caso nessuno l’ha fatto. Quarto, i due gruppi hanno proceduto per tutto il tempo una fase a distanza, le uscite degli amministratori hanno assunto forme che il tasso di turnover non conta (pensionamento, lavoro autonomo, una posizione non coperta), e la loro Fase 5 è arrivata dopo che il consiglio di amministrazione riteneva il problema risolto. Un reparto che misura il proprio personale tecnico come un’unica popolazione vedrà una crisi e sarà sorpreso dalla seconda.

8. Implicazioni per la gestione IT

La conclusione pratica è che il momento dell’intervento conta più del suo contenuto. Le stesse misure che invertono l’effetto nella Fase 2 falliscono nella Fase 4.

8.1 Prima del lock-in

Nelle Fasi da 1 a 3 il reparto contiene ancora persone in grado di valutare il lavoro, assorbire nuove assunzioni e trasferire conoscenza. Gli interventi qui sono convenzionali e ben sostenuti dalla letteratura:

• Retention differenziata. Trevor et al. (1997) mostrano che la crescita salariale è la leva più forte sul turnover degli alti rendimenti. Un budget di retention concentrato sul quartile superiore fa più di un aumento generalizzato. In un ambiente CAO lo strumento è l’indennità di mercato del lavoro (arbeidsmarkttoelage) o un’eccezione di scala, che la maggior parte dei contratti collettivi olandesi consente e la maggior parte dei reparti IT non usa. Per gli ingegneri il confronto che l’indennità deve battere è lo stipendio di un’azienda di prodotto; per gli amministratori, fino a poco tempo fa, era una tariffa giornaliera da libero professionista, che nessuna indennità batte, e dal 2025 è lo stipendio di un fornitore di servizi, che può essere battuto.

• Distribuzione forzata della conoscenza. Pairing, rotazione e requisiti di documentazione alzano il bus factor sui sistemi critici prima che qualcuno se ne vada. L’obiettivo è un bus factor misurabile di almeno due per ogni sistema in produzione. Per gli ingegneri si tratta in gran parte di revisione del codice e di rotazione tra le basi di codice. Per gli amministratori si tratta di procedure esercitate: un ripristino, un failover o una rotazione di certificati che una seconda persona ha effettivamente eseguito sotto supervisione, secondo un calendario, con il risultato registrato. Un runbook che non è stato esercitato non conta.

• Colloqui di uscita letti come uno schema. Le perdite rimpiante dovrebbero essere riviste insieme, dalla direzione ingegneria e non dalle sole risorse umane, con la domanda esplicita di che cosa abbiano in comune.

• Valutazione esterna. La revisione periodica di architettura e codice da parte di persone esterne al team fornisce il punto di riferimento che, come mostra la Sezione 3.4, il team stesso perde. Per le operations l’equivalente è un test di disaster recovery osservato da qualcuno esterno al team, e una revisione di configurazione; una cifra di disponibilità non è una revisione.

8.2 Sequenza per fase

Il modello formale della Sezione 5 assegna a ciascun intervento un tasso su cui agire, e il modello a stadi assegna a ciascuno una finestra in cui funziona ancora. La Tabella 7 mette insieme i due. Prima del punto di lock-in, gli interventi agiscono sull’hazard di uscita $\lambda$, sul tasso di trasferimento $\tau$ e, per gli amministratori, sul tasso di osservazione $\mu$; il modello mostra che il trasferimento protegge solo i sistemi che hanno ancora due o più conoscitori, che la retention guadagna mesi e non anni, e che l’osservazione è l’unica leva che accorcia il ritardo in sé. Dopo il punto di lock-in le stesse leve sono ancora disponibili in linea di principio, ma non è rimasto nulla su cui azionarle: la distribuzione della conoscenza non ha fonte, la retention non ha più nessuno di critico da trattenere, e un’assunzione forte assegnata a un sistema a bus factor zero non ha nessuno da cui imparare e se ne va o ricostruisce lentamente dagli artefatti che esistono. Le opzioni post-lock-in agiscono invece sulla struttura del reparto, ed è per questo che appartengono a un livello diverso di management.

8.3 Una dashboard di composizione

Gli indicatori della Sezione 6 sono utili solo se qualcuno li guarda insieme, alla cadenza giusta, con l’autorità di agire. Dal modello seguono tre scelte di progettazione.

Proprietario. La dashboard appartiene alla direzione ingegneria, non alle risorse umane. Le risorse umane possiedono il tasso di turnover e ne sono il giusto proprietario, ma gli indicatori di composizione richiedono giudizio ingegneristico (quali sistemi sono critici, chi è forte) e dati ingegneristici (controllo di versione). Una dashboard che le risorse umane compilano e l’ingegneria riceve ripete in forma nuova il problema di sopravvivenza della Sezione 3.4.

Cadenza. Trimestrale, con una finestra mobile di quattro trimestri. La revisione annuale è troppo lenta: nel caso della Sezione 7, il punto di lock-in è stato raggiunto tra due revisioni annuali. Quella mensile è troppo rumorosa per un reparto di sessanta persone, dove una sola uscita sposta la maggior parte dei tassi di diversi punti.

Soglie. Ogni indicatore ha bisogno di un livello di attivazione concordato in anticipo, perché un livello concordato a posteriori verrà fissato dovunque si trovi il valore corrente. Punti di partenza ragionevoli, da adeguare una volta che un reparto ha due anni di storia propria: un tasso di perdite rimpiante superiore a un terzo; più di un quarto dei sistemi critici a bus factor uno; attrito dei neoassunti superiore a un quarto in qualsiasi coorte; e due assunzioni senior consecutive che se ne vanno entro un anno. Una soglia non impone un’azione specifica; impone una revisione da parte di qualcuno esterno al reparto.

8.4 Dopo il lock-in

Nelle Fasi 4 e 5 la sostituzione fallisce per due ragioni. La prima è la legge di Brooks (1975) in forma nuova: aggiungere persone a un team che manca della capacità di inserirle rallenta il team e spinge fuori i nuovi arrivati. La seconda è che l’asticella di qualità dell’assunto è fissata dal team in cui entra, per cui un’assunzione forte o si adatta verso il basso o se ne va. Restano tre opzioni, nessuna economica:

1. Un nuovo nucleo. Costruire un team separato con norme proprie, composto da persone esterne, e migrarvi i sistemi nel tempo. Il team esistente non viene sciolto, ma non è più lo standard dell’organizzazione.

2. Declino gestito. Accettare che il reparto possa mantenere ma non cambiare, congelare di conseguenza il perimetro e pianificare la sostituzione dei sistemi anziché il rinnovo del team.

3. Capacità esterna. Spostare il lavoro di cambiamento a fornitori o partner mentre il team interno conserva le operations. È spesso ciò che accade per inerzia, senza che venga riconosciuto, ed è la più costosa delle tre quando la si conteggia onestamente. Nei Paesi Bassi questa opzione si è ristretta dal 2025: l’amministratore autonomo riassunto a tariffa giornaliera, per anni il modo standard di tenere a portata di mano la conoscenza perduta, è ora per il datore di lavoro un rischio di falso lavoro autonomo, e l’alternativa, un contratto di servizi gestiti, porta la conoscenza fuori dall’organizzazione in modo permanente.

Il filo comune è che il recupero post-lock-in è una decisione strutturale presa a un livello superiore al reparto IT. Il reparto stesso, per definizione di lock-in, non può prenderla.

9. Discussione: perché il ritardo persiste

Se gli indicatori sono economici e i meccanismi non sono oscuri, perché il ritardo persiste? Parte della risposta è che nessuno ha messo per iscritto la misurazione, cosa a cui questo articolo cerca di rimediare. Ma la parte maggiore è che il ritardo è tenuto in piedi da caratteristiche del modo in cui le organizzazioni sono gestite, e queste meritano di essere nominate, perché un indicatore che va contro di esse verrà ignorato.

Proprietà divisa del segnale. Il turnover è una metrica delle risorse umane; la delivery è una metrica IT. La composizione delle uscite cade in mezzo. Le risorse umane vedono che qualcuno se n’è andato e perché ha detto di andarsene; l’ingegneria vede che un sistema è diventato difficile da modificare. Nessuna delle due vede che si tratta dello stesso evento, perché nessun report li unisce. La dashboard di composizione della Sezione 8 è, meccanicamente, una giunzione tra due sistemi di registrazione che di norma non vengono uniti.

Disallineamento di cadenza. L’effetto si dispiega in anni; l’attenzione del management è organizzata in trimestri e revisioni annuali. Un processo lento osservato a cadenza rapida sembra rumore, e il movimento di ogni trimestre è abbastanza piccolo da essere attribuito alle circostanze particolari del trimestre. Dalton et al. (1982) sostenevano quattro decenni fa che il turnover andrebbe caratterizzato anziché contato; l’argomento non ha attecchito perché caratterizzare richiede di guardare attraverso le cadenze, e nulla nel ciclo annuale lo premia.

Ogni uscita ha una storia. Le persone se ne vanno per delle ragioni, e le ragioni sono vere: un trasferimento all’estero, una start-up, il lavoro del partner. L’organizzazione accetta ogni storia perché ciascuna è accurata. Ciò che le storie hanno in comune, che chi se n’è andato era forte, sottopagato rispetto al mercato e in grado di andarsene, non è mai la ragione dichiarata e quindi non viene mai aggregato. Il tasso di perdite rimpiante esiste per forzare quell’aggregazione.

La stabilità viene premiata. Un turnover basso viene letto come buona gestione ed è spesso un obiettivo esplicito del management. Nel caso della Sezione 7, l’anno di turnover più basso è stato l’anno in cui il reparto è stato elogiato, ed è stato anche l’anno in cui il punto di lock-in è stato superato. Un obiettivo sul tasso di turnover, senza un obiettivo sulla sua composizione, premia esattamente l’esito contro cui il modello mette in guardia: i forti se ne sono andati e gli altri restano.

Il costo visibile arriva nel budget di qualcun altro. I risparmi dovuti alle sostituzioni lente e alle assunzioni junior compaiono nel budget del reparto stesso nell’anno in cui vengono fatti. Il costo compare anni dopo, nella forma di un contratto con un fornitore, di un programma slittato o di un cambiamento fallito, e viene contabilizzato su un programma, su una voce fornitori o come una tantum. Il reparto che ha causato il costo è raramente quello a cui viene addebitato, e la contabilità quindi non chiude mai il circuito che la Figura 1 disegna.

La scala è il soffitto. Nella maggior parte dei grandi datori di lavoro olandesi e in tutto il settore pubblico, la retribuzione tecnica è una scala CAO con scatti annuali. Un ingegnere o un amministratore forte raggiunge il vertice della scala in pochi anni, dopo di che l’unica via verso una retribuzione più alta è la promozione fuori dal lavoro tecnico o l’uscita. La scala è progettata per essere equa in tutta l’organizzazione; il suo effetto sulla popolazione tecnica è di garantire la condizione in cui i più forti se ne vanno. La maggior parte dei CAO consente eccezioni, nella forma di un’indennità di mercato del lavoro o dell’inquadramento in una scala superiore, e la maggior parte dei reparti IT non lo sa o non ne fa uso.

Il residuo è protetto. Il diritto del lavoro olandese richiede per il licenziamento un motivo ragionevole, una verifica preventiva da parte dell’UWV o del giudice cantonale e un’indennità di transizione prevista per legge. È una caratteristica del sistema, non un difetto, ma significa che la composizione di un team non può essere corretta dal basso una volta che si è deteriorata; l’unica leva rimasta è l’alto. Le organizzazioni che trattano l’effetto Mar Morto come un problema di gestione delle prestazioni, da risolvere rimuovendo il personale debole, scopriranno nei Paesi Bassi che non può essere risolto in quel modo, e farebbero meglio a prevenirlo.

Gli indicatori hanno bisogno di consenso. Gli indicatori della Sezione 6 trattano dati personali del personale attuale ed ex, e diversi di essi, in particolare il quartile di prestazione di chi se ne va e la valutazione delle perdite rimpiante, costituiscono un sistema di monitoraggio delle prestazioni. Ai sensi dell’articolo 27 della legge sui consigli aziendali, il consiglio aziendale ha un diritto di consenso sulle disposizioni per il trattamento dei dati del personale e per il monitoraggio del personale (Wet op de ondernemingsraden, art. 27 lid 1), e il Regolamento generale sulla protezione dei dati richiede una finalità documentata e un calendario di conservazione. Nulla di tutto ciò impedisce la dashboard; significa però che costruirla è una decisione presa con il consiglio aziendale, non dalla sola direzione ingegneria, e che i dati su chi se n’è andato hanno un periodo di conservazione dopo il quale devono essere aggregati o cancellati. Un reparto che vuole cominciare a misurare dovrebbe cominciare da quella conversazione.

I sopravvissuti scrivono i report. Questa è la Sezione 3.4 riformulata come fatto istituzionale: le persone con il minore incentivo a segnalare il declino, e la minore capacità di vederlo, sono quelle da cui l’organizzazione prende le informazioni sul team. La revisione esterna (Sezione 6) è l’unico rimedio, ed è impopolare per la stessa ragione per cui è necessaria.

Nessuna di queste caratteristiche è irrazionale di per sé. Insieme garantiscono che un reparto verrà a sapere della propria composizione nella Fase 5. Cambiarle è più difficile che aggiungere indicatori, ma gli indicatori sono il punto da cui partire, perché rendono visibili le caratteristiche.

10. Limiti e ricerca futura

Si tratta di ricerca teorica. Ne seguono tre limiti.

Selezione nelle evidenze. I meccanismi della Sezione 3 sono tratti da casi in cui l’effetto si è verificato ed è stato infine riconosciuto. I reparti che lo hanno evitato, o in cui ingegneri capaci se ne sono andati senza il degrado previsto, non compaiono nella documentazione professionale. Il modello può quindi sovrastimare quanto spesso l’attrito dei migliori porti al lock-in.

Misurazione di «forte». Sia il saggio di Webster sia questo articolo assumono che la competenza ingegneristica possa essere classificata. In pratica le valutazioni delle prestazioni nell’IT sono rumorose, e le persone meglio collocate per giudicare sono, per la logica stessa del modello, quelle che se ne sono andate. Qualsiasi verifica empirica ha bisogno di una misura di competenza indipendente dal team studiato.

Stilizzazione del modello e del caso. Il modello formale della Sezione 5 tratta i sistemi come indipendenti, la conoscenza come binaria e i tassi come costanti; il caso della Sezione 7 è un composito. Entrambi sono dispositivi per mostrare che l’argomentazione è coerente, non prove che sia vera. I tre risultati qualitativi della Sezione 5 non dipendono dai valori dei tassi; gli anni citati sì, e in qualsiasi reparto reale i tassi andrebbero stimati dai registri che l’Appendice A descrive.

Generalizzazione. L’argomentazione è costruita sui reparti IT all’interno di grandi organizzazioni olandesi, dove la conoscenza tacita dei sistemi è concentrata, la retribuzione segue una scala collettiva, il licenziamento è tutelato e la via del lavoro autonomo si è recentemente ristretta. Potrebbe non trasferirsi ad aziende di prodotto software, società di consulenza o piccoli team, dove le condizioni individuate nella Sezione 2.2 differiscono, né immutata a mercati senza scale retributive collettive o con il licenziamento libero, dove il residuo della metafora di Webster può essere rimosso anziché soltanto prevenuto. La divisione in due gruppi è essa stessa una semplificazione: data engineer, platform engineer e site-reliability engineer si collocano tra i gruppi, e le cifre dell’articolo per loro andrebbero elaborate separatamente.

Il modello produce ipotesi abbastanza specifiche da poter essere confutate. La Tabella 8 le enuncia con i dati che ciascuna richiede.

Tre disegni di studio verificherebbero direttamente queste ipotesi:

1. Analisi retrospettiva della composizione. Per i reparti che hanno sperimentato un declino visibile, ricostruire il quartile di prestazione e la proprietà dei sistemi di ogni persona uscita negli anni precedenti, dai registri delle risorse umane e del controllo di versione. Il modello prevede che la qualità degli usciti sia calata e la concentrazione della conoscenza sia salita diversi anni prima che le metriche di delivery si muovessero.

2. Ritardo di riconoscimento per gruppo. Per ogni sistema critico che ha raggiunto bus factor zero, misurare il tempo fino al primo guasto a esso attribuito, e confrontare i sistemi software con quelli amministrati e i sistemi testati con quelli non testati. Il modello prevede un ritardo più lungo per i sistemi amministrati e più breve dove si eseguono test di disaster recovery; un ritardo che non si accorcia con i test confuterebbe il resoconto del modello sull’osservazione.

3. Validazione degli indicatori. Dove gli indicatori della Sezione 6 sono stati raccolti, verificare se anticipano le metriche di delivery e di incidenti, e di quanto. È lo studio con il valore gestionale più diretto e i minori requisiti di dati.

La storia del controllo di versione è una fonte sottoutilizzata per tutti e tre. La paternità dei commit, la partecipazione alle revisioni e la proprietà dei file nel tempo forniscono un registro longitudinale di chi sapeva che cosa, indipendente dalle valutazioni delle risorse umane, esattamente nelle organizzazioni che il modello descrive.

11. Conclusione

Le organizzazioni IT riconoscono l’effetto Mar Morto in ritardo perché i loro sistemi di misurazione sono costruiti per non vederlo. Il turnover viene contato anziché caratterizzato, la stabilità operativa viene letta come salute, e le persone che potrebbero segnalare la perdita sono quelle che se ne sono andate. Noi di Nashua abbiamo proposto un modello a cinque fasi in cui questi meccanismi producono un punto di lock-in un’intera fase prima che il primo segnale inequivocabile raggiunga il management, e un insieme di indicatori di composizione che si muoverebbero prima. Il modello è verificabile con dati che la maggior parte delle organizzazioni già possiede.

Per gli ingegneri del software la conclusione è che l’effetto è rapido, visibile a chiunque guardi e recuperabile se colto presto. Gli ingegneri forti se ne vanno in fretta verso lavori pagati dal mercato, la loro uscita viene registrata come attrito, la loro conoscenza è in parte nel codice e la composizione del team può essere letta dal controllo di versione. Nel modello il primo sistema viene perso a poco più di un anno e la perdita si vede a circa tre, un ritardo inferiore a due anni. Le leve sono la retribuzione e il trasferimento: un budget di retention differenziato entro il margine che la maggior parte dei contratti collettivi olandesi già consente, e la distribuzione della conoscenza applicata prima che i sistemi arrivino a un proprietario unico, poiché il modello mostra che dopo non può salvarli.

Per gli amministratori di sistema la conclusione è che l’effetto è lento, invisibile a chiunque non chieda e più difficile da cui riprendersi. Gli amministratori forti se ne vanno più lentamente, per vie che il tasso di turnover non conta (pensionamento, trasferimento, fino al 2025 il lavoro autonomo, e la posizione non coperta), la loro conoscenza è procedurale e non lascia artefatti, e la composizione del team non può essere calcolata; va assemblata da registri scarni e confermata chiedendo. Nel modello il primo sistema viene perso a poco meno di tre anni e la perdita si vede a quasi sei, un ritardo di tre anni che nessuna misura di retention accorcia, perché il ritardo è fissato da quanto raramente la conoscenza perduta serve. La leva è la pratica: passaggi di consegne esercitati, e test di disaster recovery osservati da qualcuno esterno al team, che il modello mostra ridurre il ritardo da tre anni a sei mesi senza rallentare la perdita di un solo giorno, e di cui nessun team di ingegneria ha bisogno perché il suo calendario dei cambiamenti fa lo stesso lavoro.

Perché il ritardo degli amministratori sia il più lungo segue da tre differenze che il modello tiene distinte. Primo, il ritardo è l’inverso della frequenza con cui la conoscenza perduta serve, equazione (2): la conoscenza degli ingegneri si esercita sul calendario dei cambiamenti, dove un cambiamento che la richiede arriva ogni due o tre anni per sistema, mentre la conoscenza degli amministratori si esercita sul calendario degli incidenti, dove un failover, un ripristino o un aggiornamento che la richiede arriva circa la metà delle volte, per cui il divario tra la perdita della conoscenza e la scoperta della perdita è lungo il doppio. Secondo, la conoscenza di un ingegnere è in parte nel codice e può essere ricostruita da esso; quella di un amministratore è procedurale e non lascia artefatti, per cui una volta che un sistema amministrato raggiunge bus factor zero vi resta, il che allunga il periodo in cui la perdita è reale e invisibile. Terzo, il guasto di ingegneria sta sul calendario dei cambiamenti e lo si vede avvicinarsi, come un programma che slitta o un cambiamento che non può essere pianificato; il guasto amministrativo sta sul calendario degli incidenti e arriva senza preavviso, come un ripristino che fallisce il giorno in cui serve. Il fatto che gli amministratori se ne vadano anche più lentamente ritarda la perdita in sé ma non la sua scoperta, ed è per questo che il rimedio per loro è la pratica e non la retribuzione: un passaggio di consegne esercitato o un test di ripristino osservato è un evento deliberatamente pianificato che richiede la conoscenza, e anticipa la scoperta senza aspettare l’incidente.

Per entrambi i gruppi il messaggio pratico è lo stesso, e nel contesto olandese ha un taglio particolare. La domanda da porre sull’attrito non è quanti se ne sono andati, ma chi, che cosa hanno portato via con sé e se è rimasto qualcuno che se ne accorgerebbe. In un mercato in cui il residuo non può essere licenziato e i più forti sono pagati secondo una scala, l’unico momento per rispondere è prima del punto di lock-in, e l’unico modo per rispondere per gli amministratori è chiedere.

Appendice A. Misurare gli indicatori

Questa appendice fornisce una definizione operativa, una fonte di dati e la principale insidia per ciascun indicatore della Tabella 4. Tutti possono essere calcolati trimestralmente da registri che la maggior parte delle organizzazioni già tiene; nessuno richiede un’indagine.

Tasso di perdite rimpiante. A ogni uscita volontaria, il responsabile della persona che se ne va risponde a una domanda, registrata dalle risorse umane: avresti fatto una controfferta per trattenere questa persona? Il tasso è il numero di uscite rimpiante diviso per tutte le uscite volontarie su quattro trimestri mobili. Insidia: i responsabili valutano retrospettivamente con più generosità una volta che si sa che un’uscita ha fatto male; raccogliere la risposta entro una settimana dal preavviso.

Quartile di prestazione di chi se ne va. La posizione di ciascuna persona uscita nella distribuzione delle prestazioni del reparto, presa dalla media delle sue ultime due valutazioni prima del preavviso. Riportare la quota di usciti dal quartile superiore. Insidia: valutazioni compresse verso il centro nascondono il segnale; dove le valutazioni non sono informative, sostituirle con una classifica forzata da parte di due responsabili all’uscita.

Divario dell’offerta in uscita. Differenza percentuale mediana tra la nuova retribuzione complessiva di chi se ne va e quella attuale, dai colloqui di uscita. Insidia: chi se ne va sottostima o rifiuta di rispondere; un tasso di risposta inferiore alla metà rende la cifra inaffidabile, e il tasso di risposta stesso diventa allora l’indicatore.

Bus factor per sistema critico. Il numero di persone che si potrebbero perdere prima che nessuno di quelli rimasti sia in grado di modificare o ripristinare il sistema. Per i sistemi sotto controllo di versione può essere calcolato dalla storia senza chiedere nulla a nessuno. Il metodo di Avelino et al. (2016) assegna a ogni sviluppatore $d$ un grado di paternità per ogni file $f$,

dove $\mathrm{FA}$ vale 1 se $d$ ha creato il file, $\mathrm{DL}$ è il numero di modifiche che $d$ vi ha apportato e $\mathrm{AC}$ il numero di modifiche apportate da altri. Uno sviluppatore viene conteggiato come conoscitore di un file quando il suo DOA normalizzato è almeno 0.75 del massimo del file e il valore assoluto è almeno 3.293. Il bus factor si trova poi rimuovendo gli sviluppatori in ordine di file conosciuti finché più della metà dei file del sistema non ha più alcuno sviluppatore competente rimasto. Per i sistemi amministrati, che sono per lo più fuori dal controllo di versione, la stessa idea si applica ad altri registri di chi ha fatto che cosa: ticket di change management per sistema, risoluzioni di incidenti per sistema, appartenenza ai turni di reperibilità e, dove l’infrastruttura è definita come codice, il repository di configurazione. Una persona conta come conoscitore di un sistema amministrato quando nell’ultimo anno vi ha chiuso cambiamenti o incidenti senza fare escalation a qualcun altro. Insidia: questi registri sono più scarni della storia dei commit e spesso attribuiscono il lavoro a chi ha aperto il ticket anziché a chi lo ha svolto; per i sistemi più critici, confermare la cifra calcolata chiedendo al team di nominare chi potrebbe ripristinare il sistema da zero, e trattare un’esitazione come un bus factor di uno.

Indice di concentrazione della conoscenza. La quota di sistemi critici il cui bus factor è uno. «Critico» dovrebbe essere definito dall’azienda (sistemi la cui interruzione ferma i ricavi o la conformità), non dall’IT. Insidia: l’indice può essere manipolato suddividendo i sistemi; fissare l’elenco dei sistemi per almeno un anno.

Numero di sistemi orfani. Il numero di sistemi critici il cui autore o manutentore principale se n’è andato e che sono stati riassegnati a un proprietario esistente senza un periodo di passaggio di consegne di almeno un mese di sovrapposizione. Per i sistemi amministrati, contare un passaggio di consegne come reale solo se il nuovo proprietario ha eseguito le procedure critiche (ripristino, failover, rotazione dei certificati) almeno una volta sotto supervisione; un runbook consegnato senza essere esercitato non è un passaggio di consegne. Fonte: registro delle proprietà dei sistemi incrociato con le date di uscita. Insidia: i registri delle proprietà sono raramente mantenuti; il primo calcolo richiede di norma la ricostruzione del registro, che è essa stessa informativa.

Asimmetria di anzianità. Il rapporto tra il personale con più di cinque anni di anzianità e quello con meno di due, calcolato separatamente per ingegneri e amministratori. Un reparto sano che si rinnova si colloca vicino a uno; un reparto il cui afflusso si è prosciugato o non resta sale sopra due. Insidia: una riorganizzazione che sposta le persone tra reparti azzera l’anzianità in alcuni sistemi delle risorse umane; usare l’anzianità presso il datore di lavoro, non presso il centro di costo.

Frequenza delle revisioni esterne. Il numero di occasioni all’anno in cui codice, architettura o pratica operativa sono stati valutati da qualcuno esterno al team: un comitato di revisione dell’architettura, un audit di sicurezza con risultati discussi, una revisione da parte di un reparto omologo, la valutazione di un consulente esterno. Contare solo le revisioni che hanno prodotto risultati scritti. Insidia: gli audit di conformità che verificano documenti anziché sistemi non andrebbero contati.

Attrito dei neoassunti. Per ogni coorte di assunzione (gli assunti in un dato semestre), la quota di chi se n’è andato entro dodici mesi dalla data di inizio. Riportare per coorte, non per anno solare, in modo che la cifra di una coorte sia nota una volta per tutte e non vari nel tempo. Insidia: la cifra è in ritardo di un anno per costruzione; abbinarla al tasso di accettazione delle offerte, che non lo è.

Tasso di accettazione delle offerte per ruoli senior. La quota di offerte per posizioni senior accettate, su quattro trimestri mobili, e i motivi registrati dei rifiuti. Insidia: i recruiter registrano il motivo che riflette meno sul processo; chiedere direttamente al candidato dove possibile.

Attualità dei test di disaster recovery (amministratori). Per ogni sistema critico amministrato, il numero di mesi trascorsi da quando un ripristino, un failover o una ricostruzione è stato eseguito per l’ultima volta da cima a fondo da qualcuno diverso dal suo proprietario principale, con il risultato registrato. Questo indicatore non ha un equivalente in ingegneria e viene aggiunto qui perché il caso della Sezione 7 ruota attorno a esso. Soglia: qualsiasi sistema critico oltre i dodici mesi, o qualsiasi sistema il cui ultimo test sia stato eseguito solo da una persona che nel frattempo se n’è andata. Insidia: un test avviato e abbandonato viene spesso registrato come eseguito; contare solo i test con un esito registrato.

Leggere l’insieme. Nessun singolo indicatore è decisivo. Lo schema che il modello prevede è un aumento delle perdite rimpiante e delle uscite dal quartile superiore (fase 1), seguito da un calo del bus factor e da un aumento dei sistemi orfani (fase 2), seguito da un aumento dell’asimmetria di anzianità e da un calo delle revisioni esterne (fase 3), e solo allora da un aumento dell’attrito dei neoassunti e da un calo dell’accettazione delle offerte senior (fase 4). Un reparto che vede i primi due movimenti ha tempo; uno che vede gli ultimi due ne ha molto poco.

Bibliografia

Avelino, G., Passos, L., Hora, A., & Valente, M. T. (2016). A novel approach for estimating truck factors. In Proceedings of the 24th IEEE International Conference on Program Comprehension (ICPC), 1–10. https://doi.org/10.1109/ICPC.2016.7503718 (author version: https://homepages.dcc.ufmg.br/~mtov/pub/2016-icpc.pdf)

Becker, W. J., & Cropanzano, R. (2011). Dynamic aspects of voluntary turnover: An integrated approach to curvilinearity in the performance–turnover relationship. Journal of Applied Psychology, 96(2), 233–246. https://doi.org/10.1037/a0021223

Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.

Cohen, W. M., & Levinthal, D. A. (1990). Absorptive capacity: A new perspective on learning and innovation. Administrative Science Quarterly, 35(1), 128–152. https://doi.org/10.2307/2393553

Cosentino, V., Cánovas Izquierdo, J. L., & Cabot, J. (2015). Assessing the bus factor of Git repositories. In Proceedings of the 22nd IEEE International Conference on Software Analysis, Evolution, and Reengineering (SANER), 499–503. https://doi.org/10.1109/SANER.2015.7081864

Dalton, D. R., Todor, W. D., & Krackhardt, D. M. (1982). Turnover overstated: The functional taxonomy. Academy of Management Review, 7(1), 117–123. https://doi.org/10.5465/amr.1982.4285499

De Holan, P. M., & Phillips, N. (2004). Remembrance of things past? The dynamics of organizational forgetting. Management Science, 50(11), 1603–1613. https://doi.org/10.1287/mnsc.1040.0273

DeLong, D. W. (2004). Lost Knowledge: Confronting the Threat of an Aging Workforce. Oxford University Press. https://doi.org/10.1093/acprof:oso/9780195170979.001.0001

Hom, P. W., Lee, T. W., Shaw, J. D., & Hausknecht, J. P. (2017). One hundred years of employee turnover theory and research. Journal of Applied Psychology, 102(3), 530–545. https://doi.org/10.1037/apl0000103

Jackofsky, E. F. (1984). Turnover and job performance: An integrated process model. Academy of Management Review, 9(1), 74–83. https://doi.org/10.5465/amr.1984.4277940

Kaplan, B. (2009). Managing the risk of knowledge loss due to workforce attrition. Presentation to the SIKM Leaders Community, June 2009. https://www.slideshare.net/SIKM/managing-the-risk-of-knowledge-loss-due-to-workforce-attrition

Manpower Inc. (2010). Knowledge retention and transfer in the world of work. White paper, announced 13 April 2010. https://investor.manpowergroup.com/node/51361

Minister van Sociale Zaken en Werkgelegenheid & Staatssecretaris van Financiën. (2026, 12 February). Brief aan de Tweede Kamer inzake zelfstandig ondernemerschap: reactie op het position paper van VZN en handhaving op arbeidsrelaties (Kamerstukken II 2025/26, 31 311, nr. 304). https://zoek.officielebekendmakingen.nl/kst-31311-304.pdf

Nyberg, A. (2010). Retaining your high performers: Moderators of the performance–job satisfaction–voluntary turnover relationship. Journal of Applied Psychology, 95(3), 440–453. https://doi.org/10.1037/a0018869

Salamin, A., & Hom, P. W. (2005). In search of the elusive U-shaped performance–turnover relationship: Are high performing Swiss bankers more liable to quit? Journal of Applied Psychology, 90(6), 1204–1216. https://doi.org/10.1037/0021-9010.90.6.1204

Trevor, C. O., Gerhart, B., & Boudreau, J. W. (1997). Voluntary turnover and job performance: Curvilinearity and the moderating influences of salary growth and promotions. Journal of Applied Psychology, 82(1), 44–61. https://doi.org/10.1037/0021-9010.82.1.44. Open-access working paper: https://ecommons.cornell.edu/entities/publication/7dd1115c-022a-4dc6-9af7-7a4a31a0c19a

UWV. (2025, 18 December). Ontwikkeling krapte naar beroep 2024–2030. https://www.uwv.nl/assets-kai/files/3dadda9c-258e-4d9f-b60c-eac75496816b/ontwikkeling-krapte-naar-beroep-2024-2030.pdf

UWV. (2026, 8 October). ICT-beroepen: arbeidsmarktinformatie. https://www.uwv.nl/nl/arbeidsmarktinformatie/sector/ict

Webster, B. F. (2008, 11 April). The wetware crisis: The Dead Sea effect. Bruce F. Webster (blog). https://brucefwebster.com/2008/04/11/the-wetware-crisis-the-dead-sea-effect/

Wet op de ondernemingsraden, art. 27. https://wetten.overheid.nl/BWBR0002747

Williams, C. R., & Livingstone, L. P. (1994). Another look at the relationship between performance and voluntary turnover. Academy of Management Journal, 37(2), 269–298. https://doi.org/10.2307/256830