Cisza wysokiego ryzyka, czyli dlaczego bezpieczeństwo psychologiczne jest kluczowe w IT

W świecie IT decyzje zapadają szybko, projekty są złożone, a presja czasu i jakości nieustannie rośnie. W takim środowisku jednym z największych zagrożeń nie jest brak kompetencji technicznych, lecz… cisza. Cisza wysokiego ryzyka to sytuacja, w której ludzie widzą problem, ryzyko lub błąd, ale nie mówią o nim głośno.

To właśnie tu bezpieczeństwo psychologiczne przestaje być „miękkim tematem HR” i staje się fundamentem skutecznego działania zespołów technologicznych.

Czym jest bezpieczeństwo psychologiczne?

Bezpieczeństwo psychologiczne, według Amy Edmondson, to przekonanie członków zespołu, że mogą zabierać głos, zadawać pytania, przyznawać się do błędów i zgłaszać wątpliwości bez obawy o ośmieszenie, karę czy negatywne konsekwencje dla swojej pozycji.

Nie oznacza to obniżania standardów. Wręcz przeciwnie. Oznacza środowisko, w którym wysokie wymagania idą w parze z wysokim poziomem zaufania.

W IT, gdzie błędy mogą kosztować pieniądze, reputację, bezpieczeństwo danych czy ciągłość działania systemów, brak otwartości bywa szczególnie groźny.

Cisza wysokiego ryzyka – skąd się bierze?

Cisza wysokiego ryzyka to nie brak zaangażowania. To milczenie wynikające z:

• lęku przed oceną lub konsekwencjami,
• wcześniejszych doświadczeń, w których zgłaszanie problemów było ignorowane lub karane,
• kultury „radzenia sobie samemu” i gloryfikowania odporności kosztem otwartości,
• silnej hierarchii, w której głos osób na niższych stanowiskach nie jest realnie brany pod uwagę.

W praktyce wygląda to tak:

• tester widzi ryzyko, ale nie zgłasza go, bo „i tak nikt nie słucha”,
• programista zauważa błąd, ale boi się podważyć decyzję seniora,
• analityk ma wątpliwości co do wymagań, lecz nie zadaje pytania, by „nie wyjść na niekompetentnego”.

Efekt? Problemy narastają w ciszy, aż eksplodują w najmniej dogodnym momencie- na produkcji, u klienta lub w sytuacji kryzysowej.

Projekt Arystoteles – przykład z branży technologicznej

To nie tylko teoria. Google, w ramach słynnego Projektu Arystoteles, przebadał setki zespołów, próbując odpowiedzieć na pytanie: co sprawia, że jedne zespoły działają lepiej niż inne?

Wbrew intuicji nie chodziło o poziom talentów, wykształcenie czy doświadczenie. Kluczowym czynnikiem okazało się bezpieczeństwo psychologiczne.

To odkrycie wpłynęło na sposób działania wielu firm technologicznych.

Spotify otwarcie buduje kulturę opartą na zaufaniu, autonomii i możliwości popełniania błędów jako elementu uczenia się. Microsoft, po transformacji kultury pod hasłem growth mindset, promuje zadawanie pytań, eksperymentowanie i uczenie się na porażkach. Pixar od lat stosuje zasadę, że każdy- niezależnie od stanowiska- ma prawo kwestionować pomysły, jeśli widzi ryzyko dla jakości projektu.

Nawet NASA, po katastrofach Challengera i Columbii, wskazała brak bezpieczeństwa psychologicznego i kulturę milczenia jako jedną z kluczowych przyczyn tragedii, co doprowadziło do głębokich zmian w sposobie komunikacji i raportowania ryzyk.

To pokazuje jedno. Bezpieczeństwo psychologiczne nie jest „miękkim tematem HR”, lecz twardą strategią zarządzania ryzykiem i jakością.

Kontekst Currendy – IT o wysokiej odpowiedzialności

Currenda działa w obszarze, w którym jakość, precyzja i odpowiedzialność mają szczególne znaczenie. To systemy informatyczne, które wspierają funkcjonowanie instytucji publicznych i procesy o wysokiej wrażliwości.

To środowisko, w którym błąd nie jest tylko „bugiem”, ale może mieć realne konsekwencje prawne, finansowe i społeczne.

W takim kontekście cisza wysokiego ryzyka jest szczególnie groźna. Jeśli ktoś widzi lukę w procedurze, ryzyko w systemie lub niejasność w wymaganiach, a nie czuje się bezpiecznie, by o tym mówić, organizacja traci najcenniejsze źródło informacji — wiedzę ludzi najbliżej problemu.

Jednocześnie firmy technologiczne działające w środowisku regulowanym, takie jak Currenda, pracują pod presją terminów, kontraktów i oczekiwań klientów. To naturalnie sprzyja koncentracji na „dowożeniu”, czasem kosztem refleksji nad ryzykami.

Dlatego bezpieczeństwo psychologiczne nie może być przypadkiem. Musi być świadomie budowane poprzez sposób prowadzenia spotkań, podejście do błędów i kulturę rozmowy o problemach.

Co buduje bezpieczeństwo psychologiczne w praktyce IT?

Bezpieczeństwo psychologiczne w Currendzie nie powstaje dzięki deklaracjom. Powstaje dzięki codziennym praktykom zespołowym i zachowaniom liderów.

W środowisku IT szczególnie ważne są:

Reakcja na błędy w code review
Jeśli code review staje się miejscem krytyki osoby zamiast analizy rozwiązania, ludzie szybko przestają zadawać pytania i proponować alternatywy. Kiedy natomiast błędy traktowane są jako element wspólnego uczenia się, rośnie otwartość i jakość dyskusji technicznych.

Blameless post-mortem po incydentach
W organizacjach technologicznych coraz częściej stosuje się zasadę „blameless post-mortem”, czyli analizę incydentu bez szukania winnych. Celem jest zrozumienie procesu i systemu decyzji, które doprowadziły do błędu, aby zapobiec jego powtórzeniu.

Retrospektywy jako przestrzeń realnej rozmowy
Retrospektywy nie powinny być formalnością. Dobrze prowadzone spotkania retrospektywne pozwalają zespołowi mówić o napięciach, problemach i usprawnieniach zanim zamienią się w poważne konflikty lub ryzyka projektowe.

Liderska reakcja na trudne pytania
Moment, w którym ktoś z zespołu mówi „nie rozumiem”, „to może być ryzykowne” albo „mamy tu problem”, jest testem dla lidera. Jeśli taka wypowiedź spotyka się z ciekawością i rozmową, zespół uczy się mówić więcej. Jeśli z irytacją lub bagatelizowaniem – uczy się milczeć.

Sygnały ostrzegawcze ciszy w zespole

Cisza wysokiego ryzyka rzadko pojawia się nagle. Zazwyczaj można zauważyć jej pierwsze symptomy.

Do najczęstszych należą:

• spadek liczby pytań podczas planowania sprintu lub refinementu,
• brak komentarzy i dyskusji w code review,
• szybkie i jednogłośne akceptowanie estymacji bez dyskusji,
• retrospektywy, na których pojawiają się tylko „bezpieczne” tematy,
• sytuacje, w których problemy pojawiają się dopiero na późnym etapie projektu.

Paradoksalnie zespół, który zawsze się zgadza, rzadko jest zespołem naprawdę zdrowym.

Dlaczego bezpieczeństwo psychologiczne jest kluczowe w IT?

Bezpieczeństwo psychologiczne przekłada się bezpośrednio na:

• wcześniejsze wykrywanie błędów i ryzyk,
• lepsze decyzje architektoniczne i projektowe,
• większą innowacyjność,
• mniejszą liczbę eskalacji kryzysowych,
• wyższe zaangażowanie i odpowiedzialność zespołów.

Nie eliminuje błędów, ale sprawia, że są one szybciej widoczne, łatwiejsze do naprawy i mniej kosztowne.

Cisza jako realny koszt organizacyjny

Milczenie w organizacji ma swoją cenę:

• koszt poprawy błędów wykrytych późno,
• koszt utraconych szans na usprawnienia,
• koszt rotacji pracowników, którzy odchodzą, bo nie czują się wysłuchani,
• koszt reputacyjny, gdy problemy wychodzą na zewnątrz.

W IT cisza bywa maskowana jako „profesjonalizm” lub „samodzielność”. Tymczasem prawdziwy profesjonalizm polega na odpowiedzialnym zgłaszaniu ryzyk, a nie na ich przemilczaniu.

Podsumowanie

Cisza w IT nie jest neutralna. Jest aktywnym czynnikiem ryzyka.

W środowiskach takich jak Currenda, gdzie stawka jest wysoka, milczenie może kosztować więcej niż pojedynczy błąd techniczny. Badania Google (Projekt Arystoteles) oraz praktyki firm takich jak Spotify, Microsoft czy Pixar pokazują jednoznacznie: bezpieczeństwo psychologiczne działa i jest mierzalnym źródłem przewagi technologicznej.

Nie chodzi o „bycie miłym”. Chodzi o tworzenie warunków, w których ludzie mogą mówić prawdę, nawet wtedy, gdy jest ona trudna, niewygodna lub niepopularna.

Bo to właśnie mówienie prawdy na czas chroni zespoły IT przed błędami, kryzysami i utratą zaufania.

Warto więc zadać sobie jedno pytanie:
kiedy ostatnio ktoś w Twoim zespole powiedział otwarcie „nie wiem”, „to może być ryzykowne” albo „tu popełniliśmy błąd”?

Jeśli takie zdania pojawiają się rzadko- być może największym ryzykiem w projekcie nie jest technologia, lecz cisza.