Episode #22: Budujemy Software House

Tak.

Dzień dobry.

Bardzo dobrze.

Tak zakładam przynajmniej ze swojej strony Marek dołączył do nas.

Słuchajcie z Twitterem znów się udało, bo tak patrząc na te ostatnie błędy to można powiedzieć, że aplikacja Schrodingera, w której rzeczy w połowie działają, a w połowie nie.

Błędy jak błędy, rachunki za API.

A tak, to świeże ogłoszenie.

No dokładnie.

Dzisiaj widziałem.

Cześć.

Cześć Marku, cześć Marku.

Czy mnie słychać?

Czy mnie dobrze słychać?

Tylko zapytam szybko.

Tak, bardzo dobrze.

Dzisiaj widziałem wycenę użycia API Twittera, jaką dostała jedna aplikacja według nowego cennika. 684 tysiące rocznie, coś takiego w dolarach.

Całkiem nowy biznes model.

Jeszcze już nie, trzeba zarabiać.

Oczywiście, myślę, że tak, rynek się tam jakoś ogarnie.

Dzisiaj dostaniemy algorytm także, podobno, o w południe.

A ten oficjalny, czy ten co wyciekł?

Ten co wyciekł to już podobno gdzieś tam mamy, nawet po sieci krąży, ale ten oficjalny ma być, także co z tego, że wyciekło, skoro moją wysłałeś?

Aczkolwiek tu kwestia jest taka, że chyba to wyciekło trochę więcej.

Nie mamy Wojtka, a już mamy Wojtka.

Dobrze, wrzucam Wojtka do nas.

Słuchajcie, w międzyczasie dużo osób dołącza, bardzo fajnie.

To ja może przypomnę jakieś nasze podstawowe ground rules.

Więc tak, witajcie wszyscy na Citio Morning Coffee.

To są nasze cykliczne spotkania, raz na dwa tygodnie spotykamy się, żeby porozmawiać o tematach istotnych dla tak zwanych senior technical leaders i oczywiście osób aspirujących.

Dzisiaj już 31 odcinek leci bardzo szybko.

Dzisiaj porozmawiamy sobie o software house'ach.

Rozmawialiśmy już swego czasu o firmach produktowych, rozmawialiśmy o konsultingu.

Dziś porozmawiajmy o software house'ach.

Mamy dzisiaj gościa specjalnego, czasami robimy odcinki właśnie z gośćmi, no bo jak rozmawiać o software house'ach, to może właśnie na przykład z kimś, kto takie software house'y dwa założył.

Jeden z tego, co pamiętam, prowadził jako VP of Engineering, też miał dużą cegiełkę, którą włożył ogólnie do rozmawiania o tym, czym jest engineering culture, zdrowe engineering culture w Polsce.

Ja osobiście pamiętam bardzo fajną prezentację, to już było chyba z 10 lat temu na Engine by Example, tak, chodziłem na tego typu konferencje i tam właśnie Marek po raz pierwszy chyba po polsku opowiadał o tym, jak się taki engineering culture buduje, więc w związku z tym witamy właśnie Marka Kierojczyka, który dzisiaj z nami zgodził się nam trochę poopowiadać, podzielić się z nami swoimi doświadczeniami.

Jeszcze, bo pewnie zapomnę, jeżeli będziecie mieli pewien niedosyt, to Marek swego czasu napisał szereg bardzo fajnych artykułów właśnie ze swoimi kurcze memoirami właśnie na temat tego jak się taki software house buduje.

To było 5 artykułów i uważam, że są top notch i warto się z tym zapoznać.

Wkleimy na pewno na Twitterze gdzieś tam pod naszymi profilami w linkach.

Witamy cię Marku.

Cześć, cześć, bardzo miło mi to dzisiaj z wami być i dziękuję za ciepłe słowa, dziękuję za zaproszenie no i już nie mogę się doczekać, że zaczniemy rozmawiać o software house.

Awesome, awesome.

Znaczy ten nie jest dla nas taki ciepły w kuluarach, więc wiesz, dlatego.

Dobrze, słuchajcie, tak, my tu będziemy tą naszą rozmowę moderować, natomiast każdy może też zadać swoje pytanie, więc po prostu podnoście łapki, korzystając z funkcjonalności Twittera.

My możemy nie zauważyć od razu, więc nie zrażajcie się i co ważne, nie możecie tego robić w aplikacji webowej, tylko i wyłącznie mobilnej, więc o tym proszę pamiętajcie.

I to chyba tak naprawdę wszystko.

To co, może jakieś pytania na rozgrzewkę?

Wojtek, co masz fajnego?

Słuchajcie, pierwsze i najważniejsze chyba pytanie.

Ja mam doświadczenie głównie i tylko i wyłącznie w firmach produktowych, więc mnie strasznie interesuje od razu na dzień dobry, czym się różni według was prowadzenie firmy typu software house od firmy produktowej z punktu widzenia firmy software house?

Więc osoby, które, Marku, szczególnie ciebie i ewentualnie ktoś, kto ma jeszcze doświadczenia, zapraszam do dyskusji i opowiedzcie o tym.

No tak, to jest takie w sumie dość częste porównanie, które miałem okazję, z którym miałem okazję się spotkać i faktycznie, jak gdyby z jednej strony jest bardzo podobnie, a z drugiej strony jest bardzo inaczej.

Wydaje mi się nawet może, że prowadzenie trochę software house może jest prostsze niż firmy produktowej, bo jak gdyby jest troszeczkę mniej aspektów, którymi trzeba się zająć.

Na przykład cała ta część taka produktowa, często, często przerzucamy ją na klienta.

Chociaż też ta granica, jak gdyby jest dosyć płynna, bo często okazuje się, że software house, jakoś tam próbując zdefiniować tą swoją usługę i być konkurencyjne, poszerzają tą swoją usługę także aspekty produktowe.

No i to jest taka śmieszna dychotomia może, czy trudno, jak gdyby, trudno znaleźć tą jasną granicę, bo powstaje takie pytanie, no dobrze, ale skoro ten software house jest taki dobry w robieniu produktów, to czemu miałby pracować dla klienta, jak gdyby, a nie sam umógł budować sukcesu produkty.

Dlatego, dlatego mi się wydaje osobiście, że jeżeli chce się zbudować takiej wysokiej jakości software house, to jednak fokus powinien być na technologię i tą wartość, którą się dowodzi, dowodzi to jest po prostu, ma się wysoko wyspecjalizowany team, który jest absolutnie fantastyczny w dowożeniu, w tworzeniu technologii i po prostu wtedy, kiedy jest, kiedy mamy tych naszych klientów, czy to jest rynek enterprise'owy, czy taki bardziej start upowy, bitumbyński, lapowy, no to kiedy te firmy potrzebują szybko coś zrobić, brakuje im sił przerobowych, to, to, to idą do software house'u i też to jest, jak gdyby ten model się zmienił, tak, bo to może brzmieć, o to my dostajemy te, jak gdyby, najgorsze projekty w tych software house'ach, bo to jakieś takie odpady, które nie ma czasu, no ale po prostu ten świat jest bardziej dynamiczny niż kiedykolwiek.

Start upy zbierają tam rundę A, B, C, no i potrzebują się zeskalować, tak, mają nagle bardzo dużo pieniędzy, potrzebują bardzo szybko je wydać, zbudować, powiększyć, urosnąć i, no i tak naprawdę takie, takie partnershipy, bo często to są wieloletnie projekty, no to często potrafią być bardzo atrakcyjne projekty, które, które rozwijają się latami, no ale jak gdyby gdzieś ten software house mityguje to ryzyko, że no nie dojedzie ten, ten, ten start up do następnej rundy i wtedy ten software house musi się martwić o to, żeby znaleźć następnego klienta, a nie jak gdyby ten start up musi się martwić o to, że musi zwolnić dużą część tych.

Mam od razu pytanie do tego, co powiedziałeś, Marku, bo powiedziałeś, że tak jakby przesuwacie całą część produktową na klienta.

Co masz przez to na myśli, czyli co, co według ciebie dobrze, żeby było u klienta, jeżeli chodzi o ten produkt, a co właśnie byś zostawił dla software house'u?

No to jest fantastyczne pytanie, bo teraz jak gdyby myślę, że warto jeszcze dodefiniować jedną rzecz.

Ja się specjalizuję w rynku takim powiedzmy start upowym, B2B takie small business, mid business, jakiś nawet taki może być teraz scale up, czyli, czyli, czyli firmy po rundzie A, po rundzie B, po rundzie C.

I no i oni często mają jak gdyby już swój team produktowy, tak, mają jakiś produkt ownerów, mają jakieś koncepcje, mają designerów, może niewystarczająco, może chcą wziąć od nas designera, ale jak gdyby mają już jakiś tam skillset i umiejętność pracy z produktem, tak.

To jest jeden rynek.

Drugi rynek to jest Enterprise, o którym teraz jak gdyby nie będę mówił, na którym jest też dużo bardzo successful software house'ów i tam oni często właśnie próbują wziąć więcej tego produktu.

Natomiast w tym moim doświadczeniu na tym rynku takim mniejszym, gdzie często pracuje się bezpośrednio z founderami w ogóle albo z kimś kto, kto jest gdzieś wysoko, ma jakąś wysoką pozycję w tej firmie, to oni często jak gdyby wiedzą co chcą zrobić, tak.

Może wiedzą dobrze, może to będzie sukcesem, co zbudują, może nie, ale jak gdyby przychodzą, mają swoją wizję, wiedzą mniej więcej co jest z MVP, wiedzą mniej więcej gdzie chcą to rozwijać i tak dalej.

Więc jak gdyby ta część taka product ownership stricte często, często po prostu odpada i ten klient tego nie chce, tak.

Ja wiem co chcę zbudować, ja przyjdę, mam dla was nie wiem, dwie, trzy godziny w tygodniu, wytłumaczę wam tak i jak gdyby budujcie, nie.

Natomiast, natomiast to jest jak gdyby moim zdaniem gwiazdka i to jest coś co myślę, że bardzo wiele software house'ów przegapia.

My powinniśmy mieć produkt, my powinniśmy mieć proces software house'y gotowy do pracy z produktem, tak.

Czyli my powinniśmy mieć szybkie iteracje, continuous delivery, umiejętność robienia testów, umiejętność szybkiego dowożenia na produkcję, umiejętność sprawdzenia czegoś, tak, zmierzenia na produkcję czy coś działa, czy nie działa i tak dalej, tak.

I to jest część skifsetu i know-how software house'ów, który często można dać w prezencie, jest częścią tego serwisu, tej usługi, która daje się startupom, które teoretycznie powinny mieć to dużo lepiej niż my zrobione, no ale w praktyce często nie mają, no bo biegną do następnej rundy, tu trzeba coś dowieźć, ktoś pracuje po nocy, tak.

Nie ma jak gdyby tej kultury inżynieryjnej, nie ma czasu zbudować tej kultury inżynieryjnej biegnąc od rundy do rundy, tak.

I to jest jak gdyby ogromna część, moim zdaniem, tej wartości, którą software house może dowodzić, a dzisiaj często jeszcze nie dowodzi.

Więc to jest...

Dobrze, to trochę pociągnę ten temat, nie, ale bo jeżeli przekazujecie, wy wchodzicie z technologią jako software house, tak będę mówił, weźmij to, że tam chcę was odpychać, nie, a produkt jest po stronie klienta, to gdzie jest odpowiedzialność wtedy za dowiezienie tego, to znaczy na ile wy jako software house bierzecie odpowiedzialność za to, że ten projekt się wydarzy albo się nie wydarzy, czy produkt?

No tutaj tak jak troszeczkę w firmie produktowej, tak samo jak byś miał w firmie produktowej, tak, jest jak gdyby ktoś w produkcie jest tym inżynieryjny, jest jakiś podział i powstaje pytanie, kto odpowiada za sukces tego, tak, no i to się przyjęło i to jest jak gdyby niekończący się zawsze problem, że jedni dowożą, a drudzy nie dowożą, tak, że inżynieria dowozi, jeździ, działa na produkcji, tak, no ale to nie jest coś, co klienci chcą, tam nie było wystarczająco, nie wiem, rozmów z klientami, danych zebranych z produkcji i tak dalej, tak, no a z drugiej strony może być super product owner oczywiście, który doskonale wie co zrobić, doskonale jak gdyby zna swoich klientów, wie czego oni potrzebują, no ale team nie dowozi technicznie, tak, no więc tutaj jak gdyby oczywiście dochodzi pewna komplikacja, jeśli no te dwie części są w dwóch różnych firmach, no ale z drugiej strony dla klienta to też jest super, bo jak nie dowozi, no to po prostu się zmienia firma, tak, i nie ma jak gdyby, jak gdyby cały czas jesteśmy na tym rynku, cały czas musimy konkurować, cały czas musimy temu klientowi dowozić wartość, bo jak nie dowozimy, no to on przychodzi i mówi jestem niezadowolony, tak, gdzie i może poprosić o zmianę, gdzie no to takie coś, gdzie się w firmie pełne powiązań i jakieś tam ograniczeń rekrutacyjnych i tak dalej, jest po prostu trudne.

Dobrze, wiesz co, ja trochę pytam, bo my tam nie rozmawialiśmy, ja mam background w usługach też, tak, prowadziłem firmę usługową dalej, prowadzę jakoś i mam jedno pytanie do Ciebie, a na ile zdarzyło Wam się, albo czy miałeś takie sytuacje i czy w to wszedłeś, albo nie wszedłeś, albo ich nie było, że klient powiedział że chce powiązać Wasz sukces ze swoim, czyli nie jesteś tylko dostarczoną technologii, nie, tylko mówili słuchajcie, jak nam wyjdzie, to nagroda jest większa, ale potrzebujemy, żebyście w tej chwili zainwestowali jako, bo my chcemy tutaj, wiesz long partnership, we bring you so much money, but in the future No tak, to są sytuacje, które się zdarzają szczególnie w świecie blockchainowym, w którym myśmy siedzieli gdzie no po prostu to jest dużo łatwiejsze, bo można się podzielić tym tokenem, nie ma takiego całego, nie ma takiego całego poziomu skomplikowania w związku z wystęgami, umowami, opcjami i papierkologią, która jest jeszcze dodatkowo bardziej skomplikowana, jak ten klient jest na przykład z Doliny Krzemowej, a Ty jesteś tutaj w Polsce więc jeszcze dwie jurysdykcje prawne wchodzą No więc ja ogólnie troszeczkę zdarzały się takie deal'e i to jak gdyby zarówno wtedy te tokeny dostawała firma i dostawały osoby zaangażowane w projekt i to nie były, nikt nie został milionerem ale to były momentami przyjemne premie w zależności co kiedy te tokeny sprzedał jeszcze i no i ja troszeczkę Bardziej chodziło o to, wiesz, nawet niż o same rozliczenia tokeny i tak dalej, to bardziej chodziło o ten model, bo faktycznie jest tak, że wiesz, Software House postrzegany jest jako model, który w którym Ty nie masz ryzyka, bo po prostu dostarczasz technologię Tak, tak, ja uważam, że to jest dobre, tak?

Jest jak gdyby wiele takiego, na rynku można usłyszeć no, że nie powinieneś pracować z Software House'em, bo oni mogą czy tam jest kwestia vendor lockingu, czy jest kwestia właśnie tego, że oni nie są zmotywowani ale właśnie czasami jest tak, myślę, w firmach produktowych, że po prostu potrzebujesz mieć dowiezione i niekoniecznie ten input taki produktowy, że każdy patrzy i myśli, niekoniecznie to jest takie aż wartościowe jak się o tym mówi, tak?

Znaczy na pewno jest ten aspekt i nie neguję tego, że tutaj jak jest team i on cały myśli produktowo to jak gdyby jest większa szansa na sukces, ale też jak gdyby rzeczywistość jest taka, że często start upy failują, bo po prostu nie dowożą, tak?

W sensie technologicznym, nie, że pomysł jest zły czy jakiś taki po prostu jest problem z egzekucją na poziomie produktu, tylko po prostu trzeba dowieść i to jak gdyby complexity rośnie w miarę im większa jest firma, tak?

W sensie jak masz MVP, no to musisz zbudować ten MVP, tak?

Ale później jak jesteś już scale up'em to masz 7 podprojektów i często jest jakiś, nie wiem, nowy projekt, który jest mało produktowy, a który jest jednak bardzo kluczowy dla tego, żeby cała reszta działała i wtedy to jest bardzo naturalny fit właśnie między firmą produktową a software house'em.

Wspomniałeś trochę na temat właśnie tego, że w software house'ie można zbudować jakąś tą kulturę inżynieryjną ciekawszą, natomiast ja się zastanawiam nad tym, czy pracowanie w software house'ie, czy budowanie software house'u nie rodzi pewnego rodzaju dysfunkcji.

Już mówię o co chodzi.

Po pierwsze właśnie ten podział między sukcesem biznesowym a technicznym.

Że wy tak naprawdę macie sukces techniczny, w sensie tak powiedziałeś, no macie dowieść, ma, jest jakiś tam scope, lepiej i gorzej jest sprecyzowany, ryzyko przerzucone na jedną, drugą firmę, no i wy się macie skupić na tym, żeby można powiedzieć, odfajkować, że pewne rzeczy się wydarzyły, no i jak już kod został napisany, to w sumie czy to miało sens, czy to nie miało sensu, no to sukces techniczny został osiągnięty.

To jest jedna taka, nie wiem, patologia czy dysfunkcja, która tutaj przychodzi mi do głowy, a druga jest jakby związana właśnie z tym, że robiąc tego typu projekty i koncentrując się na tej takiej stronie technicznej, tak naprawdę nie ma tego takiego typowego feedback'u, że ok, zrobiliśmy fajny produkt, zarobiliśmy na siebie, w związku z tym mamy pewnego rodzaju długo żyjącą ciągłość, mamy ten space for self-improvement, nie, mamy reset.

Już kolejny projekt, znowu zaczynamy od zera i nawet niekoniecznie uczymy się na podstawie tego, co zrobiliśmy, bo to już się skończyło.

Tamten projekt trwał trzy miesiące, wyrzuciliśmy to do klienta, a my już jesteśmy zupełnie gdzie indziej i budujemy to znowu od zera.

Więc, puentując to moje pytanie, czy tak naprawdę to nie jest tak, że praca w Soft House'ie wręcz utrudnia budowanie takiego healthy engineering culture w organizacji?

No tutaj widzę dwa, jak gdyby różne aspekty.

Jeden, może od niego zacznę, tylko oba jak gdyby wymienię na początek.

Jeden, że uważam, że Soft House jest absolutnie miejscem, gdzie engineering culture można zbudować lepsze niż w startupie i zaraz powiem dlaczego, ale drugie jest takie, że jak gdyby ja dużo tego widzę na tym rynku, w ogóle jak świat funkcjonuje, ale w szczególności w naszej tutaj branży programistycznej, że są takie dychotomie, że w lewo albo w prawo, że albo produkt, albo usługa.

A tak naprawdę te granice są płynne i takie stawianie rzeczy, że o, bo my tutaj odcinamy ten sukces czy coś takiego, no mogę pracować w firmie produktowej i jak gdyby nie mieć udziału w sukcesie, tylko mieć jakąś tam pensję i zmienić tą pracę po dwóch latach.

To jak gdyby jest taki jakiś success story gdzieś po prostu w naszej głowie, przynajmniej w mojej głowie, to jest to, co ja słyszę, jak ty zadajesz tu pytania o dysfunkcję, to jest jak gdyby, no bo jak jesteś tym deweloperem z Silicon Valley, prawda, i tam nie wiem, dołączasz do nich, stajesz w startupu i dostajesz nie wiem, tam ćwierć czy pół procenta po prostu w tej firmie i ta firma kiedy zostaje unicornem, jeśli okazujesz, że te twoje pół procenta jest warte po prostu 10 milionów dolarów i ty stajesz się milionerem i tak dalej, tak?

No tak, ale to jest bardzo rzadka historia, tak?

To się zdarza bardzo, bardzo rzadko, tak?

A realia są takie, że nawet jak ktoś zostaje milionerem, to z reguły tam, prawda, milion czy dwa miliony dolarów zarobi, tak?

Więc to jest jak gdyby, to jest jak gdyby taki to jest tak jak jest, wiecie, że ludzie grają na loterii, tak?

Bo oni co tydzień oglądają losowanie lotka i tam ktoś wygrywa miliony, tak?

Ale jakby oni oglądali później po każdym wygranej trzy miesiące tych wszystkich ludzi, którzy kupili i przegrali, no to nikt by nie grał w lotka, tak?

Po prostu jest rozkład prawdopodobieństwa rzeczywisty, a jak gdyby w naszych głowach jest niekoniecznie niekoniecznie są to same.

Ja mam poczucie, Marek, że cię strasznie zbombardowaliśmy pytaniami, tak że chciałem tylko wszystkim przypomnieć, że zapraszamy też do dołączenia do nas i zadania Markowi pytań.

Bardzo przepraszam, bo chyba ci we wszedłem słowo, myślałem, że skończyłeś.

Tak, nie, nie, to kończy nam się ten pierwszy temat, znaczy ten drugi temat właściwie, tak?

Więc to są jak gdyby w ogóle bardzo fajne i uczciwe pytania, natomiast i w ogóle fajnie, że je zadajecie, bo to są właśnie takie różne mity, mam wrażenie, które funkcjonują na rynku, a niekoniecznie gdzieś tam pod spodem jest głębsze rozumienie tych trade-offów, jak one dokładnie wyglądają w szczegółach.

I też jest aspekt budowania firmy inżynieryjnej, myślę, że są dwa takie aspekty, na które warto spojrzeć.

Jeden to jest taki ja z punktu widzenia pracownika, co ja dostaję, jak pracuję dla Software House'u czy produktu, a drugi to jest all over, co taka firma może osiągnąć i jaki ma wkład w ekosystem.

No i ja jestem wielkim fanem zatrudniania młodych, utalentowanych ludzi do Software House'ów i w ogóle, dlatego że jak się włoży młodych, utalentowanych, zmotywowanych ludzi w fajne środowisko, to oni się bardzo szybko rozwijają.

I to, co widziałem bardzo wiele razy w swojej karierze, to jest, że zespoły technologii, to nie jest zasada, broń Boże, i to też nie była zasada po prostu jak ja pracowałem, ale bardzo wiele razy w firmach, w których ja pracowałem, ale bardzo wiele razy widziałem, że goście prosto po studiach, przeszkoleni, którzy dopiero się dostali do nas do firmy, zostali przeszkoleni, już w pierwszym tygodniu pracy z klientem przewyższali możliwości odwożenia, rozumienia jakiegoś tam skomplikowania technologicznego, przewyższali tak zwanych senior developerów po stronie klienta.

I to jest ogromna wartość, którą można dać pracownikom.

To jest po prostu rozpoczęcie kariery w takim środowisku, w którym można bardzo szybko rosnąć.

I te różne wady, o których mówiłeś, na przykład, no, jak zaczynamy nowy projekt, no to z punktu widzenia takiego młodego człowieka, który się uczy kultury inżynierii, innej inżynierii, oprogramowania i tak dalej, no to to jest wartość, tak?

Bo ja zaczynam nowy projekt i teraz jak gdyby nauczyłem się kupę na starym projekcie, ale w miarę jak projekt tam idzie, to już coraz mniejsze można na nim nauczyć, już się robi coraz bardziej powtarzalny.

Zaczynamy nowy projekt, tam zaczynałem jako junior, tu już zaczynam jako mid, już mam większą odpowiedzialność, już konfiguruję trochę środowisko, tam mnie wkurza konfiguracja z jaja, tu zrobimy to lepiej, tam już ten framework do testów się zestarzał, to tu użyjemy już nowszego, tak?

Więc to jest jak gdyby bardzo fajny moment, gdzie można odzyskać wysokie tam pouczenia się.

No dobra.

To co powiedziałaś, to prawda.

Niektórzy używają tego do stworzenia takiej patologii pod tytułem to przyjdź do nas tam za 1 PLN, ale dużo się nauczysz, nie?

No, ale to jest kompletnie inny temat.

Słuchajcie, zadawajcie pytania, bo macie okazję przypytać człowieka, który stworzył dwa firmy i chyba nawet je sprzedał.

Marek, to pytanie o to stworzenie.

To jak się tworzy taki software house, czyli jak zacząć?

Od czego zacząć?

Czym się wyróżnić?

Wiesz, software house na rynku jest nie powiem ze 40, bo ich jest więcej, nie?

Ale okej, to zrobiłeś to dwa razy.

Jak zacząć, jak się wyróżnić?

Jak zacząć szukać klientów?

Od czego zacząć w zasadzie?

Kogo zaprosić?

Chyba tak możemy, Tomek, jeszcze dodać.

Kogo zaprosić na sam początek do tej przygody i jak zdobyć pierwszego klienta i zaufania?

No właśnie.

No.

Znowu, tutaj jest jak gdyby wiele aspektów, które się wszystkie łączą ze sobą.

Na pewno mam takie poczucie, że jest za dużo generycznych software house'ów webowych, mobilnych, webowo-mobilnych.

I tego, by the way, na Klaczu, który jest takim katalogiem software house'ów, do którego można się zgłosić samemu, no to jest tam dobrze ponad 1000 software house'ów w Polsce.

W samej kategorii web ostatnio jak sprawdzałem było ponad 800.

No więc na pewno moim zdaniem nie ma sensu otwierać, nie ma sensu otwierać kolejnego webowego software house'u.

No i trzeba sobie jeszcze zadać pytanie.

Jak jestem takim młodym człowiekiem, który ambitnym, który chce zrobić coś fajnego, to jak ja mogę zaoferować wartość klientowi, który nie może zaoferować te 1000 innych software house'ów?

I odpowiedź przebażnie i to jest to jak ja sobie odpowiadam na to pytanie, to nie jest jedyna słuszna odpowiedź na to pytanie, ale ja odpowiadam sobie, by specjalizuj się w technologii, która się dopiero zaczyna.

Technologie przechodzą cykle, mają swoje wiosny, lato, jesień i później lądują na cmentarzu technologii.

I duże software house'y nie będą za bardzo chętnie inwestować w nowe niesprawdzone technologie.

Jeżeli ja mam software house'y 50, 100, 150 osobowe, to ja myślę jak z tego zrobić 2x i nie myślę o technologii, która pozwoli mi zatrudnić 3, 7 nowych osób.

Myślę o technologii, która pozwoli mi zatrudnić 50, 100, 200 nowych osób.

I to jest ta szansa dla tych małych developerów, dla tych osób, które chcą zacząć, najlepszy sposób, żeby zacząć software house to zacząć od jakiegoś małego freelancu, żeby wejść w te technologie, które dopiero się zaczynają, które może są zbyt ryzykowne, może rynek jest jeszcze zbyt mały, jeszcze nie wiadomo jak jakby podłączyć się pod ten rynek i zacząć klepać jakieś tutaj drobne projekty.

To może być od projektu po godzinach, tak troszeczkę at work'a zacząłem, że zrobiłem projekt po godzinach jakiejś nowej, dziwnej technologii, o której ktoś losował, po prostu wylosowałem los na loterii i ktoś powiedział, że ma taki projekt do zrobienia w jakimś dziwnym eterium.

Zacząłem to klikać i jak zobaczyłem o co chodzi, wyekstraktowałem libkę i pojechałem na konferencję i w zasadzie na tą jedną libkę już udało mi się zdobyć pierwszego klienta.

I w tej historii jest jak gdyby bardzo dużo takich ważnych elementów, żeby publikować, żeby produkować coś co jest publiczne, czy to jest open source, czy to są blog posty na ten temat żeby budować już ten marketing od tych pierwszych dni pracy.

I tak, chyba Tomek chciał zacząć.

Tak, chcę Ciebie zadać pytanie, bo trochę mam też swoje doświadczenie, obserwacje rynku, a twoja osobista historia bo wiesz, są historie jak powstały firmy, nie?

My też mamy historię jak powstała firma na stronie, można ją przeczytać nawet jest prawdziwa.

Ale jest dużo takich, które są stworzone, a potem jak podrążysz to one wyglądają inaczej, więc to jest pytanie, obudziłeś się rano i miałeś, trochę odpowiedziałeś na nie, obudziłeś się rano, miałeś nad głową piłeczkę jak z pomysłowego Dobromira i dołożył software house, czy po prostu zrobiłeś to i zobaczyłeś, że działa i mówisz, o kurde, może da się zarobić pieniądze, pojadę dalej.

No wiesz jak gdyby to był taki okres, że szukałem czegoś nowego dla siebie trafił się akurat ten projekt po godzinach, gdybym pewnie nie szukał czegoś nowego to no to bym nie wziął tego projektu po godzinach i jak gdyby długo myślałem o produkcie jakimś do zrobienia, właśnie dookoła Ethereum no ale tam było dużo komplikacji, były tokeny, były te sprzedaże ICO, była niejasna taka sytuacja prawna dookoła tych ICO i nie było jasne czy to jest legalne, czy się później nie siedzi w więzieniu jak się zrobi takie ICO, tak?

No jak gdyby dostęp do VC nie był taki jak jest dzisiaj, więc jak gdyby wyszło mi, że ok, no to zróbmy software house, tak?

To też było już potem jak jeden software house sprzedałem, więc wydawało się jakimś takim naturalnym przedłużeniem po prostu tej mojej kariery więc potem wygląda historia zupełnie nieromantyczna Tak, ja po prostu spytałem się, bo wiem ile jest historii romantycznych na rynku Karol!

A ile jest prawdziwych?

Karol dołączył z pytaniem Tak, Karol.

Cześć, słuchajcie, ja mam takie pytanie, bo Marek to co mówisz przez ostatni czas, jakby jeżeli chodzi o technologię i znalezienie tej technologii dwa razy wydajniejszej jest spoko podejściem, tylko pytanie czy jakby to co działało przez ostatnie 10 lat będzie działało przez kolejne 10 lat i czy kojarzysz takie podejście jak product led i właśnie wyjście większe w kierunku samego produktu z zespołem inżynieryjnym tak, żeby on miał kontekst a nie skupiał się tylko i wyłącznie na technologii.

Co sądzisz o tym trendzie w wytwarzaniu oprogramowania?

No jak gdyby ten trend jest, ja się osobiście nie wpisuję w ten trend i myślę, że wszystko jest ok z tym trendem w sensie to nie jest tak, że to co ja robię to jest jedyny sposób żeby robić rzeczy i tak się powinno robić rzeczy zależy jaki też masz ten team founderski moim zdaniem, bo jeżeli masz team founderski w którym masz kogoś od produktu i kogoś od technologii no to to jest dream team żeby zbudować taki software house z taką usługą produktową.

Ja osobiście mam background inżynieryjny kocham inżynierię, kocham programowanie, kocham zarządzanie zespołami kocham budowanie kultury i często jak się rozmawia z founderami firm no to na koniec te wybory są lifestyle'owe ja lubię to i chciałbym robić to, ktoś lubi mieć taką firmę ma taką firmę, ktoś chce mieć stoosobową to próbuje zbudować i mu się udaje albo nie stoosobową, ktoś chce zbudować unicorna no to próbuje budować unicorna i znowu tam jakiemuś procentowi się udaje Jasne, ja też akurat...

Natomiast chciałbym tylko jeszcze dokończyć zdanie, że po prostu to co chciałbym podkreślić, że jest ogromna wartość, którą można dostarczyć klientom budując po prostu technologię i będąc bardzo dobrym w tej technologii i po prostu przeciętna firma inżynieryjna czy produktowa czy usługowa, no umówmy się poziom po prostu inżynierii na świecie nie jest wysoki nie zatrudnia się wszędzie topowych koderów, nie dowodzi się wszędzie zawsze na deadline jest dużo lepiej niż było 10 lat temu, 10 lat temu było lepiej niż było 20 lat temu no ale ciągle zdane są takie horror stories, że tutaj to nie dowiezione tamto nie dowiezione, nie wiadomo czemu, niby wymagania były itd. i ten jak gdyby rynek się fragmentaryzuje jest coraz więcej nowych specjalizacji, tak?

Jak gdyby kiedyś był web, był Ruby on Rails, Python, jakieś tam PHP a teraz jest jeszcze Rust, jest jeszcze są różne inne egzotyczne technologie i do tego jak gdyby jest cały blockchain, którego nie było jeszcze 10 lat temu do tego jest całe AI, którego było dużo mniejsze 10 lat temu, tak?

I kiedyś blockchain to był blockchain, a teraz tych technologii jest pierdyliard, a i w blockchain można robić 10 różnych rzeczy i każdy z tych rynków jest spory, tak samo w AI jest cała masa różnych rzeczy, które można zrobić, tak?

No i to są technologie, w których jak gdyby należy szukać moim zdaniem interesujących tematów na założenie specjalizacji, na założenie software house.

Nie wiem, czy to odpowiada na pytanie.

Tak, odpowiada, ale jeżeli sobie spojrzysz na to, że totalnie się zgadzam z tym, że ta technologia się fragmentaryzuje i ja też jestem inżynierem od serca i też kocham inżynierię i uważam, że technologia ma podstawowe zadanie, służyć ludziom i jakby w software house'ach, tak jak wspominałeś wcześniej, można wytworzyć świetną kulturę inżynieryjną, bo można właśnie przekazywać sobie tą wiedzę pomiędzy projektami, coś co nie jest możliwe w firmach produktowych, bo po prostu w produktowych firmach często jesteśmy zamknięci na jedną technologię, wybraliśmy 3-4 lata, jeden framework, nie wiemy o tym, że w drugim framework'u może być dużo lepiej dlatego to jest stymulacja na to, żeby właśnie szybciej się rozwijać, żeby testować sobie technologię, ale jednocześnie ja czuję, że właśnie przesunięcie się w kierunku produktu, przesunięcie się w tym miejscu, żeby ten produkt mieć kontekst produktu powoduje, że przestaje się pracować dla samego faktu tworzenia technologii technologia nie powinna być dla software house'u w żaden sposób ogranicznikiem, ona nie powinna stawiać problemu my powinniśmy je być jak najlepsi w technologii, ale jednocześnie jakby powinniśmy służyć biznesowi, a do tego żeby służyć biznesowi trzeba mieć ten kontekst biznesu, więc nie można takiej twardej linii stawiać pomiędzy inżynierią, technologią, a samym samym produktem, który wytwarzamy i jakby spojrzeć sobie od trochę innej strony czyli trochę dziwnej sytuacji, która się dzieje na rynku software'u ogólnie albo start-upów czyli w momencie, kiedy na innym totalnie rynku, jeżeli chcesz wybudować budynek i jest to wieżowiec, to po prostu idziesz do firmy, która wie jak wybudować wieżowiec i jakby zlecasz tej firmie zajęcie się całą kompleksową obsługą tego zadania, a w świecie to tak nie wygląda, tak w spowodowu mówimy o modelu, mówimy o modelu dokładnie ten model, który powiedziałeś wygląda tak, że wynajmujesz firmę, która buduje wieżowiec i to co ona robi to wynajmuje odpowiedni software house'u do zrobienia każdej rzeczy ten biznes tak nie działa, to dokładnie działa tak Dodam jeszcze, że ta osoba, która ten budynek buduje to też jest wyspecjalizowana firma, która zajmuje się budowaniem budynków tak jakby od strony finansowej Słuchajcie, ja mam jeszcze jedno pytanie, bo zaczęliśmy nie chciałem dokończyć wątek, bo to bardzo ważne z mojej perspektywy pytanie myślę wielu osób, które do nas dołączyły, jeżeli mi chodzi Marku po głowie, założenie software house'u, to jaki ten skład founderski powinien być?

Na kogo postawić, wiesz, jakie osoby zaprosić do tej przygody i na co musimy zwrócić uwagę?

Tak, no świetne pytanie, ja jeszcze chciałem tylko powiedzieć, że ja rezerwuję jeszcze tutaj trzy minuty, żeby dokończyć temat tego wątku kultury i inżynierii, bo mam wrażenie, że go nie spęliśmy z powrotem gdzieś tam z drugiej strony.

Natomiast odpowiadając na to bieżące pytanie ja powiem szczerze, że to może być jakieś moje ograniczenie mentalne ale widzę, że jakby największym takim bottleneckiem w budowie software house'u jest po prostu technologia, znowu jeżeli to jest software house, który oferuje produkt, no to produkt i technologia, tak?

Może być design więc ja bym najchętniej funduje, czy najchętniej bym tworzył nowe software house'y w oparciu o team stricte techniczny czy szerzej mówiąc ekspercki, tak?

I troszeczkę jest tak, że jak na przykład chcę zrobić dobry marketing dla software house'u, znowu w tym modelu, o którym ja myślę to najlepiej to robisz czy publikując open source, czy blog post, czy jakby publikując blog post czy jeżdżąc na konferencje, czy mieszając wiele różnych tego typu technik i no i tego nie zrobi osoba prawda, która nie ma backgroundu technicznego nie zrobi tego dobrze.

Jeżeli budujesz sprzedaż w software house'ie i jesteś wysoko wyspecjalizowanym elitarnym software house'em to przychodzą do ciebie klienci techniczni, którzy mają pytania techniczne, o które chcą zadać na callu sprzedażowym, tak?

Znowu potrzebujesz tej osoby techniczne, tak?

I jak rekrutujesz no to masz interwju techniczne, tak?

Więc jak gdyby tak naprawdę każdy aspekt działania takiego wyspecjalizowanego elitarnego software house'u jest mocno techniczny.

W związku z tym czy szerzej mówiąc mocno ekspercki, jeżeli mówimy o produktowym czy jakimś designerskim.

No i to jest powód, dla którego uważam, że największą wartość wnoszą founderzy.

To Marek.

To trochę wejdę z clean'em takim, nie?

Bo nawet czytając twoją serię, tam kiedyś trochę odpowiedziałem i dopisałem się, bo to co powiedziałaś to jest prawda, tak?

Tylko i teraz nie, nie, tak jakby nie umniejszając nic, bo ile pamiętam twojej firmy doszły do jakichś iluś osób, nie?

Tylko do 45.

A, okej.

No bo właśnie to co powiedziałaś to jest prawda na początku, a właśnie potem największym ograniczeniem jest to, że jesteście founderami technicznymi, nie?

I to jest coś, co ja mogę powiedzieć ze swojego doświadczenia, dlatego, że potem technologia okej, ale potem wchodzisz w skalowanie organizacji i tam technologia już nie pomaga.

No i ja znowu uważam, że akropał czy wadyhotonia, która funkcjonuje jest taki mit, który... znaczy mit.

To nie jest tak, że tam nie ma żadnej prawdy, to absolutnie jest tak, że osoby techniczne często mają adwersje, nie chcą czy nie znają się na budowie organizacji czy masie różnych innych rzeczy, które trzeba zrobić, żeby tą firmę przeskalować do 150 osób lub więcej, czy nawet do 100.

Natomiast jest coś takiego i miałem tą rozmowę, jak napisałem serię blog postów, to miałem fajne rozmowy z bardzo różnymi software house'ami.

Niektóre super successful, niektóre całkiem successful i nawet miałem taką fajną rozmowę, że o software house'ie, który chciał właśnie urósł do tych kilkudziesięciu osób i chciał atakować setkę i tam jest w ogóle, ja to nazywam value of death, czyli jeżeli chcesz od tych 30, 40, 50 dojść do 100 plus, to jak gdyby musisz przejść przez taką fazę profesjonalizacji firmy, czyli przedtem miałeś jednego sejfca, jednego jakiegoś tam rekrutera, jak gdyby ta struktura była niezwykle prosta, a teraz nagle potrzebujesz stworzyć dział, departament, one wszystkie muszą się ze sobą dogadać, to jak gdyby zupełnie inna bajka prowadzenie takiej firmy i wiele firm próbuje profesjonalizować w cudzysłowie marketing na przykład i przedtem stworzywali projekty właśnie budując projekty open source'owe właśnie występując na konferencjach, a teraz robią profesjonalny inbound, zaczynają się pojawiać nowe słowa, CRM'y i tak dalej, zaczyna być dużo wokół tego i okazuje się, że ten marketing przestaje działać i oni się często odbijają, taka magiczna liczba, od której widzę, że dużo software house'ów się odbija, to jest 80 plus, minus tam 5, że jak gdyby one rosną do tych 80, nie są w stanie zbudować tej nowej struktury, ale też nie są w stanie wygenerować po prostu wystarczająco dużo lead'ów i teraz jak gdyby patrząc w drugą stronę jak gdyby super sukces software house'y, które się zeskalowały do setek czy tysięcy osób, na przykład Pivotal Labs, który wszedł na giełdę kilka lat temu u Stanach, albo na przykład ThoughtWorks, który jest znany sam z publikowania radara technologicznego, to są firmy, które bardzo mocno cisną technologię, Marcin Fowler, autor książki o refactoringu klasycznej jest CTO i jak gdyby my wszyscy znamy tą firmę, bo oglądamy jego wystąpienia na topowych konferencjach, bo czytamy ten radar technologiczny często niektórzy sporadycznie i jak gdyby udało im się zeskalować tą firmę używając tych pryncypiów technologicznych, jak gdyby to jest towar, który dorobudzimy i wychodzi jak gdyby Marcin Fowler na konferencji i mówi słuchajcie serwisy można robić na trzy sposoby, sprawdziliśmy, bo mamy tysiące osób, pięćdziesiąt teamów, trzydzieści robi mikroserwisy, tak to się robi, takie widzimy pattern wychodzi Marcin Fowler i mówi event sourcing jak ludzie mówią event sourcing to zauważyliśmy, że to znaczy jedną z czterech rzeczy i to jest ten jak gdyby topowy marketing, tak?

Czy to oznacza, że tam nie trzeba foundera takiego, który to zorganizuje i tak dalej?

Oczywiście, że trzeba tylko pytanie gdzie wyważyć te role?

Marek to ja powiem ze swojej obserwacji i pójdziemy dalej, bo to jest długa i ciekawa dyskusja, ten przykład, który podałeś, to jest Toadworks na przykład to jest właśnie marketing, to znaczy oni profesjonalizowali marketing i dlatego, że go profesjonalizowali zrobili z niego po prostu funkcję w organizacji, to mają Marcina Fowlera to nie jest tak, że ta firma pracuje na technologii, oni chcą żebyś myślał, że pracują na technologii, chcą mieć taki image, tak?

To jest wszystko co się buduje dokładnie, bo to jest to co powiedziałeś, to jest prawda, jak przekraczasz te osiemdziesiąt sto osób, to właśnie musi zacząć nad tym panować, nie?

I to jest tylko pytanie czy firma postanowi się sprzedawać w taki sposób czy w inny to jest taka moja obserwacja Mam pytanie do Ciebie masz teraz ofertę współpracy z Marcinem Fowlerem budowanie firmy albo z kimś kto jest świetny w budowaniu organizacji, kogo wybierasz?

Na początku z Marcinem Fowlerem, ale po jakiejś po przekroczeniu jakiejś, ten, potrzebuję dobrego organizatora Tak, słuchajcie, pytanie czy ten problem, o którym mówicie, nie dotyczy każdej firmy tak naprawdę, która przekracza Tak, tak, tak.

Ilość node'ów, które przekazuje sobie informacje jest ograniczona do tego, żeby gdzieś tam tworzyć topologię odpowiednią, która wspiera kierunek działania firmy i można organizować sobie marketing przez właśnie mocne profile osób, mocne brandy osobiste, można też stawiać na bardziej tradycyjny marketing, można też stawiać na marketing tradycyjny, dotarcie przez Clutch'a, tak jak wspominałeś Marek Także wydaje mi się, że to może być w ogóle Znaczy ja tutaj nie czuję, znaczy Clutch już nie działa, nie?

To jest też taka, że te platformy, ten marketing internetowy on ma takie bardzo szybkie cykle i ten Clutch miał chyba 3 czy 4 letni cykl, to samo przerabialiśmy z Dribblem, tak?

Jak gdyby oparcie, to jest duży błąd oparcie jak gdyby swojego marketingu, jak gdyby core swojego marketingu, oparcie o zewnętrzną platformę, nie?

Bo one mają swoje cykle, znikają i nieważne jaką masz potężną pozycję na tej platformie, ona po prostu kiedyś zostanie się zabrana, tak?

Dokładnie takie jest.

My zwróćmy Ja tylko jedno słowo będę rzucił do tego, że to co my zauważyliśmy to to, że klienci kupują efekty i kupują zaufanie, które jesteś w stanie zbudować właśnie różnymi narzędziami to nie jest łatwe, żeby zbudować zaufanie od klienta, który dopiero do ciebie przychodzi, który tobie daje tak naprawdę często swoje oszczędności życia, często jakiś zakład, który robi, który wpływa na jego codzienne życie albo jakaś kariera osoby w korporacji, z którą pracujesz i jego projekt dla którego realizujesz dla niego tak naprawdę mówi o tym czy on za rok, za dwa awansuje czy nie zaawansuje, więc pamiętajmy o tym, że to nie jest sama technologia, tylko to są ludzie, z którymi my współpracujemy i często skupiamy się na tej technologicznej części, ja uważam, że to powinno być zadaniem Software House'u, ba, ja uważam, że to jest jedna z przyczyn w ogóle dlaczego Software House'y i specjalizacja w tym kierunku ma sens, a nie budowanie tych kompetencji wewnątrz firm, które totalnie nie wiedzą o technologii nic, natomiast ta technologia ma służyć ludziom ta technologia ma służyć i pomagać biznesom po prostu robić dobra rzeczy za połączeniem tego jaka jest ich misja Dobrze, to ja tylko utnę tutaj ten wątek, to o co mi chodziło w tym pytaniu to trochę było kiedy founder techniczny musi z tego wyjść albo czy musi ale to już jest wtedy inny temat, wiem, że Sebastian czeka gdzieś w tle z innym wątkiem, więc może przeskoczmy Właśnie, jeszcze zanim ja zadam swoje pytanie, Marek, bo jeszcze mówiłeś, że chcesz parę rzeczy na temat Engineering Culture dopowiedzieć.

No właśnie, bo teraz jeszcze żeby zwiększyć ten temat dostarczania wartości dla klienta, bo widzę, że tutaj cały czas się tam siłujemy czy my jesteśmy połączeni z tym produktem, czy nie, wystarczająco dobrze czy nasze incentywy są dobrze wyrównane ale jest taka wartość, która wynika z tego, że w Software House w kółko dowodzi się podobne projekty, jeżeli on jest dobrze wyspecjalizowany w kółko się siedzi w tej samej branży i to, że się w kółko dowodzi w tej samej branży to obserwuje się, że w kółko wszyscy rozwiązują ten sam głupi problem i pewnie w każdej branży tak jest, ja dość dobrze mogę wam opowiedzieć o tych problemach jakie są w blockchainie, ale w każdym momencie branża jest w jakimś momencie, pewne problemy są rozwiązane i jak gdyby powstaje baseline i są nowe problemy i w kółko robimy coś, co jest manualnie, co można by zautomatyzować albo jakoś tam dużo kodu, ale jest powtarzalny i to jest ta szansa, kiedy można wypracować właśnie paterny czy projekty open source'owe w tym Software House jest na to czas i budżet często bo to jest najlepszy, na przykład marketing to jest zbudowanie sobie teamu open source'owego, który realnie buduje projekty, który wpuszcza was na konferencje które są faktycznie używane, te projekty itd. o których się pisze na blogach, po publikuje ciągle update'y itd. i to jest ta super wartość i teraz jak przychodzi ten klient, który ma po swojej stronie ten produkt to on przychodzi do ciebie i ma to zrobione na przykład dwa razy szybciej albo trzy razy szybciej bo my już znamy ten najnowszy, najlepszy stos technologiczny, bo my już to robiliśmy wcześniej więc my już doskonale wiemy jak uniknąć wszystkich problemów, które po drodze się spotkamy itd. i to jest ogromna wartość, a do tego ponieważ my powiedzmy w Etworce'ach czy w dowolnym innym Software House'ie, w jakiejś tam innej specjalizacji ale ponieważ my w Etworce'ach siedzimy w blockchain'ie to my i tak rozumiemy jego kontekst naprawdę nieźle, dużo lepiej rozumiemy jego kontekst niż wiele osób, które on na przykład musiałby zatrudnić z rynku które nie do końca znają blockchain'a, ale chcą wejść do blockchain'a, ale brakuje specjalistów do blockchain'a, więc on nie zatrudni kogoś kto ma dwa, trzy, cztery lata doświadczenia w blockchain'ie, po prostu nie ma takich ludzi na rynku, są niezostępni i też warto powiedzieć, że to nie jest wyjątek dla blockchain'a, jeżeli budujemy ten Software House, tą ideospecjalizację, która zaczyna się gdzieś wcześnie, w technologii, która jest dopiero w swojej wiośnie to ten problem, jeżeli uda nam się, jeżeli ten bet się zrealizuje i ta technologia faktycznie wybuchnie, to tych specjalistów tej technologii będzie brakować i to jest ogromna wartość, którą można dać i rozumienie kontekstu, jak gdyby takiego technologicznego i rozumienie całkiem sporo kontekstu produktowego może nie tyle, jak bym siedział w tej firmie od czterech lat, ale tak naprawdę to jest dużo, dużo lepsze niż to, co on jest w stanie zatrudnić, nawet jeżeli on jest w stanie zatrudnić trzy fajne osoby, to może potrzebuje dziesięciu to jest to, gdzie chciałem, teraz możecie się ze mną zgodzić albo nie ale to chciałem powiedzieć, żeby pokazać ten trade'ów, tą dychotomię która w rzeczywistości wcale nie jest taka czarno-biała tylko ten świat jest pełen różnych complexity różnych takich skomplikowania i w tym skomplikowaniu ty możesz mu dać prostą rzecz potrzebujesz dowieść, wiesz co chcesz, boom, masz, trzy razy szybciej i tak to jest relatywnie tanio jak byś miał kogoś zatrudnić, obie byłyby to trzy razy dłużej ja do tego nawiążę, tylko może od drugiej strony, bo generalnie chciałbym porozmawiać trochę, nie mogę nie zapytać o ryzyko, tylko nie chodzi mi o ryzyko doważenia projektu tylko o ryzyko przeżycia twojego software house'a na początku, bo skupmy się może właśnie na tym przypadku o którym powiedziałeś, czyli inwestujesz w technologię, która jest nowa, na przykład blockchain tutaj się pozycjonujesz, swój offering, no i co, teraz musisz złapać jakiegoś klienta na początku wiadomo, nie masz dużo ludzi, nie masz dużo specjalistów złapajesz jeden projekt, ale ten projekt się kiedyś skończy, a ty no właśnie, jest ryzyko zostawienia gdzieś ludzi na ławce i tutaj pojawia się masa kwestii tego, jak skonstruować umowy, jak zapewnić sobie jakiś pipeline, jak zapewnić sobie jakiś sposób przeżycia na czasy, które być może będą cięższe, no właśnie, więc jakbyś tu mógł powiedzieć kilka rzeczy o tych podstawowych ryzykach i też jak sobie z nimi radzić jakie są podstawowe metody czy techniki?

No, to widzę jak gdyby dwa czy trzy aspekty, jeden główny aspekt, który widzę, to ja to czuję takie, ja aż nawet jak myślałem o tym, że będziemy dzisiaj rozmawiać i to pytanie się pojawiło w zapowiedziach jak gdyby marketing is the king to jest jak gdyby to, co my Polacy jeszcze ciągle robimy słabo chociaż dużo lepiej niż 10 czy 20 lat temu no, jak gdyby jest z nami Damian, Damian prowadzi firmę Security, Damian ma bardzo fajne usługi, prowadzi Security, tutaj w Loczynie i jak gdyby myślę, że teraz robi też bardzo fajny marketing, ale obserwowałem jak Damian zaczynał i po prostu widziałem te firmy w San Francisco, które robiły bardzo kiepskie usługi Security, ale były tak wypompowane, były tak znane, bo dużo czasu, jakby duży procent, duża część wysiłku founderów szła w marketing i to jest coś, co jak gdyby ciągle ciągle jeszcze czuję, że jest za mało tego w Polsce i mam takie poczucie, że sam za mało w ten marketing inwestowałem, myślę, że jestem dużo, dużo do przodu względem rynku, nie, że naprawdę robiliśmy ten marketing fajnie i cały czas były jakieś eventy to były duże, fajne globalne, cały czas jeździliśmy po topowych konferencjach, cały czas coś publikowaliśmy jakieś, mamy dwa projekty open source'owe, jeden używa prawie 100 tysięcy projektów dzisiaj, tak, i ciągle mam poczucie, kurde, nie a przecież można było zrobić to, można było zrobić tamto, to robiłem sam, a przecież mogłem do tego kogoś zatrudnić, nie, i takiej mam też, jak gdyby refleksję z tego prowadzenia, okresu prowadzenia twórców, że największy błąd, jaki zrobiłem, to nigdy nie stworzyłem dedykowanego teamu open source'owego, nie, i to by był, jak gdyby to by był absolutnie marketingowo, byśmy wyprzedzili cały globalny rynek wtedy, nie, bo i tak byliśmy naprawdę w fajnym miejscu i myślę, że to jest to, o czym warto pamiętać i ten marketing, jak gdyby, trzeba od pierwszego dnia firmy, a nawet od minus pierwszego dnia firmy kultywować, tak, czyli zbudować habit pisania blogpostów, mamy jakiś problem rozwiązaliśmy problem, widzimy, że inni mają z tym problemy, boom, blogpost tak, boom, wchodzimy na Stack Overflow, odpowiadamy na pytania widzimy, że powtarza się w tych projektach coś, boom, ekstraktujemy lipkę, zgłaszamy się na konferencję, żeby opowiedzieć o tej lipce, tak, czasem nas przyjmą czasem nas nie przyjmą, jak gdyby cały czas chodzimy po meetupach, zanim dostaniemy się na konferencję, żebyśmy byli na YouTubie, że aplikujemy na konferencję, żeby już były jakieś fajne wideo z nami, żeby oni widzieli, że fajne prezentacje prowadzimy tak, i jak gdyby to jest coś, co trzeba cały czas robić od tego, kiedy jestem jednoosobowym freelancerem, po, jak gdyby parotysięczne firmy, gdzie tam są już dedykowane teamy mm, czy jakieś tam developer evangelist, czy open source'owe teamy, i to jest jak gdyby moja numer jeden rada dla osoby, która otwiera software house, marketing firm tak, ja się zgodzę 100%, bo to ja przyciągnę marketing i to nas do firmy co oczywiście część techniczna firmy powiedziała, że to zaraza i w ogóle nie, ale to jest osobny temat, możemy kiedyś porozmawiać, ale Marek, bo trochę follow up do tego pytania Sebastiana prowadziłeś, akurat tylko mogę się obawiać że obawiam się, że mogłeś nie mieć tego problemu przez ostatnie kilka lat w twojej branży nie, ale wiesz, prowadzisz, prowadzisz, robisz marketing i nagle, za przeproszeniem, jeb, padło no i masz ludzi na ławce, tak, jak tym się zarządza, jakie, jak jako właściciel software house, jak kalkulujesz wtedy ryzyko, jak do tego podchodziłeś, jeżeli miałeś ten problem, bo mówię, w twojej branży mogłeś nie mieć przez ostatnie kilka lat z różnych powodów.

No ja to akurat ten problem chyba miałem tylko raz faktycznie, właśnie, tak myślałem.

Duży projekt wysypał, ja akurat był w środek poprzedniej zimy blockchainowej, a myśmy jeszcze nie mieli już skończonego marketingu i wiesz, to są takie różne modele, ja teraz rozmawiam to z różnymi, wiesz, właścicielami software house'u, bo teraz ogólnie mamy kryzys, jest zima w blockchainie, jest kryzys w ogóle, branża IT w ogóle i ogólnie na świecie i dużo osób ma ten problem i wiesz, no, budują poduszki i są różne tam, wiesz, jak gdyby mają modele, kiedy trzeba zwalniać, kiedy tam...

Może to może uproszczę pytanie, bo ja mam swoją opinię i taki mam też slogan, i ty sobie mówisz, że nie waham się jej użyć, ale zaczynasz w tej chwili software house, tak, od nowa, budujesz.

Budujesz go zakładając, że będziesz miał ławkę ludzi, czy nie?

Właśnie nie.

Moja, jak gdyby i bardzo długo moim zdaniem możesz o tym nie myśleć, w sensie, no, gdzieś przychodzi taki moment, że musisz mieć jakąś tam, nie wiem, 200 osobą firmę, przychodzą jakieś projekty, musisz mieć wiesz, no, jedną osobą nie zaczniesz 20-osobowego projektu, tak, czyli jeżeli mówimy o jakiejś tam, nie wiem, skali Net Guru, to oczywiście sytuacja jest inna i to jestem wielkim fanem małych firm, dlatego, że możesz strasznie duże rzeczy przyhackować, które po prostu już musisz, nie, nie możesz tego zrobić w dużym software house'ie, tak ale moja rada jest jedna.

Marketing first, tak.

Myśmy mieli tak dużo leadów w Adworks'ach, że jestem pewien, że dzisiaj nawet jakbyśmy mieli ławkę, to coś byśmy złowili, tak, w sensie, jak gdyby po prostu...

Mówię, to jest specyfika branży też trochę.

Tak, tylko chodzi o to, że jak gdyby to, co ja widzę często, to jak ludzie widzą, że są leady, które zostają na stole, bo nie są w stanie ich wziąć, to jest sygnał, że trzeba rosnąć, tak.

A, przecież mogliśmy wziąć, trzeba więcej tych leadów, tak.

Nie, zawsze tych leadów powinno być, jak gdyby, dużo więcej niż ty jesteś w stanie wziąć i ty zawsze powinieneś wybierać tylko topowe leady.

Taka jest moja filozofia prowadzenia, tak, w software house'u i to jest to, co mówię.

My mieliśmy dużo więcej leadów niż byliśmy w stanie wziąć w zimie, ale ja nadal uważam, że moim największym błędem było nierozhulanie tego marketingu jeszcze dalej, tak.

Było nas na to stać, mieliśmy na to capacity, tak, i mogliśmy mieć jeszcze, jak gdyby, więcej leadów, jeszcze większy zapas w zimie, tak.

I to jest to, że po prostu jak przychodzą ciężkie czasy, to zaczynamy brać projekty, których byś nie wziął, tak.

W dobrych czasach bierzesz tylko topowych klientów, topowe brendy, bierzesz tylko projekty, które są rozwojowe dla ciebie i dla twojej specjalizacji, są rozwojowe, pozwalają ci się przemieszczać, wiesz, razem z rynkiem gdzieś tam w nowe, fajne przestrzenie, a jak przychodzi kryzys, to po prostu zaczynasz brać to, co jest na stole.

Aha, to ja, wiesz co, ja tylko taką anegdotę z życia mojej firmy pewnego, mieliśmy, nazwaliśmy to literalnie rok świni, czyli mieliśmy to, co mówisz, wybieraliśmy co, jak i tak dalej, a potem mieliśmy rok pelikana, czyli łykamy wszystko, co się da.

Tak że lecimy dalej.

Słuchajcie, ja mam takie pytanie, bo, znaczy, zostało nam pięć minut, więc jest na pewno pytanie, które bardzo, bardzo chcieliśmy wszyscy zadać.

To jest specyfika naszego polskiego rynku, z waszego, przede wszystkim, Marek, z twojego doświadczenia, czyli jak prowadzić i rozwijać software house w Polsce versus Europę versus świat?

Czym się wyróżniamy, a czego nam na pewno brakuje, w twojej obserwacji?

No tutaj, wiesz co, jak gdyby, powtórzę po raz trzeci, już ostatni, także wybaczcie, że brzmię powtarzalnie, uważam, że absolutnie marketing to jest coś, co robimy coraz lepiej, ale cały czas nie rozumiemy, że to jeszcze można robić rząd wielkości lepiej.

To jest czymś, tak jak mówię, nawet z czymś, co osobiście się jakby wymierza.

Natomiast widzę też taki trend, że profesjonalizują się polskie firmy.

Kiedyś to był naprawdę taki trochę dziki zachód i te firmy były takie właśnie otwierane przez kilku informatyków i nigdy nie odrabiały tej lekcji domowej, że teraz trzeba się nauczyć budować organizację, czy teraz ta gra jest trochę inna, jak chcemy zaatakować 100 czy 150 osób.

Więc to jest fajne.

Polska ma swoje specyficzne plusy i minusy.

W Polsce ciągle pokutuje takie myślenie, zresztą znowu to jest związane z marketingiem, ciągle pokutuje takie myślenie, że w Polsce można zrobić coś taniej i dlatego klienci przyjdą do Polski.

I to jest coraz mniej na temat.

W sensie w Polsce jest ciągle taniej niż w Niemcach, Wielkiej Brytanii czy w Dolinie Krzemowej, ale te różnice są coraz mniejsze i te firmy coraz częściej się globalizują i zatrudniają bezpośrednio pracowników w Polsce.

Marek, pociągnę Cię, tutaj mamy kilka minut, to pociągnę Cię wprost do takiej jednej pytanii.

Powiedziałeś, że mamy 1000 software house'ów w Polsce.

Wszyscy wiemy, że jest dokładnie to, co powiedziałeś, to znaczy, że my już nie jesteśmy tanim krajem, nie?

Tak.

Czy prawda w tej chwili pensje się zatrzymały, koszty trochę tam stoją w miejscu, albo nawet spadają, uwzględniając inflację, ale nie jesteśmy tanim krajem.

Pytanie, co według Ciebie się stanie z tymi 1000 software house'ów?

Mi się wydaje, że rynek przejdzie przemianę.

Ja bym taką historię opowiedział software house'u z Finlandii.

Finlandia jest jednym z najdroższych krajów na świecie, mogło być gorzej, mogła być Norwegia, ale to była Finlandia, więc było naprawdę drogo, ale jeszcze nie tak drogo, jak by było w Norwegii.

I oni mieli, to w zasadzie nie był software house, to było bardziej design studio, oni mieli dwadzieścia parę osób i oni robili prototypy, designów, takie odważne dla różnych firm.

I oni, ich klientami był tam nie wiem, Microsoft, jakieś duże firmy międzynarodowe.

I kiedy jesteś w Norwegii, przepraszam, kiedy jesteś w Finlandii, albo w Norwegii i budujesz firmę usługową, to jest absolutnie jasne, że nie możesz konkurować ceną, po prostu nie wygrasz, nie?

I musisz zbudować wartość, którą dajesz, której nie dają inni.

Dlatego oni zbudowali firmę, która robiła bardzo odważne designy, prototypy, takie przyszłościowe, to było 20 senior designerów, każdy 10 lat doświadczenia w topowych firmach i tak dalej.

I jakby takich firm jest jeszcze bardzo mało w Polsce.

I ciągle pokutuje to myślenie, jak software house, to musimy tanio coś dostarczyć.

I jakby moja rada numer jeden jest, dobra, numer dwa jest znajdź jasną wartość dla klienta.

Znajdź własną, co robisz najlepiej na świecie.

I ta droga przez wąską specjalizację znającą się w technologii jest fantastyczną moim zdaniem odpowiedzią na ten temat.

My w EdWordsach, i tutaj oczywiście może się ktoś zgodzić albo nie, byliśmy jedną z najlepszych firm na świecie, jeśli trzeba było dowiedzieć coś na blockchain, na Ethereum.

I to już od nazwy, EFWord, to już się zaczynało od nazwy.

My jesteśmy gośćmi od Ethereum.

I ja myślę, że będzie coraz więcej takich firm, coraz więcej takich firm gdzieś tam przypadkiem spotykam.

I coraz więcej mniej będzie, nie myślę, że upadną webowe czy mobilne software house, ale będą po prostu mniej atrakcyjne.

Dojdzie do konsolidacji, czyli będziesz miał z jednej strony firmy duże, obsługujące po setki tysiąc osób, obsługujące generycznych klientów, a z drugiej strony będziesz miał mniejsze, wysoko wyspecjalizowane firmy, które będą działy się bardzo komfortowo, oczywiście na rynku globalnym i konkurować z firmami czy z Finlandii, czy z Doliny Krzymowej.

Myślę, że to się wydarza właśnie teraz.

Dobrze.

Michał widzimy cię, ale już jesteśmy po czasie, będziemy kończyć, więc postaramy się pewnie, Marek, tutaj ci ciągnę do publicznej deklaracji o małą dogrywkę.

Panowie, jakiś rap-up?

Mój rap-up jest taki, że kurczę, miałem pytań tyle, że zadałem z nich pewnie jedną szóstą, więc ja czuję duży niedosyt, ale rozmawiało się super, bardzo fajnie.

Marku, dziękujemy ci za udział, mam nadzieję, że również się dobrze z nami ty bawiłeś i mam nadzieję, że uda się, tak jak powiedział Tomek, namówić ciebie jeszcze na jakąś dogrywkę później.

Ja też mam bardzo podobne przemyślenie, natomiast też mam taką obserwację i też może zastanówmy się nad gościem, który będzie miał troszeczkę inny punkt widzenia, bo wydaje mi się, że nie tylko w nowych technologiach jest pole do poopisu, bo słuchajcie, COBOL i HUD mają się świetnie i naprawdę da się dużo zrobić w tej kwestii, więc to jest też bardzo ciekawy temat.

Marek, super obserwacje, dużo na pewno bardzo fajnych wątków, bardzo ci dziękujemy za obiecenie.

Ja tylko dodam dla zainteresowanych, że nasza lista pytań głównych miała 10 pozycji, pytań rezerwowych około 15.

Nie zrobiliśmy listy głównej, więc musimy zrobić dogrywkę.

Zdecydowanie.

Marek, dzięki wielkie za rozmowę.

Życzmy wszystkim miłego weekendu.

Dzięki, śliczne zaproszenie, z przyjemnością zdrowia dogrywka i życzę wszystkim miłego weekendu również.

Dla mnie.

Miłego weekendu, cześć.

Cześć.

Napisy stworzone przez społeczność Amara.org Dziękują wam za oglądanie.

Creators and Guests

Sebastian Gębski
Host
Sebastian Gębski
Geek, engineer, blogger, codefella, serial reader. In the daylight: Principal SA for @awscloud (Startups, CEE). ex-CTO. I speak here for myself only.
Tomasz Onyszko
Host
Tomasz Onyszko
Founder, entrepreneur and CTO - I write about building company and career in tech. I observe tech and society and share my opinions
Wojtek Ptak
Host
Wojtek Ptak
Learner, teams & products builder, DDD & ML mixer, leader, contributor, and freeride biker by ❤️ working as @RevolutApp’s Head of Engineering. He/him.
Marek Kirejczyk
Guest
Marek Kirejczyk
👨‍🏫 Deep diving into ZKPs and cryptography @zkWarsawPreviously:👨‍💻 Created OSS: https://t.co/2AgPSjRN7T and https://t.co/unzIcBGOgF🏣 Funded and exited @ethworks and @elpassion
Episode #22: Budujemy Software House
Broadcast by