Brak bezpieczeństwa psychologicznego to nie tylko problem działów HR, ale realne ryzyko operacyjne i finansowe, co udowodnił kryzys Boeing 737 Max. Zgodnie z badaniami Google, ten jeden czynnik decyduje o tym, czy zespół IT staje się wysokowydajną jednostką, czy grupą ludzi ukrywającą błędy krytyczne dla systemów i biznesu.
Boeing 737 Max: Architektura katastrofy przez strach
Przypadek Boeinga stanowi brutalną lekcję dla architektów systemów i liderów technicznych. Analiza wewnętrznej korespondencji ujawniła, że inżynierowie wiedzieli o problemach z symulatorami i złożonymi systemami awioniki, jednak bali się zgłaszać uwagi kierownictwu. Dominowała kultura skupiona na agresywnych harmonogramach produkcji i redukcji kosztów szkolenia pilotów.
Pracownicy narzekali jedynie między sobą, obawiając się, że bycie posłańcem złych wiadomości skończy się zwolnieniem przy najbliższej redukcji etatów. Dr Amy Edmondson z Harvard Business School definiuje bezpieczeństwo psychologiczne jako gwarancję, że nikt nie zostanie ukarany ani upokorzony za zgłoszenie błędu lub zadanie trudnego pytania. W Boeingu brak tego fundamentu doprowadził do tragicznych w skutkach błędów projektowych, które mogły zostać wykryte na etapie wczesnych testów.
Mit „miłego zespołu” kontra Learning Zone
Wielu liderów IT błędnie zakłada, że bezpieczeństwo psychologiczne polega na byciu miłym i unikaniu konfliktów. Z perspektywy inżynieryjnej to błąd poznawczy, który zabija „accountability” (odpowiedzialność). Prawdziwe bezpieczeństwo psychologiczne to przestrzeń do otwartej, merytorycznej debaty opartej na danych, nawet jeśli jest ona niekomfortowa.
Zgodnie z modelem Edmondson, zespoły mogą znaleźć się w czterech strefach: Anxiety Zone (Strefa Lęku): Wysokie standardy przy niskim bezpieczeństwie. Ludzie boją się ryzykować, co paraliżuje innowacje w środowiskach takich jak chmura czy cyberbezpieczeństwo. Comfort Zone: Wysokie bezpieczeństwo, niskie standardy. Zespoły są koleżeńskie, ale brakuje im wyzwań. * Learning Zone: „Sweet spot”, gdzie wysokie standardy łączą się z zaufaniem. To tutaj zespoły otwarcie omawiają błędy, by optymalizować kod i procesy.
Talent Magnet: Lekcje od Palantir i Google
Google, realizując Project Aristotle, przeanalizowało 180 zespołów, by odkryć, że skład osobowy (np. liczba doktorów w zespole) ma mniejsze znaczenie niż sposób, w jaki członkowie ze sobą interagują. Bezpieczeństwo psychologiczne okazało się najważniejszą z pięciu kluczowych dynamik sukcesu.
Inne podejście prezentuje Palantir, opisywany jako „autorytarna demokracja”. Mimo silnego przywództwa Alexa Karpa, firma promuje ekstremalną sprawczość („high agency”) i kulturę „poszukiwania prawdy”. Inżynierowie (Forward-Deployed Engineers) mają za zadanie nieustannie pytać klientów: „Czego nienawidzisz w tym produkcie?”. Taka brutalna szczerość pozwala na szybką iterację i budowę rozwiązań, które faktycznie działają w trudnych warunkach operacyjnych.
Wnioski praktyczne dla lidera technicznego
- Ramuj sytuację: Przedstawiaj prace nad systemami jako proces uczenia się w warunkach niepewności, a nie tylko egzekucję zadań.
- Wymuszaj wkład (Insist on input): Bezpośrednio pytaj członków zespołu o zdanie, zwłaszcza tych, którzy milczą podczas Code Review.
- Doceniaj posłańców: Nigdy nie reaguj negatywnie na informację o długu technologicznym czy luce w zabezpieczeniach. Twoja reakcja buduje standard na przyszłość.
- Buduj standardy, nie tylko polisy: Przepisy (jak Workplace Psychological Safety Act) nie stworzą kultury – tworzy ją każda interakcja wewnątrz grupy.
Dodaj komentarz