Der Architekt, ohne den nichts mehr geht

Im vorherigen Artikel dieser Serie ging es darum, wie organisationale Bedingungen an Architektur mitschreiben. Organisationen handeln jedoch nicht abstrakt: Entscheidungen werden von Menschen getroffen, Wissen liegt bei Menschen, und auch die Fähigkeit, ein gewachsenes System trotz seiner strukturellen Defizite am Leben zu halten, kann sich auf einzelne Personen konzentrieren.

In langlebigen Systemen gibt es deshalb häufig jemanden, den fast jeder kennt. Diese Person weiß, warum eine unscheinbare Änderung an einer Stelle drei andere Bereiche beschädigen kann. Sie erinnert sich an Sonderfälle, die nie dokumentiert wurden, und kennt historische Entscheidungen, deren ursprüngliche Begründung längst verloren gegangen ist. Wenn ein kritischer Produktionsfehler auftritt, wird sie angerufen; wenn ein Release hängt, schaut sie hinein. Wo andere nach Stunden noch nach einem Zusammenhang suchen, erkennt sie manchmal innerhalb weniger Minuten das Muster.

Es gibt einen guten Grund, warum Stakeholder dieser Person vertrauen: Sie hat wiederholt bewiesen, dass sie Probleme lösen kann. Wenn es brennt, rettet sie das System. Genau dort kann jedoch ein Paradox beginnen. Je besser eine Schlüsselperson die Folgen schlechter Struktur kompensiert, desto weniger unmittelbar muss die Organisation diese Struktur verändern. Der Big Ball of Mud produziert ein Problem, der Experte löst es, und der Betrieb läuft weiter. Für die Organisation entsteht daraus eine vollkommen nachvollziehbare Lernerfahrung: Wenn es kritisch wird, brauchen wir diesen Menschen.

Beim nächsten Problem wird die Person deshalb früher eingebunden. Schwierige Aufgaben landen bevorzugt bei ihr, Entscheidungen werden mit ihr abgestimmt, und andere Entwickler lernen, dass es effizienter ist, sie direkt zu fragen. Die Person wird dadurch nicht weniger wertvoll, sondern immer wertvoller. Genau darin liegt das Paradox:

Die Schlüsselperson kann gleichzeitig einer der wertvollsten Menschen im System und eines seiner größten Risiken sein.

Die Gefahr entsteht nicht aus hoher Kompetenz. Eine gesunde Organisation braucht Menschen, die außergewöhnlich viel wissen und Probleme lösen können, an denen andere scheitern. Gefährlich wird die Kombination aus exklusivem Wissen, organisatorischer Abhängigkeit, fehlender Gegenprüfung, Entscheidungsautorität und einer Struktur, in der immer mehr technische Realität durch dieselbe Person interpretiert werden muss.

Der Experte wird unverzichtbar, weil das System schlecht ist. Und das System kann schlecht bleiben, weil der Experte unverzichtbar ist.

Der Truck Factor ist nur der offensichtliche Teil

Für die Konzentration technischen Wissens existiert in der Softwareentwicklung ein bekanntes Konzept: der Bus Factor oder Truck Factor. Vereinfacht beschreibt er, wie viele zentrale Personen aus einem Projekt verschwinden müssten, bevor dessen Weiterentwicklung ernsthaft gefährdet wäre. Auch die Forschung zur Softwareentwicklung verwendet den Truck Factor als Maß für die Konzentration von Wissen. Avelino et al. untersuchten beispielsweise Verfahren zur automatisierten Schätzung dieses Risikos anhand von Software-Repositories.

Die offensichtlichen Szenarien sind bekannt. Eine Schlüsselperson kündigt, wird abgeworben, wechselt intern die Rolle, fällt länger aus oder geht irgendwann in den Ruhestand. Plötzlich wird sichtbar, dass ein Team zwar aus vielen Entwicklern bestand, ein bestimmter Teil des Systems aber faktisch nur von einem Menschen verstanden wurde. Dieses Ausfallrisiko ist real, beschreibt jedoch nur den einfacheren Teil des Problems.

Der Truck Factor beschreibt, was passiert, wenn die Schlüsselperson fehlt. Der interessantere Teil beginnt mit der Frage, was ihre Unverzichtbarkeit bereits bewirkt, solange sie noch da ist.

Denn eine Organisation verändert ihr Verhalten, sobald sie gelernt hat, dass ein bestimmter Mensch kritische Situationen besonders zuverlässig lösen kann. Damit kann sich Wissenskonzentration selbst verstärken.

Der selbstverstärkende Wissenskreislauf

Am Anfang muss überhaupt kein bewusstes Wissensmonopol stehen. Ein Entwickler kennt einen Teil des Systems etwas besser als seine Kollegen und erhält deshalb häufiger die komplizierten Aufgaben in diesem Bereich. Durch diese Aufgaben sammelt er zusätzliche Erfahrung, wodurch die Wahrscheinlichkeit steigt, dass er auch das nächste schwierige Problem schneller lösen kann. Sein Vorsprung wächst, Stakeholder und Kollegen nehmen das wahr, und weiteres kritisches Arbeiten wird an ihn geroutet. Andere Entwickler erhalten gleichzeitig weniger Gelegenheit, dieselben Erfahrungen zu sammeln.

Aus einem kleinen Kompetenzunterschied kann so mit der Zeit eine strukturelle Wissensasymmetrie entstehen:

Wissen → schwierige Aufgaben → zusätzliche Erfahrung → größere Erfolgswahrscheinlichkeit → mehr Vertrauen → mehr kritische Aufgaben → noch mehr exklusives Wissen.

Die Organisation verteilt Kompetenz dann nicht mehr, sondern routet Komplexität zu ihrem Experten. Kurzfristig ist das rational. Wenn ein Release gefährdet ist, gibt man das Problem dem Menschen, der es mit der höchsten Wahrscheinlichkeit schnell lösen kann; wenn ein kritischer Kunde wartet, ist der Moment selten geeignet, einem unerfahrenen Kollegen eine mehrtägige Lerngelegenheit zu ermöglichen. Die Summe vieler solcher rationaler Einzelentscheidungen verändert langfristig jedoch die Wissensstruktur des Teams.

Hinzu kommt ein zweites Paradox: Die Person, die ihr Wissen am besten weitergeben könnte, ist häufig gleichzeitig diejenige, die aufgrund ihrer operativen Bedeutung am wenigsten Zeit dafür besitzt. Jede kritische Situation liefert einen weiteren guten Grund, warum gerade jetzt kein Wissenstransfer stattfinden kann. Das Wissensmonopol benötigt deshalb weder einen Plan noch böse Absicht; es kann schlicht wachsen.

Je häufiger schwierige Probleme zur gleichen Person geroutet werden, desto stärker kann sich die Wissenskonzentration selbst verstärken.

Wenn Rettung sichtbarer ist als Prävention

Zu diesem Kreislauf kommt eine weitere Asymmetrie. Ein Produktionsausfall, ein fehlgeschlagener Release und ein eskalierender Incident sind sichtbar. Ebenso sichtbar ist die Person, die abends um 22 Uhr das System wieder zum Laufen bringt. Eine Architektur, durch die derselbe Incident nie entstanden wäre, produziert dagegen kein vergleichbares Ereignis. Niemand bekommt morgens eine Nachricht mit dem Inhalt: „Herzlichen Glückwunsch, auch heute Nacht ist der Fehler nicht aufgetreten, den unsere klare Modulgrenze vor drei Jahren verhindert hat.“

Operative Rettungsleistung lässt sich unmittelbar beobachten, während Prävention häufig aus Ereignissen besteht, die gerade nicht stattfinden. Das kann zu einem Belohnungsproblem führen, ohne dass irgendeine Organisation bewusst schlechte Architektur belohnen müsste.

Der Held bekommt Anerkennung für die Rettung. Gute Struktur bekommt selten Anerkennung für die Rettung, die nie notwendig wurde.

Brandschutz ist weniger spektakulär als Feuerlöschen. Das bedeutet nicht, dass die Anerkennung für den Experten unberechtigt wäre. Wer nachts ein kritisches Produktionsproblem löst, hat eine reale Leistung erbracht. Problematisch wird die Situation erst dann, wenn diese Leistung dauerhaft die strukturellen Bedingungen kompensiert, die sie immer wieder notwendig machen.

Wenn andere Entwickler abhängig werden

Für die übrigen Entwickler kann derselbe Mechanismus eine weitere Nebenwirkung besitzen. Ein Entwickler möchte eine Änderung durchführen, die Schlüsselperson schaut auf den Ansatz und sagt: „Das geht so nicht.“ Auf die Nachfrage folgen drei historische Sonderfälle, zwei implizite Abhängigkeiten, ein alter Workaround und eine Komponente, die aus Gründen, an die sich kaum noch jemand erinnert, anders behandelt werden muss als alle anderen. Nach zwanzig Minuten ist klar, dass die Änderung komplizierter ist als gedacht, und dann fällt der pragmatische Satz: „Gib es mir, ich mache das.“

Das Ticket wird erledigt, das Wissen jedoch nicht übertragen. Beim nächsten ähnlichen Problem beginnt derselbe Ablauf erneut. Irgendwann entsteht daraus keine einzelne Situation mehr, sondern eine soziale Regel: „Frag lieber den Experten“, „Das darf nur er anfassen“ oder „Ohne ihn würde ich dort nichts ändern.“ Dafür muss die Schlüsselperson niemanden absichtlich kleinhalten. Entmündigung kann eine Nebenwirkung effizienter Problemlösung sein.

Wenn komplexe Aufgaben dauerhaft zur gleichen Person wandern, verlieren andere Entwickler Lerngelegenheiten. Sie sammeln weniger Erfahrung mit kritischen Bereichen, treffen dort weniger Entscheidungen und entwickeln weniger technische Autonomie. Mit der Zeit können beide Seiten vollkommen rational handeln: Der Experte übernimmt die Aufgabe, weil er sie schneller lösen kann, während der andere Entwickler sie abgibt, weil dies kurzfristig das geringere Projektrisiko erzeugt. Langfristig wird dadurch genau der Kompetenzunterschied reproduziert, der dieselbe Entscheidung beim nächsten Mal erneut rational erscheinen lässt.

Das System besitzt formal vielleicht zwanzig Entwickler. Bestimmte Teile des Systems besitzen faktisch trotzdem nur einen.

Aus Wissen wird Expert Power

Mit der Wissenskonzentration verändert sich nicht nur die technische Arbeitsteilung, sondern auch soziale Macht. French und Raven beschrieben bereits 1959 verschiedene Grundlagen sozialer Macht. Eine davon ist Expert Power: Einfluss, der daraus entsteht, dass andere einer Person besondere Kompetenz und besonderes Wissen zuschreiben. Spätere Weiterentwicklungen des Modells differenzieren unter anderem zwischen Expert Power, Referent Power und informational power.

Expert Power ist zunächst nichts Problematisches. Wer mehr weiß, sollte bei einer technischen Entscheidung stärker gehört werden als jemand, der den Gegenstand nicht versteht; Organisationen wären schlecht beraten, Erfahrung und Kompetenz künstlich zu ignorieren. Eine Person, die über Jahre komplexe Probleme löst, gewinnt deshalb zu Recht Vertrauen. Stakeholder und Führungskräfte kennen sie, vielleicht auch Support, Operations oder wichtige Kunden. Wenn diese Person in einem Meeting sagt, dass eine Änderung riskant ist, besitzt ihre Einschätzung Gewicht.

Problematisch wird es, wenn aus „Er kennt das System am besten“ allmählich „Wenn er sagt, dass es nicht geht, dann geht es nicht“ wird. Das ist ein qualitativer Unterschied. Issac et al. untersuchten explizit, wie Expert Power und Referent Power mit Knowledge Sharing und Knowledge Hiding zusammenhängen. In ihrer Studie mit Beschäftigten aus wissensintensiven Bereichen zeigte sich ein komplexes Bild: Hohe persönliche Macht war nicht grundsätzlich mit weniger Wissensaustausch verbunden. Relevant war unter anderem, welche Veränderung ihrer persönlichen Macht die Befragten durch das Teilen ihres Wissens erwarteten. Erwartete Machtverluste waren mit geringerer Sharing-Absicht und stärkerem Knowledge Hiding verbunden. Gerade deshalb wäre die Gleichung „Macht = Wissenszurückhaltung“ zu einfach; relevant ist auch, was Menschen durch Wissenstransfer zu gewinnen oder zu verlieren glauben.

Für Architektur ergibt sich daraus eine wichtige Unterscheidung. Expertise ist gut, und Expert Power kann legitim und nützlich sein. Kritisch wird eine Konstellation, in der fachliche Autorität kaum noch durch unabhängige technische Überprüfung begrenzt werden kann.

Je unverzichtbarer eine Person für ein System wird, desto gefährlicher wird es, ihre Entscheidungen ausschließlich durch Vertrauen statt durch überprüfbare Strukturen zu begrenzen.

Drei Stufen der Abhängigkeit

Die Entwicklung lässt sich als analytisches Modell in drei Stufen betrachten. Diese Stufen sind keine etablierte wissenschaftliche Taxonomie, sondern eine Möglichkeit, unterschiedliche Qualitäten technischer Abhängigkeit voneinander zu trennen.

1. Wissenskonzentration

Auf der ersten Stufe lautet die Situation: „Nur diese Person weiß, wie das funktioniert.“ Das ist im Wesentlichen das klassische Bus-Factor-Problem. Wissen existiert, ist aber schlecht verteilt; fällt die Person aus, verliert die Organisation einen relevanten Teil ihrer Handlungsfähigkeit.

2. Operative Abhängigkeit

Auf der zweiten Stufe wird aus konzentriertem Wissen operative Abhängigkeit: „Ohne diese Person bekommen wir den Release oder Incident nicht gelöst.“ Die Person wird zum Bottleneck und gleichzeitig zum Retter kritischer Situationen. Andere können vielleicht erklären, wie der Bereich grundsätzlich funktioniert, für die wirklich schwierigen Fälle wird trotzdem dieselbe Person benötigt.

3. Epistemische Abhängigkeit

Die dritte Stufe ist subtiler: „Wenn diese Person sagt, dass etwas nicht möglich ist, besitzt die Organisation kaum noch eine unabhängige Möglichkeit, diese Aussage zu prüfen.“ Nun hängt die Organisation nicht mehr ausschließlich von Arbeitskraft oder technischem Wissen ab, sondern davon, wie eine einzelne Person die technische Realität interpretiert.

Die Organisation ist dann nicht nur von der Arbeit einer Person abhängig. Sie ist von ihrer Interpretation der Realität abhängig.

Aus konzentriertem Wissen kann operative und schließlich epistemische Abhängigkeit entstehen.

Wenn die Erklärung selbst nicht mehr überprüfbar ist

Wie weit diese Abhängigkeit reichen kann, zeigt eine anonymisierte Erfahrung aus einem langlebigen Frontend-System. Der Abstand zwischen der Anwendung und der Weiterentwicklung ihres Frameworks war über Jahre größer geworden. Ein Upgrade von Angular 17 auf Angular 19 wurde intern noch als grundsätzlich möglich eingeschätzt, allerdings bereits mit einem erwarteten Aufwand von ungefähr drei Monaten. Beim nächsten Major Release verschärfte sich die Bewertung weiter: Ein Upgrade auf Angular 20 galt für das konkrete System praktisch als nicht mehr realistisch beziehungsweise nicht mehr machbar.

In einer Besprechung erklärte der verantwortliche Architekt die Situation sinngemäß mit dem Satz:

„Da haben die Leute von Google aber richtig Mist gebaut.“

Ob diese Diagnose richtig oder falsch war, ist für den Mechanismus nicht die entscheidende Frage. Auch große Framework-Teams treffen Fehlentscheidungen; die Größe oder Reputation von Google wäre kein sinnvolles Argument dafür, dass der einzelne Architekt zwangsläufig falschliegen musste. Interessanter war, dass die anwesenden Stakeholder kaum eine realistische Möglichkeit besaßen, die Erklärung unabhängig zu bewerten.

Dabei hätten mehrere Hypothesen konkurrieren müssen. Vielleicht hatte Angular tatsächlich einen problematischen Breaking Change eingeführt. Vielleicht verwendete die Anwendung eine API, deren Verhalten sich geändert hatte. Vielleicht waren Angular-Mechanismen über Jahre umgangen worden, oder eigene Abstraktionen blockierten den vorgesehenen Upgradepfad. Ebenso denkbar war eine Kombination aus Frameworkänderungen und historisch gewachsener Architektur. Die Aussage „Google hat Mist gebaut“ war damit eine mögliche Erklärung, aber zunächst genau das: eine Hypothese.

In einer technisch gesunden Umgebung ließe sich diese Hypothese gegen Alternativen prüfen. Man könnte konkrete Breaking Changes identifizieren, minimale Reproduktionen erstellen, verwendete APIs gegen dokumentierte Frameworkmechanismen vergleichen oder externe Expertise hinzuziehen. Gefährlich wird die Situation deshalb nicht dadurch, dass ein Experte eine starke Meinung besitzt.

Das Problem beginnt dort, wo seine Meinung aufgrund seiner Stellung kaum noch falsifizierbar ist.

Damit bekommt Wissensmonopol eine zweite Bedeutung. Es bedeutet nicht nur, dass eine Person Antworten kennt; es kann bedeuten, dass die Organisation keine unabhängige Möglichkeit mehr besitzt, diese Antworten zu bewerten. An diesem Punkt ist technische Autorität nicht länger nur eine Konsequenz größerer Erfahrung. Sie wird Teil der Infrastruktur, über die die Organisation Wirklichkeit interpretiert.

Expertise und Transformationskompetenz sind nicht dasselbe

Gerade hochkompetente Schlüsselpersonen bringen Fähigkeiten mit, die in einem Big Ball of Mud außergewöhnlich wertvoll sind. Sie besitzen Betriebswissen über reale Last- und Fehlerbilder, Domänenwissen über fachliche Regeln und historische Sonderfälle sowie häufig ein ausgeprägtes Navigationswissen über implizite Abhängigkeiten, Workarounds und versteckte Kopplungen. Selbstverständlich können sie zugleich über große Architekturkompetenz verfügen.

Aus diesen Fähigkeiten folgt jedoch nicht automatisch Transformationskompetenz. Ein bestehendes System hervorragend zu beherrschen und dieses System fundamental neu zu schneiden sind unterschiedliche Aufgaben. Eine Transformation kann verlangen, vertraute Grundannahmen infrage zu stellen, eigene frühere Architekturentscheidungen neu zu bewerten, das über Jahre entwickelte mentale Modell teilweise zu verwerfen und bewusst Redundanz im Wissen sowie verteilte Entscheidungsfähigkeit aufzubauen.

Wer ein System außergewöhnlich gut beherrscht, ist nicht automatisch die Person, die am besten beurteilen kann, wie stark dieses System verändert werden sollte.

Das ist keine Kritik an Expertise, sondern eine Unterscheidung verschiedener Formen von Expertise. Gerade im Big Ball of Mud kann Navigationswissen enormen wirtschaftlichen Wert besitzen. Wer weiß, dass vor einer scheinbar unabhängigen Änderung erst Service A gestartet, anschließend Zustand B synchronisiert und danach Cache C invalidiert werden muss, verhindert reale Produktionsfehler. Gleichzeitig sollte sich die Organisation fragen, warum dieses Wissen überhaupt notwendig ist.

Navigationswissen über einen Big Ball of Mud kann extrem wertvoll sein, obwohl die Organisation gerade versuchen sollte, den Bedarf an genau diesem Wissen zu reduzieren.

Ein saubereres System macht Domänenwissen, Erfahrung oder gute Architekten nicht wertlos. Es reduziert jedoch den Wert exklusiven Wissens darüber, wie man strukturelles Chaos navigiert. Spätestens hier wird die Analyse unangenehm.

Technische Veränderung verändert auch persönliche Ressourcen

Wenn Wissen Macht und organisatorische Bedeutung erzeugen kann, ist Modernisierung nicht ausschließlich eine technische Veränderung. Exklusives Wissen kann mit Status, Anerkennung, Autonomie, Zugang zu Entscheidern und organisatorischer Zentralität verbunden sein. Das muss nicht geplant sein; eine Person kann diese Position über viele Jahre allein dadurch erwerben, dass sie zuverlässig Probleme löst.

Wenn Wissen anschließend verteilt, Standards wiederhergestellt und andere Entwickler in die Lage versetzt werden, dieselben Bereiche eigenständig zu verändern, kann sich auch diese Position verändern. Was für die Organisation Risikoreduktion bedeutet, kann für die Schlüsselperson einen Verlust exklusiver Bedeutung bedeuten. Das ist zunächst keine moralische Aussage, sondern beschreibt einen möglichen Interessenkonflikt.

Menschen besitzen Eigeninteressen. Professionelle Identität, Anerkennung, Status, Autonomie und Arbeitsplatzsicherheit sind reale Bestandteile von Arbeit. Es wäre naiv, technische Organisation so zu modellieren, als existierten diese Interessen nicht. Besonders relevant wird die Konstellation, wenn dieselbe Person, deren Rolle durch eine Transformation verändert werden könnte, gleichzeitig erheblichen Einfluss darauf besitzt, ob diese Transformation technisch überhaupt notwendig erscheint.

Die Person, deren Stellung durch eine Veränderung berührt werden könnte, besitzt möglicherweise gleichzeitig erheblichen Einfluss darauf, ob diese Veränderung überhaupt notwendig erscheint.

Ein solcher Interessenkonflikt ist noch kein Beweis für Fehlverhalten, aber er ist auch nicht irrelevant. Genau deshalb sollte die Architektur einer Organisation nicht darauf beruhen, dass Menschen keinerlei Eigeninteressen besitzen, auch wenn professionelles Verhalten selbstverständlich erwartet werden darf.

Eine Organisation darf professionelles Verhalten erwarten. Sie sollte ihre Architektur aber nicht darauf aufbauen, dass Menschen keinerlei Eigeninteressen besitzen.

Exklusives Wissen kann neben technischem Wert auch Status, Einfluss und Entscheidungsmacht erzeugen.

Wissen kann auch Sicherheit bedeuten

Ein besonders sensibler Aspekt ist Arbeitsplatzsicherheit. Die naheliegende Unterstellung wäre schnell formuliert: Jemand halte Wissen absichtlich zurück, damit er nicht ersetzbar werde. Eine solche Behauptung wäre ohne Belege unseriös. Die Forschung liefert jedoch Gründe, Arbeitsplatzunsicherheit nicht vollständig aus der Analyse zu streichen.

Jeong, Kim und Lee untersuchten 2023 in einer Drei-Wellen-Studie mit 365 Beschäftigten den Zusammenhang zwischen wahrgenommener Job Insecurity, Psychological Safety und Knowledge Hiding. In ihrem Modell war höhere Arbeitsplatzunsicherheit mit geringerer psychologischer Sicherheit verbunden; diese wiederum hing mit stärkerem Knowledge Hiding zusammen. Die Autoren interpretieren den Mechanismus unter anderem im Rahmen der Conservation-of-Resources-Theorie.

Das beweist nicht, dass Menschen Wissensmonopole aufbauen, um Kündigungen zu verhindern, und erlaubt schon gar keine Diagnose der Motivation eines konkreten Architekten. Es zeigt aber, warum auch die gegenteilige Annahme zu stark wäre: dass Arbeitsplatzsicherheit bei Wissensaustausch grundsätzlich keine Rolle spielen könne.

Exklusives Wissen besitzt nicht nur fachlichen Wert. In unsicheren Kontexten kann es auch als persönliche Ressource wahrgenommen werden.

Das ist besonders relevant, weil Modernisierungen häufig in Phasen stattfinden, in denen Rollen, Verantwortungen und bestehende Kompetenzprofile ohnehin infrage gestellt werden. Wenn gleichzeitig erwartet wird, dass eine Schlüsselperson ihr exklusives Wissen vollständig verteilt und dadurch ihre bisherige Sonderstellung reduziert, können technische und persönliche Interessen ineinandergreifen. Wie stark und in welcher Form das geschieht, lässt sich nur im konkreten Fall beurteilen; dass es geschehen kann, sollte jedoch kein Tabuthema sein.

Status ist präziser als „Ego“

In technischen Diskussionen wird für solche Situationen gern das Wort Ego verwendet. Präziser sind Begriffe wie Expert Status, Recognition, Reputation, Professional Identity und Self-Concept. Eine Person, die über zehn Jahre als derjenige galt, der ein kritisches System versteht, hat möglicherweise einen beträchtlichen Teil ihrer beruflichen Identität genau um diese Kompetenz aufgebaut. Das ist nicht irrational. Arbeit ist nicht nur die Ausführung austauschbarer Tätigkeiten; Menschen entwickeln Rollenbilder, Reputation und Erwartungen darüber, wofür sie von anderen geschätzt werden.

Moser beschreibt Wissensaustausch aus Sicht von Experten ausdrücklich als soziales Dilemma: Für die Gruppe ist das Teilen wertvollen Wissens nützlich, für den einzelnen Experten kann damit jedoch ein Wettbewerbsvorteil aufgegeben werden. In zwei Experimenten zeigte sich zugleich, dass Experten stärker beitrugen, wenn ihr Expertenstatus anerkannt wurde. Status muss Wissensteilung also keineswegs verhindern; Anerkennung kann sie gerade erleichtern.

Auch das ist ein wichtiger Gegenpunkt zu einer simplen Machtgeschichte. Der Experte muss nicht zwischen „kooperativ“ und „machtorientiert“ einsortiert werden. Menschen können Wissen teilen und gleichzeitig Wert darauf legen, dass ihre Expertise sichtbar und anerkannt bleibt. Eine Modernisierung kann diese Balance verändern. Wenn eine technische Neubewertung implizit lautet, dass viele Regeln, Workarounds und Sonderwege, die bisher geschützt oder verteidigt wurden, künftig nicht mehr benötigt werden, betrifft sie deshalb nicht ausschließlich Code.

Eine technische Neubewertung kann zugleich eine Neubewertung dessen sein, worauf bisherige fachliche Autorität aufgebaut war.

Professionelle Menschen können damit umgehen. Eine Organisation sollte aber nicht voraussetzen, dass Status und Identität deshalb bedeutungslos werden.

Nicht jedes Wissensmonopol ist Knowledge Hiding

An dieser Stelle ist eine begriffliche Trennung entscheidend. Knowledge Hiding ist in der organisationswissenschaftlichen Forschung kein Synonym für schlecht verteiltes Wissen. Connelly, Zweig, Webster und Trougakos etablierten den Begriff als eigenständiges Konstrukt und grenzten ihn unter anderem von Knowledge Sharing und Knowledge Hoarding ab. Gemeint ist eine intentionale Form des Zurückhaltens oder Verbergens von Wissen, das von einer anderen Person angefragt wurde; unterschieden werden dabei verschiedene Formen wie evasive hiding, rationalized hiding und playing dumb.

Für Softwarearchitektur ist diese Differenzierung wichtig. Ein System kann stark von einer Person abhängen, ohne dass diese jemals bewusst Wissen zurückgehalten hätte. Knowledge Concentration beschreibt zunächst einen Zustand, Tacit Knowledge kann entstehen, weil Erfahrung schwer vollständig zu dokumentieren ist, und fehlende Dokumentation oder fehlende Lerngelegenheiten können aus Zeitdruck und jahrelanger Vernachlässigung hervorgehen. Knowledge Hoarding und insbesondere Knowledge Hiding führen Intentionalität wesentlich stärker in die Betrachtung ein.

Die Forschung zu Knowledge Hiding ist deshalb kein Beleg dafür, dass jeder Schlüsselarchitekt absichtlich Kollegen unwissend hält. Ihr Wert für diese Diskussion liegt darin, dass sie intentionales Wissenszurückhalten als reales organisationales Verhalten untersucht. Eine umfangreiche Meta-Analyse von Arain et al. bündelte 104 Studien mit insgesamt 31.822 Beschäftigten und betrachtete ein breites Netzwerk individueller, relationaler und organisationaler Einflussfaktoren sowie Konsequenzen. Der angemessene Schluss lautet deshalb weder „Wissensmonopol ist immer Absicht“ noch „Absicht spielt nie eine Rolle“. Beide Positionen wären analytisch bequem, aber falsch.

Wenn Wissen als „mein“ Wissen erlebt wird

Ein weiterer Forschungsstrang beschäftigt sich mit Psychological Ownership. Menschen können Wissen, Aufgaben oder Verantwortungsbereiche psychologisch als etwas erleben, das zu ihnen gehört. Ein solches Gefühl von Ownership muss keineswegs negativ sein; Verantwortung, Identifikation und persönlicher Einsatz können für ein System äußerst wertvoll sein. Problematisch wird es dort, wo aus Verantwortung ein Besitzanspruch entsteht und sich die Sprache in Richtung „mein Bereich“, „meine Services“, „meine Architektur“ oder „Da geht niemand dran, ohne vorher mit mir zu sprechen“ verschiebt.

Auch hier ist die Trennung wichtig: Psychological Ownership ist nicht dasselbe wie Territorialität; Territorialverhalten ist eine mögliche Reaktion darauf. Huo et al. untersuchten diesen Zusammenhang in einer Zwei-Wellen-Studie mit 417 Personen aus chinesischen Forschungs- und Entwicklungsteams. In ihrem Modell vermittelte Territorialität den Zusammenhang zwischen Psychological Ownership und Knowledge Hiding. Tian et al. betrachteten mit 310 Wissensarbeitern noch spezifischer knowledge-based psychological ownership. In ihrer Drei-Wellen-Studie vermittelte der erwartete Verlust von Knowledge Power den Zusammenhang mit Knowledge Hiding; Emotional Intelligence schwächte diesen indirekten Effekt ab.

Diese Befunde dürfen nicht überdehnt werden. Sie stammen aus konkreten Stichproben und untersuchen organisationale Wissensarbeit, nicht speziell Softwarearchitekten in europäischen Großprojekten. Für die konzeptionelle Frage sind sie trotzdem relevant, weil sie zeigen, dass Wissen nicht ausschließlich als neutrale Information behandelt werden muss. Es kann psychologisch mit Besitz, Macht und erwarteten Verlusten verbunden sein.

Die Grenze zwischen Verantwortung und Besitzanspruch ist organisatorisch relevant.

Ein guter Architekt sollte Verantwortung übernehmen. Eine Organisation sollte trotzdem hellhörig werden, wenn Verantwortlichkeit faktisch bedeutet, dass ein Bereich ohne Zustimmung einer einzelnen Person nicht mehr verändert, verstanden oder unabhängig bewertet werden kann.

Macht ist hier kein Schimpfwort

Es wäre verführerisch, in diesem Zusammenhang auf weichere Begriffe wie „Standing“, „Einfluss“ oder „Seniorität“ auszuweichen. Der etablierte organisationswissenschaftliche Begriff Expert Power ist jedoch präzise: Wir sprechen über Macht. Eine Person besitzt faktisch Macht, wenn ihre Einschätzung beeinflusst, welche technische Erklärung akzeptiert wird, welche Änderung durchgeführt werden darf, welches Risiko gegenüber Stakeholdern kommuniziert wird oder welche Alternative überhaupt als realistisch gilt.

Diese Macht kann legitim, nützlich und aus echter Kompetenz entstanden sein. Sie verschwindet aber nicht dadurch, dass ihre Grundlage Kompetenz ist.

Wer bestimmen kann, wie ein Problem erklärt wird, beeinflusst auch, welche Lösungen überhaupt denkbar erscheinen.

Das wird besonders relevant, wenn organisatorische Gegenprüfung fehlt. Ein formelles Architekturboard, ein zweiter Senior Engineer oder ein Reviewprozess helfen wenig, wenn alle Beteiligten für die Bewertung der entscheidenden technischen Details wiederum dieselbe Schlüsselperson fragen müssen. Dann existiert auf dem Organigramm vielleicht eine Kontrollstruktur; epistemisch existiert sie nicht.

Unbewusste Stabilisierung

Bis hierhin benötigt der Mechanismus weiterhin keine bewusste Blockade. Eine Schlüsselperson kann vollkommen überzeugt sein, das Unternehmen zu schützen, und dafür gute Gründe besitzen. Sie kennt reale Produktionsprobleme, weiß, wie teuer frühere Fehler waren, und hat erlebt, wie scheinbar harmlose Änderungen unerwartete Seiteneffekte ausgelöst haben. Vorsicht kann deshalb fachlich berechtigt sein.

Das Problem liegt darin, dass das mentale Modell dieser Person über Jahre gemeinsam mit dem bestehenden System entstanden ist. Regeln, Sonderfälle, Workarounds und historische Architekturentscheidungen bilden darin ein zusammenhängendes Ganzes. Irgendwann kann es schwierig werden zu unterscheiden zwischen einer Regel, die fachlich oder technisch unvermeidbar ist, und einer Regel, die nur deshalb notwendig erscheint, weil die bestehende Architektur sie hervorgebracht hat.

Eine bestimmte Reihenfolge „muss“ eingehalten werden, eine bestimmte Komponente „kann“ nicht ersetzt werden, ein Framework „eignet“ sich nicht oder eine Standardlösung „funktioniert bei uns nicht“. All diese Aussagen können stimmen. In einem stark gewachsenen System kann „notwendig“ jedoch manchmal lediglich bedeuten: notwendig unter den Annahmen des heutigen Systems.

Wer dieses System besonders gut versteht, besitzt deshalb nicht automatisch die neutralste Perspektive auf seine Grundannahmen. Das ist weder ein kognitiver Defekt noch eine Charakterschwäche, sondern kann gerade die Konsequenz tiefer Erfahrung mit einem bestehenden Modell sein. So kann eine Schlüsselperson Veränderung stabilisieren, obwohl sie aufrichtig versucht, Risiken zu reduzieren.

Bewusste Stabilisierung existiert ebenfalls

Hier endet die Analyse allerdings nicht, denn Menschen besitzen Handlungsmacht. Eine Person kann erkennen, dass eine Veränderung ihren Einfluss reduziert, verteiltes Wissen andere Entwickler unabhängiger macht, standardisierte Lösungen Teile ihres exklusiven Navigationswissens weniger wichtig machen oder eine technische Neubewertung frühere Entscheidungen infrage stellt. Sie kann darauf reagieren.

Mögliche Verhaltensweisen sind beispielsweise, die Anforderungen an Nachweise für Veränderungen immer weiter zu erhöhen, Risiken einer Alternative besonders stark hervorzuheben, konkurrierende Lösungsansätze ohne gleichwertige Prüfung zu verwerfen, Reviews und Freigaben bei sich zu zentralisieren oder Wissen selektiv weiterzugeben. Auch die Erklärung, eine Standardlösung sei „bei uns nicht möglich“, kann zu einer informellen Vetoposition werden, wenn niemand mehr in der Lage ist, die Behauptung unabhängig zu überprüfen.

Das bedeutet weder, dass solche Verhaltensweisen bei Schlüsselpersonen generell auftreten, noch dass man aus einer abgelehnten Modernisierung automatisch auf Machterhalt schließen dürfte. Die umgekehrte Position wäre allerdings ebenso unrealistisch:

Die Möglichkeit bewusster Machterhaltung aus Höflichkeit vollständig auszublenden wäre ebenso problematisch wie sie jeder Schlüsselperson zu unterstellen.

Gerade deshalb darf der Verzicht auf Blaming nicht dazu führen, menschliche Interessen aus dem Modell zu entfernen.

Experten sind keine passiven Objekte ihrer Organisation

Eine interessante Perspektive liefert dazu die Forschung von Peter Kalum Schou und Torstein Nesheim. In einer qualitativen Studie untersuchten sie Experteningenieure eines großen Energieunternehmens während einer organisatorischen Veränderung. Das Unternehmen zentralisierte Aufgaben und führte digitale Kontrollmechanismen ein, wodurch bisherige Autonomie und formale Kontrolle der Experten eingeschränkt wurden.

Die Forscher beobachteten, dass die Experten darauf nicht lediglich passiv reagierten. Sie entwickelten Praktiken, mit denen sie Teile ihrer früheren Kontrolle zurückgewannen: unter anderem strategische Compliance bei gleichzeitigen Workarounds, die Nutzung historisch gewachsener Strukturen und die informelle Wiederherstellung von Expert Control. Schou und Nesheim fassen diese Praktiken unter dem Begriff Stealth Work zusammen.

Diese Studie sollte sehr vorsichtig übertragen werden. Sie untersucht Experteningenieure in einem konkreten Unternehmen und einen spezifischen Veränderungsprozess; daraus folgt selbstverständlich nicht, dass Softwarearchitekten grundsätzlich verdeckt Reformen sabotieren. Relevant ist eine andere Beobachtung: Experten sind nicht ausschließlich Objekte organisationaler Strukturen. Sie besitzen Agency und können auf Veränderungen von Status, Autonomie und Kontrolle reagieren und selbst versuchen, die entstehende Ordnung zu beeinflussen.

Eine Schlüsselperson ist nicht nur Objekt organisatorischer Strukturen. Sie kann selbst aktiv auf diese Strukturen einwirken.

Damit wird die Erklärung „die Organisation hat das Problem geschaffen“ unvollständig. Organisationale Bedingungen können Wissenskonzentration fördern, Zeitdruck kann sie verstärken und historische Strukturen können sie begünstigen. Irgendwann treffen trotzdem konkrete Menschen konkrete Entscheidungen.

Hohe Kompetenz macht Gegenprüfung nicht überflüssig

Gerade weil die Schlüsselperson häufig außerordentlich kompetent ist, entsteht ein weiteres Risiko. Ein Juniorentwickler kann eine falsche technische Einschätzung treffen; wenn das Team funktioniert, wird diese Einschätzung im Review hinterfragt. Ein weithin anerkannter Architekt kann dieselbe falsche Einschätzung treffen, doch seine Aussage erreicht möglicherweise mehrere Teams, beeinflusst Budgets oder beendet eine technische Alternative, bevor sie überhaupt prototypisch geprüft wurde.

Der Unterschied ist nicht Intelligenz, sondern Reichweite. Je größer die Entscheidungsmacht einer Person ist, desto größer kann die Reichweite einer Fehlentscheidung werden. Das gilt selbstverständlich ebenso für Führungskräfte, Product Owner, Sicherheitsverantwortliche und andere Rollen.

Hohe Kompetenz reduziert die Wahrscheinlichkeit mancher Fehler. Sie macht institutionelle Gegenprüfung aber nicht überflüssig.

Gerade Vertrauen darf deshalb kein Ersatz für Falsifizierbarkeit werden. Ein guter Experte sollte starke Argumente liefern können; eine gute Organisation sollte trotzdem in der Lage bleiben, sie zu prüfen.

Eine provokante Consulting-Regel

Aus einer anderen Business Unit stammt eine Anekdote aus früherer Consulting-Arbeit. Dort habe es für besonders extreme Wissensmonopole eine drastische Empfehlung gegeben: Wenn festgestellt wurde, dass kritisches Wissen vollständig auf einer einzelnen Person konzentriert war, sei teilweise empfohlen worden, sich von genau dieser Person zu trennen.

Als allgemeine Handlungsempfehlung wäre das gefährlich. Eine Organisation, die bereits strukturell von einem Menschen abhängig ist, kann sich durch dessen abrupten Verlust erheblich destabilisieren. Genau die Person zu entfernen, die das System noch versteht, beseitigt die Abhängigkeit nicht; im schlechtesten Fall beseitigt es nur das Wissen.

Interessant ist die Provokation trotzdem, weil sie zwei Fragen sichtbar macht, die Organisationen gern vermeiden:

Was bleibt von der technischen Handlungsfähigkeit übrig, wenn diese Person morgen nicht mehr verfügbar ist?

Besitzt die Organisation überhaupt noch einen Anreiz, die Abhängigkeit abzubauen, solange diese Person zuverlässig jede kritische Situation auffängt?

Die angemessene Schlussfolgerung lautet deshalb nicht, den Experten zu entfernen, sondern das Monopol. Das Ziel kann nicht sein, außergewöhnliche Expertise aus einer Organisation zu entfernen; es muss darin bestehen, zu verhindern, dass ausschließlich diese Expertise die Organisation handlungsfähig macht. Wie das praktisch gelingt, gehört in den späteren Artikel über Wege aus dem Big Ball of Mud.

Das Schlüsselpersonen-Paradox

Damit lassen sich die einzelnen Mechanismen zusammenführen. Ein Big Ball of Mud ist schwer verständlich, wodurch Navigationswissen wertvoll wird. Die Person mit dem meisten Navigationswissen löst schwierige Probleme erfolgreicher und erhält deshalb weitere schwierige Aufgaben. Ihre Rettungen sind sichtbar und erhöhen das Vertrauen von Stakeholdern und Kollegen; mit diesem Vertrauen wächst ihre Expert Power, und mehr kritische Entscheidungen laufen über sie. Andere Entwickler erhalten gleichzeitig weniger Gelegenheit, dieselben Erfahrungen aufzubauen, sodass die Wissenskonzentration weiter zunimmt.

Mit dieser Unverzichtbarkeit können Status, Autonomie, organisatorische Zentralität und unter bestimmten Bedingungen auch ein Gefühl persönlicher Sicherheit verbunden sein. Eine Modernisierung, die das System verständlicher macht, würde gleichzeitig die Exklusivität dieses Wissens reduzieren. Damit kann eine Veränderung, die für die Organisation Risikoreduktion bedeutet, Ressourcen verändern, die für die Schlüsselperson persönlich relevant sind. Die Person kann die Veränderung aufgrund ihrer tiefen Erfahrung für falsch halten, sie unbewusst aus dem mentalen Modell des bestehenden Systems heraus stabilisieren oder sie in manchen Fällen bewusst bremsen.

Bleibt die Veränderung aus, bleibt auch das System schwer verständlich. Dadurch bleibt Navigationswissen wertvoll, und der Kreislauf kann erneut beginnen. Als analytisches Modell lässt er sich so zusammenfassen:

Big Ball of Mud → schwer verständliches System → exklusives Expertenwissen → operative Rettung → Vertrauen und Expert Power → mehr zentrale Entscheidungen → weniger verteiltes Wissen → stärkere Abhängigkeit → erschwerte Veränderung → Big Ball of Mud bleibt bestehen.

Damit ist kein universelles Gesetz beschrieben, sondern ein möglicher selbstverstärkender Mechanismus, der gerade in langlebigen Big Balls of Mud plausibel wird.

Der Experte kann unverzichtbar werden, weil das System schlecht ist – und seine Unverzichtbarkeit kann gleichzeitig dazu beitragen, dass die strukturellen Ursachen länger bestehen bleiben.

Kein Blaming bedeutet nicht keine Verantwortung

Es wäre einfach, für diesen Kreislauf einen Schuldigen zu suchen. Ebenso einfach wäre es, jede individuelle Verantwortung hinter dem Begriff „Systemproblem“ verschwinden zu lassen. Beides hilft nicht.

Die Organisation trägt Verantwortung dafür, Wissensmonopole zu erkennen, Abhängigkeiten nicht dauerhaft zu institutionalisieren und technische Aussagen überprüfbar zu halten. Sie muss außerdem Bedingungen schaffen, unter denen Wissenstransfer nicht permanent hinter dem nächsten Incident zurückstehen muss. Die Schlüsselperson besitzt jedoch ebenfalls Agency. Sie kann Wissen teilen oder zurückhalten, andere Entwickler aufbauen oder Aufgaben dauerhaft an sich ziehen, Entscheidungen nachvollziehbar begründen oder sich auf Autorität berufen und Widerspruch zulassen oder abwerten. Sie kann ihre Rolle so gestalten, dass ihre Expertise andere befähigt, oder so, dass dieselbe Expertise dauerhaft Voraussetzung dafür bleibt, dass andere handeln können.

Nicht jede dieser Entscheidungen besitzt dieselbe Motivation, und von außen ist diese Motivation häufig nicht sicher erkennbar. Verantwortung verschwindet deshalb trotzdem nicht.

Kein Blaming bedeutet nicht, individuelles Verhalten für irrelevant zu erklären.

Organisationale Ursachen erklären, wie ein bestimmter Handlungskontext entstehen konnte. Sie determinieren nicht jede Handlung innerhalb dieses Kontextes. Menschen besitzen Handlungsmacht.

Was die Forschung zeigt – und was nicht

Gerade bei einem Thema, das so schnell persönlich werden kann, ist die Grenze zwischen empirischer Evidenz und Interpretation entscheidend. Die Forschung zeigt, dass Knowledge Hiding ein reales und breit untersuchtes organisationales Phänomen ist. Connelly et al. haben es als eigenständiges, intentionales Konstrukt etabliert; spätere Meta-Analysen dokumentieren eine umfangreiche empirische Literatur zu seinen Antezedenzien und Konsequenzen. Einzelne Studien verbinden Psychological Ownership und Territorialität mit Knowledge Hiding und zeigen, dass erwarteter Verlust von Knowledge Power dabei eine Rolle spielen kann. Forschung zu Expert Status und Expert Power macht zugleich deutlich, dass Status und Macht nicht einfach mit Wissenszurückhaltung gleichgesetzt werden dürfen: Anerkennung von Expertenstatus kann Sharing fördern, während erwartete Machtverluste Sharing erschweren können. Studien zu Job Insecurity liefern Hinweise darauf, dass wahrgenommene Arbeitsplatzunsicherheit über psychologische Mechanismen mit Knowledge Hiding zusammenhängen kann. Schou und Nesheim zeigen schließlich in einem konkreten qualitativen Fall, dass Experten auf den Verlust von Autonomie, Status und Kontrolle aktiv reagieren und informelle Praktiken entwickeln können, um Teile ihrer Kontrolle zurückzugewinnen.

Die Forschung zeigt dagegen nicht, dass jeder Schlüsselarchitekt Wissen absichtlich zurückhält, jeder Experte seine Macht verteidigt oder Arbeitsplatzsicherheit der Grund für eine konkrete Architekturentscheidung ist. Sie zeigt ebenso wenig, dass jede starke technische Gegenposition auf verletztem Status oder professioneller Identität basiert oder eine Organisation ihrem besten Experten grundsätzlich misstrauen sollte. Persönliche Erfahrungen können die Frage eröffnen und Mechanismen illustrieren; die Verallgemeinerung muss auf Forschung beruhen. Gerade diese Trennung ermöglicht es, über Macht, Status, Sicherheit, Territorialität und bewusstes Knowledge Hiding zu sprechen, ohne konkrete Menschen ohne Evidenz zu diagnostizieren.

Die Organisation braucht Experten – aber keine Unfehlbarkeit

Eine Organisation sollte außergewöhnliche Experten besitzen: Menschen, die mehr wissen als andere, historische Zusammenhänge verstehen, schwierige Probleme lösen und in einer Krise genau die Erfahrung einbringen können, die gerade gebraucht wird. Das Risiko beginnt nicht mit Kompetenz, sondern mit Exklusivität.

Wenn nur noch eine Person wesentliche Teile eines Systems versteht, kritische Produktionsprobleme lösen kann, Änderungen faktisch freigeben muss und gleichzeitig als einzige glaubwürdig beurteilen kann, ob technische Aussagen über dieses System überhaupt richtig sind, ist die Organisation strukturell abhängig geworden. Diese Abhängigkeit muss weder absichtlich entstanden sein noch bewusst aufrechterhalten werden. Das ändert nichts daran, dass persönliche Interessen existieren können: Wissen kann Status, Einfluss, Autonomie und unter bestimmten Bedingungen auch Sicherheit erzeugen. Eine Veränderung, die das System für die Organisation gesünder macht, kann deshalb gleichzeitig die bisherige Bedeutung einer Person verändern.

Das macht diese Person nicht zum Bösewicht. Es macht die Situation zu einem Interessenkonflikt, den eine professionelle Organisation nicht ignorieren darf.

Der Truck Factor beschreibt, was passiert, wenn die Schlüsselperson morgen fehlt. Das Wissensmonopol ist bereits ein Problem, solange sie noch da ist.

Noch gefährlicher als die operative Abhängigkeit ist dabei die epistemische, denn sie betrifft nicht nur die Fähigkeit, Arbeit auszuführen, sondern auch die Fähigkeit, technische Aussagen unabhängig zu beurteilen:

Die gefährlichste Form des Wissensmonopols ist nicht, dass nur eine Person das System reparieren kann. Es ist der Zustand, in dem nur noch diese Person erklären kann, was technisch überhaupt wahr ist.

Vielleicht ist genau deshalb die offensichtlichste Stärke eines Projekts manchmal zugleich sein Warnsignal: die Person, die immer helfen kann, jeden Sonderfall kennt, bei jeder Krise angerufen wird und ohne die nichts mehr geht. Sie ist nicht deshalb riskant, weil außergewöhnliches Wissen problematisch wäre, sondern weil eine Organisation irgendwann verlernen kann, ohne dieses eine Wissen selbst handlungsfähig zu bleiben.

Die Schlüsselperson kann gleichzeitig einer der wertvollsten Menschen im System und eines seiner größten Risiken sein.

Eine gesunde Organisation besitzt Experten. Ein fragiles System benötigt Helden.

Damit ist auch die Richtung für eine spätere Sanierung erkennbar, ohne sie hier vorwegzunehmen: Nicht der Experte muss verschwinden, sondern das Monopol.

Quellen und weiterführende Forschung

• Avelino, G., Passos, L., Hora, A. & Valente, M. T. (2016): A Novel Approach for Estimating Truck Factors. 24th IEEE International Conference on Program Comprehension. DOI 10.1109/ICPC.2016.7503718.
• Connelly, C. E., Zweig, D., Webster, J. & Trougakos, J. P. (2012): Knowledge hiding in organizations. Journal of Organizational Behavior, 33(1), 64–88. DOI 10.1002/job.737.
• French, J. R. P. Jr. & Raven, B. H. (1959): The Bases of Social Power. In D. Cartwright (Hrsg.), Studies in Social Power. Institute for Social Research, University of Michigan. Zur Weiterentwicklung des Modells siehe Raven (1993): DOI 10.1111/j.1540-4560.1993.tb01191.x.
• Issac, A. C., Bednall, T. C., Baral, R., Magliocca, P. & Dhir, A. (2022): The effects of expert power and referent power on knowledge sharing and knowledge hiding. Journal of Knowledge Management, 27(2), 383–403. DOI 10.1108/JKM-10-2021-0750.
• Moser, K. S. (2017): The Influence of Feedback and Expert Status in Knowledge Sharing Dilemmas. Applied Psychology, 66(4), 674–709. DOI 10.1111/apps.12105.
• Huo, W., Cai, Z., Luo, J., Men, C. & Jia, R. (2016): Antecedents and intervention mechanisms: a multi-level study of R&D team’s knowledge hiding behavior. Journal of Knowledge Management, 20(5), 880–897. DOI 10.1108/JKM-11-2015-0451.
• Tian, Y., Mao, L., Zhou, M. & Cao, Q. (2021): Knowledge-based psychological ownership and knowledge hiding: The roles of loss of knowledge power and emotional intelligence. Social Behavior and Personality, 49(8), e10530. DOI 10.2224/sbp.10530.
• Jeong, J., Kim, B.-J. & Lee, J. (2023): The effect of job insecurity on knowledge hiding behavior: The mediation of psychological safety and the moderation of servant leadership. Frontiers in Public Health, 11, 1108881. DOI 10.3389/fpubh.2023.1108881.
• Arain, G. A., Bhatti, Z. A., Hameed, I., Khan, A. K. & Rudolph, C. W. (2024): A meta-analysis of the nomological network of knowledge hiding in organizations. Personnel Psychology, 77(2), 651–682. DOI 10.1111/peps.12562.
• Schou, P. K. & Nesheim, T. (2024): What We Do in the Shadows: How expert workers reclaim control in digitalized and centralized organizations through ‘stealth work’. Organization Studies, 45(5), 719–744. DOI 10.1177/01708406241233175.