Przepytaliśmy Piotra Stachowicza z edrone, który wyjaśnia, jakie są największe wyzwania CTO. Z naszej rozmowy dowiesz się kiedy programista może nazwać się seniorem.
Marta Bąk, Marketing i Biznes: Od jak dawna zajmujesz się programowaniem?
Piotr Stachowicz, Edrone: Zawodowo robię to od 2004 roku, styczność z programowanie miałem jednak dużo wcześniej. Rodzice kupili pierwszy komputer na początku lat 90-tych. Służył nam głównie do gier, ale była dołączona do niego książka z kodem źródłowym prostych programów. Dużą frajdę sprawiało mi przepisywanie tych instrukcji z książki, pomimo że nie wiedziałem co dokładnie robią. Były jak sekretny język, którym w jakiś sposób dało się porozumiewać z maszyną. Pamiętam liczne frustracje, gdy po paru godzinach żmudnego przepisywania zamiast efektownej animacji pojawiał się niezrozumiały kod błędu. To była trudna lekcja cierpliwości.
Zatem co, oprócz cierpliwości, uważasz za kluczowe przy nauce programowania?
Ciekawość jak rzeczy działają pod spodem i nieograniczanie się do jednej wybranej specjalności. Warto wybrać sobie cel, np. język programowania, ale mieć oczy otwarte na technologie z nim związane, zależności. Gdzie i w jaki sposób mój kod jest wykonywany, co się dzieje gdy robię dane wywołanie API, itd. Czasami problem można rozwiązać na wielu poziomach, wiedza o tym jak różne elementy ze sobą współdziałają pozwala lepiej to ocenić.
Jaki masz sposób na budowanie zespołu programistów? Czy to jest łatwe zadanie?
Staramy się wprowadzać w naszym zespole model “leader-leader”, którego istota polega na tym, że kontrola i decyzja nie jest skupiona w wąskim gronie zarządu, ale jest udziałem całej firmy. Jak ognia unikam mikro-zarządzania. Wymaga to wiele wysiłku m.in. zbudowania odpowiednich kompetencji, bez tego oddanie kontroli zamienia się w chaos. Pełnię w tym układzie dwie główne role: usuwanie przeszkód spod stóp innych ludzi oraz dbanie o kontekst, czyli świetną komunikację zarówno w obrębie zespołu programistów, jak i całej firmy. Mam w firmie wiele obowiązków, ale te dwa uważam za absolutnie krytyczne.
Do zespołu edrone dołączyłeś w marcu 2015 roku – jakie zmiany od tego czasu zostały wprowadzone w narzędziu? Z jakiego sukcesu jesteś szczególnie dumny?
Kiedy dołączyłem do firmy, produkt istniał już kilka miesięcy i miał pierwszych klientów. Zaczęliśmy od krytycznego przyjrzenia się temu, co działa, a co wymaga zmiany. Co mówią użytkownicy i jak sprawić, że będą chcieli korzystać z naszego narzędzia codziennie. Czym chcemy odróżnić się od konkurencji.
Efektem wielu, czasem dość emocjonalnych rozmów było gruntowna zmiana narzędzia. Wyeliminowaliśmy funkcjonalności, które wymagałyby zbyt dużej ilości konfiguracji po stronie użytkownika. Zainwestowaliśmy mnóstwo czasu w integracje z głównymi platformami e-commerce, tak by maksymalnie ułatwić wdrożenia. Z pierwszej wersji systemu pozostała jedynie idea, ale ten etap był dla nas niezbędny, by zrozumieć czego potrzebuje rynek.
Równolegle zaczęliśmy wkładać dużo energii w budowę kultury pracy w firmie. Chcieliśmy stworzyć organizację, w której ludzie nie będą po prostu wykonywać poleceń ale będą decydować o kierunku rozwoju, priorytetach. Miejsce, w którym nie będziemy bali się eksperymentować z pomysłami, mówić o swoich porażkach, otwarcie krytykować rozwiązania koleżanek i kolegów z zachowaniem pełnego szacunku dla ludzi.
Jestem dumny z wielu naszych sukcesów: pierwszej nagrody “Best in Cloud 2017” w konkursie Computer World, czy tego, że jako firma zostaliśmy zaproszeni przez Amazon Web Services do prowadzenia prezentacji otwierającej na konferencji AWSome Day. Najbardziej jednak jestem dumny, gdy klienci na publicznych forach polecają nasze narzędzie innym i wiem, że nikt im za to nie płaci.
Jakie było najcięższe zadanie podczas tworzenia CRM-a dla e-commerce? W jaki sposób rozwiązaliście ten problem?
Najcięższym zadaniem było i jest mówienie “nie” dobrym pomysłom. Zatrudniamy obecnie ponad dwadzieścia bardzo kreatywnych osób. Do tego mamy kilkuset klientów, wśród których jest wielu doskonałych specjalistów w dziedzinie marketingu. Jedni i drudzy niemal codziennie zgłaszają świetne uwagi do rozwoju produktu.
Każdy pomysł dokumentujemy i wstępnie analizujemy. Mamy jednak świadomość, że wielu z nich nie zrealizujemy. Najbardziej ograniczonym zasobem młodej firmy jest czas. Powiedzenie czemuś “tak” oznacza powiedzenie “nie” nieskończonej ilości innych rzeczy.
Naszym sposobem na ten problem jest bardzo agresywna priorytetyzacja i trzymanie się wizji intuicyjnego narzędzia.
Kiedy według Ciebie junior developer stanie się seniorem? Jakie wskazówki dałbyś osobą z mniejszym doświadczeniem w programowaniu?
“Senior” to w branży IT dość kłopotliwe pojęcie. Jest bardzo subiektywne, tytułują się tak osoby, które mają kilkanaście lat doświadczenia, i takie, które mają trzy ale w nowym bardzo modnym frameworku.
W dużych firmach, z precyzyjnie określonymi szczeblami kariery, zdarza się, że tytuł “senior” nadaje się, by obejść widełki płacowe narzucone przez odgórną politykę. Małe firmy z kolei dość swobodnie rozdają wysokie tytuły, bo jest to dużo łatwiejsze niż podniesienie wynagrodzenia, czy zwiększenie autonomii pracownika. W efekcie nastąpiła dewaluacja tego terminu.
To spory problem bo większość młodych programistów chce czuć postęp w karierze i ta sytuacja jest dezorientująca. Ten temat dość często pojawia się na naszych spotkaniach 1:1.
W moim przekonaniu pojęcie “senior” należy mierzyć w kilku wymiarach. Kompetencje techniczne są kluczowe podobnie jak czas pracy z daną technologią – nie ma algorytmu kompresji na doświadczenie. Są jednak co najmniej dwie inne grupy cech i umiejętności, bez których trudno przejść na wyższy poziom.
Po pierwsze: zdolności komunikacyjne i umiejętność przekonywania innych do swoich pomysłów. Programowanie to sport zespołowy. Nie ma znaczenia jak skomplikowany algorytm potrafisz zaimplementować, jeśli nikt nie chce z Tobą pracować.
Po drugie: odpowiedzialność za produkt i firmę. Wymaga to otwartości na rozmowę z klientami, proaktywność i dużo, dużo pokory.
Jak już wspomniałeś, zdolności komunikacyjne są niezwykle istotne. Dla kogoś, kto nie jest w branży programiści wydają się być osobami, które prędzej komunikują się z maszyną, niż z inną osobą. W jaki sposób dbasz o komunikacje w swoim zespole?
Faktycznie jest taki stereotyp programisty, ale w moim doświadczeniu częściej problemem jest organizacja. Zaniedbując ten newralgiczny aspekt sama tworzy problem.
Mamy kilka praktyk, które bardzo dobrze sprawdzają się w edrone.
Codzienne robimy dwie krótkie odprawy: z działem sprzedaży i działem wsparcia. Skracają nam one dystans do klientów: jego potrzeb i problemów. Są codziennym treningiem opowiadania o problemie bez nadmiernego epatowania technikaliami.
Gdy tylko możliwe używamy tzw. asynchronicznej komunikacji, która nie wymaga natychmiastowej odpowiedzi. Główną motywacją jest nieodrywanie ludzi od pracy, kiedy są głęboko nad czymś skupieni. Mamy bardzo intensywnie używany chat firmowy, podzielony na kanały tematyczne i zintegrowany z licznymi narzędziami. Taka rozmowa tekstowa też jest treningiem: wymaga dużej precyzji i klarowności języka, bo pewne niewerbalne niuanse są niedostępne.
Sądzę, że nadmierna komunikacja jest lepsza niż niewystarczająca, stąd niektóre rzeczy powtarzamy wielokrotnie (tzw. “over-communicate).
Stan zdrowia firmy można ocenić po tym jak długo czasu mija od momentu kiedy ktoś chce dać komuś informację zwrotną do momentu kiedy to robi. W skrajnej sytuacji wzajemnego braku zaufania ten „feedback”, może nie pojawić się nigdy.
Kto Cię inspiruje?
Staram się dużo czytać i od czasu do czasu trafiam na pozycje po których zmienia się mój punkt widzenia. Niekiedy radykalnie. John Allspaw (były CTO firmy Etsy, współtwórca ruchu DevOps) sprawił, że diametralnie zmieniłem sposób analizy sytuacji w których coś poszło nie tak (tzw. post-mortem). Prace Daniela Kahnemana (psychologa i ekonomisty) uświadomiły mi jak bardzo mój własny umysł jest podatny na błędy poznawcze. Model “leader-leader” zaczerpnąłem od L.David’a Marquet, który z ogromny sukcesem wprowadził go na pokładzie łodzi podwodnej z napędem atomowym, miejscu tradycyjnie kojarzonym z bardzo ścisłą hierarchią.
Czego Ci mogę życzyć?
Ciągłej frajdy z ogromnego wyzwania, jakim jest praca w małej firmie o światowych aspiracjach. Nie pogardziłbym też 25-godzinną dobą.
Piotr Stachowicz: CTO w firmie edrone. Ma duże doświadczenie w prowadzeniu zespołów programistów, budujących systemy IT wysokiej skalowalności i niezawodności. Absolwent Politechniki Warszawskiej i University College Dublin. Certyfikowany architekt rozwiązań Amazon Web Services.
Wywiad powstał dzięki:
Coders Lab
Łącząc doświadczenie edukacyjne ze znajomością rynku pracy IT, Coders Lab umożliwia szybkie i efektywne zdobycie pożądanych kompetencji związanych z nowymi technologiami. Skupia się się na przekazywaniu praktycznych umiejętności, które w pierwszej kolejności są przydatne u pracodawców.
Wszystkie kursy odbywają się na bazie autorskich materiałów, takich samych niezależnie od miejsca kursu. Dzięki dbałości o jakość kursów oraz uczestnictwie w programie Career Lab, 82% z absolwentów znajduje zatrudnienie w nowym zawodzie w ciągu 3 miesięcy od zakończenia kursu.
Zostaw komentarz