Psychologische Sicherheit: Die verborgene Kraft hinter leistungsstarken Teams

Der Aufhänger: Google gab 10 Mio. $ aus, um eine einzige Sache zu lernen

2012 startete Google Project Aristotle – eine mehrjährige, millionenschwere Studie, um eine einzige Frage zu beantworten: Was macht ein Team effektiv?

Sie analysierten 180 Teams, befragten Hunderte Mitarbeiter und maßen Dutzende Variablen: individuellen IQ, technisches Können, Betriebszugehörigkeit, Freundschaftsnetzwerke, Persönlichkeitstypen, wie oft man sich außerhalb der Arbeit traf. Nichts davon sagte die Teamleistung zuverlässig vorher.

Der mit Abstand stärkste Prädiktor war etwas weit weniger Greifbares: ob sich die Teammitglieder sicher fühlten, zwischenmenschliche Risiken einzugehen.

Das betrifft dich unmittelbar. In der IT-Beratung bewegst du dich ständig in Umgebungen, in denen Menschen „Ich weiß es nicht" sagen, Risiken vor einem Kunden ansprechen, die Entscheidung eines erfahrenen Architekten infrage stellen oder zugeben sollen, dass eine Deadline unrealistisch ist. Ob Menschen das tatsächlich tun – oder Dinge stillschweigend schieflaufen lassen –, hängt fast vollständig von der psychologischen Sicherheit der Umgebung ab.

Kernkonzept: Was psychologische Sicherheit wirklich ist

Amy Edmondson (Harvard Business School) prägte den Begriff Ende der 1990er Jahre, nachdem sie Medikationsfehlerraten in Krankenhäusern untersucht hatte. Sie erwartete, dass leistungsstarke Teams weniger Fehler berichten würden. Stattdessen berichteten sie mehr. Der Grund: Bessere Teams hatten Umgebungen geschaffen, in denen sich Pflegekräfte und Ärzte sicher fühlten, Fehler zuzugeben, statt sie zu verbergen.

Ihre Definition:

Psychologische Sicherheit ist die geteilte Überzeugung, dass das Team ein sicherer Ort für zwischenmenschliches Risiko ist.

Drei Dinge, die sie nicht ist und die häufig für Verwirrung sorgen:

Das klarste mentale Modell: Stell dir vor, du hast in einem Meeting eine schlechte Idee. Vertrauen heißt zu glauben, dass deine Kollegin sie dir nicht stiehlt. Psychologische Sicherheit heißt zu glauben, dass deine Kollegin dich nicht dafür auslacht.

Die vier Stufen (Timothy Clarks Framework)

Clarks Modell zeichnet nach, wie sich psychologische Sicherheit in einem Team entwickelt – und wo die meisten Teams stecken bleiben:

Stufe 1: Inklusionssicherheit

„Ich gehöre dazu und werde nicht ausgeschlossen."

Menschen müssen sich als Mitglieder akzeptiert fühlen, bevor sie sich einbringen. In der deutschen IT-Beratung scheitert das oft an Senioritätslinien – Junior-Berater fühlen, dass sie sich erst beweisen müssen, bevor sie zu Diskussionen beitragen „dürfen".

Anzeichen, dass sie fehlt: Neue Teammitglieder verstummen in Meetings. Menschen sprechen nur, wenn sie angesprochen werden.

Stufe 2: Lernsicherheit

„Ich kann Fragen stellen, Unwissen zugeben und Fehler machen, ohne mich zu blamieren."

Hier scheitern die meisten technischen Teams. „Was macht dieser API-Endpunkt eigentlich?" oder „Ich verstehe nicht, warum wir diese Architektur gewählt haben" zu fragen, kann sich anfühlen wie das Eingeständnis von Inkompetenz.

Anzeichen, dass sie fehlt: Niemand stellt klärende Fragen. Bugs werden versteckt. Post-mortems werden zu Leistungsbeurteilungen.

Stufe 3: Beitragssicherheit

„Ich kann Ideen einbringen und den Status quo infrage stellen, ohne abgewürgt zu werden."

Hier lebt Innovation. Ein Berater, der einen Fehler in einem Migrationsplan erkennt, aber schweigt, weil der Projektleiter sich bereits festgelegt hat – das ist ein Versagen auf Stufe 3.

Anzeichen, dass sie fehlt: „Nicht mein Platz, das zu sagen", „Die hören sowieso nicht zu", Brainstormings, in denen nur die Senioren reden.

Stufe 4: Herausforderungssicherheit

„Ich kann mächtige Personen und bestehende Normen infrage stellen, ohne Vergeltung."

Die seltenste und wertvollste Stufe. Sie ist es, die einen Junior-Entwickler befähigt, einem Kunden zu sagen, dass dessen Cloud-Architektur den BSI-Grundschutz verletzt – selbst wenn der CTO des Kunden im Raum sitzt.

Drei konkrete Beispiele

1. Das Paradox des medizinischen Fehlers (Edmondsons ursprüngliche Forschung)

Edmondson stellte fest, dass die besten Krankenhausteams zehnmal mehr Medikationsfehler berichteten als durchschnittliche Teams. Ihre ursprüngliche Hypothese – dass bessere Teams weniger Fehler machten – war falsch.

Bessere Teams machten nicht weniger Fehler; sie erkannten und meldeten sie früher. Die Kultur machte es sicher zu sagen: „Ich habe die falsche Dosis gegeben, hier ist, was passiert ist." In Teams mit geringer Sicherheit wurden Fehler vergraben, bis sie ernst wurden.

Übertragung auf die IT-Beratung: Ein Team, das im Sprint Review Bugs lautstark sichtbar macht, ist gesünder als eines, das immer „im Plan" ist, bis der Go-live scheitert.

2. Googles Kultur der schuldfreien Postmortems (SRE)

Das Site-Reliability-Engineering-Handbuch von Google baut Stufe-2- und Stufe-3-Sicherheit ausdrücklich in den Incident-Prozess ein. Nach jedem Ausfall:

• Die Person, die den Vorfall verursacht hat, schreibt das Postmortem.
• Es gibt keine schuldzuweisende Sprache („X hat einen Fehler gemacht" → „das System ließ zu, dass X passierte").
• Die Erkenntnisse werden intern veröffentlicht, damit andere lernen können.

Das Ergebnis: Ingenieure melden Vorfälle schneller, vertuschen Beinahe-Fehler nicht und die Organisation lernt, statt nur zu bestrafen.

Für ein deutsches mittelständisches IT-Unternehmen: Die meisten Firmen betreiben Postmortems noch als Schuldsuche. Die organisatorischen Kosten – in verborgenen Problemen und unengagierten Ingenieuren – sind enorm.

3. Das Hierarchieproblem in der deutschen Geschäftskultur

Die deutsche Unternehmenskultur weist eine dokumentierte hohe Machtdistanz auf – es gibt eine starke Norm, Autorität und Hierarchie zu respektieren. Das schafft eine strukturelle Herausforderung für psychologische Sicherheit, besonders auf Stufe 3 und 4.

Forschungen von Geert Hofstede zeigen, dass Deutschland mäßig hoch bei der Unsicherheitsvermeidung und mittel bei der Machtdistanz liegt – das heißt, Menschen erwarten klare Strukturen und zögern etwas, jene über ihnen herauszufordern.

Das zeigt sich in der IT-Beratung, wenn:

• ein Berater Scope Creep erkennt, es dem Partner aber nicht sagt,
• ein Team weiß, dass der Zeitplan unmöglich ist, im Lenkungsausschuss aber grünen Status präsentiert,
• Sicherheitsrisiken intern angesprochen, aber nie zum Kunden eskaliert werden.

Die Lösung ist nicht, Hierarchie zu zerstören – sondern Herausforderung innerhalb der Hierarchie ausdrücklich zu legitimieren. Die Führungskraft muss die Tür öffnen.

Das Dilemma (und die Chance) der Führungskraft

Psychologische Sicherheit entsteht nicht von selbst. Sie muss von oben vorgelebt werden. Die Forschung ist eindeutig: Das wirkungsstärkste Einzelverhalten für eine Teamleitung oder einen Projektleiter ist, als Erster Verletzlichkeit zu zeigen.

Das bedeutet:

• „Ich weiß es nicht" zu sagen, bevor man andere bittet, Unsicherheit zuzugeben,
• in Retrospektiven Fragen zu stellen statt Antworten zu geben,
• das Ansprechen von Risiken durch andere öffentlich anzuerkennen („Guter Hinweis – das hätte uns drei Sprints gekostet"),
• niemals den Überbringer zu bestrafen, selbst wenn die Botschaft unwillkommen ist.

Edmondson nennt das „die Arbeit als Lernproblem rahmen, nicht als Ausführungsproblem".

Die Erkenntnis zum Mitnehmen

Mach diese Woche ein einfaches Experiment in einem Meeting oder einer Interaktion:

Stelle eine echt neugierige Frage, statt eine Aussage zu treffen.

Statt: „Wir sollten hier Azure API Management nutzen." Versuche: „Was müssten wir glauben, damit Azure API Management hier die richtige Wahl ist?"

Statt: „Dieser Zeitplan ist unrealistisch." Versuche: „Was ist unsere größte Unsicherheit dabei, diesen Termin zu halten?"

Diese Technik – Erkundung vor Befürwortung (inquiry before advocacy) – bewirkt zweierlei gleichzeitig: Sie signalisiert, dass Fragen willkommen sind, und sie schafft Raum, damit andere zeigen, was sie wirklich denken, statt das, was sie für deine Erwartung halten.

Reflexionsfrage: Denk an das letzte Mal, als du oder jemand in deinem Team über ein echtes Risiko geschwiegen hat. Was hätte es sicher gemacht, den Mund aufzumachen? Was hat es gekostet, diese Information nicht früher zu kennen?

Edmondsons Buch „The Fearless Organization" (2018) ist die beste Einzelquelle, wenn du tiefer einsteigen willst. Ihr TED-Talk von 2014 ist eine gute zwölfminütige Einführung.

← All articles