Mitarbeiter kündigt — wie sichern Sie sein Wissen in zwei Wochen? Was Communities wirklich raten

„Was passiert, wenn mein einziger Operations-Mensch kündigt?“

Diese Frage wurde in r/Entrepreneurs in unterschiedlicher Form mindestens vier Mal in zwei Monaten gestellt — mit konsistenter Resonanz. Der lauteste Thread („My employee quit and took all the knowledge with her because I never built proper training materials“, ca. 1.500 Upvotes, 378 Kommentare ^[1]) zeigt das volle Muster: Inhaber realisiert beim Abschied, dass die Person nicht nur Aufgaben, sondern Kundenbeziehungen, Vendor-Historie und ungeschriebene Workarounds mitnimmt.

Die Community-Antwort ist über alle Threads hinweg dieselbe Triage-Reihenfolge:

1. Zugänge zuerst. Passwörter, Admin-Accounts, MFA-Recovery, Domain-/DNS-/Hosting-Logins. Ohne sie ist alles andere irrelevant.
2. Wiederkehrende Aufgaben dokumentieren. Was passiert täglich, wöchentlich, monatlich, jährlich? Diese Liste fehlt fast immer.
3. Ausnahmen und „rote Linien“. Was darf nie passieren? Welche Kunden brauchen Sonderbehandlung? Wann wird eskaliert?
4. Beziehungen. Wer ist der Ansprechpartner bei Lieferant X, wer bei Bank Y, wer bei der Behörde?
5. Erst dann SOPs für Standardprozesse.

In r/ITManagers („How to manage when someone key quits?“, 35 Upvotes, 31 Kommentare ^[2]) verschärft sich dieses Muster zu einem klaren Notice-Period-Playbook: Admin-Zugriff sofort auf Read-Only, MSP für kritische Systeme on standby, recurring tasks in geteilten Kalendern dokumentieren, WIP-Übergabe an namentlich benannte Personen.

„Two weeks is not enough to transfer three years of context. It is enough to map what you don't know.“ — Kommentar aus r/ITManagers

„Ist ‚Mitarbeiter geht — Wissen weg' wirklich ein 8.000-Dollar-Problem?“

Ja, und es ist dokumentiert. Der r/Entrepreneurs-Thread „My employee quit and I realized we had zero training materials. Cost me $8K to fix“ ^[3] (149 Upvotes, 40 Kommentare) beziffert den Schaden explizit — und die Kommentatoren bestätigen ähnliche Größenordnungen aus eigener Erfahrung: Neu-Einarbeitung, doppelte Gehälter während Übergangsphasen, Kundenfriktion, Rework, verlorene Vendor-Konditionen.

Die Zahl ist aber nur die sichtbare Spitze. Prof. Dr. Dr. Oliver Hoffmann beschreibt auf LinkedIn ^[4] den eigentlichen, unsichtbaren Verlust präzise:

„Unternehmen besitzen Wissen nicht wie Lagerbestand. Sie sind Wissen — als Routine, Entscheidungslogik, Handgriff.“

Was beim Weggang verschwindet, ist die interpretierende Schicht: warum Entscheidungen so getroffen wurden, welche Edge Cases jeden Februar auftauchen, welche regulatorische Logik hinter einer scheinbar kuriosen Preisregel steht. CM First Group nennt das auf LinkedIn die „interpretive layer“ ^[5] — sie taucht in keinem Wiki auf.

„Hat jemand einen guten Weg gefunden, Wissen zu sichern, bevor Mitarbeiter gehen?“

Diese exakte Frage stellte u/denesmbezi in r/smallbusiness ^[6] — und löste mit 36 Upvotes und 106 Kommentaren die längste praktische Antwort-Liste in unserem Sample aus. Die genannten Bausteine, gewichtet nach Häufigkeit der Empfehlung:

| Häufig empfohlen | Selten, aber wirkungsvoll | Klar abgelehnt | |---|---|---| | Loom-/Scribe-Screen-Recordings | Consulting-Retainer mit Ex-Mitarbeiter | Reines Notion-/Confluence-Wiki ohne Pflegeprozess | | Wiederkehrende Aufgaben mit Frequenz dokumentieren | „What keeps you up at night?“-Interview vor Kündigung | KI-SOP-Generator ohne menschliche Validierung | | Cross-Training in Stellvertretungstandems | Skills-Matrix mit Frische-Datum pro Eintrag | Tool-Pitches in Kommentaren („astroturfed“) | | Exit-Interview mit Fokus auf Ausnahmen | Decision Records (ADRs) für Geschäftsentscheidungen | Performance-/Überwachungs-Framing |

Auffällig: Die Community erkennt astroturfed Werbung sofort. Mehrere Threads, in denen ein Tool plump empfohlen wurde, wurden in den Kommentaren entlarvt und downgevotet. Das hat direkte Konsequenzen für die Kommunikation: Wer Wissenssicherung verkauft, muss vom Pain ausgehen, nicht vom Tool.

„Warum dokumentieren Mitarbeiter nicht — und was tun, wenn sie sich weigern?“

Der explosivste Thread in unserem Sample ist „New employee hired as a SME refusing to document processes“ aus r/managers ^[7]: 164 Upvotes, 234 Kommentare — und eine überraschende Mehrheit verteidigte den SME. Die Gründe, die Mitarbeiter gegen Dokumentation nennen, sind in den Kommentaren systematisch:

• Job-Security-Angst. „Sobald alles dokumentiert ist, bin ich ersetzbar.“
• Keine geschützte Zeit. Dokumentation wird zusätzlich zur Vollauslastung verlangt.
• Niemand liest sie ohnehin. Wenn vorhandene Doku ignoriert wird, lohnt sich die Mühe nicht.
• Misstrauenskultur. Wer ein Klima von Überwachung erlebt, teilt nichts freiwillig.
• Sorge vor schlechter KI-Nutzung. „Mein Wissen wird abgesaugt und in ein Tool gefüttert, das mich ersetzt.“

Hier liegt der entscheidende Designhebel jeder Wissenssicherung: Trust & Participation müssen vor Capture kommen. Konkret heißt das: keine People Analytics, keine Performance-Rankings, private Drafts, Expert Review vor Veröffentlichung, sichtbare Attribution, klares Statement, dass Wissenssicherung Wirkung sichert — nicht Personen ersetzt.

Auch Vanessa Błaszczak greift das in einem deutschsprachigen LinkedIn-Post ^[8] auf. Die Kommentare dort fragen identisch: Wer pflegt? Wer prüft? Wer entwickelt weiter?

„Wie geht man mit Tribal Knowledge in Engineering und Manufacturing um?“

In r/MechanicalEngineer („How do teams actually deal with tribal knowledge loss in MechEng?“, 61 Upvotes, 26 Kommentare ^[9]) zeigt sich, dass Manufacturing-Wissen besonders schwer zu kodifizieren ist:

• Alte Zeichnungen ohne Kontext
• Tooling- und Materialverhalten, das nur durch Erfahrung verstanden wird
• Vendor-Historie und Sonderkonditionen
• Designentscheidungen, die nirgends begründet sind
• „Wenn Maschine X klingt wie Y, dann …“

Trevor Smith (Dirac) bringt das auf LinkedIn ^[10] auf den Punkt: Work Instructions in vielen Werken sind nicht die gelebte Best Practice. Shadowing reicht nicht. Was funktioniert, ist die direkte Anreicherung der Work Instruction mit Expert-Knowledge — also nicht ein paralleles Wiki, sondern eine Erweiterung dessen, was Mitarbeiter ohnehin nutzen.

„Unser ERP läuft nur, weil eine Person weiß, wie es funktioniert — was tun?“

Sam Gupta bringt diesen weit verbreiteten Mittelstands-Pain auf LinkedIn ^[11] auf eine Zeile:

„If your ERP depends on one person, it doesn't belong to your company. It belongs to their memory. And memory isn't a system of record.“

Die Reaktionen auf den Post (u. a. von Sara Duff) bestätigen einen wiederkehrenden Industriefall: Eine einzelne Person hat das MRP-System eigenhändig customized, sie verlässt das Unternehmen, das Wissen ist weg — und es bleibt nur die Reimplementierung. Salem Automation und CM First Group dokumentieren dasselbe Muster für Legacy-Modernisierungsprojekte: Die Discovery der „interpretive layer“ muss vor jeder Modernisierung kommen.

Für KMU bedeutet das praktisch: Vor jeder ERP-Migration und jeder Mitarbeiter-Übergabe brauchen Sie ein Customization Rationale Capture — eine kuratierte Liste aller Sonderlogiken im System, mit Begründung, Ausnahmen und Verantwortlichem.

„Ist Confluence/Notion-Doku überhaupt etwas wert, wenn sie veraltet?“

Die einstimmige Community-Antwort: nein, sie ist schlechter als keine. In r/cscareerquestions ^[12] und r/programming ^[13] beschreiben Engineers stale documentation als aktiven Risikofaktor — sie erzeugt scheinbare Sicherheit und führt zu falschen Entscheidungen. Christoph Pacher formuliert es in einem deutschsprachigen LinkedIn-Kommentar ^[14] präzise: „Veraltete Doku ist fast so schlimm wie keine.“

Was die Communities stattdessen empfehlen, ist konsistent:

• Owner pro Dokument mit Frische-Datum
• Revalidation Cadence (vierteljährlich, halbjährlich)
• Confidence Score / Status („verified“, „outdated“, „disputed“)
• Source Binding — jede Aussage mit überprüfbarer Quelle
• Versionierung und Change History
• Lieber wenige geprüfte Artefakte als viele veraltete Seiten

Die Mustererkennung: drei Sätze, die alles zusammenfassen

Über alle Diskussionen hinweg lassen sich die Belege auf drei Sätze verdichten — sie taugen als Stresstest für jede Wissensstrategie:

1. „Memory is not a system of record.“ Was nur im Kopf einzelner liegt, ist Risiko, nicht Asset.
2. „The notice period is not a knowledge-transfer strategy.“ Zwei Wochen reichen nie für drei Jahre impliziten Kontext.
3. „Stale docs sind gefährlicher als keine Docs.“ Ohne Frische, Owner und Quelle schaden Wikis mehr als sie nützen.

Wer diese drei Sätze ernst nimmt, sucht keine Doku-Plattform mehr. Sondern eine Methode, kritisches Rollenwissen vor dem Buying Moment systematisch zu identifizieren, zu erfassen und revalidierbar zu halten — mit Vertrauen, Berechtigungen und Frischeprüfung. Genau dort setzt busfactor.app an.