1. Einleitung

Unter Personalabgang verstehen wir den fortlaufenden Verlust von Mitarbeitern durch Austritte, freiwillige oder nicht, und in diesem Beitrag kommt es auf seine Zusammensetzung an, nicht auf seine Rate. Die Kosten des Personalabgangs in der IT sind gut dokumentiert; der Zeitpunkt seiner Erkennung ist es nicht. Schätzungen der Wiederbeschaffungskosten in der Praktikerliteratur reichen von etwa 90% bis 200% eines Jahresgehalts, wenn Rekrutierung, Einarbeitung und Produktivitätsverlust mitgerechnet werden. Dennoch überwachen die meisten IT-Abteilungen den Personalabgang über eine einzige nachlaufende Zahl: die jährliche Fluktuationsrate. Diese Zahl beantwortet, wie viele gegangen sind, nicht wer gegangen ist oder was mit ihnen gegangen ist.

Die Lücke ist von Bedeutung, weil IT-Arbeit implizites Wissen in wenigen Köpfen konzentriert. Eine Altintegration, ein undokumentiertes Deployment-Ritual, ein Backup-Schema, aus dem nur ein einziger Administrator je wiederhergestellt hat, oder eine Lieferantenbeziehung lebt häufig bei ein oder zwei Personen. Wenn diese Personen gehen, versagt die Abteilung nicht sofort. Sie verfällt langsam, und der Verfall ist für die Kennzahlen, die das Management liest, unsichtbar.

Webster (2008) hat das selektive Muster dahinter benannt: In großen IT-Organisationen gehen die stärksten technischen Mitarbeiter am ehesten, und die am wenigsten mobilen bleiben. Er nannte es den Totes-Meer-Effekt. Sein Essay wird von Praktikern breit zitiert, ist aber nie zu einem Modell weiterentwickelt worden und sagt wenig darüber, wann der Effekt sichtbar wird.

Dieser Beitrag schließt diese Lücke mit einer Frage: Warum erkennen IT-Organisationen den Totes-Meer-Effekt erst nach dem Punkt, an dem er noch umkehrbar wäre, und was würde es ihnen erlauben, ihn früher zu erkennen?

Zwei Populationen und ein Markt. Eine IT-Abteilung hat zwei technische Populationen, die dieser Beitrag von der ersten bis zur letzten Seite auseinanderhält: Softwareentwickler, die Systeme bauen und ändern und deren Arbeit eine Spur in der Versionsverwaltung hinterlässt, und Systemadministratoren, die Infrastruktur, Netzwerke, Datenbanken, Speicher und Betrieb verantworten und deren Wissen prozedural ist und seine Spur hauptsächlich in Tickets, Rufbereitschaftsplänen und im Gedächtnis hinterlässt. Beide Gruppen unterliegen dem Totes-Meer-Effekt. Sie unterliegen ihm nicht auf dieselbe Weise: Sie gehen mit unterschiedlichen Raten und auf unterschiedlichen Wegen, ihr Wissen geht unterschiedlich verloren und wird unterschiedlich wiedergewonnen, und die Instrumente, die ihren Verlust erfassen würden, sind verschieden. Sie in eine Kategorie zusammenzufassen, wie Websters Essay und der größte Teil der Praktikerliteratur es tun, verbirgt genau die Unterschiede, die darüber entscheiden, wie lange die Verzögerung dauert. Wo dieser Beitrag eine Zahl, einen Befund oder eine Empfehlung gibt, gibt er sie für jede Gruppe und sagt, wo sie übereinstimmen.

Der Beitrag ist für die niederländische Marktsituation geschrieben. Vier ihrer Merkmale wirken unmittelbar auf die Argumentation und kehren durchgehend wieder. Die meisten großen niederländischen Arbeitgeber und der gesamte öffentliche Sektor legen die Vergütung technischer Mitarbeiter über Tarifverträge (CAOs) mit festen Gehaltsstufen und jährlichen Schritten fest, sodass das Gehaltswachstum eines starken Entwicklers, der bleibt, langsam und vorhersehbar ist, was genau die Bedingung ist, unter der Leistungsträger gehen (Abschnitt 2.2). Das niederländische Kündigungsrecht verlangt eine präventive Prüfung durch das UWV oder den Kantonrichter sowie eine gesetzliche Abfindung, sodass die Mitarbeiter, die bleiben, nur schwer zu versetzen sind, sobald sie sich festgesetzt haben. Betriebsräte haben ein Zustimmungsrecht bei Systemen, die Mitarbeiter überwachen, und bei der Verarbeitung von Personaldaten, was einschränkt, wie die Indikatoren aus Abschnitt 6 gebaut werden dürfen. Und der niederländische ICT-Arbeitsmarkt wurde im vierten Quartal 2024 für alle drei ICT-Berufsgruppen, die das UWV unterscheidet, als sehr angespannt eingestuft (UWV, 2025) und hat sich seither abgekühlt: Die offenen Stellen sind von ihrem Höchststand 2023 auf etwa 18,900 im zweiten Quartal 2026 gefallen, während die Arbeitslosigkeit unter ICT-Fachkräften gestiegen ist (UWV, 2026); die Wiederaufnahme der Durchsetzung gegen Scheinselbstständigkeit im Januar 2025 hat zugleich den Freelance-Weg verengt, den beide Gruppen, und Administratoren besonders, als Ausweg nutzten und den Arbeitgeber als Ersatz für Einstellungen nutzten (Minister van SZW & Staatssecretaris van Financiën, 2026). Keines dieser Merkmale ist einzigartig für die Niederlande, ihre Kombination aber schon, und der Beitrag beansprucht nicht, dass seine Zahlen unverändert auf andere Märkte übertragbar sind.

Die Argumentation verläuft wie folgt. Abschnitt 2 behandelt den Totes-Meer-Effekt, die Forschungsliteratur, die seine Kernaussage stützt, die benachbarten Konstrukte, mit denen er oft verwechselt wird, und die beiden Populationen, wie der niederländische Markt sie zeigt. Abschnitt 3 benennt die Mechanismen, die die Erkennung verzögern. Abschnitt 4 schlägt ein Fünfphasenmodell vor, und Abschnitt 5 leitet aus einem minimalen Modell der Wissensabdeckung sowohl den Lock-in-Punkt als auch die Länge der Verzögerung ab. Abschnitt 6 leitet Frühindikatoren ab, Abschnitt 7 verfolgt eine stilisierte Abteilung durch die fünf Phasen, Abschnitt 8 erörtert Interventionen, und Abschnitt 10 legt Grenzen und eine empirische Forschungsagenda dar. Anhang A gibt operationale Definitionen für jeden Indikator.

2. Hintergrund

2.1 Der Totes-Meer-Effekt

Webster (2008) beobachtete, dass die Kompetenzverteilung einer großen IT-Abteilung unter sonst gleichen Bedingungen die ihrer Neueinstellungen spiegeln sollte, in der Praxis aber im Lauf der Zeit nach unten driftet. Die Entwickler, die am ehesten anderswo Arbeit finden, gehen, wenn sie auf organisatorische Dysfunktion stoßen; die Verbleibenden neigen dazu, sich als Betreuer kritischer Systeme festzusetzen und schwer entfernbar zu werden. Er benannte das Muster nach dem Toten Meer, aus dem Wasser nur durch Verdunstung entweicht und Salz zurückbleibt. Webster rahmte es ausdrücklich als Tendenz, nicht als Gesetz: Nicht jeder, der bleibt, ist „Rückstand“, und gut geführte Gruppen vermeiden das Muster vollständig. Der Essay erschien auf seinem Blog als Kapitelentwurf für ein Buch, das nie veröffentlicht wurde, und das Konzept hat sich seither hauptsächlich über Praktikerkanäle verbreitet.

2.2 Wer geht: die Literatur zu Leistung und Fluktuation

Die Kernaussage, dass Abgänger keine Zufallsstichprobe der Belegschaft sind, ist empirisch gut belegt. Jackofsky (1984) schlug vor, dass freiwillige Fluktuation kurvilinear in der Leistung ist: Leistungsschwache werden hinausgedrängt, Leistungsstarke durch externe Angebote herausgezogen, und Durchschnittliche bleiben. Trevor, Gerhart und Boudreau (1997) bestätigten dies an 5,143 Beschäftigten eines einzelnen Unternehmens und fanden, dass das Leistungsträger-Ende der Kurve vom Gehaltswachstum getrieben wird: Wo das Gehaltswachstum zurückblieb, war die Fluktuation unter den Besten extrem hoch. Salamin und Hom (2005) replizierten die U-Form im Schweizer Bankwesen. Williams und Livingstone (1994) meta-analysierten 55 Studien und fanden, dass Fluktuation sich nur dort auf Leistungsschwache konzentriert, wo die Vergütung leistungsabhängig ist; wo sie es nicht ist, schwächt sich der Zusammenhang ab oder verschwindet.

Daraus folgen zwei Implikationen für die IT. Erstens ist der Totes-Meer-Effekt der Leistungsträger-Arm einer gut etablierten Kurve, keine Volkstheorie. Zweitens sind die Bedingungen, die ihn hervorbringen, spezifisch: flaches Gehaltswachstum und schwache Leistungsdifferenzierung, beides verbreitet in großen Unternehmens- und öffentlichen IT-Organisationen.

2.3 Funktionale versus dysfunktionale Fluktuation

Dalton, Todor und Krackhardt (1982) argumentierten, dass eine rohe Fluktuationsrate irreführend ist, weil sie funktionale Fluktuation (Leistungsschwache gehen, was der Organisation hilft) mit dysfunktionaler Fluktuation (Leistungsstarke gehen, die hätten gehalten werden können) vermengt. Ihre Taxonomie nimmt das zentrale Messproblem vorweg, das dieser Beitrag untersucht: Eine aggregierte Fluktuationszahl kann gesund aussehen, während ihre Zusammensetzung zerstörerisch ist.

2.4 Was geht: Wissensverlust

DeLong (2004) dokumentierte, wie technologieintensive Organisationen kritisches implizites Wissen durch Pensionierungen und unerwartete Austritte in der Mitte der Laufbahn verlieren, und zeigte, dass der Verlust typischerweise Monate oder Jahre nach dem Austritt zutage tritt, wenn eine Situation eintritt, die nur der ausgeschiedene Mitarbeiter zu handhaben wusste. Praktikerarbeiten aus derselben Zeit rahmten das Problem ausdrücklich als Personalabgang; Kaplan (2009) und Manpower (2010) berichteten beide, dass ein erheblicher Teil der Arbeitgeber keinen Prozess hatte, um das Wissen ausscheidender Mitarbeiter zu sichern.

2.5 Verwandte Konstrukte

Der Totes-Meer-Effekt steht neben mehreren bekannteren Ideen, und es lohnt sich, genau zu sagen, worin er sich von jeder unterscheidet.

Bus-Faktor. Der Bus-Faktor eines Systems ist die Zahl der Personen, die gehen müssten, bevor das System nicht mehr gewartet werden kann. Die Software-Engineering-Forschung hat ihn aus der Versionsverwaltungshistorie operationalisiert (Cosentino, Cánovas Izquierdo & Cabot, 2015; Avelino et al., 2016). Er ist eine Momentaufnahme der Wissenskonzentration zu einem Zeitpunkt, und seine etablierten Maße bauen auf der Versionsverwaltung auf, die aufzeichnet, was Softwareentwickler tun, aber nicht, was Administratoren tun; Anhang A erweitert ihn auf administrierte Systeme. Der Totes-Meer-Effekt ist der Prozess, der den Bus-Faktor nach unten treibt; der Bus-Faktor ist eine seiner besten Messgrößen (Abschnitt 6), keine konkurrierende Erklärung.

Brooks’ Gesetz. Brooks (1975) beobachtete, dass das Hinzufügen von Personen zu einem verspäteten Softwareprojekt es weiter verspätet, weil Einarbeitungs- und Kommunikationsaufwand die hinzugewonnene Kapazität überwiegen. Das Gesetz betrifft ein Projekt in Zeitnot. Abschnitt 8 verallgemeinert den Mechanismus auf ein Team in Zusammensetzungsnot: Einem Team, das seine stärksten Mitglieder verloren hat, fehlt die Kapazität zur Einarbeitung, sodass das Hinzufügen von Personen aus demselben Grund scheitert, dauerhaft statt nur für die Dauer eines Projekts.

Funktionale und dysfunktionale Fluktuation. Dalton et al. (1982) lieferten die Taxonomie; der Totes-Meer-Effekt ist der Fall, in dem Fluktuation systematisch dysfunktional ist und die aggregierte Zahl dies verbirgt. Der Beitrag hier ist das zeitliche Argument: warum die Organisation spät von der Dysfunktion erfährt.

Organisationales Vergessen. De Holan und Phillips (2004) unterscheiden absichtliches von unbeabsichtigtem Vergessen und innerhalb des Letzteren das Versäumnis, neues Wissen zu erfassen, vom Verfall bereits vorhandenen Wissens. Wissensverlust durch Personalabgang ist unbeabsichtigter Verfall. Der Totes-Meer-Effekt fügt dieser Literatur einen Selektionsmechanismus hinzu: Es ist nicht zufälliges Wissen, das verfällt, sondern überproportional das Wissen derer, die am ehesten gehen können.

Absorptionsfähigkeit. Cohen und Levinthal (1990) argumentierten, dass die Fähigkeit einer Organisation, neues Wissen zu erkennen, aufzunehmen und anzuwenden, von dem verwandten Wissen abhängt, das sie bereits besitzt. Der Mechanismus in Abschnitt 3.5 ist Absorptionsfähigkeit, angewandt auf Menschen statt auf Information: Die Fähigkeit eines Teams, eine starke Neueinstellung zu halten, hängt von den starken Kollegen ab, die bereits da sind. In Abschnitt 5 erscheint dies als die einfache Tatsache, dass Wissenstransfer eine Quelle braucht: Sobald niemand mehr da ist, der ein System kennt, kann es niemandem mehr beigebracht werden.

Fluktuationstheorie. Ein Jahrhundert Fluktuationsforschung (Hom et al., 2017) hat sich auf Antezedenzien auf Individualebene konzentriert: warum eine bestimmte Person sich zum Gehen entschließt. Nyberg (2010) zeigt, dass bei Leistungsträgern Gehaltswachstum und Beförderungsgeschwindigkeit diese Entscheidung moderieren. Der vorliegende Beitrag nimmt die Ergebnisse auf Individualebene als gegeben und stellt eine Frage auf Teamebene: was die Folge solcher Entscheidungen mit der Zusammensetzung dessen macht, was bleibt, und wann jemand es bemerkt.

2.6 Zwei Populationen, zwei Arbeitsmärkte

Die Literatur zu Leistung und Fluktuation behandelt Beschäftigte als eine nach Leistung geordnete Population. Für die Argumentation hier muss das technische Personal einer IT-Abteilung in zwei Teile geteilt werden, weil der Totes-Meer-Effekt über drei Dinge wirkt, die sich zwischen Softwareentwicklern und Systemadministratoren systematisch unterscheiden: die Form, die ihr Wissen annimmt, der Weg, auf dem sie gehen, und die Spur, die sie für die Messung hinterlassen.

Wissen. Das Wissen von Entwicklern ist teilweise in den Artefakten kodifiziert, die sie erzeugen. Code, Tests, Schemata und Pipelines überdauern ihren Autor, schlecht dokumentiert, aber lesbar. Das Wissen von Administratoren ist prozedural: wie man einen Cluster umschaltet, in welcher Reihenfolge Dienste neu zu starten sind, worin die undokumentierte Abhängigkeit zwischen der Firewall und dem Batch-Fenster besteht, warum die Wiederherstellung aus dem zweitältesten Snapshot erfolgen muss. Es wird durch Tun erworben und im Gedächtnis gehalten, und es wird an Systemen ausgeübt, deren Ausfall das gesamte Geschäft stillstehen lässt statt nur eine Funktion. In den Begriffen von Abschnitt 5 ist ein starker Administrator schwerer durch eine starke Neueinstellung zu ersetzen als ein starker Entwickler, weil es weniger zu lesen und mehr zu zeigen gibt.

Austrittswege im niederländischen Markt. Im vierten Quartal 2024 stufte das UWV alle drei ICT-Berufsgruppen, die es unterscheidet, Software- und Anwendungsentwickler, Datenbank- und Netzwerkspezialisten sowie ICT-Anwendersupport, als mit einem sehr angespannten Arbeitsmarkt konfrontiert ein (UWV, 2025); seither hat sich der Markt abgekühlt, wobei die offenen ICT-Stellen seit 2023 stetig sinken und die Zahl der ICT-Fachkräfte im Arbeitslosengeldbezug im Juli 2026 auf etwa 6,400 gestiegen ist, teils durch Reorganisationen im Bankwesen (UWV, 2026). Innerhalb dieses gemeinsamen Bildes gehen die beiden Gruppen durch verschiedene Türen. Starke Entwickler in einer Unternehmens-IT-Abteilung werden zu Softwareproduktunternehmen, Scale-ups und Beratungen gezogen, wo die Vergütung vom Markt statt von einer CAO-Tabelle bestimmt wird und wo die Arbeit im Bauen statt im Warten besteht. Starke Administratoren werden zu Managed-Service-Providern, Cloud- und Hosting-Unternehmen gezogen und, bis vor Kurzem, in die Selbstständigkeit: Der zzp-Weg war jahrelang der Standardweg für einen erfahrenen niederländischen Administrator, sein Einkommen zu verdoppeln und dabei dieselbe Arbeit für denselben Arbeitgeber zu tun. Die Aufhebung des Durchsetzungsmoratoriums am 1. Januar 2025 hat Auftraggeber vorsichtig gemacht, Freelancer für eingebettete Rollen zu beauftragen (Minister van SZW & Staatssecretaris van Financiën, 2026), was einen Teil dieser Tür geschlossen hat und, wie Abschnitt 8 erörtert, zugleich einen Teil des Fluchtwegs des Arbeitgebers.

Die Seite, die bleibt. Der niederländische institutionelle Rahmen prägt auch, wer bleibt. CAO-Tabellen mit jährlichen Stufen bedeuten, dass ein starker Entwickler oder Administrator, der bleibt, innerhalb weniger Jahre das Ende seiner Gehaltsstufe erreicht und danach kein Wachstum mehr sieht, genau die Bedingung, unter der Trevor et al. (1997) die Fluktuation von Leistungsträgern als extrem hoch finden. Kündigungsschutz bedeutet, dass Mitarbeiter, die sich festgesetzt haben, nicht ohne Weiteres versetzt werden können; die präventive Prüfung und die gesetzliche Übergangsvergütung machen den Rückstand aus Websters Metapher zu einer dauerhaften Tatsache statt zu einer Managemententscheidung. Beide Merkmale gelten für beide Gruppen. Der Unterschied ist, dass ein festgesetzter Administrator die Root-Passwörter und den Rufbereitschaftsplan hält, sodass die Verfestigung ebenso operativ wie organisatorisch ist.

Spur. Schließlich unterscheiden sich die beiden Gruppen darin, was sie für die Messung hinterlassen. Jede Änderung, die ein Entwickler vornimmt, ist in der Versionsverwaltung zugeordnet, sodass Wissenskonzentration aus der Historie berechnet werden kann (Anhang A). Die Arbeit eines Administrators ist, wenn überhaupt, in Change-Tickets, Incident-Aufzeichnungen und Rufbereitschaftsplänen zugeordnet, die dünner sind, weniger konsistent geführt werden und oft festhalten, wer eingereicht hat, statt wer es getan hat. Die praktische Konsequenz zieht sich durch den Rest des Beitrags: Der Effekt ist bei Administratoren schwerer zu sehen, und die Indikatoren für sie müssen sich mehr auf Fragen und weniger auf Berechnen stützen.

Zusammengenommen belegen diese Literaturen, wer geht, was geht und welche benachbarten Ideen bereits in Gebrauch sind, und dieser Abschnitt hat dargelegt, warum die beiden Populationen getrennt verfolgt werden müssen. Keine dieser Literaturen befasst sich damit, wann die Organisation davon erfährt. Das ist der Beitrag der folgenden Abschnitte.

3. Warum der Effekt verzögert ist

Der Totes-Meer-Effekt ist verzögert, weil jedes Signal, das das Management erhält, entweder neutral oder trügerisch beruhigend ist, bis der Schaden strukturell ist. Nashua identifiziert sechs Mechanismen. Sie sind nicht unabhängig; zusammen bilden sie ein Messsystem, das genau für die Variable blind ist, auf die es ankommt.

3.1 Der Personalbestand sinkt, aber langsam. Personalabgang wird nur teilweise nachbesetzt, sodass der Personalbestand nach unten driftet statt abzustürzen. Eine Abteilung, die drei Entwickler verliert und zwei einstellt, meldet einen Nettoverlust von einem, eine Zahl, klein genug, um im Budgetzyklus aufgefangen oder als Effizienz gelesen zu werden. Die Fluktuationsrate, die einzige Abgangskennzahl, die die meisten IT-Führungskräfte sehen, ist eine Zählung. Sie kann den Austritt der Person, die die Abrechnungsintegration verstand, nicht vom Austritt einer Person unterscheiden, die in einer Woche zu ersetzen war, und eine langsam schrumpfende Zählung verbirgt die Tatsache, dass das, was ging, überproportional die Spitze der Verteilung war. Dalton et al. (1982) machten diesen Punkt allgemein; in der IT, wo die Kompetenz zwischen Individuen um eine Größenordnung variiert, ist die Verdeckung extrem. Bei Administratoren gibt es eine weitere Maske: Ein größerer Teil ihrer Austritte nimmt die Form geplanter Pensionierung oder interner Versetzung in eine Service-Management-Rolle an, die keine Fluktuationskennzahl überhaupt als Verlust zählt.

3.2 Die Systeme laufen weiter. Produktionssoftware hört nicht auf zu laufen, wenn ihr Autor geht. Die Wissenslücke wird erst sichtbar, wenn das System geändert werden muss oder ausfällt, was Monate oder Jahre später sein kann (DeLong, 2004). Bis dahin scheint die Abteilung wie zuvor zu liefern. Bei administrierten Systemen ist der Punkt noch schärfer: Ein Backup, das nie wiederhergestellt wurde, eine Zertifikatserneuerung, die einmal im Jahr von Hand erledigt wird, ein Firewall-Regelwerk, das niemand sonst gelesen hat, alle funktionieren weiter bis zu dem Tag, an dem sie es nicht mehr tun, und dieser Tag kann Jahre nach dem Weggang der Person liegen, die sie verstand. Betriebliche Stabilität wird als organisatorische Gesundheit gelesen, wo sie in Wirklichkeit Trägheit ist. Bei Entwicklern wird die Latenz vom Änderungskalender bestimmt: Die Lücke zeigt sich, wenn das System das nächste Mal geändert werden muss. Bei Administratoren wird sie vom Ausfallkalender bestimmt: Die Lücke zeigt sich, wenn das System das nächste Mal ausfällt, was seltener und später ist.

3.3 Die Verfestigung des Rückstands sieht aus wie Loyalität. Webster bemerkte, dass diejenigen, die bleiben, dazu neigen, die Verantwortungen zu übernehmen, die sonst niemand will, und zu Wartungsexperten für kritische Systeme werden. Vom Stuhl des Managements aus liest sich das als Engagement und geringes Risiko: Das sind die Leute, die die Systeme kennen und nie gehen. Die Abhängigkeit der Organisation von ihnen wächst genau in dem Maß, in dem ihre Fähigkeit schwindet, sie zu beurteilen, weil die Leute, die ihre Arbeit hätten beurteilen können, gegangen sind. Bei Administratoren ist die Verfestigung buchstäblich wie organisatorisch: Der verbleibende Administrator hält die privilegierten Konten, die Lieferantenkontakte und den Rufbereitschaftsplan und ist nach niederländischem Kündigungsrecht ohnehin nicht ohne Weiteres zu versetzen. Bei Entwicklern nimmt sie die Form alleinigen Eigentums an Systemen an, die sonst niemand bauen kann.

3.4 Survivorship in der Berichterstattung. Informationen über die Qualität der Entwicklung fließen über Entwickler nach oben. Nachdem die stärksten Entwickler gegangen sind, sind die Leute, die über den Zustand der Systeme, des Backlogs und des Teams berichten, die verbleibenden Mitarbeiter, die keinen Anreiz und oft keinen Bezugspunkt haben, über Verfall zu berichten. Austrittsgespräche, der eine Kanal, der die Sicht der Abgänger erfasst, werden typischerweise von der Personalabteilung geführt, aggregiert und als individuelle Beschwerden statt als Muster gelesen. Bei Administratoren ist die Survivorship schlimmer, denn ihr Berichtskanal ist das Incident- und Verfügbarkeits-Dashboard: Ein Betriebsteam, das seine besten Leute verloren hat, meldet Grün bis zu dem Tag, an dem es Rot meldet.

3.5 Die Rückmeldung aus der Einstellung kommt spät und wird falsch zugeschrieben. Wenn die Abteilung schließlich versucht, mit starken Neueinstellungen nachzubesetzen, geschehen zwei Dinge. Starke Kandidaten bemerken das Umfeld in den Vorstellungsgesprächen oder in den ersten Monaten und gehen wieder, was Frühfluktuation erzeugt. Diejenigen, die bleiben, werden in die Arbeitsweise des Rückstands aufgesogen. Das Management schreibt dies typischerweise einem angespannten Arbeitsmarkt oder schlechtem Recruiting zu, nicht dem Zustand des Teams, dem die Neuen beitreten. Die beiden Gruppen scheitern hier unterschiedlich. Starke Entwickler werden gefunden und dann verloren: Sie nehmen an, sehen das Umfeld und gehen innerhalb des Jahres. Starke Administratoren werden häufiger gar nicht gefunden: Der niederländische Pool ist dünner, die Starken sind bereits bei Dienstleistern oder waren selbstständig, und die Stelle bleibt monatelang offen, was das Management als Marktsignal statt als Zusammensetzungssignal liest.

3.6 Die Rückkopplungsschleife verstärkt sich selbst. Jeder Austritt eines fähigen Entwicklers macht das Umfeld für den nächsten weniger attraktiv, erhöht die Last auf den Verbleibenden und senkt die Qualitätsmesslatte, an der Neueinstellungen gemessen werden. Der Effekt beschleunigt sich, während jeder Indikator, den das Management liest, tolerabel aussieht. Wenn sich die Lieferkennzahlen bewegen, hat die Abteilung das überschritten, was wir den Lock-in-Punkt nennen: den Zustand, in dem das verbleibende Team eine starke Neueinstellung nicht mehr aufnehmen oder halten kann.

Die Verzögerung ist also kein Aufmerksamkeitsversagen. Sie ist das vorhersehbare Ergebnis davon, Personalabgang als Zählung zu messen, Stabilität als Gesundheit zu lesen und sich für Informationen über das Verlorene auf die Überlebenden zu verlassen.

Abbildung 1 zeichnet die sechs Mechanismen als zwei verstärkende Rückkopplungsschleifen und markiert, wo die Instrumente der Organisation angebracht sind. Beide Schleifen laufen über den Austritt starker Entwickler. Die erste (R1) läuft über die Arbeitslast: Jeder Austritt erhöht die Last auf den Verbleibenden und senkt die Attraktivität des Bleibens. Die zweite (R2) läuft über die Beurteilung: Jeder Austritt entfernt jemanden, der Arbeit beurteilen und Neue einarbeiten kann, was die Qualitätsmesslatte senkt und die nächste starke Neueinstellung früh gehen lässt. Die Instrumente, die das Management liest, Fluktuationsrate, Personalbestand und Lieferkennzahlen, sind an der Peripherie der Schleifen angebracht, an den Punkten, die sich zuletzt bewegen. Die Variablen im Zentrum, der Anteil starker Entwickler und die Konzentration des Wissens, haben überhaupt kein Instrument.

4. Ein Phasenmodell des verzögerten Totes-Meer-Effekts

Die Mechanismen in Abschnitt 3 entfalten sich in einer erkennbaren Reihenfolge. Wir bei Nashua beschreiben sie als fünf Phasen, unterschieden durch die Lücke zwischen dem, was das Management beobachtet, und dem, was im Team geschieht (Abbildung 2). Die Phasen sind geordnet, nicht terminiert: Die Dauer jeder Phase hängt von der Organisation ab, und wir ordnen ihnen absichtlich keine Dauern zu.

Phase 4 ist der Angelpunkt. Vor ihr kann sich die Abteilung noch durch gewöhnliche Bindungs- und Einstellungsmaßnahmen erholen. Nach ihr verhindern die Normen, die Last und die Wissenslücken des verbleibenden Teams, dass starke Neueinstellungen Fuß fassen, sodass dieselben Maßnahmen scheitern und als Marktproblem missdeutet werden. Das erste eindeutige Signal für das Management (Phase 5) kommt eine volle Phase nach dem letzten Zeitpunkt, an dem eine konventionelle Intervention noch gewirkt hätte.

Die beiden Gruppen durchlaufen dieselben fünf Phasen, zeigen aber in jeder unterschiedliche Signaturen, und die Verzögerung zwischen dem, was geschieht, und dem, was gesehen wird, ist bei Administratoren in jeder Phase länger (Tabelle 1). Der Unterschied ist in den Phasen 2 und 5 am größten. In Phase 2 ist die Wissenskonzentration eines Entwicklungsteams in der Versionsverwaltung zumindest für jeden sichtbar, der hinschaut; die eines Betriebsteams ist nur für das Team sichtbar. In Phase 5 scheitert ein Entwicklungsteam an einer Änderung, die geplant ist und deren Kommen daher gesehen wird; ein Betriebsteam scheitert an einem Incident, bei dem das nicht so ist.

Das Modell stellt zwei prüfbare Behauptungen auf. Erstens existiert der Lock-in-Punkt und ist identifizierbar: Für jedes kritische System ist er der Moment, in dem niemand mehr da ist, der es ändern oder wiederherstellen kann, nach dem das Wissen nur noch aus Artefakten rekonstruiert werden kann, falls es welche gibt. Zweitens bleiben die beobachtbaren Indikatoren in der linken Spalte von Abbildung 2 bis Phase 5 innerhalb tolerabler Grenzen, während die messbaren Teameigenschaften in der rechten Spalte (Wissenskonzentration, Qualität der Abgänge, Frühfluktuation) sich von Phase 1 an bewegen. Abschnitt 5 zeigt, dass beides aus einem Modell mit einer Zustandsvariable folgt.

5. Eine formale Behandlung

Das Phasenmodell ist verbal. Um zu prüfen, dass die Verzögerung eine Folge der Mechanismen ist und kein rhetorisches Mittel, schreiben wir das kleinste Modell auf, das sie enthält. Es hat eine Zustandsvariable, den Bus-Faktor eines kritischen Systems, und vier Raten. Alles, was der Beitrag misst (Abschnitt 6), und alles, worauf die Fallstudie beruht (Abschnitt 7), lässt sich direkt daraus ablesen, und der Unterschied zwischen den beiden Gruppen geht als Unterschied darin ein, was Wissen ist und wie sein Verlust beobachtet wird, nicht als Unterschied in Parametern, die zur Anpassung gewählt wurden.

5.1 Aufbau

Betrachten wir ein kritisches System und sei $k(t)$ die Zahl der Personen, die es ändern oder wiederherstellen können: sein Bus-Faktor. Vier Dinge geschehen mit $k$, jedes an einen Mechanismus aus Abschnitt 3 gebunden.

1. Austritt. Jeder Wissende geht mit Hazardrate $\lambda$ pro Jahr und nimmt das Wissen mit: $k \to k-1$ mit Rate $\lambda k$. Dies ist der Totes-Meer-Effekt selbst; $\lambda$ ist die Austrittsrate der Personen, die kritisches Wissen halten, und das sind nach Websters Argument und Abschnitt 2.2 die Starken.

2. Transfer. Jeder Wissende bildet mit Rate $\tau$ pro Jahr einen Kollegen aus: $k \to k+1$ mit Rate $\tau k$. Transfer braucht eine Quelle. Wenn $k = 0$, gibt es niemanden, von dem man lernen könnte, was der Lock-in-Punkt aus Abschnitt 4 ist, nun exakt: Ein System ist im Lock-in, wenn sein Bus-Faktor null erreicht, weil aus diesem Zustand interner Transfer unmöglich ist.

3. Rekonstruktion aus Artefakten. Wenn $k = 0$, kann ein Neuer das Wissen aus dem, was das System hinterlassen hat, mit Rate $\alpha$ rekonstruieren. Bei Software machen Code, Tests und Schemata $\alpha$ nennenswert; bei administrierten Systemen, deren Wissen prozedural ist, liegt $\alpha$ nahe null. Dies ist der eine strukturelle Unterschied zwischen den Gruppen.

4. Beobachtung. Das System wird mit Rate $\mu$ pro Jahr von einem Ereignis getroffen, das tiefes Wissen erfordert: eine Änderungsanforderung, die seine Interna berührt, oder ein Incident, der mehr als einen Neustart braucht. Ist $k = 0$, wenn das Ereignis eintrifft, ist das Scheitern für das Management sichtbar; andernfalls wird es absorbiert, und nichts wird gesehen. Bei Entwicklern ist $\mu$ die Rate tiefgreifender Änderungen, bei Administratoren die Rate tiefgreifender Incidents, und die zweite ist niedriger.

Nur die ersten drei Raten bewegen $k$; die vierte entscheidet, wann das Management davon erfährt. Mit $\alpha = 0$ ist der Prozess ein linearer Geburts-Todes-Prozess, und die Wahrscheinlichkeit, dass ein System mit $k_0$ Wissenden bis zum Zeitpunkt $t$ null erreicht hat, hat eine geschlossene Form,

und sobald es bei null ist, ist die erwartete Zeit, bis das Management ein Scheitern sieht, einfach

Gleichung (1) sagt, dass ein System mit einem alleinigen Eigentümer ($k_0 = 1$) mit Wahrscheinlichkeit $\lambda(1-e^{-(\lambda-\tau)t})/(\lambda - \tau e^{-(\lambda-\tau)t})$ verloren geht, die gegen eins steigt, wann immer Austritte den Transfer überholen; ein System mit zwei Wissenden geht mit dem Quadrat davon verloren, weshalb der Phase-2-Indikator in Abschnitt 6 die Zahl der Systeme mit Bus-Faktor eins ist. Gleichung (2) ist die Verzögerung aus dem Titel des Beitrags in einem Symbol: Die Lücke zwischen dem Verlust und seiner Erkennung wird davon bestimmt, wie oft das verlorene Wissen gebraucht wird, und von nichts anderem. Eine Abteilung kann sie nur verkürzen, indem sie das Wissen absichtlich braucht, und genau das ist ein Disaster-Recovery-Test.

5.2 Ergebnis: erst der Verlust, später die Erkennung, und bei Administratoren noch später

Tabelle 2 gibt illustrative Raten für die beiden Gruppen und die Ausgangsabdeckung der Fallabteilung aus Abschnitt 7: zwölf kritische Entwicklungssysteme, drei davon mit einem alleinigen Eigentümer, und acht administrierte Systeme, eines davon mit einem alleinigen Eigentümer. Die Werte sind so gewählt, dass sie rund sind und drei in Abschnitt 2.6 begründete Ordnungen respektieren: Starke Entwickler gehen schneller als starke Administratoren; Code kann gelesen werden, nachdem sein Autor gegangen ist, eine Prozedur nicht; und eine Änderung, die tiefes Wissen über ein bestimmtes System erfordert, kommt häufiger als ein Incident, der es erfordert. Abbildung 3 zeigt, was daraus folgt, aus der geschlossenen Form für $\alpha = 0$ und sonst aus Simulation.

Panel A ist das Bild von Phase 2. Die Abdeckung erodiert in beiden Gruppen vom ersten Jahr an, und der Anteil der Systeme mit einem alleinigen Eigentümer, der Indikator, den ein Zusammensetzungs-Dashboard zeigen würde, überschreitet die Hälfte nach 0.9 Jahren bei Entwicklern und 1.8 Jahren bei Administratoren. Der Anteil ohne verbleibende Wissende steigt langsamer, und hier kreuzen sich die Gruppen: Entwickler verlieren Systeme schneller auf null, gewinnen aber einige davon aus dem Code zurück, sodass ihre Kurve bei etwa drei von zehn Systemen abflacht; Administratoren verlieren langsamer, aber ohne etwas, aus dem sich rekonstruieren ließe, verlieren sie weiter und haben ab dem vierten Jahr mehr Systeme auf null als die Entwickler.

Panel B ist das Bild von Phase 5 und die zentrale Behauptung des Beitrags in einer einzigen Abbildung. Bei Entwicklern beträgt die Medianzeit bis zum ersten System ohne Abdeckung 0.6 Jahre und die Medianzeit bis zum ersten sichtbaren Scheitern 1.5 Jahre: eine Erkennungsverzögerung von 0.9 Jahren, in denen das Zusammensetzungs-Dashboard den Verlust gezeigt hätte und das Management-Dashboard nichts. Bei Administratoren kommt die erste Null nach 1.4 Jahren und das erste sichtbare Scheitern nach 3.0: eine Verzögerung von 1.6 Jahren und ein sichtbares Scheitern, das anderthalb Jahre nach dem der Entwickler eintritt. Die langsamere Erosion der Administratoren, die sie wie die stabile Gruppe aussehen lässt, ist genau das, was ihr Scheitern später eintreten lässt, und ihre niedrigere Beobachtungsrate ist das, was es noch später eintreten lässt.

Drei weitere Ergebnisse folgen aus dem Modell und betreffen Abschnitt 8.

1. Transfer schützt den Bestand, nicht die alleinigen Eigentümer. Eine Verdoppelung der Transferrate $\tau$ verlangsamt die Erosion der Abdeckung der Abteilung (der Auslöser bei der Hälfte rückt um ein Jahr oder mehr nach hinten), verschiebt aber die Zeit bis zur ersten Null kaum, weil ein System mit einem einzigen Eigentümer in einem Wettlauf zwischen einem Austritt und einer Übergabe steht, wie auch immer der Durchschnitt der Abteilung aussieht. Wissensverteilung wirkt in Phase 2, an den Systemen, die noch zwei oder mehr Wissende haben; sie kann die Systeme, die bereits bei eins sind, nicht retten.

2. Bindung kauft überall Zeit, aber weniger, als man hoffen würde. Eine Senkung der Austrittsrate um ein Fünftel verschiebt jeden Meilenstein um zwei bis zehn Monate nach hinten. Sie ändert die Form der Kurven nicht und insbesondere nicht die Erkennungsverzögerung, die allein von $\mu$ abhängt.

3. Beobachtung ist ein Hebel, und nur Administratoren brauchen ihn. Ein Disaster-Recovery-Test an jedem administrierten System einmal im Jahr hebt deren effektives $\mu$ von 0.4 auf 1.4. Er verlangsamt den Verlust nicht um einen Tag, verkürzt aber die mediane Erkennungsverzögerung von 1.6 Jahren auf 0.7, sodass das Betriebsteam von seinem ersten verlorenen System im Jahr 2.0 statt im Jahr 3.0 erfährt, solange noch Zeit ist, bei den anderen zu handeln (Strich-Punkt-Linie in Abbildung 3B). Entwickler brauchen diesen Hebel nicht, weil der Änderungskalender ihre Systeme für sie testet.

Tabelle 3 fasst diese Ergebnisse zusammen.

5.3 Was das Modell nicht behauptet

Das Modell ist eine Skizze, keine Kalibrierung. Die Raten sind so gewählt, dass sie rund und richtig geordnet sind, nicht geschätzt; Systeme werden als unabhängig behandelt, obwohl in einer realen Abteilung dieselben Personen mehrere besitzen und ein Austritt mehr als eines entleert; und „kennt das System“ ist binär, wo Kompetenz es nicht ist. Was das Modell aber belegt, hängt nicht von den Werten ab. Gegeben, dass Wissende gehen, dass Transfer eine Quelle braucht und dass das verlorene Wissen nur gelegentlich gebraucht wird, folgen drei Dinge für beliebige Werte: Der Verlust geht seiner Erkennung um eine Lücke voraus, deren erwartete Länge der Kehrwert der Häufigkeit ist, mit der das Wissen gebraucht wird; Systeme mit einem alleinigen Eigentümer sind diejenigen, die verloren gehen, sodass ihre Zahl der Frühindikator ist; und eine Gruppe, deren Wissen prozedural ist und deren Scheitern Incidents statt Änderungen sind, wird später erkannt als eine, deren Wissen in Artefakten liegt und deren Scheitern auf dem Änderungskalender steht. Der niederländische Rahmen geht über $\lambda$ ein, das die CAO-Tabelle für die Stärksten erhöht und das Kündigungsrecht für die Übrigen in keiner Weise senkt, und über die jüngste Schließung des Freelance-Wegs, die den einen Weg beseitigt hat, den ein Arbeitgeber hatte, um $k$ wieder auf eins zu bringen, nachdem es null erreicht hatte.

6. Frühwarnindikatoren

Wenn das Modell zutrifft, sollte die Abteilung aufhören, die Fluktuationsrate zu beobachten, und anfangen, die Zusammensetzung und die Folgen der Austritte zu beobachten. Jeder Indikator in Tabelle 4 entspricht einem Mechanismus aus Abschnitt 3 und bewegt sich in der angegebenen Phase, lange vor den Lieferkennzahlen.

Die Indikatoren sind für beide Gruppen dieselben; ihre Quellen und ihre Zuverlässigkeit sind es nicht (Tabelle 2). Bei Entwicklern lassen sich die beiden Zusammensetzungsindikatoren, die in Phase 2 am meisten zählen, Bus-Faktor und Wissenskonzentration, aus der Versionsverwaltungshistorie berechnen, ohne jemanden zu fragen. Bei Administratoren müssen sie aus Change- und Incident-Aufzeichnungen zusammengesetzt und durch Nachfragen bestätigt werden, was sie sowohl teurer als auch leichter zu umgehen macht. Umgekehrt sind die Phase-1-Indikatoren bei Entwicklern in einer Hinsicht schwieriger: Ein größerer Teil ihrer Austritte geht zu Arbeitgebern, die nach Markt zahlen, sodass die Gehaltslücke beim Austritt aussagekräftig ist, während sie bei Administratoren durch Pensionierungen und Versetzungen verwässert wird und die Frage nach dem bedauerten Abgang zu Austritten gestellt werden muss, die die Fluktuationsrate gar nicht zählt.

Operationale Definitionen, Datenquellen und bekannte Fallstricke für jeden Indikator finden sich in Anhang A. Drei Beobachtungen zu dem Satz. Erstens sind die meisten Indikatoren billig: Mehrere erfordern nur einen anderen Schnitt durch Daten, die die Personalabteilung bereits hält. Zweitens sind die Indikatoren in den Phasen 1 und 2 diejenigen, die zählen, da in Phase 4 der Lock-in-Punkt erreicht ist. Drittens sind die Indikatoren zusammensetzungsbezogen, nicht aggregiert: Sie fragen wer und was, nicht wie viele. Das ist der Wandel, den Dalton et al. (1982) vor vier Jahrzehnten forderten und den das IT-Managementreporting weitgehend nicht vollzogen hat.

7. Eine konstruierte Fallstudie

Die folgende Fallstudie ist konstruiert, nicht beobachtet. Sie existiert, um zu zeigen, wie die fünf Phasen von innerhalb einer Organisation aussehen, und um dem Modell aus Abschnitt 5 einen konkreten Rahmen zu geben. Sie ist kein Bericht über irgendeinen Arbeitgeber, und ihre Zahlen sind illustrativ statt gemessen; ihr Wert liegt darin, dass jedes Ereignis in ihr eines ist, das ein Leser, der in der Unternehmens-IT gearbeitet hat, wiedererkennen wird.

7.1 Ausgangslage

Abteilung R ist die interne IT-Abteilung eines mittelgroßen niederländischen Fertigungsunternehmens. Im Jahr 0 hat sie 60 technische Mitarbeiter: 36 Softwareentwickler in drei Teams (ERP-Integration, Logistik- und Lagersysteme, eine Datenplattform) und 24 Systemadministratoren in zwei (Infrastruktur und Netzwerk; Datenbanken, Speicher und Arbeitsplatz). Sie betreut etwa zwanzig Produktionssysteme, die das Geschäft als kritisch betrachtet, zwölf im Besitz der Entwicklungsteams und acht im Besitz des Betriebs. Die Fluktuation lag ein Jahrzehnt lang bei 10 bis 13% pro Jahr, im Einklang mit den anderen Abteilungen des Unternehmens. Die Vergütung folgt der Unternehmens-CAO: feste Gehaltsstufen mit jährlichen Schritten, sodass ein Senior-Entwickler und ein Senior-Administrator, die bleiben, innerhalb von vier oder fünf Jahren das Ende ihrer Stufe erreichen und danach kein Wachstum mehr sehen. Leistungsbeurteilungen existieren, haben aber keine Auswirkung auf die Vergütung. Mehrere der Administratoren sind über fünfzig.

7.2 Die sechs Jahre

Tabelle 6 fasst zusammen, was das Management-Dashboard der Abteilung in jedem Jahr zeigte und was ein Zusammensetzungs-Dashboard, hätte es existiert, gezeigt hätte. Die Phasen aus Abbildung 2 sind markiert.

Die beiden Gruppen durchlaufen die Phasen versetzt, die Entwickler durchgehend etwa eine Phase voraus, und das Management der Abteilung sieht eine Krise, wo es zwei gibt. Der Zeitverlauf ist ein plausibler Pfad durch das Modell aus Abschnitt 5 bei den Parametern aus Tabelle 2: Die Entwickler von Abteilung R sehen ihr erstes Scheitern im Jahr 5, später als der Median des Modells von 1.5 Jahren, und ihre Administratoren im Jahr 6, dem Doppelten des Medians von 3.0. Im Jahr 1 gehen zwei der stärksten Entwickler der Abteilung innerhalb von vier Monaten. Jeder Austritt hat seine eigene Erklärung, und jede wird für sich genommen akzeptiert; niemand fragt, was sie gemeinsam haben. Beide waren Leistungsträger im obersten Quartil, beide waren seit vier Jahren in derselben Gehaltsstufe, und beide gingen für eine Erhöhung von etwa einem Viertel. Die Fluktuationsrate steigt um einen Prozentpunkt.

Jahr 2 ist ruhig. Der Personalbestand ist um eins gesunken, die Fluktuation ist wieder im Rahmen, und die Systeme, die die beiden Abgänger gebaut haben, laufen weiter. Die Systeme, die sie besaßen, werden dem einen verbleibenden Senior-Entwickler im Integrationsteam zugewiesen, der bereits drei andere besitzt. Auf der Betriebsseite sieht das Jahr noch ruhiger aus. Der Senior-Speicheradministrator geht planmäßig in den Ruhestand, ein Austritt, den niemand bedauert, weil er geplant war; die Backup- und Wiederherstellungsprozeduren, die er fünfzehn Jahre lang von Hand ausführte, werden dem Netzwerkadministrator in einer zweistündigen Besprechung übergeben und nie geübt. Der Senior-Netzwerkadministrator kündigt, um sich selbstständig zu machen, und wird am folgenden Montag auf Tagessatzbasis für dieselbe Arbeit zurückgeholt, was die Abteilung als Einsparung beim Personalbestand verbucht und der Administrator als Verdoppelung seines Einkommens; keines von beiden erscheint in der Fluktuationszahl als bedauerter Verlust. Zwei Nachbesetzungen in der Entwicklung erfolgen auf Junior-Niveau, weil das Budget zwei Juniors oder einen Senior erlaubt und zwei sicherer scheinen. Die Zahl der kritischen Systeme mit einer einzigen wissenden Person steigt auf der Entwicklungsseite von sechs auf acht und auf der Betriebsseite von eins auf vier.

Jahr 3 sieht vom Dashboard her wie das beste Jahr des Zeitraums aus. Die Fluktuation ist die niedrigste seit fünf Jahren, weil die Leute, die gegangen wären, bereits weg sind. Der langjährige Kern wird in der Jahresbeurteilung für Stabilität gelobt. Ein Senior-Entwickler wird ins Datenplattform-Team eingestellt und geht nach sieben Monaten mit der Begründung, nichts ändern zu können; das Austrittsgespräch wird unter „kulturelle Passung“ abgelegt. Niemand außerhalb der Abteilung hat ihre Architektur begutachtet, seit der Integrationsarchitekt gegangen ist. Im Januar beendet die Rechtsabteilung des Unternehmens als Reaktion auf die wieder aufgenommene Durchsetzung der Wet DBA den Vertrag des freiberuflichen Netzwerkadministrators; er lehnt ein Angebot ab, zu einem CAO-Gehalt von etwa der Hälfte seines Tagessatzes zurückzukehren, und die Firewall-Landschaft, die er allein verstand, geht an einen Kollegen über, der nie eine Regel darauf geändert hat. Seit zwei Jahren ist kein Disaster-Recovery-Test durchgeführt worden; die Verfügbarkeit liegt bei 99.9%, und das Betriebsteam wird als Muster an Stabilität hingestellt.

Im Jahr 4 bemerkt das Management, dass Einstellen schwierig ist, und bemerkt es zuerst bei den Entwicklern. Drei Senior-Entwickler werden eingestellt; zwei gehen innerhalb des Jahres. Die angebotene und akzeptierte Erklärung ist der Arbeitsmarkt, und ein externer Recruiter wird beauftragt. Innerhalb der Abteilung hatten die beiden, die gingen, jeweils ein System übernommen, das niemand sonst verstand, ohne dass jemand ihre Arbeit begutachten oder ihre Fragen beantworten konnte. Die Entwicklungsteams haben den Lock-in-Punkt überschritten: Sie können die Leute, die ihren Niedergang umkehren könnten, nicht mehr halten. Die Betriebsteams zeigen dieselbe Phase anders. Eine Senior-Administratorstelle ist das ganze Jahr offen; zwei Kandidaten lehnen das Angebot ab, einer nimmt an und zieht nach einem Gespräch mit dem Team vor Antritt zurück. Weil niemand eingestellt wird, geht niemand früh, und die Vakanz erscheint im Recruiting-Bericht als Marktproblem statt in irgendeiner Abgangszahl.

Im Jahr 5 wird der Niedergang der Entwickler sichtbar. Das ERP-Upgrade, abhängig von der Integrationsschicht, deren Architekt vier Jahre zuvor gegangen ist, verzögert sich um neun Monate. Eine Änderungsanforderung an der Preis-Engine kann nicht eingeplant werden, weil der einzige Entwickler, der sie ändern kann, derjenige ist, der sechs andere Systeme trägt. Die Sache erreicht den Vorstand, dem gesagt wird, die Abteilung habe ein Problem mit Personalabgang. Das Problem mit Personalabgang ist vier Jahre alt; was sich geändert hat, ist, dass es endlich ein Signal erzeugt hat, das das Management liest. Die Betriebsteams, deren Verfügbarkeitszahl noch bei 99.8% liegt, sind nicht Teil des Gesprächs.

Jahr 6 bringt für die Entwickler die Standardauflösung aus Abschnitt 8: Änderungsarbeit wandert zu einem Dienstleister, das interne Entwicklungsteam schrumpft, und die Kosten des Dienstleisters übersteigen das, was ein differenziertes Bindungsbudget im Jahr 1 gekostet hätte, um eine Größenordnung. Es bringt auch, ein Jahr später, die Phase 5 der Betriebsteams. Während einer Speichermigration muss die Lagerdatenbank wiederhergestellt werden; die Wiederherstellung scheitert, weil die vom Speicheradministrator vier Jahre zuvor hinterlassene Prozedur ein Array beschreibt, das drei Jahre zuvor ersetzt wurde, und die einzige Person, die je eine Wiederherstellung auf dem neuen Array durchgeführt hatte, der freiberufliche Netzwerkadministrator war, dessen Vertrag im Jahr 3 beendet wurde. Das Lager steht zwei Tage still. Dem Vorstand, der glaubte, das Problem mit Personalabgang im Vorjahr gelöst zu haben, wird gesagt, dass er ein zweites hat.

7.3 Das kontrafaktische Szenario

Angenommen, Abteilung R hätte das Zusammensetzungs-Dashboard aus Abschnitt 8 vom Jahr 0 an geführt, mit den dort vorgeschlagenen Auslöseschwellen, getrennt für die beiden Gruppen. Die Quote bedauerter Abgänge von 60% im Jahr 1 hätte den Auslöser bei einem Drittel im ersten Quartal nach dem zweiten Austritt überschritten und ein gemeinsames Review durch Entwicklungsleitung und Personalabteilung darüber erzwungen, was die beiden Abgänger gemeinsam hatten. Das Review hätte die Gehaltslücke beim Austritt und die gemeinsame Gehaltsstufe gefunden, und die billigste zu diesem Zeitpunkt verfügbare Intervention, eine Bindungsanpassung für die verbleibenden Entwickler im obersten Quartil, hätte etwa ein Zehntel einer Senior-Nachbesetzung gekostet. Ob sie genehmigt worden wäre, ist eine andere Frage; der Punkt ist, dass die Entscheidung im Jahr 1 statt im Jahr 5 jemandem vorgelegt worden wäre.

Wäre der erste Auslöser ignoriert worden, hätte die Bus-Faktor-Zählung im Jahr 2 den Auslöser bei einem Viertel überschritten, zu einem Zeitpunkt, an dem eine erzwungene Wissensverteilung auf die elf Systeme mit alleinigem Eigentümer noch möglich war, weil die alleinigen Eigentümer noch da waren. Im Jahr 3 hätte sich die Senior-Neueinstellung, die nach sieben Monaten ging, als 50% Frühfluktuation in einer Kohorte von zwei niedergeschlagen, eine Zahl, klein genug, um sie anzuzweifeln, aber groß genug, um die Frage aufzuwerfen, warum die Abteilung ihn nicht halten konnte. Auf der Betriebsseite hätten die Auslöser später und leiser angeschlagen: Die Frage nach dem bedauerten Abgang, zur Pensionierung und zum Freelance-Austritt im Jahr 2 gestellt, hätte die Betriebsteams in einem Jahr, in dem die Fluktuationszahl nichts zeigte, auf 100% bedauerte Verluste gesetzt; der Bus-Faktor-Auslöser bei einem Viertel hätte im selben Jahr bei 4 von 8 angeschlagen; und ein DR-Test-Auslöser, den dieser Beitrag in Anhang A für administrierte Systeme hinzufügt, hätte im Jahr 3 angeschlagen. Jeder Auslöser verschafft der Organisation eine Phase. Die Fallstudie illustriert die zentrale Behauptung des Modells: Die zum Handeln nötige Information existierte an jedem Punkt, und die Instrumente der Organisation waren schlicht nicht darauf gerichtet, und für eine der beiden Gruppen wurde sie nicht einmal erhoben.

7.4 Was die Fallstudie zeigt

Vier Merkmale der Fallstudie übertragen sich auf reale Abteilungen. Erstens war jedes Signal in der linken Spalte von Tabelle 6 wahr und wurde, soweit es reichte, richtig gelesen; das Versagen lag in dem, was nicht gemessen wurde. Zweitens war das Jahr, das am besten aussah (Jahr 3), das letzte Jahr, in dem eine gewöhnliche Intervention bei den Entwicklern gewirkt hätte, und Jahr 4 das letzte bei den Administratoren. Drittens war die rechte Spalte für die Entwickler aus Daten berechenbar, die das Unternehmen bereits hielt, aus Versionsverwaltung, Beurteilungen und Einstellungsunterlagen, musste für die Administratoren aber zusammengesetzt und erfragt werden, weshalb in der Fallstudie niemand es tat. Viertens liefen die beiden Gruppen durchgehend eine Phase auseinander, die Austritte der Administratoren hatten Formen, die die Fluktuationsrate nicht zählt (Ruhestand, Selbstständigkeit, eine unbesetzte Stelle), und ihre Phase 5 kam, nachdem der Vorstand das Problem für gelöst hielt. Eine Abteilung, die ihr technisches Personal als eine Population misst, wird eine Krise sehen und von der zweiten überrascht werden.

8. Implikationen für das IT-Management

Die praktische Schlussfolgerung ist, dass der Zeitpunkt einer Intervention mehr zählt als ihr Inhalt. Dieselben Maßnahmen, die den Effekt in Phase 2 umkehren, scheitern in Phase 4.

8.1 Vor dem Lock-in

In den Phasen 1 bis 3 enthält die Abteilung noch Personen, die Arbeit beurteilen, Neueinstellungen aufnehmen und Wissen weitergeben können. Interventionen hier sind konventionell und durch die Literatur gut gestützt:

• Differenzierte Bindung. Trevor et al. (1997) zeigen, dass Gehaltswachstum der stärkste Hebel auf die Fluktuation von Leistungsträgern ist. Ein auf das oberste Quartil konzentriertes Bindungsbudget bewirkt mehr als eine pauschale Erhöhung. In einem CAO-Umfeld ist das Instrument die Arbeitsmarktzulage (arbeidsmarkttoelage) oder eine Ausnahme von der Gehaltsstufe, die beide die meisten niederländischen Tarifverträge erlauben und die meisten IT-Abteilungen nicht nutzen. Bei Entwicklern ist der Vergleich, den die Zulage schlagen muss, ein Gehalt bei einem Produktunternehmen; bei Administratoren war es bis vor Kurzem ein Freelance-Tagessatz, den keine Zulage schlägt, und seit 2025 ist es ein Gehalt bei einem Dienstleister, das sich schlagen lässt.

• Erzwungene Wissensverteilung. Pairing, Rotation und Dokumentationspflichten erhöhen den Bus-Faktor kritischer Systeme, bevor jemand geht. Das Ziel ist ein messbarer Bus-Faktor von mindestens zwei pro Produktionssystem. Bei Entwicklern ist das weitgehend eine Frage von Code-Review und Rotation über Codebasen. Bei Administratoren ist es eine Frage geübter Prozeduren: eine Wiederherstellung, ein Failover oder eine Zertifikatsrotation, die eine zweite Person tatsächlich unter Aufsicht durchgeführt hat, nach Plan, mit dokumentiertem Ergebnis. Ein Runbook, das nicht geübt wurde, zählt nicht.

• Austrittsgespräche als Muster gelesen. Bedauerte Verluste sollten gemeinsam begutachtet werden, von der Entwicklungsleitung statt von der Personalabteilung allein, mit der ausdrücklichen Frage, was sie gemeinsam haben.

• Externe Bewertung. Periodische Begutachtung von Architektur und Code durch Personen außerhalb des Teams liefert den Bezugspunkt, den das Team selbst, wie Abschnitt 3.4 zeigt, verliert. Für den Betrieb ist das Äquivalent ein Disaster-Recovery-Test, der von jemandem außerhalb des Teams beobachtet wird, und ein Konfigurationsreview; eine Verfügbarkeitszahl ist kein Review.

8.2 Reihenfolge nach Phase

Das formale Modell aus Abschnitt 5 gibt jeder Intervention eine Rate, auf die sie wirkt, und das Phasenmodell gibt jeder ein Fenster, in dem sie noch wirkt. Tabelle 7 bringt beides zusammen. Vor dem Lock-in-Punkt wirken Interventionen auf die Austrittsrate $\lambda$, die Transferrate $\tau$ und, bei Administratoren, die Beobachtungsrate $\mu$; das Modell zeigt, dass Transfer nur Systeme schützt, die noch zwei oder mehr Wissende haben, dass Bindung Monate statt Jahre kauft und dass Beobachtung der eine Hebel ist, der die Verzögerung selbst verkürzt. Nach dem Lock-in-Punkt sind dieselben Hebel im Prinzip noch verfügbar, aber es ist nichts mehr da, woran man sie ansetzen könnte: Wissensverteilung hat keine Quelle, Bindung hat niemanden Kritischen mehr zu binden, und eine starke Neueinstellung, die einem System mit Bus-Faktor null zugewiesen wird, hat niemanden, von dem sie lernen könnte, und geht oder rekonstruiert langsam aus den vorhandenen Artefakten. Die Optionen nach dem Lock-in wirken stattdessen auf die Struktur der Abteilung, weshalb sie auf eine andere Managementebene gehören.

8.3 Ein Zusammensetzungs-Dashboard

Die Indikatoren aus Abschnitt 6 sind nur nützlich, wenn jemand sie gemeinsam betrachtet, im richtigen Takt, mit der Befugnis zu handeln. Drei Gestaltungsentscheidungen folgen aus dem Modell.

Eigentümer. Das Dashboard gehört der Entwicklungsleitung, nicht der Personalabteilung. Die Personalabteilung besitzt die Fluktuationsrate und ist dafür der richtige Eigentümer, aber die Zusammensetzungsindikatoren erfordern technisches Urteil (welche Systeme kritisch sind, wer stark ist) und technische Daten (Versionsverwaltung). Ein Dashboard, das die Personalabteilung zusammenstellt und die Entwicklung empfängt, wiederholt das Survivorship-Problem aus Abschnitt 3.4 in neuer Form.

Takt. Quartalsweise, mit einem rollierenden Fenster von vier Quartalen. Eine jährliche Überprüfung ist zu langsam: In der Fallstudie aus Abschnitt 7 wurde der Lock-in-Punkt zwischen zwei Jahresüberprüfungen erreicht. Monatlich ist für eine Abteilung von sechzig zu verrauscht, wo ein einzelner Austritt die meisten Quoten um mehrere Punkte bewegt.

Schwellen. Jeder Indikator braucht eine im Voraus vereinbarte Auslöseschwelle, weil eine nachträglich vereinbarte Schwelle dort gesetzt wird, wo der aktuelle Wert gerade liegt. Vernünftige Ausgangspunkte, anzupassen, sobald eine Abteilung zwei Jahre eigener Historie hat: eine Quote bedauerter Abgänge über einem Drittel; mehr als ein Viertel der kritischen Systeme mit Bus-Faktor eins; Frühfluktuation über einem Viertel in irgendeiner Kohorte; und zwei aufeinanderfolgende Senior-Neueinstellungen, die innerhalb eines Jahres gehen. Ein Auslöser schreibt keine bestimmte Handlung vor; er schreibt ein Review durch jemanden außerhalb der Abteilung vor.

8.4 Nach dem Lock-in

In den Phasen 4 und 5 scheitert Nachbesetzung aus zwei Gründen. Der erste ist Brooks’ (1975) Gesetz in neuer Form: Personen zu einem Team hinzuzufügen, dem die Kapazität fehlt, sie einzuarbeiten, verlangsamt das Team und treibt die Neuen hinaus. Der zweite ist, dass die Qualitätsmesslatte der Neueinstellung vom Team gesetzt wird, dem sie beitritt, sodass eine starke Neueinstellung sich entweder nach unten anpasst oder geht. Drei Optionen bleiben, keine davon billig:

1. Ein neuer Kern. Ein separates Team mit eigenen Normen aufbauen, von außen besetzt, und Systeme im Lauf der Zeit dorthin migrieren. Das bestehende Team wird nicht aufgelöst, ist aber nicht mehr der Standard der Organisation.

2. Kontrollierter Niedergang. Akzeptieren, dass die Abteilung warten, aber nicht ändern kann, den Umfang entsprechend einfrieren und den Ersatz von Systemen statt der Erneuerung des Teams planen.

3. Externe Kapazität. Änderungsarbeit zu Dienstleistern oder Partnern verlagern, während das interne Team den Betrieb behält. Das ist oft, was standardmäßig und unerkannt geschieht, und bei ehrlicher Rechnung die teuerste der drei. In den Niederlanden hat sich diese Option seit 2025 verengt: Der auf Tagessatzbasis zurückgeholte freiberufliche Administrator, jahrelang der Standardweg, verlorenes Wissen in Reichweite zu halten, ist für den Arbeitgeber nun ein Scheinselbstständigkeitsrisiko, und die Alternative, ein Managed-Service-Vertrag, verlagert das Wissen dauerhaft aus der Organisation.

Der gemeinsame Faden ist, dass die Erholung nach dem Lock-in eine strukturelle Entscheidung ist, die auf einer Ebene über der IT-Abteilung getroffen wird. Die Abteilung selbst kann sie, per Definition des Lock-in, nicht treffen.

9. Diskussion: warum die Verzögerung fortbesteht

Wenn die Indikatoren billig und die Mechanismen nicht obskur sind, warum besteht die Verzögerung fort? Ein Teil der Antwort ist, dass niemand die Messung aufgeschrieben hat, was dieser Beitrag zu beheben versucht. Der größere Teil aber ist, dass die Verzögerung durch Merkmale der Art festgehalten wird, wie Organisationen geführt werden, und diese verdienen es, benannt zu werden, weil ein Indikator, der ihnen zuwiderläuft, ignoriert wird.

Geteiltes Eigentum am Signal. Fluktuation ist eine HR-Kennzahl; Lieferung ist eine IT-Kennzahl. Die Zusammensetzung der Austritte fällt dazwischen. Die Personalabteilung sieht, dass jemand gegangen ist und warum er sagte, dass er geht; die Entwicklung sieht, dass ein System schwer zu ändern geworden ist. Keine von beiden sieht, dass dies dasselbe Ereignis ist, weil kein Bericht sie verbindet. Das Zusammensetzungs-Dashboard aus Abschnitt 8 ist, mechanisch gesehen, ein Join zwischen zwei führenden Systemen, die normalerweise nicht verbunden werden.

Taktungleichheit. Der Effekt entfaltet sich über Jahre; die Aufmerksamkeit des Managements ist in Quartalen und Jahresüberprüfungen organisiert. Ein langsamer Prozess, in schnellem Takt beobachtet, sieht aus wie Rauschen, und die Bewegung jedes Quartals ist klein genug, um den besonderen Umständen des Quartals zugeschrieben zu werden. Dalton et al. (1982) argumentierten vor vier Jahrzehnten, dass Fluktuation charakterisiert statt gezählt werden sollte; das Argument setzte sich nicht durch, weil Charakterisieren den Blick über Takte hinweg erfordert und nichts im Jahreszyklus das belohnt.

Jeder Austritt bekommt eine Geschichte. Menschen gehen aus Gründen, und die Gründe sind wahr: ein Umzug ins Ausland, ein Start-up, die Stelle des Partners. Die Organisation akzeptiert jede Geschichte, weil jede zutrifft. Was die Geschichten gemeinsam haben, dass der Abgänger stark, relativ zum Markt unterbezahlt und in der Lage war zu gehen, ist nie der genannte Grund und wird deshalb nie aggregiert. Die Quote bedauerter Abgänge existiert, um diese Aggregation zu erzwingen.

Stabilität wird belohnt. Niedrige Fluktuation wird als gutes Management gelesen und ist oft ein explizites Managementziel. In der Fallstudie aus Abschnitt 7 war das Jahr der niedrigsten Fluktuation das Jahr, in dem die Abteilung gelobt wurde, und es war auch das Jahr, in dem der Lock-in-Punkt überschritten wurde. Ein Ziel für die Fluktuationsrate ohne ein Ziel für ihre Zusammensetzung belohnt genau das Ergebnis, vor dem das Modell warnt: Die Starken sind gegangen, und die Übrigen bleiben.

Die sichtbaren Kosten landen in jemand anderes Budget. Die Einsparungen durch langsame Nachbesetzung und Junior-Einstellungen erscheinen im Jahr, in dem sie gemacht werden, im eigenen Budget der Abteilung. Die Kosten erscheinen Jahre später, in Form eines Dienstleistervertrags, eines verzögerten Programms oder einer gescheiterten Änderung, und werden einem Programm, einer Dienstleisterposition oder einem Einmalposten zugebucht. Die Abteilung, die die Kosten verursacht hat, ist selten die, der sie belastet werden, und die Buchhaltung schließt daher nie die Schleife, die Abbildung 1 zeichnet.

Die Gehaltstabelle ist die Decke. Bei den meisten großen niederländischen Arbeitgebern und im gesamten öffentlichen Sektor ist die technische Vergütung eine CAO-Tabelle mit jährlichen Stufen. Ein starker Entwickler oder Administrator erreicht das Ende der Tabelle in wenigen Jahren, danach führt der einzige Weg zu höherer Vergütung über die Beförderung aus der technischen Arbeit heraus oder über den Austritt. Die Tabelle ist darauf ausgelegt, über die Organisation hinweg fair zu sein; ihre Wirkung auf die technische Population ist, die Bedingung zu garantieren, unter der die Stärksten gehen. Die meisten CAOs erlauben Ausnahmen, in Form einer Arbeitsmarktzulage oder der Einstufung in eine höhere Gehaltsstufe, und die meisten IT-Abteilungen wissen das nicht oder nutzen es nicht.

Der Rückstand ist geschützt. Das niederländische Kündigungsrecht verlangt einen vernünftigen Grund, eine präventive Prüfung durch das UWV oder den Kantonrichter und eine gesetzliche Übergangsvergütung. Das ist ein Merkmal des Systems, kein Fehler, aber es bedeutet, dass die Zusammensetzung eines Teams, einmal verschlechtert, nicht von unten korrigiert werden kann; der einzige verbleibende Hebel ist oben. Organisationen, die den Totes-Meer-Effekt als Problem des Leistungsmanagements behandeln, das durch Entfernen schwacher Mitarbeiter zu lösen sei, werden in den Niederlanden feststellen, dass er so nicht gelöst werden kann, und tun besser daran, ihn zu verhindern.

Die Indikatoren brauchen Zustimmung. Die Indikatoren aus Abschnitt 6 verarbeiten personenbezogene Daten gegenwärtiger und früherer Mitarbeiter, und mehrere von ihnen, insbesondere das Leistungsquartil der Abgänger und die Einstufung als bedauerter Verlust, stellen ein System zur Leistungsüberwachung dar. Nach Artikel 27 des niederländischen Betriebsrätegesetzes hat der Betriebsrat ein Zustimmungsrecht bei Regelungen zur Verarbeitung von Personaldaten und zur Überwachung von Mitarbeitern (Wet op de ondernemingsraden, art. 27 lid 1), und die Datenschutz-Grundverordnung verlangt einen dokumentierten Zweck und einen Löschplan. Nichts davon verhindert das Dashboard; es bedeutet aber, dass sein Aufbau eine mit dem Betriebsrat getroffene Entscheidung ist, nicht eine der Entwicklungsleitung allein, und dass die Daten über Abgänger eine Aufbewahrungsfrist haben, nach der sie aggregiert oder gelöscht werden müssen. Eine Abteilung, die mit dem Messen beginnen will, sollte dieses Gespräch zuerst beginnen.

Die Überlebenden schreiben die Berichte. Das ist Abschnitt 3.4, als institutionelle Tatsache neu formuliert: Die Menschen mit dem geringsten Anreiz, über Verfall zu berichten, und der geringsten Fähigkeit, ihn zu sehen, sind diejenigen, von denen die Organisation ihre Informationen über das Team bezieht. Externes Review (Abschnitt 6) ist das einzige Heilmittel, und es ist aus demselben Grund unbeliebt, aus dem es notwendig ist.

Keines dieser Merkmale ist für sich genommen irrational. Zusammen garantieren sie, dass eine Abteilung in Phase 5 von ihrer Zusammensetzung erfährt. Sie zu ändern ist schwerer, als Indikatoren hinzuzufügen, aber die Indikatoren sind der Ausgangspunkt, weil sie die Merkmale sichtbar machen.

10. Grenzen und weitere Forschung

Dies ist theoretische Forschung. Drei Grenzen folgen daraus.

Selektion in der Evidenz. Die Mechanismen in Abschnitt 3 sind aus Fällen gewonnen, in denen der Effekt auftrat und schließlich erkannt wurde. Abteilungen, die ihn vermieden haben oder in denen fähige Entwickler ohne den vorhergesagten Verfall gingen, erscheinen in der Praktikeraufzeichnung nicht. Das Modell könnte daher überzeichnen, wie oft der Abgang starker Leistungsträger zum Lock-in führt.

Messung von „stark“. Sowohl Websters Essay als auch dieser Beitrag nehmen an, dass technische Kompetenz geordnet werden kann. In der Praxis sind Leistungsbeurteilungen in der IT verrauscht, und die Personen, die am besten urteilen könnten, sind nach der Logik des Modells selbst diejenigen, die gegangen sind. Jeder empirische Test braucht ein Kompetenzmaß, das vom untersuchten Team unabhängig ist.

Stilisierung des Modells und der Fallstudie. Das formale Modell aus Abschnitt 5 behandelt Systeme als unabhängig, Wissen als binär und Raten als konstant; die Fallstudie aus Abschnitt 7 ist ein Komposit. Beide sind Mittel, um zu zeigen, dass die Argumentation kohärent ist, nicht Belege, dass sie wahr ist. Die drei qualitativen Ergebnisse aus Abschnitt 5 hängen nicht von den Ratenwerten ab; die genannten Jahre schon, und in jeder realen Abteilung müssten die Raten aus den Aufzeichnungen geschätzt werden, die Anhang A beschreibt.

Generalisierung. Die Argumentation ist auf IT-Abteilungen innerhalb großer niederländischer Organisationen aufgebaut, wo implizites Systemwissen konzentriert ist, die Vergütung einer kollektiven Tabelle folgt, Kündigung geschützt ist und sich der Freelance-Weg kürzlich verengt hat. Sie überträgt sich möglicherweise nicht auf Softwareproduktunternehmen, Beratungen oder kleine Teams, wo die in Abschnitt 2.2 identifizierten Bedingungen anders sind, und nicht unverändert auf Märkte ohne kollektive Gehaltstabellen oder mit jederzeit kündbaren Arbeitsverhältnissen, wo der Rückstand aus Websters Metapher entfernt werden kann statt nur verhindert. Die Zweiteilung ist selbst eine Vereinfachung: Data Engineers, Platform Engineers und Site-Reliability-Engineers sitzen zwischen den Gruppen, und die Zahlen des Beitrags für sie müssten gesondert ausgearbeitet werden.

Das Modell liefert Hypothesen, die spezifisch genug sind, um widerlegt zu werden. Tabelle 8 formuliert sie mit den Daten, die jede erfordert.

Drei Studiendesigns würden diese Hypothesen direkt prüfen:

1. Retrospektive Zusammensetzungsanalyse. Für Abteilungen, die sichtbaren Niedergang erlebt haben, das Leistungsquartil und den Systembesitz jedes Abgängers über die vorangegangenen Jahre aus HR- und Versionsverwaltungsaufzeichnungen rekonstruieren. Das Modell sagt voraus, dass die Qualität der Abgänger sank und die Wissenskonzentration stieg, mehrere Jahre bevor sich die Lieferkennzahlen bewegten.

2. Erkennungsverzögerung nach Gruppe. Für jedes kritische System, das Bus-Faktor null erreicht hat, die Zeit bis zum ersten ihm zugeschriebenen Scheitern messen und Softwaresysteme mit administrierten Systemen sowie getestete mit ungetesteten Systemen vergleichen. Das Modell sagt eine längere Verzögerung bei administrierten Systemen und eine kürzere dort voraus, wo Disaster-Recovery-Tests durchgeführt werden; eine Verzögerung, die sich durch Testen nicht verkürzt, würde die Darstellung der Beobachtung im Modell widerlegen.

3. Indikatorvalidierung. Wo die Indikatoren aus Abschnitt 6 erhoben wurden, prüfen, ob sie den Liefer- und Incident-Kennzahlen vorauslaufen, und um wie lange. Das ist die Studie mit dem direktesten Managementnutzen und den geringsten Datenanforderungen.

Die Versionsverwaltungshistorie ist für alle drei eine zu wenig genutzte Quelle. Commit-Autorschaft, Review-Beteiligung und Dateibesitz im Zeitverlauf liefern eine längsschnittliche Aufzeichnung darüber, wer was wusste, unabhängig von HR-Beurteilungen, in genau den Organisationen, die das Modell beschreibt.

11. Schlussfolgerung

IT-Organisationen erkennen den Totes-Meer-Effekt spät, weil ihre Messsysteme so gebaut sind, dass sie ihn verfehlen. Fluktuation wird gezählt statt charakterisiert, betriebliche Stabilität wird als Gesundheit gelesen, und die Menschen, die den Verlust melden könnten, sind diejenigen, die gegangen sind. Wir bei Nashua haben ein Fünfphasenmodell vorgeschlagen, in dem diese Mechanismen einen Lock-in-Punkt eine volle Phase vor dem ersten eindeutigen Signal an das Management erzeugen, sowie einen Satz von Zusammensetzungsindikatoren, die sich früher bewegen würden. Das Modell ist mit Daten prüfbar, die die meisten Organisationen bereits besitzen.

Für Softwareentwickler lautet die Schlussfolgerung, dass der Effekt schnell ist, für jeden sichtbar, der hinschaut, und umkehrbar, wenn er früh erkannt wird. Starke Entwickler gehen rasch zu marktbezahlter Arbeit, ihr Austritt wird als Personalabgang erfasst, ihr Wissen steckt teilweise im Code, und die Zusammensetzung des Teams lässt sich aus der Versionsverwaltung ablesen. Im Modell geht das erste System nach gut einem Jahr verloren, und der Verlust wird nach etwa drei gesehen, eine Verzögerung von unter zwei Jahren. Die Hebel sind Vergütung und Transfer: ein differenziertes Bindungsbudget innerhalb des Spielraums, den die meisten niederländischen Tarifverträge bereits erlauben, und Wissensverteilung, angewandt, bevor Systeme einen einzigen Eigentümer erreichen, da das Modell zeigt, dass sie sie danach nicht mehr retten kann.

Für Systemadministratoren lautet die Schlussfolgerung, dass der Effekt langsam ist, für jeden unsichtbar, der nicht fragt, und schwerer zu beheben. Starke Administratoren gehen langsamer, auf Wegen, die die Fluktuationsrate nicht zählt (Ruhestand, Versetzung, bis 2025 Selbstständigkeit und die unbesetzte Stelle), ihr Wissen ist prozedural und hinterlässt kein Artefakt, und die Zusammensetzung des Teams kann nicht berechnet werden; sie muss aus dünnen Aufzeichnungen zusammengesetzt und durch Nachfragen bestätigt werden. Im Modell geht das erste System nach knapp drei Jahren verloren, und der Verlust wird nach fast sechs gesehen, eine Verzögerung von drei Jahren, die keine Bindungsmaßnahme verkürzt, weil die Verzögerung davon bestimmt wird, wie selten das verlorene Wissen gebraucht wird. Der Hebel ist Übung: geübte Übergaben und Disaster-Recovery-Tests, die von jemandem außerhalb des Teams beobachtet werden, die, wie das Modell zeigt, die Verzögerung von drei Jahren auf sechs Monate verkürzen, ohne den Verlust um einen Tag zu verlangsamen, und die kein Entwicklungsteam braucht, weil sein Änderungskalender dieselbe Arbeit tut.

Warum die Verzögerung der Administratoren die längere ist, folgt aus drei Unterschieden, die das Modell auseinanderhält. Erstens ist die Verzögerung der Kehrwert der Häufigkeit, mit der das verlorene Wissen gebraucht wird, Gleichung (2): Das Wissen der Entwickler wird auf dem Änderungskalender ausgeübt, wo eine Änderung, die es braucht, alle zwei oder drei Jahre pro System kommt, während das Wissen der Administratoren auf dem Incident-Kalender ausgeübt wird, wo ein Failover, eine Wiederherstellung oder ein Upgrade, das es braucht, etwa halb so oft kommt, sodass die Lücke zwischen dem Verlust des Wissens und der Entdeckung des Verlusts doppelt so lang ist. Zweitens steckt das Wissen eines Entwicklers teilweise im Code und kann daraus rekonstruiert werden; das eines Administrators ist prozedural und hinterlässt kein Artefakt, sodass ein administriertes System, das einmal Bus-Faktor null erreicht hat, dort bleibt, was den Zeitraum verlängert, in dem der Verlust real und unsichtbar ist. Drittens steht das Scheitern der Entwicklung auf dem Änderungskalender und wird kommen gesehen, als Programm, das sich verzögert, oder Änderung, die nicht eingeplant werden kann; das Scheitern der Administration steht auf dem Incident-Kalender und kommt ohne Anlauf, als Wiederherstellung, die an dem Tag scheitert, an dem sie gebraucht wird. Dass Administratoren zudem langsamer gehen, verzögert den Verlust selbst, nicht aber seine Entdeckung, weshalb das Heilmittel für sie Übung statt Vergütung ist: Eine geübte Übergabe oder ein beobachteter Wiederherstellungstest ist ein absichtlich angesetztes Ereignis, das das Wissen braucht, und es zieht die Entdeckung vor, ohne auf den Incident zu warten.

Für beide Gruppen ist die praktische Botschaft dieselbe, und im niederländischen Rahmen hat sie eine besondere Schärfe. Die Frage, die zum Personalabgang zu stellen ist, lautet nicht, wie viele gegangen sind, sondern wer, was sie mitgenommen haben und ob noch jemand da ist, der es bemerken würde. In einem Markt, in dem der Rückstand nicht gekündigt werden kann und die Stärksten nach Tabelle bezahlt werden, ist der einzige Zeitpunkt, sie zu beantworten, vor dem Lock-in-Punkt, und der einzige Weg, sie für Administratoren zu beantworten, ist zu fragen.

Anhang A. Messung der Indikatoren

Dieser Anhang gibt für jeden Indikator in Tabelle 4 eine operationale Definition, eine Datenquelle und den wichtigsten Fallstrick. Alle lassen sich quartalsweise aus Aufzeichnungen berechnen, die die meisten Organisationen bereits führen; keiner erfordert eine Umfrage.

Quote bedauerter Abgänge. Bei jedem freiwilligen Austritt beantwortet der Vorgesetzte des Abgängers eine Frage, die von der Personalabteilung festgehalten wird: Hätten Sie ein Gegenangebot gemacht, um diese Person zu halten? Die Quote ist die Zahl der bedauerten Austritte geteilt durch alle freiwilligen Austritte über vier rollierende Quartale. Fallstrick: Vorgesetzte urteilen rückblickend großzügiger, sobald bekannt ist, dass ein Austritt geschadet hat; die Antwort innerhalb einer Woche nach der Kündigung erheben.

Leistungsquartil der Abgänger. Die Position jedes Abgängers in der Leistungsverteilung der Abteilung, aus dem Mittel seiner letzten beiden Beurteilungen vor der Kündigung. Den Anteil der Abgänger aus dem obersten Quartil berichten. Fallstrick: Zur Mitte komprimierte Beurteilungen verbergen das Signal; wo Beurteilungen nicht aussagekräftig sind, durch eine erzwungene Rangordnung durch zwei Vorgesetzte beim Austritt ersetzen.

Gehaltslücke beim Austritt. Mediane prozentuale Differenz zwischen der neuen Gesamtvergütung des Abgängers und seiner bisherigen, aus Austrittsgesprächen. Fallstrick: Abgänger untertreiben oder verweigern die Antwort; eine Antwortquote unter der Hälfte macht die Zahl unzuverlässig, und die Antwortquote selbst ist dann der Indikator.

Bus-Faktor pro kritischem System. Die Zahl der Personen, die verloren gehen könnten, bevor niemand Verbleibender das System mehr ändern oder wiederherstellen kann. Für Systeme unter Versionsverwaltung lässt er sich aus der Historie berechnen, ohne jemanden zu fragen. Die Methode von Avelino et al. (2016) weist jedem Entwickler $d$ für jede Datei $f$ einen Autorschaftsgrad zu,

wobei $\mathrm{FA}$ 1 ist, wenn $d$ die Datei erstellt hat, $\mathrm{DL}$ die Zahl der Änderungen ist, die $d$ daran vorgenommen hat, und $\mathrm{AC}$ die Zahl der Änderungen durch andere. Ein Entwickler gilt als Kenner einer Datei, wenn sein normalisierter DOA mindestens 0.75 des Maximums der Datei beträgt und der Absolutwert mindestens 3.293 ist. Der Bus-Faktor ergibt sich dann, indem Entwickler in der Reihenfolge der gekannten Dateien entfernt werden, bis mehr als die Hälfte der Dateien des Systems keinen verbleibenden kundigen Entwickler mehr hat. Für administrierte Systeme, die meist außerhalb der Versionsverwaltung liegen, wird dieselbe Idee auf andere Aufzeichnungen darüber angewandt, wer was getan hat: Change-Management-Tickets pro System, Incident-Lösungen pro System, Mitgliedschaft in der Rufbereitschaftsrotation und, wo Infrastruktur als Code definiert ist, das Konfigurations-Repository. Eine Person gilt als Kenner eines administrierten Systems, wenn sie im letzten Jahr Changes oder Incidents daran abgeschlossen hat, ohne an jemand anderen zu eskalieren. Fallstrick: Diese Aufzeichnungen sind dünner als die Commit-Historie und schreiben Arbeit oft dem zu, der das Ticket eingereicht hat, statt dem, der sie erledigt hat; für die kritischsten Systeme die berechnete Zahl bestätigen, indem man das Team bittet zu benennen, wer das System von null wiederherstellen könnte, und ein Zögern als Bus-Faktor eins behandeln.

Wissenskonzentrationsindex. Der Anteil kritischer Systeme, deren Bus-Faktor eins ist. „Kritisch“ sollte vom Geschäft definiert werden (Systeme, deren Ausfall Umsatz oder Compliance stoppt), nicht von der IT. Fallstrick: Der Index lässt sich durch Aufteilen von Systemen manipulieren; die Systemliste für mindestens ein Jahr festschreiben.

Zahl verwaister Systeme. Die Zahl kritischer Systeme, deren Autor oder Hauptbetreuer gegangen ist und die ohne eine Übergabephase von mindestens einem Monat Überlappung einem bestehenden Eigentümer neu zugewiesen wurden. Bei administrierten Systemen eine Übergabe nur dann als real zählen, wenn der neue Eigentümer die kritischen Prozeduren (Wiederherstellung, Failover, Zertifikatsrotation) mindestens einmal unter Aufsicht ausgeführt hat; ein ungeübt übergebenes Runbook ist keine Übergabe. Quelle: Systemeigentümerregister, abgeglichen mit Austrittsdaten. Fallstrick: Eigentümerregister werden selten gepflegt; die erste Berechnung erfordert gewöhnlich die Rekonstruktion des Registers, was selbst aufschlussreich ist.

Schiefe der Betriebszugehörigkeit. Das Verhältnis der Mitarbeiter mit mehr als fünf Jahren Betriebszugehörigkeit zu denen mit weniger als zwei, getrennt für Entwickler und Administratoren berechnet. Eine gesunde Abteilung, die sich erneuert, liegt nahe eins; eine Abteilung, deren Zustrom versiegt ist oder nicht bleibt, steigt über zwei. Fallstrick: Eine Reorganisation, die Personen zwischen Abteilungen verschiebt, setzt in manchen HR-Systemen die Zugehörigkeit zurück; die Zugehörigkeit zum Arbeitgeber verwenden, nicht zur Kostenstelle.

Häufigkeit externer Reviews. Die Zahl der Gelegenheiten pro Jahr, bei denen Code, Architektur oder Betriebspraxis von jemandem außerhalb des Teams bewertet wurden: ein Architekturgremium, ein Sicherheitsaudit mit besprochenen Feststellungen, das Review einer Nachbarabteilung, die Einschätzung eines externen Beraters. Nur Reviews zählen, die schriftliche Feststellungen hervorgebracht haben. Fallstrick: Compliance-Audits, die Dokumente statt Systeme prüfen, sollten nicht gezählt werden.

Frühfluktuation. Für jede Einstellungskohorte (Einstellungen in einem gegebenen Halbjahr) der Anteil derer, die innerhalb von zwölf Monaten nach ihrem Startdatum gegangen sind. Nach Kohorte berichten, nicht nach Kalenderjahr, sodass die Zahl für eine Kohorte einmal bekannt ist und nicht driftet. Fallstrick: Die Zahl hinkt konstruktionsbedingt ein Jahr hinterher; sie mit der Angebotsannahmequote koppeln, die das nicht tut.

Angebotsannahmequote für Seniorrollen. Der Anteil der Angebote für Seniorpositionen, die angenommen wurden, über vier rollierende Quartale, und die festgehaltenen Gründe für Absagen. Fallstrick: Recruiter halten den Grund fest, der am wenigsten auf den Prozess zurückfällt; wo möglich den Kandidaten direkt fragen.

Aktualität des Disaster-Recovery-Tests (Administratoren). Für jedes kritische administrierte System die Zahl der Monate, seit eine Wiederherstellung, ein Failover oder ein Neuaufbau zuletzt vollständig von jemand anderem als dem Haupteigentümer durchgeführt wurde, mit dokumentiertem Ergebnis. Dieser Indikator hat kein Gegenstück in der Entwicklung und wird hier hinzugefügt, weil die Fallstudie aus Abschnitt 7 von ihm abhängt. Auslöser: jedes kritische System über zwölf Monaten oder jedes System, dessen letzter Test nur von einer Person durchgeführt wurde, die seither gegangen ist. Fallstrick: Ein Test, der begonnen und abgebrochen wurde, wird oft als durchgeführt protokolliert; nur Tests mit dokumentiertem Ergebnis zählen.

Den Satz lesen. Kein einzelner Indikator ist entscheidend. Das Muster, das das Modell vorhersagt, ist ein Anstieg der bedauerten Verluste und der Austritte aus dem obersten Quartil (Phase 1), gefolgt von einem Rückgang des Bus-Faktors und einem Anstieg verwaister Systeme (Phase 2), gefolgt von einem Anstieg der Schiefe der Betriebszugehörigkeit und einem Rückgang externer Reviews (Phase 3), und erst dann von einem Anstieg der Frühfluktuation und einem Rückgang der Annahme von Senior-Angeboten (Phase 4). Eine Abteilung, die die ersten beiden Bewegungen sieht, hat Zeit; eine, die die letzten beiden sieht, hat sehr wenig.

Literatur

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