Po przeczytaniu książki Technical Leadership. Od eksperta do lidera byłem mile zaskoczony że pojawiła się taka pozycja. Bynajmniej nie dlatego że dowiedziałem się tam czegoś zupełnie nowego. Książka ta jest świetnym wprowadzeniem „entry-level” dla programistów, którzy sami chcą zostać liderami lub gdy organizacja chce ich do tego przekonać i potrzebują wsparcia.

Do moich własnych obowiązków należy wspieranie kreowania liderów technicznych – jest to zadanie niekiedy niełatwe ale zawsze bardzo satysfakcjonujące. Mimo że pracuję w dojrzałej i uporządkowanej organizacji, to z kreowaniem liderów są często dwa kłopoty. Pierwszy, że są bardzo różni kandydaci: niektórzy chcą przewodzić, wchodzą w to naturalnie i trzeba im tylko od czasu do czasu przekazać konstruktywne uwagi czy trochę pomóc. Ale równie często liderami powinna zostać osoba która nie jest na to zdecydowana, taka którą zespół „wypycha na przód”, a sam kandydat nie czuje takich kompetencji wolałby tylko programować, a nie „chodzić na spotkania”.

Drugim problemem często jest niewiedza kandydata z obszaru zarządzania i brak bezpośredniego mentoringu: w sprzyjających warunkach można terminować jako zastępca lidera, obserwować go w czasie pracy, uczyć się i przejmować kolejne zadania. Jednak parę razy zdarzyły mi się sytuacje gdy do przekazanie całej wiedzy o zarządzaniu zespołem miałem do dyspozycji kartkę A4 z zakresem obowiązków, kilka spotkań instruktażowych i zachętę typu „jakbyś miał jakieś pytania to wiesz gdzie mnie szukać”. I z tego co wiem z różnych źródeł, to w naszej branży jest to nierzadka sytuacja :-).

Wracając do samej książki – jest to dobra lektura dla wszystkich którzy interesują się taką rolą lub firma na nich taką rolę wymusza bez zapewnienia wystarczającego wsparcia. Już pierwsze rozdziały odpowiadają na tradycyjne pytania: czego będą ode mnie oczekiwać, co z tego będę miał i czy będę miał jeszcze czas programować. Kolejne rozdziały to przyzwoity know-how jak radzić sobie już w tej roli, jak ustawiać sobie relacje z zespołem i z organizacją na zewnątrz, jak rozwiązywać trudne przypadki. Ostatni rozdział to typowe FAQ, czyli często zadawane pytania z odpowiedziami odnoszącymi się do treści poprzednich rozdziałów. Po stylu książki widać że pisał ją inżynier: krótko, treściwie, recepty na gotowe rozwiązania. Książka jest niedługa (180 stron) i szybko się ją czyta, więc można ją przeczytać dwa wieczory. Ale dodatkową zaletą jest dobra bibliografia – tematy potraktowane płytko z minimalną ilością teorii zawierają odesłania do wyczerpujących klasycznych pozycji – można ją więc traktować jako przewodnik po dalszych lekturach. Zaletą jest też to że autor czerpał doświadczenie z polskiego rynku, więc przykłady są adekwatne do naszych realiów – w przeciwieństwie do częstych oderwanych od rzeczywistości przykładów z rynku amerykańskiego.

Parę razy podchodziłem do przygotowania własnego szkolenia dla kierowników, jednak nie udało mi się wyjść dużo dalej poza spis tematów do poruszenia. Tym bardziej byłem mile zaskoczony, że ta niewielka książka zaadresowała około 70% tego co zamierzałem przekazać, więc oceniam ją jako wartościową.

Jako wady książki można wymienić trochę chaotyczną organizacje, wskazujący że musiała powstawać jako zbiór wiedzy ze różnych szkoleń prowadzonych komercyjnie przez autora, i nieco irytujący „couchingowy” styl rozwiązywania problemów poprzez forsowanie pytań „a jakbyś Ty to zrobił?”. Nie znalazłem też wartości w „mapach myśli” podsumowujących każdy rozdział ale może innym one pomagają.

Reasumując: mimo że książkę można by zatytułować „zostań kierownikiem w weekend”, to i tak uważam warto ją przeczytać interesując się wejściem w taką rolę lub szukając pomocy gdy się już ją wykonuje. Chętnie też zobaczyłbym kolejną książkę tego autora.