TL;DR: Inżynierowie utykają między mid a senior nie z braku wiedzy, tylko dlatego, że nikt nie mentoruje ich osądu — zdolności ramowania niepewności, ważenia kompromisów i obrony ograniczeń pod presją. Osąd da się mentorować, ale wyłącznie na żywych decyzjach: realnych designach, realnych pull requestach, realnych incydentach. Abstrakcyjne rady kariery go nie ruszają.
Senior to nie checklista
Najczęstsza frustracja, jaką słyszę na sesjach mentoringowych, pochodzi od mocnych midów: „Znam technologie z ogłoszenia na seniora. Czemu tam nie jestem?". Uczciwa odpowiedź: checklista nigdy nie była tą luką. Senior engineer to nie po prostu ktoś, kto zna więcej API, wzorców i chmur.
Seniority widać gdzie indziej: w tym, jak ktoś ramuje niepewność zamiast ją ukrywać, jak broni ograniczeń, gdy napiera na nie deadline, i jak pomaga ludziom wokół podejmować decyzje lepsze, niż podjęliby sami. Te zdolności mają wspólny korzeń — osąd — a osąd to dokładnie ta rzecz, której większość mentoringu nie dotyka, bo łatwiej polecić kurs, niż rozebrać decyzję.
Wiedza odpowiada na pytanie „jak to zrobić?". Osąd odpowiada na „czy powinniśmy, ile to będzie kosztować i kto musi o tym wiedzieć?".
Czym naprawdę jest osąd
Osąd brzmi mistycznie, dopóki się go nie rozłoży. W praktyce mentoruję cztery konkretne zdolności — każdą obserwowalną w codziennej pracy:
- Ramowanie. Zamiana mglistej sytuacji w rozstrzygalne pytanie. „Czy powinniśmy użyć Kafki?" jest niezramowane; „potrzebujemy uporządkowanych, odtwarzalnych zdarzeń między dwiema usługami o niezależnych cyklach wdrożeń — jakie mamy opcje i ich koszty?" to decyzja, którą ktoś może realnie podjąć.
- Czytanie kompromisów. Świadomość, że każdy wybór kupuje coś za coś, i umiejętność powiedzenia ceny na głos. Inżynier, który nie umie nazwać kosztu swojego ulubionego designu, ma preferencje, nie stanowisko.
- Wyczucie odwracalności. Odróżnianie decyzji tanich w cofnięciu od tych, które tanie nie są — i proporcjonalne wydawanie czasu na analizę. Rozdrabnianie się nad odwracalnym i pośpiech przy nieodwracalnym to klasyczna inwersja poziomu mid.
- Obrona ograniczeń. Utrzymanie granicy — wymogu bezpieczeństwa, niezmiennika danych, budżetu wydajności — gdy presja na jej naginanie jest społeczna, nie techniczna. Najtrudniejsza z czterech, bo ćwiczy się ją pod stresem albo wcale.
Mentoruj na realnych decyzjach
Typowe podejście do mentoringu to rozmowa o karierze co dwa tygodnie: cele, odczucia, polecona książka. Miłe, czasem użyteczne i niemal całkiem oderwane od miejsca, w którym formuje się osąd. Najmocniejszy mentoring, jaki prowadziłem — i jaki dostałem — działa się na żywej pracy: jak podzielić usługę, kiedy odmówić zależności, jak zakomunikować ryzyko interesariuszowi, który nie chce go słyszeć, jak dowozić bez chowania słabych założeń.
Żywe decyzje niosą trzy rzeczy, których hipotetyczne nie mają nigdy: realne ograniczenia, realną stawkę i realny wynik, do którego można wrócić. Kiedy podopieczny przechodzi przez swoje rozumowanie na prawdziwym designie, a ja pytam „co się zepsuje, jeśli mylisz się co do wzorca obciążenia?", odpowiedź ma znaczenie — a za miesiąc porównamy przewidywanie z produkcją.
Słaby feedback
„Zrób to czyściej." „Pomyśl o przypadkach brzegowych." „To mogłoby lepiej się skalować."
Użyteczny feedback
„Ta granica uzależnia rollback od dwóch zespołów. Nazwij ten kompromis w notatce designu i napisz, kto go akceptuje."
Różnica między kolumnami to nie ton — to fakt, że użyteczny feedback wskazuje konkretną decyzję, nazywa jej konsekwencję i przypisuje następny ruch. Feedback, na którym nie da się działać, jest komentarzem.
Użyteczne pętle feedbacku
Wzrost przyspiesza, gdy feedback jest konkretny i rytmiczny. Pętla, którą prowadzę z podopiecznymi na ścieżce senior, używa trzech artefaktów na cykl — celowo małych:
- Jedna notatka designu. Napisana przez podopiecznego przed rozmową. Samo pisanie to połowa mentoringu — mgliste myślenie nie przeżywa pisemnej sekcji kompromisów.
- Jeden pull request. Nie pod kątem stylu — pod kątem decyzji. Czemu ta granica, czemu taka obsługa błędów, czego reviewer musiałby się dowiedzieć, a czego diff nie mówi.
- Jeden incydent albo zaskoczenie. Cokolwiek, co produkcja zrobiła wbrew oczekiwaniom podopiecznego. Rekonstruujemy, które założenie padło i czy dało się to wiedzieć wcześniej.
Po każdym artefakcie najważniejszy jest ruch zamykający: nazwij wzorzec stojący za pracą. „Znowu domyślnie sięgasz po synchroniczne sprzężenie, bo łatwiej je testować lokalnie" jest przenośne; naprawiony PR nie jest. Nazwane wzorce podopieczny zaczyna łapać sam, zanim praca wyjedzie — i o to właśnie chodzi.
Odpowiedzialność i komunikacja
Dwa kolejne przesunięcia oddzielają mocnych implementatorów od seniorów — i oba dobrze reagują na celowy mentoring.
Odpowiedzialność dotyczy wyniku, nie zadania. Mid domyka ticket; senior zauważa, że ticket nie osiągnie tego, czego chciał jego autor — i mówi to, zanim zacznie budować. Mentoruję to, zmieniając pytanie o pracę z „czy skończone?" na „czy zadziałało?" — i każąc podopiecznemu prezentować wynik, także ten rozczarowujący, ludziom, których dotyczy.
Komunikacja na poziomie senior to głównie tłumaczenie ryzyka: mówienie rzeczy technicznie prawdziwych w formie, na której product manager albo founder może oprzeć działanie. Ćwiczenie, którego używam, jest brutalne i skuteczne — weź swoją ostatnią zignorowaną techniczną obawę i przepisz ją w trzech zdaniach: co może się stać, jak prawdopodobne, ile by kosztowało. Jeśli znów ją zignorowano, problemem rzadko była publiczność.
Formaty, które działają
Kilka formatów konsekwentnie wygrywa z resztą w mojej praktyce mentoringowej:
- Cień decyzji — podopieczny siedzi na prawdziwej dyskusji architektonicznej, spisuje decyzję tak, jak ją zrozumiał, a potem porównujemy jego wersję z tym, co faktycznie postanowiono i dlaczego.
- Pre-mortem własnych designów — „jest pół roku później i to padło; opowiedz najbardziej prawdopodobną historię". Tanie, szybkie i buduje dokładnie ten mięsień, który testują incydenty.
- Odwrócone review — podopieczny recenzuje mój design albo PR i ma obowiązek znaleźć najsłabsze założenie. Konieczność bezpiecznego postawienia się komuś starszemu trenuje obronę ograniczeń lepiej niż każda rozmowa o asertywności.
- Pisemne notatki kompromisów — pół strony na istotny wybór, trzymane w repo. Po pół roku podopieczny ma widoczny zapis własnego, poprawiającego się osądu — a to robi dla pewności siebie więcej niż jakakolwiek pochwała.
Gdzie mentoring zawodzi
- Teatr rad. Sesje pełne zasad i tytułów książek, puste od faktycznej pracy podopiecznego. Wygodne dla obu stron, bezużyteczne dla osądu.
- Klonowanie. Mentoring optymalizujący pod „czy ja bym to tak zrobił?" produkuje naśladowców, nie seniorów. Celem jest zdrowe rozumowanie podopiecznego, nie zgodność jego wniosku z moim — mówię to wprost i tak myślę.
- Feedback bez stawki. Jeśli podopieczny prezentuje decyzje wyłącznie mentorowi, ćwiczy w wyściełanym pokoju. Prawdziwy wzrost wymaga zderzenia jego osądu z realnymi interesariuszami — z mentorem jako asekuracją, nie tarczą.
- Brak wyjścia. Celem mentoringu jest jego własna zbędność. Jeśli po roku podopieczny nadal potrzebuje sesji do decyzji, które podejmował ze mną kwartał temu — zbudowałem zależność, nie seniority.
Podsumowanie
- Luka między mid a senior to osąd, odpowiedzialność i komunikacja — nie kolejna technologia.
- Osąd rozkłada się na ramowanie, czytanie kompromisów, wyczucie odwracalności i obronę ograniczeń — wszystko obserwowalne, wszystko mentorowalne.
- Mentoruj na żywych decyzjach: jedna notatka designu, jeden pull request, jeden incydent na cykl.
- Zamykaj zawsze nazwaniem wzorca za pracą — wzorce się przenoszą, poprawki nie.
- Zmień pytanie robocze z „czy skończone?" na „czy zadziałało?" i trenuj tłumaczenie ryzyka na realnych, zignorowanych obawach.
- Mierz mentoring jego zbędnością: podopieczny podejmujący trafne decyzje bez Ciebie to warunek sukcesu.