Solidne zespoły nie powstają przypadkowo – Bartłomiej Tyranowski (Picodi)

W startupach, spółkach technologicznych, czy w software house’ach, frontmenami zazwyczaj zostają CEO. To oni barwnie opowiadają o przeszłości, teraźniejszości i przyszłości firmy, którą prowadzą zawsze z pasją i zaangażowaniem. W cyklu CTO Story chcieliśmy pochylić się nad rolą CTO w różnego rodzaju firmach. Do pierwszej części cyklu zaprosiliśmy Bartka Tyranowskiego, który porzucił programowanie na rzecz zostania CTO, choć jak sam mówi, nigdy nie miał czasu na spokojne przejście do tej roli.

Bartek współtworzy Picodi.com – portal, który dawniej nazywał się kodyrabatowe.pl. Portal z kodami rabatowymi powstał w 2010 roku i od początku przynosił zyski. Dzięki pozyskaniu dużych klientów, którzy umieszczali kody zniżkowe na produkty, kodyrabatowe.pl zdobyły szybko popularność wśród polskich internautów. Przez ten czas kodyrabatowe.pl przekształciło się w picodi.com i otworzyło na nowe rynki. To wszystko nie byłoby możliwe, gdyby nie zespół zaangażowanych w rozwój firmy developerów. Przez cały ten czas zarządzał nimi Bartek Tyranowski, dawniej PHP i Ruby developer, teraz CTO Picodi.

Gdzie zdobywałeś swoje doświadczenia, zanim powstał pomysł na Picodi?

W boju. Od wczesnych lat studenckich (a nawet jeszcze w liceum) kręciłem się wokół tworzenia aplikacji, w większości webowych, ze szczególnym uwzględnieniem e-commerce’u. Realizowałem wtedy mniejsze i większe projekty – zarówno sklepy internetowe, jak i różne dedykowane narzędzia zwiększające efektywność sprzedażową zleceniodawców. Wiesz, to był okres jeszcze przed web 2.0 – wtedy bywało tak, że niewiele trzeba było zrobić, żeby osiągnąć spory zysk lub optymalizację w kosztach. Głównie dlatego, że narzędzi na rynku było nieporównywalnie mniej niż teraz.

Od czego zacząłeś tworzenie Picodi? W jakiej technologii powstało MVP?

W porównaniu do wielu przedsiębiorstw i startupów, Picodi ma dość krętą historię. Pierwsza wersja technologii protoplasty Picodi (kodyrabatowe.pl) powstała jeszcze zanim zaczęliśmy poważnie działać na polskim rynku. Nie wytworzyłem jej sam, raczej przejąłem z dobrodziejstwem inwentarza od moich dzisiejszych wspólników – Tomka Krausa i Łukasza Halucha, którzy mieli wtedy spółkę software’ową i w ramach tej spółki zrealizowali etap, który można śmiało nazwać MVP dzisiejszego Picodi. I jak to zwykle jest (lub powinno być) przy MVP – użyte zostały możliwie najprostsze technologie, ale takie, które prowadziły do celu. Była to wtedy dedykowana aplikacja (monolit) w PHP, wsparta dodatkowo wordpress’em.

Projekt Picodi powstał po godzinach? Wiesz, ile czasu poświęcono na stworzenie MVP?

Z tego co wiem od Tomka, pierwsza wersja, która ujrzała światło dzienne, powstała w kilka dni (po godzinach – w święta). Potem, gdy z Szymonem Doboszem przejęliśmy sterowanie, zaczęła się już regularna praca i budowanie zespołu – tak żeby projekt utrzymać i szybko rozwijać. U mnie owszem, był to bardzo intensywny czas i niejednokrotnie siedziałem do późna. Głównie dlatego, że późny wieczór lub nawet noc były dla mnie najlepszymi momentami do tego, żeby niezależnie od codziennych zadań bieżących móc wreszcie coś zrobić. Choć i z tym nie było łatwo, bo już wtedy udało nam się wytworzyć dość specyficzną atmosferę, przy której zespół nie liczył czasu spędzonego w biurze. Ludzie przychodzili, robili co do nich należało, a potem często zostawali do późna albo nawet na noc – bo chcieli. Z dużym sentymentem wspominam te czasy.

Z jakich wówczas dostępnych frameworków korzystaliście? Dlaczego wybraliście te, a nie inne i na co one pozwalały?

MVP powstało w PHP (CakePHP wersja 1.x). Dodatkowo niektóre sekcje były obsłużone wordpress’ami, bo nie było sensu wynajdywać koła na nowo. Nie wybierałem takiego zestawu, ale jeśli brać pod uwagę w jakim miejscu były wtedy narzędzia i technologie, jak najbardziej się pod takim wyborem podpisuję. Przy użyciu takiego zestawu dało się szybko postawić aplikację realizującą podstawowe założenia, bez konieczności przesadnego skupiania się na tym co jest pod maską. Oczywiście dzisiaj, przy znacznie większej skali, wymagania są trochę inne, więc zarówno narzędzia/frameworki, jak i sam proces deweloperski wyglądają zupełnie inaczej.

Jak dzisiaj, przy dostępnych frameworkach, zbudowałbyś Picodi?

Gdybyśmy mieli Picodi startować dzisiaj, pewnie szukałbym rozwiązań o podobnej specyfice do tych zastosowanych kilka lat temu. Jakiegoś prostego framework’a, spełniającego minimalne założenia i dającego możliwość szybkiego doprowadzenia aplikacji na rynek. Nie wiem co by to było. Niewykluczone, że też cakePHP, tylko nowy.

Uważam, że frameworki i narzędzia trzeba dobierać do etapu, na którym jest firma. Jeśli pomysł się sprawdzi i zacznie finansować, nie raz jeszcze będzie okazja, żeby software mocno zmodyfikować lub nawet napisać od zera. My wraz ze wzrostem skali robiliśmy sporo refactoru i aktualizacji frameworków do nowszych, lepszych wersji. W 2015 roku w ogóle przepisaliśmy cały soft – tak, żeby nadążał za nowymi trendami i był bardziej atrakcyjny pod względem HR’owym. I dzisiejszego stanu absolutnie bym nie zmieniał.

Kiedy do teamu Picodi dołączył pierwszy zatrudniony developer? Jakimi kryteriami oceniałeś jego umiejętności twarde i miękkie?

U mnie w zespole od samego początku było dwóch. Powiem tak: moje ówczesne rekrutacje można by chyba ocenić jako mocno politycznie niepoprawne. Umiejętności techniczne oczywiście weryfikowałem, ale tylko w stopniu absolutnie koniecznym (pozostawiając sporo miejsca na chęć do nauki, którą większość kandydatów deklaruje 🙂 ). Miałem natomiast dość skuteczny zestaw pytań niestandardowych, które dawały mi możliwość poznania kandydata pod względem tego jak będzie podchodził do pracy i czy będzie pasował do reszty zespołu.

Jakie to były pytania?

Dziwne, pytałem na przykład o to jak dany kandydat wyobraża sobie życie w wyimaginowanym kraju X, w którym obowiązuje niski podatek pogłówny (niezależny od pracy i dochodu) w jakiejś tam wysokości (chyba to było 400 zł)? Pytanie mocno abstrakcyjne, ale odpowiedź na nie dawała mi sporo informacji. Jeśli ktoś płynął w kierunku “ale jak to? przecież to niesprawiedliwe społecznie!” itd. to już wiedziałem, że przy moich dość konserwatywnych poglądach i podejściu do budowania firmy, niezależnie od umiejętności technicznych, możemy się po prostu nie dogadać.

Jeszcze dawniej, jak zatrudnialiśmy głównie studentów, pamiętam, że na teście dawaliśmy w pierwszym pytaniu jakąś bezsensowną, ale za to bardzo groźnie wyglądającą całkę. Bynajmniej nie oczekiwaliśmy, żeby ktoś ją rozwiązał (szczerze mówiąc nawet nie wiem czy było to w ogóle wykonalne), bardziej chodziło o wybadanie reakcji. Najlepiej poradził sobie z nią jeden kandydat (i to jego wtedy zatrudniliśmy), który kilka razy spojrzał najpierw na kartkę, potem na mnie, po czym z uśmiechem powiedział coś w stylu… no chyba sobie jaja robicie 🙂 I z tego też można było sporo wywnioskować – po pierwsze, że gość ma poczucie humoru (czyli do zespołu będzie pasował) oraz, że raczej nie lubi akademickich dyskusji i bezsensownych poleceń… tylko wyraźnie zgłasza wątpliwości i szybko przechodzi do konkretów. A to bardzo istotne cechy ludzi, którzy mają dowozić dobre rozwiązania.

Czym różni się praca deva w startupie od pracy w innej firmie?

Powiem tak: osobiście nie lubię określenia startup. Picodi nigdy (no, może poza naprawdę samym początkiem) nie było startupem w powszechnym rozumieniu tego słowa. Od samego początku mieliśmy dość precyzyjnie zdefiniowany model biznesowy i praktycznie od razu zaczęliśmy zarabiać. Zatem mógłbym przekornie odpowiedzieć, że nie wiem jak to jest w startupie. Ale odpowiem politycznie, że to zależy.

Wyobrażam sobie startup, w ramach którego realizowany jest jakiś bardzo zaawansowany technologicznie projekt. Taki, który ma, jak to się przyjęło mówić – “zrobić disruption” na całym świecie i okolicach. Founderzy zbierają duże finansowanie i wszyscy dostają takiego ciśnienia na innowacyjność i fajność, że czasem zapominają o realnym biznesie, procesach oraz zwykłej, codziennej egzekucji. W takich przedsięwzięciach deweloper często robi rzeczy fajne i ciekawe (uśredniając pewnie ciekawsze niż tłumaczenie XML’a na innego XML’a w 10-letnim projekcie dla dużego klienta, napisanego w Javie 1.3), ale bywa, że niekoniecznie potrzebne. Pod wpływem ciągłych zmian, reiteracji strategii, kolejnych podejść do MVP (a to częsta startupowa przypadłość) dużo pracy deweloperskiej niejednokrotnie idzie do kosza. Nawet jeśli jest to praca wykonana od strony technicznej bez zarzutu.

U nas było trochę inaczej. Nie mieliśmy zewnętrznego finansowania, więc od początku mocno zależało nam na wysokiej efektywności. Dlatego zawsze szukaliśmy rozwiązań prostych. Takich też wymagaliśmy od deweloperów we wszystkich naszych projektach – zewnętrznych i wewnętrznych. I tak jest do dzisiaj, co widać na przykład po tym, że mimo dość dynamicznego wzrostu złożoności technologicznej naszych projektów w ostatnich dwóch latach, zespół IT pod względem liczebności na tle innych zespołów w firmie rośnie relatywnie wolno. I starcza, bo chłopaki dają radę!

Oferty pracy z

Co było dla Ciebie największym wyzwaniem obejmując stanowisko CTO? Czego nie spodziewałeś się podejmując się zarządzania zespołem?

Szczerze mówiąc, nie miałem nawet za bardzo okazji do takich rozważań. Nie było u nas takiego momentu jak “objęcie stanowiska CTO”. Podobnie było z Szymonem (CEO). My po prostu od samego początku robiliśmy swoje, wiedząc z grubsza jak przebiega linia oddzielająca nasze zakresy kompetencji i związanych z tym obowiązków. I dopiero z czasem w rozmowie ze wspólnikami wyszło, że ze względów wizerunkowych (na zewnątrz) wypadałoby zacząć się przedstawiać w ten sposób.

Co do zarządzania zespołem to chyba najbardziej zaskoczył mnie moment, w którym okazało się, że jest to już zadanie wymagające zaangażowania full time. Niby jest to naturalna kolej rzeczy, ale nasza organizacja rozrastała się z taką dynamiką, że chyba nikt nie spodziewał się, że ten moment nastąpi tak szybko.

Dzisiaj jesteś CTO, czym to stanowisko różni się od stanowiska developera? Co zabiera Tobie więcej czasu: organizacja pracy innych, czy programowanie?

Wraz z rozwojem firmy i zwiększaniem się liczebności zespołu rola CTO bardzo się zmienia. Na początku chyba najczęściej sprowadza się ona do bycia po prostu głównym deweloperem. Niekoniecznie stricte lepszym niż inni, ale na pewno mającym szersze spojrzenie i większe doświadczenie. Z czasem ta rola zmienia się w kierunku całościowej odpowiedzialności za technologię i budowanie przewag technologicznych w firmie. Dochodzi dużo elementów z zakresu zarządzania projektami i optymalizacji procesów – tych stricte technologicznych i nie tylko. No i oczywiście budowa zespołu, która też jest wyzwaniem.

To jednak mocno zależy od specyfiki firmy i jej projektów. Z moich obserwacji im bardziej spółka jest technologiczna (tech-first), tym częściej CTO mają tendencję do oddawania tych zarządczych obowiązków swoim podwładnym lub nawet managerom z innej części organizacji. Ja zarządzanie zespołem oddałem dopiero niedawno (pojawił się u mnie Head of Engineering), ale też nie do końca. Zespół, który obecnie mamy w Picodi jest czymś, z czego jestem bardzo dumny. Dlatego praca z nim sprawia mi dużą frajdę i w jakimś tam stopniu potrzebuję wpływać na to jak ta praca przebiega.

Niemniej, obecnie najwięcej czasu pochłania mi planowanie i egzekucja projektów, które realizujemy. Mocno wchodzę w obszary, które w różnych firmach realizowane są przez “Project Managerów”, “IT Project Manager’ów”, “Product Manager’ów” a czasem nawet COO. Jest to zresztą dla mnie dość naturalne środowisko, bo lubię widzieć jak procesy dobrze działają. Nie, sam nie koduję. Chyba, że coś na własne, analityczne potrzeby – jak nikt nie widzi. Ale żeby commitować do kodu Picodi to chyba obecnie byłoby mi głupio próbować.

Dev kiedy czegoś nie wie, prosi starszego kolegę o pomoc. Co gdy CTO nie wie, jak rozwiązać dany problem? Kogo może pytać o poradę?

Musi sobie radzić. A tak poważnie, wiesz, tak jak nadmieniałem wcześniej – rzadko kiedy jest tak, żeby rola CTO sprowadzała się do bycia takim deweloperem tylko trochę lepszym. Najczęściej są to zupełnie różne odpowiedzialności. W przypadku zagadnień stricte technicznych obstawiałbym nawet, że często deweloper, admin czy architekt prędzej rozwiąże trudny problem niż CTO. CTO jeśli miewa trudne wyzwania to raczej na poziomie, że tak powiem – biznesowym / zarządczym. Więc musi albo pytać innych CTO, albo zdać się na intuicję. I jako, że każdy biznes jest inny i na swój sposób specyficzny – chyba ta druga opcja jest najlepsza.

Mówi się, że zostając CTO należy zrezygnować z programistycznych ambicji. Naprawdę nie da się połączyć zarządzania z programowaniem?

Połączyć się da. Nawet powiedziałbym, że niejednokrotnie programowanie (nawet na poziomie middle) może w skutecznym zarządzaniu bardzo pomóc. Myślę, że jak najbardziej można być np. bardzo dobrym managerem i jednocześnie dobrym programistą. Ale już być świetnym programistą i jednocześnie świetnym managerem to raczej zestawienie niewykonalne. Im wyższy poziom mamy na myśli, tym większe znaczenie ma fakt, że obie te specjalizacje wymagają trochę innych cech, umiejętności i talentów. Jeśli więc mówimy o naprawdę wysokich ambicjach to prędzej czy później trzeba na jakiegoś konia postawić bardziej niż na pozostałe.

Jaką radę chciałbyś przekazać tym, którzy właśnie dostali propozycję zostania CTO? Na co powinni uważać?

Przede wszystkim muszą dbać o swój zespół – budować i rozwijać go w przemyślany sposób, nie tylko w oparciu o hard skille. Solidne i dobrze funkcjonujące zespoły nie powstają przypadkowo i rzadko złożone są z samych gwiazd i indywidualistów. To bardzo kosztowny proces, ale chyba najważniejszy jeśli chce się mieć technologię i development na wysokim poziomie.

Bartłomiej Tyranowski. Inżynier IT, CTO i wiceprezes zarządu w Picodi.com. Absolwent Informatyki stosowanej na AGH w Krakowie. Zaczynał jako freelancer – tworząc narzędzia i aplikacje w różnych technologiach – głównie PHP i Ruby. Obecnie odpowiada za technologię, rozwój produktu i zarządzanie projektami w Picodi.com SA – polskiej firmie pomagającej oszczędzać pieniądze użytkownikom już w 41 krajach świata.