Oni po prostu nie potrafią współpracować

Dwaj świetni inżynierowie, jeden martwy projekt

Marek i Tomek byli najlepszymi inżynierami w firmie. Marek projektował systemy z chirurgiczną precyzją — każda decyzja architektoniczna była poprzedzona tygodniem analizy, dokumentacją i listą ryzyk. Tomek działał inaczej: prototypował w piątek, wdrażał w poniedziałek, a retrospektywę traktował jako okazję do świętowania, nie do rozliczania. Obaj byli skuteczni. Razem — paraliżowali cały zespół.

CTO obserwował tę sytuację przez trzy kwartały. Próbował mediacji, wspólnych sesji planowania, nawet zmiany struktury sprintów. Nic nie działało. W końcu uznał, że problem leży w ludziach — że Marek jest zbyt sztywny, a Tomek zbyt chaotyczny. To był błąd diagnozy, który kosztował firmę seniora i sześć miesięcy opóźnienia w roadmapie.

Problem nie leżał w charakterach. Leżał w tym, że system organizacyjny wymagał od nich identycznego sposobu pracy, podczas gdy ich naturalne tryby były strukturalnie różne. To nie była niezgodność osobowości. To była niezgodność między ludźmi a środowiskiem, które dla nich zaprojektowano — albo raczej: którego nikt świadomie nie zaprojektował.

Słuszne preferencje — różne tryby

Kiedy mówimy, że ktoś 'nie potrafi współpracować', zwykle mamy na myśli, że nie współpracuje tak jak my. To fundamentalne zniekształcenie poznawcze w ocenie zespołów. Marek nie był trudny — był wysoko sumienny, z silną preferencją do porządku i przewidywalności. Tomek nie był nieodpowiedzialny — był otwarty na doświadczenia, z naturalnym napędem do eksploracji i szybkiego feedbacku. Oba tryby są ewolucyjnie uzasadnione. Oba są wartościowe.

HEXACO — model osobowości oparty na sześciu wymiarach, wywodzący się z dekad badań psychometrycznych — pozwala zobaczyć te różnice bez wartościowania. Wymiar Sumienności (Conscientiousness) opisuje, jak bardzo ktoś potrzebuje struktury, planu i kontroli przed działaniem. Wymiar Otwartości (Openness to Experience) opisuje apetyt na nowość i tolerancję na niejednoznaczność. Marek i Tomek siedzieli na przeciwnych końcach obu tych osi — i żaden z nich nie był w błędzie.

Problem pojawia się, gdy system zakłada, że wszyscy działają w tym samym trybie. Scrum napisany przez kogoś z wysoką Sumiennością będzie pełen ceremonii, dokumentacji i checkpointów. Kultura inżynierska zbudowana przez kogoś z wysoką Otwartością będzie pełna eksperymentów, pivotów i 'zobaczmy co wyjdzie'. Gdy te dwa podejścia zderzają się bez żadnego frameworku do zarządzania różnicą — wybucha konflikt, który wygląda jak problem personalny, a jest problemem projektowym.

Inżynierowie z wysokim wynikiem na wymiarze Ugodowości (Agreeableness-Altruism) będą unikać konfrontacji nawet wtedy, gdy mają rację — co w środowisku technicznym prowadzi do cichego gromadzenia długu decyzyjnego. Ci z niskim wynikiem będą wchodzić w bezpośrednie starcia, które reszta zespołu odczyta jako toksyczność, choć dla nich to po prostu efektywna komunikacja. Bez mapy tych różnic lider zarządza ciemnością.

Dlaczego liderzy błędnie diagnozują

Większość CTOs i VPs of Engineering, z którymi rozmawiałem, ma ten sam odruch: gdy w zespole pojawia się tarcie, szukają winnego. To ludzka heurystyka — szybsza niż analiza systemowa, dająca złudzenie kontroli. 'Marek jest zbyt defensywny' jest prostszą diagnozą niż 'nasz proces code review nie ma jasno zdefiniowanych kryteriów akceptacji, co powoduje, że każdy broni własnej interpretacji'.

Ta błędna diagnoza ma swoją nazwę w psychologii społecznej: fundamentalny błąd atrybucji. Przypisujemy zachowania ludziom, zamiast sytuacjom. W inżynierii wiemy, że gdy system produkuje błędy, nie przeklinamy kompilatora — szukamy przyczyny w kodzie. W zarządzaniu ludźmi ta logika nagle znika i zaczynamy 'przeklinać kompilator'.

Konsekwencje są poważne. Gdy diagnoza jest błędna, interwencja jest błędna. Wysyłasz Marka na coaching z komunikacji, zamiast przeprojektować proces review. Rozdzielasz Tomka i Marka do różnych projektów, zamiast zdefiniować, który z nich odpowiada za eksplorację, a który za konsolidację. Leczysz objaw, a choroba zostaje — i przenosi się na kolejny zespół, z kolejnymi ludźmi.

Naprawa systemu — jasne granice

Pierwszym krokiem nie jest rozmowa z ludźmi. Pierwszym krokiem jest audyt systemu. Gdzie w waszym procesie decyzyjnym nie ma jasno zdefiniowanego właściciela? Gdzie 'konsensus' jest wymagany, ale nikt nie zdefiniował, co konsensus oznacza? Gdzie dwie osoby mają nakładające się zakresy odpowiedzialności bez jasnego protokołu rozwiązywania konfliktów? To są miejsca, w których tarcie jest nieuniknione — niezależnie od tego, kogo tam posadzisz.

Jasne granice nie oznaczają silosów. Oznaczają zdefiniowane punkty styku. Marek i Tomek mogą świetnie współpracować, jeśli system mówi: Tomek ma pełną autonomię w fazie eksploracji przez pierwsze dwa tygodnie sprintu, Marek wchodzi na etapie design review z listą kryteriów, które zostały uzgodnione z góry. Nie ma wtedy starcia stylów — jest podział pracy zgodny z naturalnymi preferencjami obu.

To nie jest zarządzanie przez unikanie konfliktu. To jest projektowanie środowiska, w którym różne tryby pracy mają swoje miejsce i czas. Najlepsze zespoły inżynierskie, jakie widziałem, nie składają się z ludzi o identycznych preferencjach — składają się z ludzi, którzy wiedzą, kiedy i jak przekazują pałeczkę. Ta wiedza nie bierze się z dobrej woli. Bierze się z jasno zaprojektowanego systemu.

Warto też rozróżnić konflikty strukturalne od interpersonalnych. Konflikt strukturalny pojawia się, gdy dwoje ludzi ma sprzeczne mandaty — i żadna ilość empatii tego nie naprawi, dopóki mandaty nie zostaną przeprojektowane. Konflikt interpersonalny pojawia się, gdy różnice w wartościach lub komunikacji są tak duże, że wymagają mediacji. Większość konfliktów, które liderzy traktują jako interpersonalne, jest w rzeczywistości strukturalna. Zmień strukturę, a ludzie często zaczynają ze sobą rozmawiać.

Co mówi nauka o tym, czego nie widać

HEXACO to nie kolejny korporacyjny test osobowości. To jeden z najlepiej zwalidowanych modeli psychometrycznych dostępnych w nauce — oparty na analizie leksykalnej języków na całym świecie i replikowany w dziesiątkach niezależnych badań. Sześć wymiarów — Uczciwość-Pokora, Emocjonalność, Ekstrawersja, Ugodowość, Sumienność i Otwartość — wyjaśnia znaczącą część wariancji w zachowaniach zawodowych, w tym w sposobie podejmowania decyzji, reagowania na stres i budowania relacji w zespole.

Wymiar, który jest najczęściej pomijany w kontekście inżynierskim, to Uczciwość-Pokora (Honesty-Humility). Osoby z niskim wynikiem na tej skali mają naturalną tendencję do rywalizacji, dominacji i postrzegania relacji zawodowych jako gry o sumie zerowej. Gdy taka osoba trafia do środowiska, które nagradza 'ownership' bez jasnych granic, zaczyna poszerzać swoje terytorium kosztem innych — nie z powodu złej woli, ale z powodu naturalnego napędu. System bez granic wzmacnia te tendencje.

LU Teams używa HEXACO właśnie dlatego, że daje precyzję, której nie dają intuicja ani rozmowy 1:1. Zanim dojdzie do konfliktu, możesz zobaczyć, gdzie w zespole istnieje strukturalne napięcie między profilami — gdzie wysoka Sumienność zderzy się z wysoką Otwartością, gdzie niski wynik Ugodowości u dwóch osób w tym samym obszarze decyzyjnym stworzy tarcie. To nie jest wróżenie z fusów. To inżynieria systemów ludzkich oparta na danych.

Predykcja nie eliminuje konfliktu. Ale daje liderowi coś, czego bez niej nie ma: czas. Czas na przeprojektowanie procesu zanim ludzie zaczną się okopywać. Czas na rozmowę o preferencjach zanim staną się zarzutami. Czas na zbudowanie systemu, który działa z naturą ludzi, a nie przeciwko niej.

Projektowanie przed terapią

Najdroższy moment w zarządzaniu zespołem to ten, w którym dobry inżynier składa wypowiedzenie z powodu konfliktu, który można było przewidzieć. Nie dlatego, że był niekompatybilny z firmą — ale dlatego, że nikt nie zaprojektował środowiska, które by go utrzymało. Rekrutacja seniora kosztuje średnio sześć do dwunastu miesięcy wynagrodzenia, gdy wliczyć czas rekrutacji, onboarding i utracony kontekst. Projektowanie systemu jest tańsze.

Liderzy, którzy budują najtrwalsze zespoły, mają jeden wspólny nawyk: projektują przed terapią. Zanim pojawi się problem, definiują granice odpowiedzialności, protokoły eskalacji i — co najważniejsze — mają model tego, jak różne osoby w ich zespole naturalnie przetwarzają informacje, podejmują decyzje i reagują na presję. Nie dlatego, że są idealistami. Dlatego, że policzyli koszty.

Marek i Tomek mogli tworzyć razem coś wyjątkowego. Marek jako strażnik jakości i architekt długoterminowy, Tomek jako silnik eksploracji i szybkiego uczenia się. To nie jest utopia — to jest podział pracy zgodny z tym, kim oboje są. Ale żeby do tego dojść, ktoś musiał najpierw zobaczyć ich jako profile, a nie jako problem. LU Teams istnieje dokładnie po to, żeby liderzy mieli tę perspektywę — zanim koszt braku jej stanie się oczywisty.