Co katastrofy lotnicze uczą o dynamice zespołowej

Wahadłowiec kosmiczny Challenger

28 stycznia 1986. Wahadłowiec kosmiczny Challenger eksplodował 73 sekundy po starcie, zabijając wszystkich siedmiu członków załogi.

Przyczyna? Uszczelka O-ring zawiodła z powodu niskiej temperatury. Inżynierowie ostrzegali o tym. Mieli dane. Mieli obawy.

Ale nie naciskali wystarczająco mocno. Kierownictwo nadrzędziło inżynierom. Start się odbył.

Wnioski, które wszyscy wyciągają: "mów głośniej."

Ale to nie jest prawdziwy wniosek. Prawdziwy wniosek dotyczy dynamiki zespołowej, gradientów autorytetu i systemów, które umożliwiają katastrofalne decyzje.

Prawdziwe Wnioski

1. Gradienty autorytetu zabijają.

W aerospace jest jasna hierarchia. Dowódca ma autorytet. Pilot ma autorytet. Inżynierowie są "poniżej" w łańcuchu decyzyjnym.

To tworzy środowisko, gdzie osoby o niższej randze wahają się kwestionować osoby wyższe. Gdy inżynier mówi "to może być niebezpieczne" a menedżer mówi "startujemy," inżynier uczy się nie naciskać.

To dzieje się w każdej organizacji. Gdy starszy inżynier mówi "powinniśmy to zrobić po mojemu" a młodszy inżynier ma wątpliwości, młodszy uczy się milczeć.

Gradient jest realny. Szkoda jest realna.

2. Nie ma złej pogody, nie ma złego ubrania.

To terminologia aerospace: nie ubieraj się pod warunki, ubieraj się pod pracę, którą musisz wykonać.

W kategoriach dynamiki zespołowej: stwórz środowisko, gdzie mówienie jest właściwą rzeczą do zrobienia, niezależnie od warunków.

Jeśli ktoś musi być wyznaczonym "pytającym," to jest jego praca. Nie jako dodatkowe zadanie — jako podstawowa odpowiedzialność.

3. Normalizacja dewiacji.

Uszczelki O-ring doświadczyły "anomalii" wcześniej — przebicie, erozja. To było akceptowane jako normalne. Nikt nie podnosił alarmu.

Tak kumuluje się dług techniczny. Nie jako dramatyczne awarie, ale jako powolne odchylenia od standardów. Każde małe odchylenie wydaje się akceptowalne. Agregat jest katastrofalny.

4. Całość jest większa niż suma.

W aerospace nie potrzebujesz tylko mądrych ludzi. Potrzebujesz mądrych ludzi, którzy pracują razem. Najważniejszy system to nie silnik czy awionika — to system ludzki, który je obsługuje.

Zespoły, które nie komunikują się, nie ufają sobie, nie dzielą informacjami — te zespoły zawodzą, niezależnie od indywidualnych zdolności.

Zarządzanie Zasobami Załogi

Po badaniu katastrof za każdym razem, aerospace rozwinęło Crew Resource Management (CRM) — system szkolenia zespołów do efektywnej pracy razem.

CRM uczy:

Odpowiednie mówienie. Nie po prostu "mów głośniej" (co nie działa) — konkretne techniki podnoszenia obaw w sposób, który jest słyszany.

Przywództwo zapraszające wkład. Pilot, który aktywnie prosi o obawy, uznaje je i reaguje na nie.

Wzajemne monitorowanie wydajności. Członkowie zespołu obserwujący pracę innych, łapiący błędy, zanim się skumulują.

Procesy decyzyjne. Ustrukturyzowane podejścia do podejmowania decyzji wysokiego ryzyka z wkładem wszystkich stron.

To szkolenie dramatycznie zmniejszyło wypadki. Te same zasady stosują się bezpośrednio do zespołów inżynierskich.

Równoległość Inżynierska

Każda awaria oprogramowania ma składnik dynamiki zespołowej:

Migracja bazy danych, która nie była testowana. Ktoś wiedział, że powinna być testowana. Nie naciskał wystarczająco. Produkcja zawiodła. Winę przypisano, nie przyczyny główne.

Luka w bezpieczeństwie, którą wszyscy przeoczyli. Ktoś podniósł obawy. Zostały odstawione jako "zbyt paranoiczne." Włamanie nastąpiło.

Opóźniony projekt, o którym wszyscy wiedzieli, że jest opóźniony. Raporty statusu mówiły „zgodnie z planem.” Rzeczywistość mówiła „przegrywa.” Nikt nie chciał być posłańcem złych wiadomości.

To nie są awarie techniczne. To awarie zespołowe przebrane za awarie techniczne.

Co To Oznacza dla Liderów Inżynierskich

Twórz jawne sieci bezpieczeństwa dla podnoszenia obaw.

Nie mów tylko "moje drzwi są zawsze otwarte." To nie działa. Ludzie nie chcą zawracać głowy liderowi.

Zamiast tego: planuj jawne przeglądy, gdzie obawy są zadawane. Zadawaj konkretne pytania. Podążaj za odpowiedziami.

Spraw, by gradient autorytetu był jawny, a potem go spłaszcz.

Uznaj, że hierarchia istnieje. Następnie jawnie zapraszaj do kwestionowania przez wszystkich. "Chcę słyszeć obawy od wszystkich, niezależnie od poziomu. Będę o nie jawnie prosić."

Obserwuj normalizację dewiacji.

Śledź małe odchylenia. Zapytaj: "to odchylenie od standardów jest akceptowalne, czy kumuluje ryzyko?"

Buduj wzajemne monitorowanie.

Recenzje kodu to nie tylko o jakości kodu — o członkach zespołu obserwujących pracę innych. Spraw, by były znaczące.

Ćwicz podejmowanie decyzji.

Sposób, w jaki zespół podejmuje decyzje, jest możliwy do nauczenia. Ćwicz to jawnie. Przeglądaj decyzje potem. Ucz się.

Ujęcie HEXACO

Czynniki osobowości przewidujące awarie zespołowe w środowiskach wysokiego ryzyka:

Niski Altruizm. Członkowie zespołu, którzy naturalnie nie pomagają innym, nie czują odpowiedzialności za zbiorowe wyniki.

Niskie Zaufanie. Członkowie zespołu, którzy zakładają, że inni są niekompetentni lub złośliwi.

Niska Prostolinijność. Członkowie zespołu, którzy komunikują się pośrednio, nie mówią tego, co myślą.

Wysoka Lękliwość (Emocjonalność). Członkowie zespołu zestresowani tak, że nie mogą myśleć jasno, komunikować się, pomagać.

Te cechy mapują się bezpośrednio na wymiary HEXACO. Rozumienie ich pomaga przewidywać i zapobiegać awariom zespołowym.

Czynnik Ludzki

W aerospace nazywają to "czynnikiem ludzkim" — wkład błędu ludzkiego w wypadki.

Oto niewygodna prawda: większość "błędów ludzkich" nie dotyczy indywidualnych błędów. Dotyczy dynamiki zespołowej, która umożliwia lub zapobiega tym błędom.

Mądry inżynier może pracować w dysfunkcyjnym zespole i produkować śmieci. Zwykły inżynier może pracować w wysoko funkcjonującym zespole i produkować doskonałość.

Zespół jest systemem. System jest produktem tego, jak ludzie wchodzą w interakcje.

Inwestuj w dynamikę zespołową. Buduj zespoły, które komunikują się, kwestionują siebie, łapią błędy, zanim się skumulują, mówią, gdy coś jest nie tak.

Bo w końcu różnica między udanym startem a katastrofalną awarią nie jest technologia.

To zespół.

Ten artykuł jest częścią serii Leadership Unfiltered o dynamice zespołów inżynierskich. Więcej informacji o budowaniu wysoko wydajnych zespołów w erze AI znajdziesz w LU Teams.