Feedback którego nikt nie usłyszał

Kiedy pętla feedbacku się urywa

Wyobraź sobie senior engineera, który po tygodniu pracy pokazuje PR gotowy do merge'a. Wszystko wygląda schludnie, dobrze opisane, bez WIP. Jego tech lead przegląda kod i myśli: 'Czemu nikt nie powiedział mi wcześniej, że idziemy w tym kierunku?' Obaj są sfrustrowani. Obaj mają rację.

To nie jest problem komunikacji w klasycznym sensie. To problem niedopasowania — dwóch ludzi, którzy mają zupełnie inne modele tego, kiedy i jak powinna wyglądać wymiana informacji. Jeden zakłada, że feedback pojawia się na końcu, gdy praca jest 'gotowa'. Drugi zakłada, że feedback to ciągły dialog, który zaczyna się od pierwszego commita.

Niedopasowanie tego rodzaju nie generuje konfliktu — generuje ciszę. A cisza w inżynierii jest dużo bardziej kosztowna niż kłótnia. Kłótnia przynajmniej ujawnia, że coś jest nie tak. Cisza pozwala tygodniom mijać, zanim ktokolwiek zauważy, że pętla feedbacku jest zerwana.

Ukrywanie: chowanie wczesnej pracy jako strategia przetrwania

Są inżynierowie, którzy nigdy nie otworzą draft PR. Nie dlatego, że są leniwi albo nie rozumieją wartości wczesnego feedbacku — wręcz przeciwnie. Chowają wczesną pracę, bo dla nich niedokończona praca to praca, za którą mogą zostać ocenieni. To nie jest irracjonalne. To jest wyuczone zachowanie, często z poprzednich środowisk.

W praktyce wygląda to tak: engineer pracuje dwa tygodnie nad modułem, który mógłby być zrewidowany po trzech dniach. Kiedy w końcu pokazuje pracę, okazuje się, że architektura poszła w złym kierunku. Nie dlatego, że engineer był niekompetentny — dlatego, że nikt nie wiedział, co się dzieje. Tech lead jest sfrustrowany. Engineer jest sfrustrowany. Oboje tracą czas na refactor, który mógł nie istnieć.

W badaniach osobowości ten wzorzec koreluje z wysokim poziomem Lęku (Anxiety) w modelu HEXACO — skłonnością do zamartwiania się oceną, unikania ekspozycji na krytykę w stanie niepewności. Nie jest to wada charakteru. Jest to cecha, która w jednym środowisku może być niewidoczna, a w innym — destrukcyjna dla całego procesu review.

Problem pogłębia się, gdy tech lead ma niski poziom tej samej cechy. Dla niego draft PR z błędami to naturalna część pracy. Nie rozumie, dlaczego ktoś miałby czekać z pokazaniem kodu. Jego domyślny model: 'Jeśli nie pytasz, to znaczy, że wszystko gra.' Engineer tymczasem myśli: 'Jeśli pytam za wcześnie, będę wyglądał na nieprzygotowanego.' Żadne z nich nie mówi tego głośno.

Niedopasowanie stylu: różne filtry, ta sama wiadomość

Bezpośredni nie zawsze znaczy jasny. To zdanie brzmi jak paradoks, ale każdy, kto pracował w zróżnicowanym zespole, wie, że jest prawdziwe. Możesz powiedzieć 'ten kod jest nieczytelny' i mieć na myśli techniczną obserwację. Odbiorca może usłyszeć ocenę swojej kompetencji. Obaj macie rację — ale żyjecie w różnych modelach tego, co komunikacja powinna robić.

W inżynierii ten problem jest szczególnie ostry, bo kultura techniczna gloryfikuje bezpośredniość. 'Mów wprost, bez owijania w bawełnę' — to mantra wielu engineering teams. Ale bezpośredniość to nie jest neutralna właściwość. To preferencja stylistyczna, która faworyzuje ludzi z wysoką Śmiałością Społeczną (Social Boldness) i niską wrażliwością na sygnały hierarchiczne. Dla reszty bezpośredni feedback nie brzmi jak efektywna komunikacja — brzmi jak atak.

Klasyczny przykład: tech lead na code review pisze 'to nie ma sensu, przepisz'. Dla niego to skrót myślowy, który oszczędza czas. Dla engineera z wysokim poziomem Emocjonalności (Emotionality) w HEXACO to zdanie uruchamia reakcję obronną, która blokuje zdolność do spokojnego przetworzenia feedbacku. Engineer nie pyta o szczegóły. Robi poprawki na ślepo. Albo unika następnych review.

Co gorsza, tech lead interpretuje brak pytań jako zrozumienie. 'Powiedziałem wprost, więc na pewno wie, o co chodzi.' Tymczasem engineer wyszedł z rozmowy z mglistym poczuciem, że zrobił coś fundamentalnie złego, ale nie wie co. Pętla feedbacku nie działa — nie dlatego, że ktoś nie chciał, żeby działała, ale dlatego, że obaj używają różnych protokołów komunikacyjnych i żaden z nich nie zdaje sobie z tego sprawy.

Niedopasowanie stylu jest szczególnie podstępne, bo jest niewidoczne dla obu stron. Tech lead myśli, że komunikuje się efektywnie. Engineer myśli, że problem leży w nim. Żadne z nich nie zadaje pytania: 'Czy możliwe, że my po prostu mówimy różnymi językami?'

Kiedy feedback dociera, ale nie zmienia niczego

Jest jeszcze trzecia kategoria problemu, rzadziej omawiana: feedback, który technicznie dotarł, ale nie został przetworzony w żaden użyteczny sposób. Engineer słyszy 'musisz lepiej komunikować postęp prac'. Kiwa głową. Tydzień później nic się nie zmienia. Tech lead zakłada złą wolę albo brak kompetencji. Tymczasem engineer naprawdę nie wie, co konkretnie ma robić inaczej.

To jest problem precyzji, nie intencji. 'Lepiej komunikuj' to nie jest instrukcja — to jest ocena. Żeby feedback mógł zmienić zachowanie, musi być zakorzeniony w konkretnym działaniu, które odbiorca jest w stanie powtórzyć albo zmodyfikować. 'Otwórz draft PR po pierwszym dniu pracy nad nową funkcją i opisz, co próbujesz osiągnąć' — to jest instrukcja. Różnica jest fundamentalna.

Ale żeby dawać tak precyzyjny feedback, musisz rozumieć, dlaczego dane zachowanie w ogóle się pojawia. Jeśli nie wiesz, że engineer chowa wczesną pracę z powodu lęku przed oceną, a nie z powodu lenistwa, twój feedback będzie skierowany w złe miejsce. Będziesz naprawiać symptom, nie przyczynę. I będziesz się dziwić, czemu nic się nie zmienia.

Nazwij niedopasowanie zanim ono nazwie ciebie

Większość problemów z feedbackiem w zespołach inżynierskich nie jest problemem złej woli ani braku kompetencji. Jest problemem niewidocznych założeń — o tym, kiedy feedback powinien się pojawić, jak powinien brzmieć, co znaczy 'gotowość' do pokazania pracy, i co znaczy 'zrozumienie' po rozmowie. Te założenia są tak głęboko zakorzenione, że nikt ich nie artykułuje. Nikt nie pyta. Nikt nie sprawdza.

Pierwszym krokiem jest nazwanie niedopasowania wprost — nie jako czyjegoś błędu, ale jako strukturalnego problemu, który wymaga strukturalnego rozwiązania. 'Zauważam, że mamy różne modele tego, kiedy warto pokazywać pracę. Chcę to zrozumieć, zanim założę, że coś jest nie tak.' To zdanie zmienia dynamikę z oceny na diagnozę. I to jest jedyna rozmowa, która może cokolwiek zmienić.

W praktyce oznacza to też, że jako tech lead musisz być gotowy zakwestionować własne domyślne ustawienia. Twój model bezpośredniości, twój model 'gotowości', twój model tego, co znaczy dobry feedback — to są preferencje, nie standardy. Inne osoby mają inne preferencje, które są równie legitymizowane i równie zakorzenione w ich osobowości i historii.

HEXACO jako mapa, nie wyrok

LU Teams zostało zbudowane na fundamencie modelu HEXACO właśnie dlatego, że jest on jednym z najlepiej zwalidowanych narzędzi do przewidywania zachowań w kontekście pracy zespołowej. Nie po to, żeby etykietować ludzi — po to, żeby dawać zespołom wspólny język do rozmowy o tym, co w innym przypadku pozostaje niewidoczne. Różnica w poziomie Lęku, Śmiałości Społecznej czy Emocjonalności między dwoma osobami nie jest problemem — jest informacją.

Kiedy tech lead widzi, że jego engineer ma wysoki poziom Emocjonalności i niską Śmiałość Społeczną, przestaje interpretować chowanie wczesnej pracy jako brak zaangażowania. Zaczyna projektować środowisko, w którym pokazywanie niedokończonej pracy jest bezpieczne — przez explicit invitation, przez modelowanie własnego zachowania, przez zmianę tonu code review. To nie jest miękkie zarządzanie. To jest precyzja.

Podobnie, gdy engineer rozumie, że bezpośredniość tech leada nie jest krytyką jego osoby, ale stylem komunikacji zakorzenionym w konkretnym profilu osobowości, zmienia się jego zdolność do przetwarzania feedbacku. Nie dlatego, że nagle staje się inną osobą — dlatego, że ma kontekst, który pozwala mu oddzielić sygnał od szumu. To jest właśnie to, co robi dobra mapa: nie zmienia terenu, ale sprawia, że możesz po nim nawigować.

Pętla feedbacku nie zrywa się dlatego, że ludzie są trudni. Zrywa się dlatego, że pracujemy z niewidocznymi założeniami o tym, jak komunikacja powinna działać — i nigdy ich nie sprawdzamy. HEXACO daje narzędzie do tego sprawdzenia. LU Teams daje kontekst, w którym to sprawdzenie może się wydarzyć zanim problem stanie się kosztem.