Wywiady

Decydując się na założenie startupu, przestajesz być tylko programistą. Rozmawiamy z CTO TwójPsycholog

Robert Witkowski przebył drogę od juniora do Lead Software Engineera, by po sześciu latach porzucić etat na rzecz startupu TwójPsycholog, którego jest współzałożycielem. Zapytaliśmy go o to, jak podjął decyzję o tym, by przejść ”na swoje”. Z naszej rozmowy dowiecie się także, o czym za mało mówi się w kontekście pracy w startupie.

Spis treści

Mainstreamowe media mówią, że praca programisty to praca marzeń. W domu, przed komputerem, raczej mało komu kojarzy się ze stresem, zmęczeniem czy frustracją. Jaka jest Twoja perspektywa?

Dużo zależy od tego, jak zdefiniowalibyśmy pojęcie pracy marzeń. Dla jednego będzie to praca przed komputerem z wysokimi zarobkami, a dla kogoś innego praca, w której może podróżować i całymi dniami chodzić boso po dżungli zarabiając przy tym przysłowiowe parę groszy.

Dla mnie praca to pasja, dzięki czemu jest mi zdecydowanie łatwiej. Po prostu lubię to, co robię i naprawdę nie mam na co narzekać. Oczywiście zdarzają się gorsze dni spowodowane nudnymi zadaniami, niepotrzebnymi spotkaniami czy natłokiem obowiązków, ale to zdecydowanie wyjątek od reguły.

Co jest najczęstszą przyczyną zmęczenia czy frustracji w IT?

Nie znajdziemy jednej, konkretnej odpowiedzi. Wszystko zależy od miejsca, w którym aktualnie znajduje się dana osoba. Dla jednych będzie to nierozwojowy projekt z powtarzalnymi zadaniami, dla innych zbyt wygórowane wymagania i oczekiwania, a dla jeszcze innych toksyczna atmosfera/zespół/szef.

Co w podejściu do pracy powinni zmienić programiści, a na co uwagę powinni zwrócić Team Leaderzy, kadra zarządcza?

Programiści powinni przestać skupiać się na używaniu konkretnych technologii i uprawianiu tzw. CV-driven development, a zacząć myśleć przede wszystkim o rozwiązywaniu problemów i dostarczaniu wartości biznesowej. 

Team Leaderzy z kolei powinni skupić się przede wszystkim na codziennym doskonaleniu swojego zespołu: na wsparciu, budowaniu autonomii, pozytywnej atmosfery i środowiska, w którym po prostu chce się pracować. Team Leader nie musi brać na siebie najtrudniejszych technicznych zadań i poświęcać im większości swojego czasu.

Co masz na myśli mówiąc “CV-driven development”?

CV-driven development to takie delikatnie “prześmiewcze” określenie na podejście do tworzenia oprogramowania, w którym nie znając wymagań biznesowych i kontekstu projektu, architekci i programiści już wiedzą, że “będą robić mikroserwisy z wykorzystaniem Quarkusa, eventy będą latały po Kafce, zastosują event sourcing, CQRSa i 15 najnowszych bibliotek utils’owych”. 

Najpopularniejszą definicją jest chyba ta z bloga Martina Jee:

CV Driven Development (CDD) is a software development process which prioritises design and development choices that will enhance the implementing programmer’s Curriculum Vitae over other potential solutions, regardless of how rational that choice is.

Używanie nowoczesnych technologii jest oczywiście fajne i również to lubię. Ale trzeba to robić z głową.

Co z kolei masz na myśli, mówiąc o tym, że programiści powinni myśleć o rozwiązywaniu problemów i dostarczaniu wartości biznesowej? 

Uważam, że my, programiści, mamy tendencje do rozdmuchiwania rozwiązań, niepotrzebnie je komplikując i utrudniając sobie życie. Próbujemy rozwiązywać problemy techniczne, które nie istnieją. Optymalizować rozwiązania pod kątem wydajności nie mając z nią żadnych problemów, działając na 100 razy mniejszej skali niż zakładana we wstępnie definiowanych wymaganiach. Nie stosujemy się do podstawowych, dobrych praktyk budowania oprogramowania – KISS (Keep it simple stupid) oraz YAGNI (You aren’t gonna need it).

W wielu sytuacjach na samym początku naprawdę wystarczy dobrze zaprojektowana monolityczna aplikacja, która niekoniecznie musi składać się z wielu mikroserwisów wystawianych na Kubernetesie komunikujących się asynchronicznie przez Kafkę. Kluczowe jest to, aby aplikacja spełniała postawione przed nią wymagania biznesowe i realizowała cele organizacji.

W poszukiwaniu kolejnej pracy nie ma znaczenia technologia, w której pracowałeś, ale sposób, w jaki rozwiązywałeś problemy? 

Znajomość technologii ma ogromne znaczenie i jest bardzo pomocna w codziennej pracy. Jednak to, jak bardzo zwracamy na nią uwagę w poszukiwaniu nowego miejsca pracy jest zależne od kilku czynników.

Na rynku mamy wiele typów programistów, na przykład “klepaczy”. Biorą oni konkretne zadanie dotyczące nowej funkcjonalności, bardzo dobrze rozpisane przez analityka systemowego i bawią się w tłumaczenie z polskiego na Javę/Pythona przy użyciu swoich pięciu ulubionych technologii. Jak mają się dotknąć czegoś innego (a szczególnie tego, co w firmie nazywają “systemem legacy”) to wpadają w rozpacz. Dla tego typu osób technologia będzie miała kluczowe znaczenie.

Mam wrażenie, że wraz z doświadczeniem u większości z nas opisane wyżej podejście się zmienia. Grzebanie w starych technologiach przestaje być straszne, a staje się ciekawe. Współpraca z biznesem przy określaniu wymagań okazuje się czasem nawet fajniejsza niż kolejny dzień spędzony na debugowaniu problemów z wydajnością relacyjnej bazy danych.

Dla tego typu osób konkretne nazwy technologii wymienione w ogłoszeniu o pracę nie będą miały już tak dużego znaczenia.

Jak na etapie rekrutacji sprawdzić, czy firma, do której aplikuję, po prostu zadba o mnie? O to, że będę pracował w wartościowym zespole? 

To jest niestety bardzo trudne. Na rozmowach firmy często przedstawiają siebie w samych superlatywach, chcąc przekonać kandydata. Dopiero po jakimś czasie wychodzą tematy, które zaczynają irytować i przestaje być tak kolorowo.

Dobrym pomysłem jest prośba o spotkanie z zespołem, w którym docelowo będziemy pracować. Na takie spotkanie kandydat powinien przygotować listę konkretnych pytań i tematów, które go nurtują. Członkowie konkretnego zespołu dużo dokładniej i, moim zdaniem, bardziej szczerze są w stanie opowiedzieć o sytuacji w projekcie/firmie.

O co byś ich zapytał?

Na pewno warto zapytać:

  1. Czy każdy pracownik ma zaplanowaną ścieżkę rozwoju? Jak ona wygląda i kto odpowiada za wsparcie w jej realizacji?
  2. Jak wygląda przykładowy dzień w pracy
  3. Jak wygląda cały proces rozwoju oprogramowania?
  4. Jak dużo procesów jest zautomatyzowanych?
  5. Jak wygląda współpraca z innymi rolami wewnątrz zespołu – z analitykami, testerami, biznesem, Product Owner’ami?
  6. Jak wygląda współpraca z innymi zespołami – czy zespół jest mocno zależy od wielu innych działów, czy jest mocno autonomiczny/samowystarczalny?

Nie wszystkie pytania są stricte związane z tym, czy “firma się mną zaopiekuje”, ale jestem pewny, że pokażą, jak mi się będzie w niej na co dzień pracować.

Firmy, w których pracowałeś znajdowały czas na integrację, poświęcały czas na rozmowy zespołowe, szkolenia dla Team Leaderów? Te elementy nie przynoszą zysku, nie przekładają się na realizację tasków.

Nie zgadzam się z tym, że wymienione inicjatywy nie przekładają się na realizację zadań/celów. Moim zdaniem jest wręcz przeciwnie. Zespół, który jest zgrany, potrafi ze sobą szczerze rozmawiać, a członkowie ufają sobie nawzajem, na co dzień pracuje wydajniej i po prostu lepiej. 

Pracowałem w różnych zespołach – w jednych regularnie wychodziliśmy na wspólne piwko po pracy, a w innych przez pół roku nikt nawet o tym nie wspomniał. Pewnie możesz się już domyśleć, który zespołów był tym wydajniejszym, a mi osobiście pracowało się po prostu fajniej.

Jeżeli chodzi o szkolenia dla Team Leaderów – sam uczestniczyłem w dwóch kilkudniowy szkoleniach tego typu, na których skupialiśmy się tylko i wyłącznie na tematach miękkich – poprawnej komunikacji, kulturze feedbacku, umiejętności rozwiązywania trudnych sytuacji, rozmowach o podwyżkach. 

Myślę, że jest to bardzo potrzebne i każda osoba, która chce iść w stronę ścieżki liderskiej (a nie eksperckiej), powinna przejść przez tego typu szkolenie.

Skupmy się na Twojej ścieżce kariery. Dwa lata temu odszedłeś z etatu w Altkom Software, by rozwijać swój startup – TwójPsycholog. Opowiedz o procesie podejmowania decyzji. Dlaczego z Altkomu odszedłeś dwa lata temu, a nie wcześniej/później?

Proces był długi i wymagał wielu przemyśleń. W Altkomie spędziłem 6 lat, to tam rozpoczynałem pracę jako programista, przechodząc drogę od juniora bez doświadczenia do lidera technicznego ze swoim kilkuosobowym zespołem. Miałem naprawdę super ludzi obok siebie, bardzo ciekawe wyzwania, a dodatkowo zarabiałem dobre pieniądze. 

Pójście “na swoje” wiązało się z obniżeniem wynagrodzenia, utratą “ciepłej posady” oraz założeniem JDG (jednoosobowej działalności gospodarczej). Biorąc pod uwagę dodatkowo to, że w życiu prywatnym byliśmy z narzeczoną (teraz już żoną) w trakcie załatwiania kredytu hipotecznego – nie było łatwo.

Przymierzałem się do tego dobrych parę miesięcy. Odszedłem w maju, a firma wiedziała o moich planach już w styczniu. Chciałem być na maxa “fair”, domknąć swoje tematy i  przekazać wiedzę. Załatwienie tematów z obecnym pracodawcą to był jednak tylko jeden obszar.

Drugim było upewnienie się, czy nasz startup na pewno na to stać i czy moja pensja to będą odpowiednio wydane pieniądze. TwójPsycholog nie był finansowany przez VC, więc nie mieliśmy kilku milionów na koncie na inwestycje. W momencie mojego przejścia na pełen etat pozyskaliśmy kilkaset tysięcy złotych od aniołów biznesu i to była ta baza, która miała zapewnić możliwość rozwoju firmy i wypłaty wynagrodzeń współzałożycielom przez kilka miesięcy. 

Jakiego rzędu jest to inwestycja czasowa?

Pracujesz ile starczy Ci sił. Na początku rozwoju firmy pracowałem 8 godzin dziennie na etacie, a praktycznie drugie 8 godzin tworzyłem TwójPsycholog. Jeśli nie ogarnąłem czegoś w tygodniu, siedziałem w weekend. Na każdy wyjazd (czy to urlop, czy wyjazd na weekend do rodziców) – brałem ze sobą komputer, żeby przeczytać maile z ogólnej skrzynki, naprawić buga czy zrobić przynajmniej jakąś małą nową funkcjonalność. 

To nie jest zdrowe podejście na dłuższą metę. Jestem zdania, że można tak działać przez jakiś czas, jeśli mocno wierzymy w sukces i nam zależy. Pomimo tego, że naprawdę mogę nazwać siebie pasjonatem i bardzo lubię pracę programisty to uwierzcie mi, że nikomu na dobre nie wychodzi siedzenie po 16 godzin dziennie przed komputerem. 

A pod kątem finansów? Jakiego rzędu to inwestycja?

Inwestycja finansowa zależy od konkretnej sytuacji. W naszym przypadku jeden ze współzałożycieli udzielił startupowi pożyczki w wysokości kilkudziesięciu tysięcy złotych – to były pieniądze na start (opłacenie księgowości, prawników, serwerów, narzędzi), które wystarczyły do momentu pozyskania dodatkowych inwestorów zewnętrznych (aniołów biznesu).

Dlatego jeśli chce się zrezygnować z pracy na etacie i poświęcić się w pełni rozwojowi swojego startupu, trzeba mieć przygotowaną solidną poduszkę finansową. Nie liczyłbym na to, że po miesiącu od startu firma będzie zarabiać tyle, że starczy na (porównywalną z etatową) pensję dla założycieli – a jeśli to się uda tzn., że jesteś kozakiem i idź w jej rozwój na 200%.

Inaczej sprawy się mają, gdy firma pozyskuje na wstępnym etapie (np. na etapie posiadania ładnej prezentacji w PowerPoincie) inwestora i kilka milionów na rozwój. Wtedy pensje dla founderów mogą być zagwarantowane już na etapie umowy inwestycyjnej i jest na pewno trochę spokojniej pod kątem finansowym. Jednak niech nikt nie liczy na to, że ta zagwarantowana pensja to będą górne rynkowe widełki danego stanowiska.

Czego programistę uczy praca nad własnym startupem?

Wszystko zależy od tego, jak wygląda podział obowiązków między co-founderami. Nauczyłem się bardzo dużo z obszarów zdecydowanie bardziej biznesowych niż samo programowanie. Budowanie produktu, kontakt z klientami/funduszami, sprzedaż, strategia, finanse – mnóstwo tematów, o których wcześniej nie miałem zielonego pojęcia.

O czym za mało mówi się w kontekście pracy nad startupem?

Budowanie startupu to nie zabawa dla osób, które chcą popracować bez stresu przez 8 godzin dziennie, a następnie zamknąć komputer i nie myśleć o pracy. Jeśli komuś się to udało bez “turbo-doładowania” od rodziców czy bogatego wujka – chapeau bas! Moim zdaniem jest to nierealne na początkowym etapie rozwoju spółki. 

Uważam, że takie podejście “jak na etacie w korpo” jest możliwe po osiągnięciu pewnego etapu dojrzałości spółki, czy to w kontekście rozwoju samego produktu, czy break event point’u w kontekście finansowym.

Co skłoniło Cię do pracy nad własnym startupem? 

Przekonał mnie pomysł na produkt i człowiek, który mi go przedstawił. Oczywiście myśl o tym, że “stworzymy polskiego jednorożca i za 5 lat będę miał miliony dolarów na koncie” również działała motywującą.

To etap rozwoju każdego programisty?

Na pewno to nie jest etap rozwoju każdego programisty. Budowanie własnego biznesu to naprawdę ciężki temat, który wymaga poświęceń i wchodzenia w “nieswoje buty”. Decydując się na założenie startupu, przestajesz być tylko programistą odpowiedzialnym za kwestie techniczne, a stajesz się współzałożycielem firmy (najczęściej spółki), przedsiębiorcą. Trzeba odpowiedzieć sobie na pytanie, czy na pewno tego chcemy i jesteśmy na to gotowi.


Robert Witkowski. Programista i Architekt Rozwiązań lubiący wyzwania, nowe technologie i dobrze zaprojektowane rozwiązania. Prywatnie świeżo upieczony tata, współzałożyciel i CTO startupu TwójPsycholog.pl.

Redaktor naczelny w Just Geek IT

Od pięciu lat rozwija jeden z największych polskich portali contentowych dot. branży IT. Jest autorem formatu devdebat, w którym zderza opinie kilku ekspertów na temat wybranego zagadnienia. Od 10 lat pracuje zdalnie.

Podobne artykuły

[wpdevart_facebook_comment curent_url="https://justjoin.it/blog/programista-w-startupie-twojpsycholog" order_type="social" width="100%" count_of_comments="8" ]