servant leadership

Continuous Learning w karierze programisty. Historia Damiana Skonecznego

– Na początku pełniąc rolę tylko programistyczną byłem “zamknięty” w swojej strefie komfortu. Ale teraz mam mocną motywację do tego, żeby wychodzić poza jej ramy i otwierać się na nowe możliwości. Dzięki temu łapię dużo nowych i wartościowych dla mnie doświadczeń, które rozwijają mnie zarówno jako lidera, product ownera czy programistę – powiedział w rozmowie z nami Damian Skoneczny z HTD Health. 

Jak wyglądała jego ścieżka kariery? Dlaczego rozwijał się w kierunku leadera? Czy warto dążyć w kierunku servant leadershipu? Na te i na wiele innych pytań odpowiedzi znajdziecie w naszej rozmowie z Damianem.

servant leadership

Spis treści

Zaczynałeś od pracy w software housie – uważasz, że to najlepsze miejsce dla rozwoju młodego programisty?

Z mojego punktu widzenia, organizacje pokroju software house dają najwięcej możliwości, bo masz szansę trafić od razu do prawdziwego projektu i prawdziwego klienta. Jednocześnie zyskujesz możliwość większego rozwoju, dzięki pracy na projekcie (na żywym organizmie). 

Również uczysz się i oswajasz z kontaktem z klientem. Ten medal ma dwie strony, bo jedni programiści lubią mieć bezpośredni kontakt z klientami, a drudzy wolą go unikać. Ja należę do tych pierwszych. Dzięki temu jestem bliżej problemów klienta, które musimy rozwiązać. Mamy też większą świadomość tego, jak oprogramowanie ma działać i jakie ma dostarczać wartości użytkownikom końcowym. 

Dużą korzyścią zaczynania, czy pracowania w firmie programistycznej (software house) jest to, że masz też bezpośredni kontakt ze wszystkim ludźmi w firmie. Np. jeśli potrzebujesz dostępów do jakiegoś “toola”, to otrzymasz go prawie natychmiastowo. 

Dwa lata później poszedłeś w kierunku JavaScriptu. Skąd ta decyzja?

Nie kierowała mną technologia. Kierowała mną chęć rozwoju i sprawdzenia się czy potrafię odrobinę ”spivotować” moją karierę programistyczną. Z perspektywy czasu myślę, że technologia jest rzeczą drugorzędną. Dla mnie kluczowe jest wykształcenie w sobie umiejętności i chęci do rozwoju, żeby jak najlepiej adaptować się do sytuacji na rynku czy trendów w IT. 

Jak przebiegało to przebranżowienie? Gdzie uczyłeś się JSa?

“Liznąłem” trochę JSa w poprzedniej organizacji i od tego zaczęła się moja praca z tą technologią. Przechodząc do nowego miejsca pracy od razu trafiłem do projektu w JavaScript, więc musiałem bardzo szybko nadrabiać swoją wiedzę i rozwijać umiejętności techniczne. Na szczęście miałem cały czas wsparcie od bardziej doświadczonych współpracowników, którzy regularnie dzielili się informacjami zwrotnymi na temat moich pull requestów. 

Najważniejsza była praktyka. Książki i kursy są ok, ale dopiero w realnym działaniu jesteśmy w stanie zweryfikować to, co już wiemy, a przede wszystkim to czego nie wiemy, a powinniśmy. 

Opowiedz o kontekście Twojego przyjścia do HTD Health – przyszedłeś z większej firmy do mniejszej. Ile osób wtedy liczył zespół HTD, jak szybko rósł i co oznaczał dla Ciebie ten szybki wzrost?

Przychodząc do firmy byłem siódmą osobą na pokładzie. To była dla mnie duża zmiana – przejść z większej firmy do mniejszej, gdzie do tej pory byłem przyzwyczajony do codziennej pracy z dużą liczbą osób. Na początku było to dla mnie trudne, ale z czasem zaczęliśmy budować ze sobą silniejsze relacje, co na co dzień pomagało nam w pracy nad projektami. 

Firma zaczęła szybko rosnąć, zarówno jeśli chodzi o skalę projektów, jak i zespołów. Programując dla branży medycznej czułem się dodatkowo zmotywowany, bo prawie każdy nasz projekt zmienia świat na lepsze.

Momentem przełomowym był pierwszy firmowy retreat w 2017, kiedy w firmie było ok. 30 osób. To było jeszcze w czasach, kiedy można było podróżować swobodnie, więc wybraliśmy się całą firmą do Toskanii. To było dla mnie o tyle wyjątkowe, pierwszy raz wziąłem udział w wyjeździe, w trakcie którego mogliśmy wszyscy nawiązać ze sobą bliższe relacje, lepiej się poznać, co później przełożyło się na efektywniejszą pracę w zespole.

Dopiero w HTD Health doświadczyłem tego, jak silną i mocno rozwijającą się organizacją jesteśmy. Nie dość, że robimy społecznie ważne projekty, to do tego stanowimy silny i wspierający się team specjalistów IT. 

Od początku czułem, że osiągniemy jako firma coś wielkiego, ale nie spodziewałem się, że w zaledwie 4 lata będzie ponad 120 osób na pokładzie. Dziś musimy mierzyć się z inną skalą wyzwań. Zarówno jeśli chodzi o projekty, jak i budowanie zespołów czy dobór odpowiednich narzędzi. 

Dość szybko zostałeś Product Ownerem. Z jakimi wyzwaniami mierzysz się na co dzień?

Najważniejsze w pracy Product Ownera jest przełożenie słów klienta, wymagań i oczekiwań na język, który zrozumie zespół i będzie w stanie wypracować te feature’y, czy efekt końcowy, który oczekuje klient. 

Jednocześnie ważne jest zadbanie o to, żeby dawać zespołowi wolną rękę w działaniu. Dla mnie najważniejsza jest realizacja zadania, a sprawy techniczne i użyte rozwiązania są po stronie zespołu. Ponieważ mam background techniczny, to mogę w tych obszarach wspierać team, ale dbam o to, żeby skupiać się na kwestiach biznesowych oraz user experience użytkownika końcowego, zamiast narzucać swoje rozwiązania. 

Co dla Product Ownera jest najważniejszym wskaźnikiem rozwoju, sukcesu: liczebność zespołu programistów czy szybkość realizacji projektu?

Zasadniczo, to dużo bardziej złożona kwestia. Według mnie liczy się przede wszystkim pogodzenie dobra klienta i jego zadowolenia z realizacji projektu, a z drugiej strony zapewnienie tego, żeby zespół miał optymalne warunki do pracy. W naszej organizacji istotną rolę we współpracy i osiąganiu najważniejszych celów jest udział Scrum Mastera w projekcie. Wspiera on cały zespół, a także klienta, w procesie wytwarzania oprogramowania, żeby proces ten szedł dużo sprawniej, szczególnie kiedy pojawiają się niuanse komunikacyjne. 

W HTD Health od początku 2020 roku mocno stawiamy na zwinność i na tyle na ile to możliwe, prowadzimy projekty w oparciu o Scruma. Wiadomo, że to swojego rodzaju “framework”, który różne firmy dostosowują do swojej rzeczywistości. Jednak my staramy się dążyć do tego, żeby realizować projekty zgodnie z założeniami tej metodologii. Dlatego mamy zespoły składające się z Product Ownerów, Scrum Masterów, pracujące zgodnie z tym “frameworkiem.”

Jako organizacja jesteśmy nastawieni na warm fuzzy feeling dla klienta – podchodzimy do jego potrzeb proaktywnie i regularnie proponujemy usprawnienia, czy nowe feature’y , które mogłyby wzbogacić jego produkt. Clou jest dążenie do tego, żeby wraz z klientem tworzyć zespół produktowy, który będzie grać do jednej bramki, podzielać te same cele i posiadać świadomość tego, że nasza współpraca jest oparta na partnerskich relacjach. 

Na czym skupiasz się będąc Liderem zespołu? Co doceniasz wśród współpracowników, jak rozwiązujesz ich problemy?

W naszym przypadku jest trochę inaczej, niż możesz zakładać, zadając to pytanie. Otóż w HTD Health lider ma swoich podopiecznych, tylko wcale nie muszą oni należeć do tych samych zespołów. Rzadkością jest, że te dwie osoby są w tym samym projekcie, ale nie jest to zasadą ani w jedną, ani w drugą stronę. 

servant leadership

Zadaniem lidera jest dbanie o to, żeby jego podopieczny rozwijał się w odpowiedni dla siebie sposób i wiedza o tym, do kogo skierować go w sytuacji, w której dany problem (np. technologiczny) będzie wykraczać poza kompetencje mentora. 

Dla mnie najbardziej satysfakcjonujący jest ten moment, kiedy pomagam realnie rozwiązywać problemy podopiecznych i to jest dla mnie jeden z najważniejszych aspektów tej roli. Wspieramy też w bardziej prozaicznych tematach, jak np. pomoc w pracy zdalnej, ale też w stwarzaniu możliwości do zwykłej rozmowy. Szczególnie teraz, kiedy wszyscy pracujemy ze swoich domowych “biur”

Jak rozwiązuję problemy? To zależy. Gdy zaczynam z kimś współpracę to staram się prowadzić tę osobę i dawać jej jak najwięcej ze swojego doświadczenia i wsparcia. Z kolei, dla tych bardziej doświadczonych stwarzam możliwość do tego, żeby sami rozwiązywali swoje problemy. Pomagam im tylko poprzez zadanie pytania, którego sami wobec siebie by nie postawili. 

Co doceniam? Gdy człowiek jest zaangażowany, czy to w projekt, czy w życie organizacji, to jest to dla mnie duża wartość. Podobnie jak bycie szczerym i mówienie wprost, co mi siedzi na wątrobie lub co mi przeszkadza. Jeżeli są osoby bardziej zamknięte w sobie, to staram się pracować z nimi długofalowo, budując zaufanie i otwartą komunikację. Wierzę, że to będzie pracować dla dobra organizacji, naszej współpracy z klientami, a przede wszystkim nas samych. 

Twoim zdaniem Leader powinien dbać o rozwój współpracowników? Jak Lider może pomóc programiście w jego ścieżce rozwoju?

Jako lider jestem hubem komunikacyjnym między mną, a podopiecznym i organizacją. Moją rolą jest pomóc określić drogę rozwoju i skupienie się na tych kompetencjach czy umiejętnościach, które będą przynosić możliwie dużo wartości dla tej osoby, jak i organizacji. 

Nie muszę wiedzieć wszystkiego i znać odpowiedzi na każde pytanie. Po mojej stronie jest orientować się, do kogo przekierować tę osobę, gdy ma jakiś problem lub po prostu wskazać kierunek, np. wybór technologii, który powinna obrać. 

Angażowałeś się m.in. w firmowy program stażowy. Co Developerowi daje tworzenie i prowadzenie takiego programu?

servant leadership

To była moja pierwsza możliwość, aby pracować więcej z ludźmi nad ich rozwojem i móc ich prowadzić. Zawsze czułem to pod skórą, że jest to dla mnie zarówno dużo wyzwanie, ale też satysfakcja płynąca z tego, że mogę im pomagać rozwijać się i mocniej integrować z firmą. 

Dla mnie najważniejsze było to, że mogłem spróbować czegoś innego, niż tylko realizacja zadań w projekcie. Uważam, że jeżeli masz możliwość współpracy z innymi osobami z firmy, z którymi wcześniej nie miałeś do czynienia, to może to być też dla ciebie bardzo rozwojowe przedsięwzięcie. 

Nauczyłem się też, że tego typu aktywności to duże wyzwanie logistyczne i sprawiające, że musisz znacznie lepiej zarządzać swoimi zadaniami. Bo, gdy masz 200 kandydatów na staż, to nie dość, że musisz rzetelnie przefiltrować ich CV, to potem zaprosić na rozmowy rekrutacyjne i je przeprowadzić. A to wszystko kosztuje czas. Wtedy, gdy się tym zajmowałem nie mieliśmy jeszcze działu rekrutacji, dziś na szczęście jest już inaczej, tj. mamy dział Recruitment, bez którego żaden z rekruterów technicznych dziś nie wyobraża sobie życia 

Największym wyzwaniem była dla mnie selekcja osób po rozmowach rekrutacyjnych – to było dla mnie coś nowego, ale dzięki temu dzisiaj mogę swobodnie prowadzić procesy rekrutacyjne. Szczególnie, że ludzie wracali z informacją zwrotną na temat samego procesu, który prowadziłem, że w trakcie rozmów czuli się bardzo ludzko traktowani i było to dla nich wartościowe. A dla mnie samego satysfakcjonujące.

Co myślisz na temat sytuacji juniorów w Polsce? Jak mogą szybciej znaleźć doświadczenie, co poskutkuje szybszym znalezieniem pracy?

Moim zdaniem idealnym krokiem na start jest pójście na staż do firmy programistycznej. Zdaję sobie sprawę z tego, że może to brzmieć jako coś łatwego, a często takim nie jest. W HTD Health rekrutacja na staż przypomina tę na stanowiska o wyższym poziomie “seniority”. Jednocześnie nie oczekujemy od takiej osoby, że będzie ekspertem w jakiejś technologii. To co jest dla nas kluczowe na początku (i potem) współpracy to czy dana osoba będzie chciała się rozwijać i przekona nas do tego. Konkretnej technologii prawie każdy jest w stanie się nauczyć, ale to co jest niezbędne na start, czy dla juniora czy dla stażysty, to motywacja i zaangażowanie do tego, żeby programować i czerpać z tego radość. 

Gdybym był dzisiaj na miejscu junior developera to starałbym się robić jak najwięcej projektów, możliwie komercyjnych lub na studiach. Chciałbym mieć jakiś swój projekt, który mogę komuś pokazać “na produkcji”. Nawet jeśli skończyłem bootcamp, to warto zadbać o praktyczne wykorzystanie zdobytej tam wiedzy, zamiast tylko pokazywania projektów zrealizowanych w trakcie nauki. Zadbałbym o taki program, z którego będę szczególnie dumny i przede wszystkim rozumiem, co zakodowałem i dlaczego. 

Jeżeli widać u kogoś tę ”zajawkę” do IT, to też będzie odebrane to jako dobra moneta i start do rozmów.

Nie jesteś więc “tylko” Developerem, ale też podjąłeś się wielu ról w firmie. Dlaczego? To jeden ze sposobów utrzymania motywacji, czy zdobywania kolejnych doświadczeń?

Na początku pełniąc rolę tylko programistyczną byłem “zamknięty” w swojej strefie komfortu. Ale teraz mam mocną motywację do tego, żeby wychodzić poza jej ramy i otwierać się na nowe możliwości, bo dzięki temu łapię dużo nowych i wartościowych dla mnie doświadczeń, które rozwijają mnie zarówno jako lidera, product ownera czy programistę. 

Ten medal ma oczywiście drugą stronę, bo przez to, że lubię się angażować w różne tematy, to często trudno jest to pogodzić z moim kalendarzem. Staram się nad tym pracować – nad organizacją pracy. Wydaje mi się, że jestem w tym coraz lepszy. Nabywam świadomość tego, co robię źle oraz pracuję nad asertywnością. 

Co do dziś dało Tobie największe doświadczenie, zarówno pod kątem programistycznym, jak i bycie Liderem?

Jak o tym myślę, to jest zbiór różnych i bardzo odmiennych sytuacji. Zarówno tych, które sam przeżyłem na własnej skórze w projektach, jak i tych z którymi borykają się moi podopieczni, a także te wszystkie wyzwania, które stoją przed naszą organizacją. 

Wszechstronność bycia w różnych sytuacjach i w różnym czasie były dla mnie bardzo rozwijające. Perspektywa z roli lidera, product ownera oraz programisty nauczyły mnie, że nie ma “złotego środka” dla każdej sytuacji. Jednak każde przezwyciężone wyzwanie daje mi wskazówki, co mogę użyć w nadchodzących projektach i współpracy z moimi podopiecznymi. 

Czy dziś, z perspektywy czasu, podjąłbyś inne decyzje jeśli chodzi o Twoją ścieżkę kariery?

Z tego miejsca, gdzie dziś jestem, to jestem zadowolony z podjętych decyzji. Do dziś miałem okazję pełnić rolę lidera, product ownera oraz mam solidne doświadczenie programistyczne. Jak rozmawiam z klientami to już na etapie samego pomysłu widzę, gdzie potencjalnie są ryzyka i zdaje sobie sprawę z tego, co może nas czekać w projekcie (jakie wyzwania), jeszcze zanim on się rozpocznie.  

Mimo, iż nie jestem “mistrzem jednego kopnięcia” [red. Jak Bruce Lee], to mam szeroki wachlarz wiedzy i umiejętności z różnych obszarów. Jeśli tylko podejmę decyzję, że chcę zostać mistrzem w danej dziedzinie, to będzie mi łatwiej, bo już będę miał z nią pewne doświadczenia oraz przekonanie, czy w ogóle chcę to robić.


Damian Skoneczny. Od 2016 roku w HTD Health, gdzie rozpoczął swoją pracę jako JavaScript Developer, a następnie wybrał ścieżkę budowania produktów IT. Od początkowych rozmów z klientami, zbierania wymagań, projektowania rozwiązań technicznych, czy pracą i wyznaczaniem drogi rozwoju danego produktu aż do pracy z całym zespołem odpowiedzialnym za wdrożenie. Od 2019 coraz mocniej rozwija się w kierunku servant leadershipu.

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
Historia zmian na GitHubie. Prasówka Technologiczna: 04-08.02.2019