Umiejętności których nie uczy dyplom

Fundamenty, których nie znajdziesz w sylabusie

Moja babcia nigdy nie skończyła studiów technicznych. Nie pisała kodu, nie prowadziła retrospektyw, nie czytała książek o przywództwie. A jednak to od niej nauczyłem się więcej o byciu liderem niż z jakiegokolwiek kursu na Courserze. Mówiła prosto: jeśli coś robisz, rób to tak, żebyś nie musiał się wstydzić, kiedy ktoś zapyta, kto to zrobił.

Moja mama z kolei nauczyła mnie czegoś, co w inżynierii nazywamy bias for action — choć ona nigdy nie użyłaby tego terminu. Kiedy był problem, nie czekała na idealny moment. Działała, korygowała, szła dalej. Obserwowałem to przez lata i myślałem, że to oczywiste. Okazało się, że nie jest — szczególnie gdy zostałem tech leadem i zobaczyłem, ilu inteligentnych inżynierów paraliżuje się w obliczu niepewności.

Dyplom inżynierski dał mi narzędzia do rozwiązywania problemów technicznych. Ale to, co wyniosłem z domu — poczucie odpowiedzialności za jakość własnej pracy i gotowość do działania mimo braku pełnej informacji — okazało się fundamentem, na którym zbudowałem wszystko inne. Nie mówię tego nostalgicznie. Mówię to jako diagnozę: branża technologiczna ma problem z uznawaniem tych kompetencji za strukturalne, a nie dekoracyjne.

Zrobione dobrze — rzemiosło jako postawa, nie technika

W inżynierii oprogramowania bardzo szybko uczymy się rozróżniać między kodem, który działa, a kodem, który jest dobry. Ale jest trzecia kategoria, o której rzadko się mówi wprost: kod, za który autor bierze odpowiedzialność. To nie jest kwestia styleguide'ów ani code review. To postawa — decyzja, że twoje imię jest przy tym commicie i że to coś znaczy.

Pracowałem z inżynierami, którzy technicznie byli wybitni, ale ich pull requesty wyglądały jak prace zaliczeniowe — zrobione na tyle, żeby przeszły. I pracowałem z inżynierami o przeciętnych umiejętnościach, którzy zostawiali kod lepszym, niż go zastali, za każdym razem. Ci drudzy zostawali seniorami i techleadami. Nie dlatego, że ktoś ich nagradzał za postawę — ale dlatego, że ta postawa generowała zaufanie, a zaufanie generuje wpływ.

Jako lider widzę to wzorzec regularnie: inżynierowie, którzy mają standard 'zrobione dobrze' wbudowany w swój system wartości, potrzebują znacznie mniej zarządzania. Nie dlatego, że są idealni — ale dlatego, że sami sobie stawiają poprzeczkę i sami ją egzekwują. To redukuje overhead zarządczy bardziej niż jakikolwiek proces.

Najtrudniejsza rozmowa, jaką miałem jako VP of Engineering, była z bardzo utalentowanym inżynierem, który konsekwentnie dostarczał pracę na poziomie 'wystarczająco dobrym'. Technicznie nie było się do czego przyczepić. Ale każdy, kto przejmował jego kod, tracił czas na rozumienie decyzji, które nigdy nie zostały wyjaśnione, na edge case'y, które były widoczne, ale zignorowane. Koszt był rozproszony, więc trudny do zmierzenia — ale realny. Ta rozmowa trwała godzinę. Powinna była odbyć się na etapie rekrutacji.

Standard 'zrobione dobrze' to nie perfekcjonizm — to coś innego. Perfekcjonizm blokuje dostarczanie. Standard jakości przyspiesza, bo redukuje dług techniczny, redukuje pytania, redukuje naprawianie w produkcji. To ekonomia, nie estetyka. I jest to kompetencja, której nie nauczy żaden bootcamp, bo nie ma jej w programie — jest w charakterze.

Odwaga — działanie jako pierwsza odpowiedź, nie ostatnia

Większość organizacji technologicznych ma problem z decyzyjnością, który maskuje jako problem z procesem. Dodają kolejne spotkania, kolejne dokumenty RFC, kolejne rundy feedbacku — i myślą, że to dojrzałość. Często to tylko strach przed byciem tym, który podjął złą decyzję. Odwaga w przywództwie technicznym to nie brawura. To gotowość do powiedzenia: mam wystarczająco dużo informacji, żeby działać teraz, i wezmę odpowiedzialność za wynik.

Moja mama nie mówiła 'poczekajmy, aż będziemy mieć więcej danych'. Mówiła: 'robimy to, a jak wyjdzie źle — naprawimy'. To nie jest naiwność. To jest rozumienie, że koszt bezczynności jest równie realny jak koszt błędnej decyzji — tylko trudniejszy do zobaczenia, bo nie pojawia się w żadnym raporcie.

W praktyce inżynierskiej odwaga wygląda tak: incident na produkcji, trzy osoby na kanale, każda czeka, aż ktoś inny weźmie ownership. Albo: nowy feature, który wszyscy widzą, że jest źle zaprojektowany, ale nikt nie chce powiedzieć tego PM-owi. Albo: tech debt, który narasta od kwartałów, bo żaden lider nie chce zabrać czasu z roadmapy, żeby go adresować. We wszystkich tych przypadkach brakuje jednej rzeczy — kogoś, kto zrobi pierwszy krok.

Kiedy buduję zespoły, szukam ludzi, którzy mają ten odruch. Nie tych, którzy nigdy się nie mylą — tych, którzy działają, uczą się i korygują szybciej niż inni. To jest przewaga kompetencyjna, której nie widać w CV i której nie mierzy żaden test algorytmiczny na rozmowie kwalifikacyjnej. A jest ona często ważniejsza niż znajomość konkretnego frameworka.

Dlaczego branża tech systematycznie ignoruje te kompetencje

Proces rekrutacyjny w większości firm technologicznych jest zoptymalizowany pod kątem tego, co łatwo zmierzyć: rozwiązywanie problemów algorytmicznych, znajomość systemów rozproszonych, doświadczenie z konkretnymi technologiami. To sensowne — te rzeczy są ważne i da się je ocenić w ciągu kilku godzin. Problem w tym, że to, co łatwo zmierzyć, zaczyna być traktowane jako to, co ważne. A reszta spada do kategorii 'miękkie umiejętności' — czyli czegoś, co jest miłe, ale opcjonalne.

Efekt jest przewidywalny: zatrudniamy ludzi, którzy są technicznie silni, ale nie mają standardu jakości wbudowanego w system wartości. Albo którzy czekają na konsensus zamiast działać. Albo którzy nie powiedzą trudnej prawdy, bo nie mają odwagi do konfrontacji. A potem jesteśmy zdziwieni, że zespół nie działa tak, jak powinien, i szukamy rozwiązania w nowym procesie zamiast w diagnozie ludzi.

To nie jest problem indywidualnych firm — to jest strukturalny błąd w tym, jak branża myśli o kompetencjach. Traktujemy charakter jako coś, co albo jest, albo go nie ma, i nie warto go mierzyć. Tymczasem dekady badań psychologicznych pokazują, że cechy charakteru są stabilne, przewidywalne i mierzalne. My po prostu zdecydowaliśmy, że nie będziemy ich mierzyć, bo to trudniejsze niż sprawdzenie, czy ktoś potrafi odwrócić drzewo binarne.

Miękkie umiejętności są strukturalne — i można je przewidzieć

Kiedy mówię, że miękkie umiejętności są strukturalne, mam na myśli konkretną tezę: to, jak ktoś zachowuje się pod presją, jak reaguje na krytykę, jak traktuje jakość swojej pracy i jak podejmuje decyzje w warunkach niepewności — to nie są przypadkowe zachowania. To są wzorce wynikające z głęboko zakorzenionych cech osobowości. I te cechy można zmierzyć z dużą dokładnością.

Model HEXACO — sześciowymiarowy model osobowości oparty na wieloletnich badaniach cross-kulturowych — daje nam narzędzie do opisania właśnie tych wzorców. Wymiar Honesty-Humility mówi nam o tym, czy ktoś będzie grał fair z zespołem czy będzie optymalizował pod kątem własnego wizerunku. Conscientiousness mówi o standardzie jakości — czy ktoś ma wewnętrzny drive do robienia rzeczy dobrze, czy potrzebuje zewnętrznej kontroli. Emotionality i Extraversion mówią o tym, jak ktoś zarządza stresem i jak buduje relacje pod presją.

LU Teams zostało zbudowane dokładnie wokół tej idei: że tarcia w zespołach inżynierskich nie są losowe. Są przewidywalne, jeśli wiesz, gdzie patrzeć. Dwie osoby z wysokim Conscientiousness i niskim Agreeableness będą walczyć o standard jakości w sposób, który może być produktywny albo destrukcyjny — zależy od kontekstu i od tego, czy lider to widzi. Bez narzędzi do pomiaru tych cech, lider działa po omacku i reaguje na konflikty zamiast im zapobiegać.

To, czego nauczyła mnie babcia i mama, można opisać w terminach HEXACO: wysoka Conscientiousness, wysoka Honesty-Humility i wysoki poziom tego, co badacze nazywają Openness to Experience w połączeniu z bias for action. Nie wiedziałam wtedy, że to są mierzalne konstrukty. Ale efekty były jak najbardziej realne. Dziś, budując narzędzia dla CTOs i VP of Engineering, wiem, że pierwszym krokiem do lepszego zespołu nie jest lepszy proces — jest lepsze rozumienie ludzi, którzy ten proces tworzą.