Ein Entwickler kündigt, ein zweiter zieht kurz darauf nach, und plötzlich verlässt nicht nur Personal, sondern jahrelang gewachsenes Systemwissen das Unternehmen. Genau in diesem Moment beginnt für Ulrich Luttner die eigentliche Arbeit. Als Knowledge Management Consultant begleitet er Unternehmen dabei, Wissenstransfer beim Auf- und Abbau von Software-Entwicklungsteams nicht dem Zufall zu überlassen. Seine zentrale Beobachtung: Die meisten Probleme entstehen nicht erst mit der Kündigung, sondern lange davor, durch übersehene Konflikte, fehlende Wertschätzung und einen zu späten Beginn der eigentlichen Übergabe. Wie sich dieses Muster durchbrechen lässt und warum Vertrauen dabei wichtiger ist als jede Dokumentationsvorlage, beschreibt er im Gespräch anhand konkreter Praxiserfahrung.
Was auf dem Spiel steht, wenn Entwickler gehen
Wissenstransfer klingt für viele Führungskräfte zunächst nach einer administrativen Formalie, nach Übergabedokumenten und einem letzten Meeting. Luttner widerspricht dieser Verkürzung entschieden. Wenn ein Entwicklungsteam abgebaut wird, geht mit den Personen weit mehr verloren als reiner Programmcode: „Erfahrene Entwickler kennen nicht nur den Code, sondern auch Architekturentscheidungen, technische Schulden, Sonderfälle, Anforderungen und die Gründe für frühere Entscheidungen“, erklärt er. Genau dieses Hintergrundwissen ist es, das in den seltensten Fällen vollständig dokumentiert vorliegt.
Geht es dennoch verloren, hat das nach Luttners Erfahrung konkrete Folgen: Die Einarbeitung neuer Mitarbeitender verlängert sich erheblich, Fehler wiederholen sich, Änderungen am System werden riskanter. Im Extremfall lässt sich ein Produkt nicht mehr zuverlässig betreiben oder weiterentwickeln, mit entsprechenden Kosten, Verzögerungen und im schlimmsten Fall einer Gefährdung des gesamten Geschäftsmodells. Der Aufbau eines neuen Teams bedeutet für ihn deshalb mehr als Personal zu ersetzen: Es geht darum, fachliche und technische Handlungsfähigkeit systematisch zu übertragen.
Die hausgemachten Fehler vor der Kündigung
Bevor Wissen tatsächlich verloren geht, passiert nach Luttners Beobachtung meist schon vorher etwas Entscheidendes: Unternehmen reagieren zu spät. Konflikte, Überlastung oder schwindende Motivation werden häufig über lange Zeit ignoriert, bis mangelnde Wertschätzung dazu führt, dass sich Mitarbeitende innerlich zurückziehen, erkranken oder schließlich kündigen. „Viele dieser Probleme sind daher zumindest teilweise hausgemacht“, stellt er unumwunden fest.
Seine Empfehlung setzt entsprechend früh an: Die Interessen beider Seiten sollten von Beginn an berücksichtigt, Konflikte offen angesprochen und Nachfolger rechtzeitig aufgebaut werden. Und selbst wenn eine Kündigung bereits ausgesprochen ist, warnt Luttner vor einer verbreiteten Fehleinschätzung: Wissenstransfer darf nicht auf das Abliefern einiger Dokumente reduziert werden. Es braucht einen verbindlichen Übergabeprozess, ausreichend Zeit und einen respektvollen Umgang mit den ausscheidenden Mitarbeitenden, gerade weil deren Kooperationsbereitschaft in dieser Phase über den Erfolg der gesamten Übergabe entscheidet.
Wissensrisiken systematisch statt zufällig erkennen
Bevor überhaupt ein einzelner Wissensträger identifiziert werden kann, braucht es aus Luttners Sicht einen strukturierten Blick auf das gesamte Team. Hilfreich ist dafür eine einfache Matrix, die für jedes wesentliche System oder jede Produktkomponente festhält, wie viele Personen sie im Ernstfall eigenständig betreiben, weiterentwickeln oder zumindest erklären könnten. Systeme, bei denen diese Zahl bei eins liegt, gelten als kritischer Einzelpunkt und sollten priorisiert behandelt werden, unabhängig davon, ob aktuell eine Kündigung im Raum steht oder nicht.
Eine solche Übersicht lässt sich mit überschaubarem Aufwand in wenigen Workshop-Stunden erstellen, wird in der Praxis jedoch selten routinemäßig gepflegt. Meist entsteht sie erst reaktiv, wenn ein Abgang bereits absehbar ist, obwohl sie eigentlich fester Bestandteil der Personal- und Projektplanung sein sollte, ähnlich einer Risikoanalyse für kritische Lieferanten oder Systeme in anderen Unternehmensbereichen. Gerade in kleineren Entwicklungsteams, in denen ein einzelner Senior-Entwickler oft mehrere Systeme gleichzeitig verantwortet, empfiehlt Luttner, diese Übersicht mindestens einmal jährlich gemeinsam mit der Teamleitung durchzugehen, unabhängig davon, ob aktuell personelle Veränderungen anstehen.
Vom Kopf ins Team: wie Wissen wirklich ankommt
Beim Aufbau eines neuen Teams reicht es nach Luttners Erfahrung nicht, Wissen einfach niederzuschreiben und weiterzureichen. Der erste Schritt besteht darin, kritische Wissensträger, Wissensgebiete und Abhängigkeiten überhaupt erst zu identifizieren. Erst danach wird das vorhandene Wissen priorisiert, in Interviews erhoben, dokumentiert und durch moderierte Übergaben, gemeinsame Arbeit am Code und gezielte Einarbeitung praktisch vermittelt.
Entscheidend ist dabei eine Unterscheidung, die in vielen Übergabeprozessen untergeht: „Es geht nicht nur um explizites Wissen, das sich einfach aufschreiben lässt. Besonders wichtig ist das implizite Wissen, Erfahrungen, Einschätzungen, Hintergründe und informelle Zusammenhänge“, so Luttner. Dieses implizite Wissen wird nach seiner Erfahrung vor allem durch persönlichen Kontakt, strukturierte Interviews und die gemeinsame Arbeit an konkreten Aufgaben sichtbar, kaum jedoch durch reine Textdokumentation. Sein Ziel ist entsprechend nicht in erster Linie eine umfangreiche Dokumentation, sondern ein arbeitsfähiges Team, das Entscheidungen nachvollziehen, die Software betreiben und selbstständig weiterentwickeln kann.
Dokumentation allein reicht nicht: Werkzeuge und ihre Grenzen
Viele Unternehmen reagieren auf drohenden Know-how-Verlust zunächst mit einem Dokumentationsprojekt: Ein Wiki wird angelegt, Architekturentscheidungen sollen nachträglich in Entscheidungsprotokollen festgehalten werden, Prozesse werden in Diagrammen abgebildet. Solche Werkzeuge sind aus Luttners Sicht sinnvoll, lösen das eigentliche Problem jedoch nur teilweise. Ein Architekturentscheidungsprotokoll erklärt zwar, welche Option gewählt wurde, selten jedoch, welche Alternativen aus welchen politischen oder organisatorischen Gründen verworfen wurden, ein Wissen, das oft nur in den Köpfen der Beteiligten existiert.
Aus diesem Grund kombiniert er klassische Dokumentation stets mit Formaten, die einen direkten Austausch erzwingen: gemeinsame Code-Reviews zwischen ausscheidenden und neuen Mitarbeitenden, moderierte Übergabegespräche zu einzelnen Systemkomponenten, und ein zeitlich begrenztes Pairing, bei dem neue Entwickler unter Anleitung erfahrener Kollegen an echten Aufgaben arbeiten. Reine Textdokumentation dient dabei als Gedächtnisstütze für spätere Rückfragen, nicht als Ersatz für den persönlichen Übergabeprozess selbst.
Warum Kultur über Erfolg oder Scheitern entscheidet
Die vielleicht wichtigste Voraussetzung für gelingenden Wissenstransfer liegt für Luttner jedoch nicht in Prozessen oder Werkzeugen, sondern in der Unternehmenskultur. „Wertschätzung ist die entscheidende Voraussetzung. Mitarbeiter müssen das Gefühl haben, dass ihre Arbeit, ihre Erfahrung und ihre Person ernst genommen werden“, sagt er, und ergänzt, dass das Gehalt dabei nur einen Teil der Bindung an ein Unternehmen ausmacht.
Gerade in einer angespannten Trennungssituation hängt der Wissenstransfer stark vom Vertrauen der Beteiligten ab, oft mehr als von der Qualität eines Übergabeplans. Hier sieht Luttner auch seine eigene Rolle als externer Berater: Als neutraler und unbelasteter Ansprechpartner kann er Verständnis schaffen und den Stolz der Entwickler auf ihre geleistete Arbeit wieder in den Vordergrund rücken. Dadurch tritt der Groll gegenüber der Geschäftsleitung zurück, und eine sachliche Übergabe wird überhaupt erst wieder möglich.
Ohne diesen Vertrauensaufbau bleibt selbst ein methodisch guter Prozess wirkungslos. Wertschätzung entscheidet darüber, ob Wissenstransfer als Zumutung oder als letzter gemeinsamer Beitrag zum Unternehmen erlebt wird.
Ein Praxisbeispiel: vom zerrütteten Team zum arbeitsfähigen Nachfolgeteam
Wie stark Kultur und Prozess zusammenhängen, zeigt ein anonymisiertes Beispiel aus Luttners Praxis. Das Verhältnis zwischen Geschäftsleitung und Entwicklungsteam war bereits schwer beschädigt, mehrere Entwickler kündigten nahezu gleichzeitig, die Arbeitsleistung ging spürbar zurück. Der Frust im Team war zeitweise so groß, dass eine weitere Eskalation und ein vollständiger Verlust des Wissens drohten.
Luttners erster Schritt war deshalb nicht technischer, sondern menschlicher Natur: die Fäden aufnehmen, Vertrauen aufbauen und gemeinsam einen Überblick über Produkte, Verantwortlichkeiten und offene Probleme schaffen. Erst danach wurden Architektur, Anforderungen, technische Schulden, Entscheidungsgründe und organisatorische Zusammenhänge systematisch dokumentiert. Parallel unterstützte er die Suche nach geeigneten neuen Mitarbeitenden über Empfehlungen, Stellenanzeigen, soziale Netzwerke und Kandidateninterviews, arbeitete die neuen Kollegen ein und übernahm zeitweise selbst Aufgaben des Interimsmanagements.
Gleichzeitig verbesserte er den Austausch innerhalb des Teams und die Abstimmung mit der Geschäftsleitung. Am Ende stand ein arbeitsfähiges neues Team: Die Software konnte weiterbetrieben und weiterentwickelt werden, kritisches Wissen blieb erhalten, und die zuvor aufgelaufenen technischen Schulden konnten gezielt aufgearbeitet werden, ein Ergebnis, das ohne den vorausgehenden Vertrauensaufbau kaum erreichbar gewesen wäre.
Bemerkenswert an diesem Fall ist aus Luttners Sicht vor allem die Reihenfolge der Maßnahmen. Hätte er direkt mit der technischen Dokumentation begonnen, ohne zuvor Vertrauen aufzubauen, wären ausscheidende Entwickler kaum bereit gewesen, ihr implizites Wissen offen zu teilen, unabhängig davon, wie professionell der Interviewleitfaden gestaltet gewesen wäre. Erst die vorausgehende Klärung der zwischenmenschlichen Spannungen schuf die Grundlage dafür, dass die anschließende fachliche Übergabe überhaupt inhaltlich ergiebig werden konnte.
Sofortmaßnahmen, wenn Wissen nur in wenigen Köpfen steckt
Für Unternehmen, die gerade erst erkennen, dass wichtiges Know-how auf wenige Personen konzentriert ist, hat Luttner einen klaren Rat: sofort handeln. Der erste Schritt besteht darin zu klären, welche Aufgaben die jeweilige Person tatsächlich übernimmt, über welche Produkte und Systeme nur sie ausreichend Bescheid weiß und welche Folgen ein kurzfristiger Ausfall hätte. Dabei sollte nicht nur der aktuelle Aufgabenbereich betrachtet werden, sondern auch, was diese Person in der Vergangenheit entwickelt, entschieden und informell übernommen hat.
Darauf folgt eine strukturierte Bestandsaufnahme: kritische Wissensgebiete priorisieren, Interviews führen, Architektur- und Betriebswissen dokumentieren, Entscheidungsgründe festhalten und weitere Mitarbeitende praktisch einarbeiten. Aus implizitem Wissen soll so möglichst viel explizites, übertragbares Wissen werden. Ein Punkt ist Luttner dabei besonders wichtig, weil er über Erfolg oder Scheitern des gesamten Prozesses entscheidet: Dieser Prozess darf nicht als Misstrauensmaßnahme gegenüber dem Wissensträger verstanden werden. Er sollte stattdessen als Anerkennung seiner Leistung und als Sicherung seines beruflichen Beitrags kommuniziert werden. Das erhöht die Bereitschaft zur Mitwirkung erheblich und schafft eine belastbare Grundlage für die Zukunft des Unternehmens.
Wann ein externer Berater sinnvoller ist als interne Lösungen
Nicht jedes Unternehmen braucht für diesen Prozess einen externen Berater, doch gerade in konfliktbeladenen Situationen sieht Luttner klare Vorteile in einer neutralen dritten Partei. Interne Führungskräfte sind selbst Teil der angespannten Beziehung zwischen Geschäftsleitung und Team, was ihre Vermittlungsfähigkeit einschränkt, selbst wenn sie fachlich sehr kompetent sind. Ein externer Berater ohne emotionale Vorgeschichte kann dagegen offener nachfragen, ohne dass Aussagen sofort als Vorwurf oder Rechtfertigung interpretiert werden.
Gleichzeitig warnt Luttner davor, externe Unterstützung erst dann zu holen, wenn die Eskalation bereits weit fortgeschritten ist. Je früher ein neutraler Blick von außen auf mögliche Wissensrisiken geworfen wird, desto mehr Handlungsspielraum bleibt, bevor Kündigungen überhaupt ausgesprochen werden. In der Praxis bedeutet das, Knowledge-Management-Expertise nicht erst als Feuerwehr im Krisenfall, sondern bereits als präventives Element der Personalplanung zu betrachten.
Was Führungskräfte aus diesem Ansatz für den Alltag mitnehmen können
Nicht jedes Unternehmen steht kurz vor einer größeren Team-Umstrukturierung, dennoch lassen sich aus Luttners Vorgehen auch für den laufenden Betrieb konkrete Gewohnheiten ableiten. Dazu gehört, Architekturentscheidungen von Beginn an mit ihrer Begründung festzuhalten, statt nur das Ergebnis zu dokumentieren, neue Teammitglieder bewusst mit erfahrenen Kolleginnen und Kollegen an denselben Aufgaben arbeiten zu lassen, und regelmäßig, nicht nur beim Abschied, offen zu fragen, was jemand für seine Arbeit eigentlich braucht.
Diese Gewohnheiten kosten im Alltag zunächst zusätzliche Zeit, reduzieren im Ernstfall jedoch genau jenes Risiko, das Luttner in seiner Beratungspraxis immer wieder als teuerste Überraschung erlebt: das plötzliche Verschwinden von Wissen, das nie als eigenständiges Risiko erkannt wurde, weil es zu selbstverständlich schien, um es zu benennen.
Fazit für die Praxis
Luttners Erfahrung läuft auf eine einfache, aber unbequeme Erkenntnis hinaus: Wissenstransfer scheitert selten an fehlenden Vorlagen oder Wikis, sondern an zu spätem Handeln und fehlender Wertschätzung. Wer wartet, bis eine Kündigung bereits ausgesprochen ist, hat den wichtigsten Zeitpunkt für Prävention bereits verpasst. Wer dagegen frühzeitig kritische Wissensträger identifiziert, Vertrauen aufbaut und Übergaben als Anerkennung statt als Kontrolle gestaltet, sichert nicht nur technisches Wissen, sondern auch die Handlungsfähigkeit des Unternehmens, wenn erfahrene Köpfe das Team verlassen.
Für Geschäftsführer und Führungskräfte, die aktuell auf ein einzelnes, unersetzlich wirkendes Teammitglied blicken, liefert das eine konkrete erste Frage für die kommende Woche: Wüssten wir, wie wir ohne diese Person morgen weiterarbeiten würden, und haben wir das offen genug angesprochen, um es gemeinsam zu klären?
Über Ulrich Luttner
Ulrich Luttner ist Knowledge Management Consultant mit Sitz in der Metropolregion München, unter anderem als Senior Consultant für Strategic Systems International und SPQR Informatik GmbH tätig. Vor seiner Beratungstätigkeit arbeitete er über 14 Jahre als IT Analyst und Ausbilder bei Seagate Technology. Er studierte Amerikanische Kulturgeschichte, Politologie und Interkulturelle Kommunikation an der Ludwig-Maximilians-Universität München und begann seine berufliche Laufbahn ursprünglich als Feinmechaniker, bevor er über eine langjährige Tätigkeit als IT Analyst den Weg in die Beratung fand. Diese Kombination aus technischem Verständnis, kulturwissenschaftlicher Ausbildung und praktischer Vermittlungserfahrung prägt bis heute seinen Ansatz im Wissenstransfer.
