Psychological Safety hat in weniger als einem Jahrzehnt den vollständigen Weg vom Forschungskonzept zum Corporate-Buzzword zurückgelegt. Er erscheint heute in Team-Chartas, Leadership-Kompetenzrahmen und HR-Trainingsprogrammen weltweit. Die meisten Organisationen, die den Begriff verwenden, haben das, was er beschreibt, nicht geschaffen. Einige haben es durch ihre Versuche sogar verschlechtert.


Der Hook: Der Begriff, den alle benutzen und niemand versteht

Bitte einen Raum voller Manager, Psychological Safety zu definieren, und du erhältst verschiedene Antworten. „Das bedeutet, dass Menschen sich wohl fühlen, ihre Meinung zu sagen.” „Das bedeutet, wir haben eine Blame-Free-Kultur.” „Das bedeutet, dass jede Meinung geschätzt wird.” Diese Antworten sind nicht exakt falsch. Aber sie verfehlen die Präzision dessen, was die Forschung tatsächlich beschreibt – und diese Präzision ist wichtig, weil ohne sie Versuche, Psychological Safety zu schaffen, oft etwas völlig anderes schaffen.


Die Realität: Was die Forschung wirklich sagt

Das Konzept der Psychological Safety wurde von der Harvard-Business-School-Professorin Amy Edmondson entwickelt, deren Forschung in den 1990er Jahren an Medizin-Teams ein kontraintuitives Ergebnis produzierte: Die Teams, die die meisten Fehler meldeten, waren nicht die schlechtesten Teams. Sie waren die besten. Die hochleistungsfähigen Teams machten nicht mehr Fehler – sie meldeten sie ehrlicher. Der Unterschied war das Team-Klima: In hochleistungsfähigen Teams glaubten die Menschen, dass es sicher war, Probleme anzusprechen, ohne Bestrafung oder Demütigung zu fürchten.

Edmondson definierte Psychological Safety als „eine gemeinsam geteilte Überzeugung der Teammitglieder, dass das Team sicher für zwischenmenschliches Risikoverhalten ist.” Die Schlüsselwörter sind gemeinsam geteilt, zwischenmenschlich und Risiko. Es geht nicht um Komfort. Es geht nicht um Harmonie. Es geht um die spezifische Überzeugung, dass du zwischenmenschliche Risiken eingehen kannst – sprechen, widersprechen, Unwissenheit zugeben, ein Problem melden – ohne negative Konsequenzen für deinen Status in der Gruppe.

Die Google-Bestätigung

Psychological Safety erreichte das Mainstream-Business-Bewusstsein durch Googles Project Aristotle – ein mehrjähriges Forschungsprojekt, das 180 Google-Teams untersuchte, um zu identifizieren, was manche Teams deutlich effektiver machte als andere. Der 2016 veröffentlichte Befund war in seiner Klarheit bemerkenswert: Psychological Safety war bei weitem der wichtigste Faktor in der Team-Effektivität, wichtiger als individuelles Talent, Team-Zusammensetzung oder jede andere Variable, die die Forscher maßen.

Googles Definition stimmte mit Edmondsons überein: Psychological Safety war die Überzeugung, dass das Team dich nicht in Verlegenheit bringen, zurückweisen oder bestrafen würde, wenn du dich äußerst. Teams mit hoher Psychological Safety schnitten bei nahezu jedem Maß, das die Forschung verfolgte, besser ab.

Leseempfehlung: Googles Project-Aristotle-Forschung ist auf rework.withgoogle.com verfügbar. Amy Edmondsons Buch „The Fearless Organisation” (2018) ist die umfassendste Behandlung der Forschung und ihrer organisationalen Implikationen. Beides lohnt sich zu lesen, bevor man eine Intervention plant, die Psychological Safety verbessern soll.


Der Checksum: Was Psychological Safety nicht ist

Die Lücke zwischen dem Forschungskonzept und seiner organisationalen Anwendung ist erheblich. Hier sind die häufigsten Fehlanwendungen.

Es ist keine Nettigkeit

Die häufigste Fehlanwendung. Organisationen, die Psychological Safety mit einer angenehmen, konfliktfreien Umgebung gleichsetzen, schaffen Teams, in denen schwierige Gespräche nicht stattfinden – was das Gegenteil von dem ist, was Psychological Safety ermöglicht. Hohe Psychological Safety bedeutet nicht, dass alle einig sind oder dass keine Meinungsverschiedenheiten auftreten. Sie bedeutet, dass Meinungsverschiedenheiten ehrlich ausgedrückt werden können, ohne persönliche Konsequenzen.

Ein Team, in dem alle höflich sind und niemand den anderen herausfordert, ist nicht psychologisch sicher. Es ist psychologisch komfortabel – was eine sehr andere Sache ist. Komfort bewahrt den Status quo. Sicherheit ermöglicht ehrliche Herausforderung davon.

Es wird nicht durch einen Workshop erreicht

Die zweithäufigste Fehlanwendung. Organisationen führen einen halbtägigen Workshop zu Psychological Safety durch, erstellen Team-Grundregeln und betrachten das Problem als gelöst. Der Workshop mag gut moderiert sein und die Grundregeln mögen durchdacht geschrieben sein. Sie werden allein keine Psychological Safety schaffen.

Psychological Safety wird durch gesammelte Erfahrungen aufgebaut, was tatsächlich passiert, wenn Menschen zwischenmenschliche Risiken eingehen. Wenn jemand in einem Meeting spricht und abgewiesen, unterbrochen oder später aus Entscheidungen ausgeschlossen wird, ist diese Erfahrung mächtiger als jede Grundregel. Wenn jemand einen Fehler zugibt und die Reaktion unterstützend statt bestrafend ist, baut diese Erfahrung die Überzeugung auf, dass Risikobereitschaft sicher ist. Kein Workshop schafft diese Überzeugung. Nur konsistentes Verhalten über Zeit.

Es ist nicht die Aufgabe der Führungskraft, Menschen sicher zu fühlen

Näher an der Wahrheit, aber immer noch ungenau. Die Aufgabe der Führungskraft ist nicht, Menschen sicher zu fühlen – es ist, sich so zu verhalten, dass es genuinzu sicher ist, zwischenmenschliche Risiken einzugehen. Das klingt ähnlich. Es ist nicht.

Menschen sicher zu fühlen lässt sich durch Beruhigung, positive Rahmung, eine Atmosphäre der Wärme erreichen. Das produziert Komfort, keine Sicherheit. Genuine Psychological Safety erfordert, dass Führungskräfte tatsächlich ohne Bestrafung oder Demütigung reagieren, wenn Menschen zwischenmenschliche Risiken eingehen. Das Verhalten, nicht die Absicht, ist es, was zählt. Und das Verhalten muss konsistent sein – eine Instanz, in der eine Führungskraft defensiv auf Kritik reagiert, kann monatelang aufgebautes Vertrauen zerstören.

„Psychological Safety wird nicht in Workshops aufgebaut. Sie wird in den Momenten aufgebaut, nachdem jemand etwas Schwieriges gesagt hat. Was in diesen Momenten passiert, ist das, was das Team tatsächlich über Sicherheit lernt.” Markus – agile-checksum.com


Warum sie für Agile-Teams besonders wichtig ist

Psychological Safety ist kein Agile-spezifisches Konzept. Aber sie ist besonders kritisch für Agile-Teams, weil jede Agile-Zeremonie davon ausgeht, dass sie existiert.

  • Daily Standups erfordern, dass Teammitglieder Blocker und Schwierigkeiten ehrlich melden – was voraussetzt, dass sie glauben, ehrliches Melden wird nicht gegen sie verwendet.
  • Sprint Reviews erfordern ehrliches Feedback von Stakeholdern – was voraussetzt, dass Stakeholder glauben, ihr kritisches Feedback ist willkommen und nicht bedrohlich.
  • Retrospektiven erfordern, dass Teams echte Probleme statt sichere aufdecken – was eine genuine Überzeugung voraussetzt, dass das Ansprechen von Problemen zu Lösung statt zu Schuldzuweisung führt.
  • Sprint Planning erfordert ehrliche Schätzung statt optimistischer Verpflichtung – was voraussetzt, dass Teammitglieder glauben, „ich weiß es nicht” oder „das ist komplexer als es aussieht” zu sagen ist akzeptabel.

Führe eine dieser Zeremonien in einer Umgebung mit niedriger Psychological Safety durch und du bekommst die Theater-Versionen, die anderswo in diesem Blog beschrieben werden. Die Zeremonien finden statt. Der ehrliche Austausch, von dem sie abhängen, nicht. Das Format ist korrekt. Die Substanz fehlt.


Praxisbeispiele: Die Lücke zwischen Absicht und Realität

Die Blame-Free-Kultur, die keine war

Ein Technologieunternehmen hatte „Blame-Free-Kultur” als einen ihrer erklärten Werte. Er erschien auf der Unternehmenswebseite, im Mitarbeiterhandbuch und im Onboarding-Programm. Ein Post-Incident-Review-Prozess war speziell dafür konzipiert worden, systemische Ursachen statt individuelle Schuld zu identifizieren.

In der Praxis, als ein erheblicher Produktionsvorfall auftrat, war der Post-Incident-Review gründlich und gut moderiert. Die systemischen Ursachen wurden identifiziert. Die Empfehlungen wurden dokumentiert. Und dann erhielt, in einem separaten Gespräch, das nie offiziell anerkannt wurde, der Ingenieur, dessen Code-Änderung den Vorfall ausgelöst hatte, Feedback bei seinem nächsten Performance-Review, das „schlechtes Urteilsvermögen” als Entwicklungsbereich nannte.

Niemand kündigte an, dass die Blame-Free-Kultur eine Fiktion war. Niemand musste es. Das Team lernte die Lektion ohne Unterricht: der formale Prozess war blame-free. Die informellen Konsequenzen nicht. Die Menschen passten ihr Verhalten entsprechend an.

Die Retrospektive, die echt wurde

Ein Scrum-Team, das ich coachte, hatte sechs Monate lang Retrospektiven mit konsistent oberflächlichem Output durchgeführt. Die diskutierten Probleme waren real, aber geringfügig. Die bedeutenden Themen – eine dysfunktionale Beziehung zwischen dem Tech-Lead und dem Product Owner, eine Arbeitslast, die wirklich nicht nachhaltig war, eine technische Architekturentscheidung, von der das Team glaubte, sie sei falsch, aber von oben auferlegt worden – wurden nicht aufgedeckt.

In der siebten Retrospektive änderte ich das Format. Anstatt der üblichen strukturierten Übung stellte ich eine Frage: „Was ist die eine Sache, die du an der Arbeitsweise dieses Teams reparieren würdest, wenn du wüsstest, dass es keine Konsequenzen für das Sagen gibt?” Ich verließ den Raum für zehn Minuten und bat sie, ihre Antworten individuell zu schreiben, bevor sie teilten.

Die Antworten nannten jedes bedeutende Problem, das das Team sechs Monate lang vermieden hatte. Die Tech-Lead-und-Product-Owner-Beziehung. Die nicht nachhaltige Arbeitslast. Die Architekturentscheidung. In den folgenden Wochen wurden diese Themen mit sorgfältiger Moderation angegangen – nicht perfekt, nicht ohne Schwierigkeit, aber angegangen. Die Team-Performance verbesserte sich im folgenden Quartal messbar.

Was sich änderte, war nicht die Situation des Teams. Es war die vorübergehende Schaffung einer sichereren Bedingung für ehrliche Offenlegung. Die Frage „wenn es keine Konsequenzen gäbe” suspendierte ausdrücklich das zwischenmenschliche Risiko für ein Gespräch. Das Team nutzte die Öffnung.

Die Führungskraft, die die Dynamik änderte

Eine Abteilungsleiterin bei einem Versicherungsunternehmen hatte ein Team mit konsistent niedrigen Engagement-Werten und hoher Fluktuation. Retrospektiven produzierten oberflächliche Outputs. Einzelgespräche waren höflich und nichtssagend. Sie konnte die Quelle des Problems nicht identifizieren.

Auf den Rat eines Executive-Coaches hin probierte sie ein Experiment. Im nächsten All-Hands-Meeting beschrieb sie eine bedeutende strategische Entscheidung, die sie im Vorjahr getroffen hatte und die nicht die erwarteten Ergebnisse produziert hatte. Sie erklärte, was sie gedacht hatte, was schiefgelaufen war und was sie gelernt hatte. Sie minimierte den Fehler nicht und rahmte ihn nicht als Lernmöglichkeit in einer Art, die die Rechenschaftspflicht abmilderte. Sie war spezifisch und ehrlich darüber, falsch gelegen zu haben.

Der Effekt auf das Team war erheblich und schnell. Innerhalb von zwei Wochen erhielt sie mehr ehrliches Feedback in Einzelgesprächen als in den vorangegangenen sechs Monaten. Die Retrospektiven in den folgenden Sprints brachten Probleme ans Licht, die offensichtlich seit über einem Jahr vorhanden waren. Die Engagement-Werte verbesserten sich innerhalb eines Quartals messbar.

Nichts Strukturelles hatte sich geändert. Ein Akt genuiner Führungsvulnerabilität hatte, kraftvoller als jeder Workshop es könnte, demonstriert, dass ehrliche Offenlegung sicher war.


Wie man sie tatsächlich aufbaut

Es gibt keine Abkürzung. Aber es gibt Bedingungen, die konsistent die Entwicklung genuiner Psychological Safety unterstützen.

  • Das gewünschte Verhalten vorleben. Führungskräfte, die Unsicherheit zugeben, Fehler anerkennen und echte Neugier auf Team-Perspektiven ausdrücken, demonstrieren, wie Sicherheit in der Praxis aussieht. Das ist der einzeln wirkungsvollste Hebel, der Führungskräften zur Verfügung steht.
  • Auf schlechte Nachrichten mit Neugier reagieren, nicht mit Schuldzuweisung. Die Reaktion auf einen Fehler, ein verfehltes Ziel oder eine überbrachte schlechte Nachricht ist mächtiger als jede erklärte Richtlinie. Teams beobachten, was tatsächlich passiert. Reagiere mit „was ist passiert und was können wir lernen?” statt „wessen Schuld ist das und was sind die Konsequenzen?”
  • Es sicher machen, speziell dir zu widersprechen. Generelle Ermutigung zu Meinungsverschiedenheiten ist weniger mächtig als sichtbares Begrüßen von Widerspruch gegen eigene Positionen. Wenn ein Teammitglied die Idee einer Führungskraft herausfordert und die Führungskraft sich ernsthaft mit der Herausforderung auseinandersetzt statt die ursprüngliche Position zu verteidigen, wird diese Interaktion von allen im Raum beobachtet und erinnert.
  • Nachverfolgen, was angesprochen wurde. Menschen sprechen Themen an, wenn sie glauben, dass das Ansprechen irgendwohin führt. Wenn Probleme, die in Retrospektiven, Einzelgesprächen oder Team-Meetings aufgedeckt werden, konsistent anerkannt und dann vergessen werden, ist die implizite Botschaft, dass das Risikoeinzehen es nicht wert war.

Die Messfrage: Psychological Safety kann gemessen werden. Edmondsons ursprüngliche Forschung verwendete eine Sieben-Item-Skala, die weit verbreitet ist. Team-Health-Check-Tools wie das Spotify-Modell beinhalten Psychological-Safety-Dimensionen. Wenn du wissen möchtest, ob deine Interventionen funktionieren, miss die Baseline, interveniere und miss erneut. Intuition über Team-Klima ist unzuverlässig. Daten sind besser.


Das Fazit: Real, messbar und nicht verhandelbar

Psychological Safety ist kein Buzzword. Es ist eines der am rigorosesten erforschten Konzepte im Organisationsverhalten, mit konsistenten Belegen, die es mit Team-Performance, Innovation, Lernen und Wohlbefinden verknüpfen. Die Organisationen, die es als Buzzword behandeln – die es ihrer Werte-Liste hinzufügen, ohne die Führungsverhaltensweisen zu ändern, die bestimmen, ob es existiert – scheitern nicht nur daran, es zu schaffen. Sie zerstören, in manchen Fällen, aktiv Vertrauen, indem sie behaupten, etwas zu haben, was sie nicht haben.

Die Organisationen, die es ernst nehmen – die es als Produkt konsistenten Führungsverhaltens statt als Workshop-Ergebnis verstehen – neigen dazu, Teams aufzubauen, die ehrlicher, adaptiver und über die Zeit effektiver sind. Die Investition ist nicht in Programme oder Tools. Sie ist in der täglichen, wiederholten Entscheidung, auf zwischenmenschliches Risikoeinzehen mit Neugier und Unterstützung zu reagieren statt mit Defensivität und Konsequenz.

Führe den Checksum für die Psychological Safety deines Teams durch:

  1. Wann hat zuletzt jemand in deinem Team einer Senior-Führungskraft in einem Meeting widersprochen? Was passierte unmittelbar danach?
  2. Wann wurde zuletzt ein Fehler offen in deinem Team besprochen, ohne jeden Anflug von Schuld oder Konsequenz? Wer initiierte dieses Gespräch?
  3. Bringt deine Retrospektive jedes Mal dieselbe Art von Problem ans Licht – oder produziert sie gelegentlich etwas Überraschendes, das darauf hindeutet, dass Menschen Dinge sagen, die sie vorher nicht gesagt haben?

Die Antworten werden dir mehr über die Psychological Safety deines Teams sagen als jedes Survey-Tool. Sie werden dir auch sagen, wo du dich konzentrieren solltest, wenn du sie aufbauen möchtest.


In diesem Artikel verwendete Glossarbegriffe

  • Psychological Safety – Die gemeinsame Überzeugung, dass es sicher ist, zwischenmenschliche Risiken innerhalb eines Teams einzugehen.
  • Retrospective – Eine Scrum-Zeremonie zur Inspektion des Sprints und Identifizierung von Verbesserungen.
  • Agile Transformation – Der Prozess, durch den eine Organisation versucht, Agile-Werte und -Praktiken im großen Maßstab einzuführen.
  • Servant Leader – Eine Führungsphilosophie, die sich auf das Dienen des Teams statt das Dirigieren konzentriert.
  • Daily Standup – Ein 15-minütiges tägliches Event für das Team, um Fortschritte zu inspizieren und den Plan anzupassen.

Markus Philipp

Senior Scrum Master · 20+ Jahre IT · 16 Jahre Backend-Entwicklung

Ich überprüfe, ob das, was als Agile gilt, noch mit dem Original übereinstimmt. Enterprise-Kontext, keine Theorie.

Mehr über mich

Newsletter

Kein Buzzword-Bingo. Nur echtes Agile.

Direkt in dein Postfach. Kein Spam.

Kein Spam. Abmeldung jederzeit.