Różnorodność to koszt – dopóki nie wdrożysz bezpieczeństwa psychologicznego.

Masz zespół złożony z najlepszych specjalistów z różnych środowisk, kultur i pokoleń?
Świetnie. Właśnie drastycznie podniosłeś poziom ryzyka operacyjnego w swoim
projekcie. Brzmi jak biznesowa herezja?

Z perspektywy 20 lat na pierwszej linii frontu w IT – to po prostu fakt.
Na współczesnym rynku zarządzania różnorodność (diversity) jest sprzedawana jako automatyczna gwarancja innowacji, kreatywności i synergii.

W praktyce wdrażania złożonych systemów technologicznych rzadko jednak mówi się o drugiej stronie tego medalu:

różnorodność oznacza gigantyczny wzrost złożoności środowiska operacyjnego.

To zderzenie odmiennych modeli myślenia, różnych stylów komunikacji oraz diametralnie innych reakcji na stres i niepowodzenia.

Mechanizm, który organizacje tak często ignorują, jest bezlitosny: różnorodność nie
tworzy wartości samej w sobie.

Wartość z różnorodności pojawia się TYLKO i wyłącznie wtedy, gdy w zespole istnieje bezpieczeństwo psychologiczne.

Paradoks zróżnicowanego zespołu

Kiedy do jednego projektu technologicznego trafiają eksperci o skrajnie różnych kulturach operacyjnych i doświadczeniach, system staje się podatny na szum informacyjny.

Bezpieczeństwo psychologiczne nie jest tutaj synonimem „miłej atmosfery przy kawie” ani braku merytorycznego konfliktu. To precyzyjny parametr środowiskowy – przekonanie zespołu, że podjęcie ryzyka interpersonalnego nie skończy się
utratą pozycji, wizerunku lub krytyką personalną.

Jeśli wrzucisz zróżnicowanych ludzi do środowiska, w którym dominuje lęk przed oceną, ich odmienne perspektywy zamiast budować nową jakość, stają się obciążeniem operacyjnym. Zamiast otwartości uruchamiają się biologiczne mechanizmy obronne (zgodnie z modelem SCARF), które bezpośrednio wpływają na jakość dowożonych rozwiązań.

Neurobiologia wydajności operacyjnej

Z perspektywy neuroprzywództwa sprawa jest czysto techniczna. Mózg w stanie zagrożenia interpersonalnego przekierowuje zasoby energetyczne na przetrwanie. Lęk przed popełnieniem błędu lub wyjściem na niekompetentnego skutecznie blokuje pracę kory przedczołowej.

To właśnie ta struktura odpowiada w zespole IT za logikę, chłodną analizę ryzyka, architekturę systemową oraz pisanie czystego kodu.

Lider, który nie potrafi ustabilizować biologii swojego zespołu, nie wyciągnie z niego deklarowanych kompetencji. Żadna metodologia Agile, framework SAFe czy certyfikacja PMP nie uratuje wdrożenia przed błędami wynikającymi z przeciążenia poznawczego ludzi.

• Brak stabilizacji biologicznej zespołu generuje realny dług poznawczy, który uderza bezpośrednio w marżę, kontrolę kosztów i realizację milestone’ów. W środowisku pozbawionym bezpieczeństwa psychologicznego regularnie odpalają się określone anomalie procesowe:
• Ukrywanie błędów: Anomalie i bugi są maskowane tak długo, jak to możliwe, by chronić pozycję jednostki. Trafiają do rejestru dopiero wtedy, gdy stają się pożarem krytycznym na produkcji.
• Paraliż decyzyjny: Nikt nie podejmuje ryzyka architektonicznego. Decyzje są odkładane lub eskalowane w nieskończoność, ponieważ bezpieczniej jest milczeć niż zaproponować nieszablonowe rozwiązanie.
• Polaryzacja i silosy: Zamiast naturalnej wymiany wiedzy, zespół dzieli się na hermetyczne obozy („my kontra oni”).
• Komunikacja traci na jakości, a know-how ucieka z projektu wraz z rotacją
  przemęczonych specjalistów.

Różnorodność potrzebuje stabilnego podłoża.

Sama różnorodność nie dowozi wyniku. Generuje jedynie rosnącą złożoność, którą trzeba efektywnie zarządzać. Realna wartość biznesowa i przewaga konkurencyjna pojawiają się dopiero wtedy, gdy zespół nie traci cennych zasobów poznawczych na ciągłą samoobronę.

Dopiero w bezpiecznym środowisku odmienne perspektywy mogą się konstruktywnie zderzyć, by wyłapać ryzyka z odpowiednim wyprzedzeniem.

Bezpieczeństwo psychologiczne to fundament, na którym różnorodność ma w ogóle szansę zadziałać. Bez niego organizacja płaci za ogromny potencjał ekspertów, z którego na koniec nikt nie ma odwagi skorzystać.

Katarzyna Chmura
IT Project Management Practice Lead (DACH) | 20 lat w IT
Buduję struktury dowożenia projektów i projektuję odporność operacyjną zespołów.