07 sie 2019 POIT #041: Praca w międzynarodowej firmie IT
Witam w czterdziestym pierwszym odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest praca w międzynarodowej firmie IT.
Dziś moimi gościem jest Piotr Dolistowski, dyrektor technologiczny polskiego oddziału Instapage w Warszawie. Programista z wieloletnim doświadczeniem, specjalizujący się w aplikacjach webowych.
Merytoryczne rozmowy o IT wspiera www.polecaj.home.pl. Program partnerski, w którym zyskujesz nawet 400 zł za polecenie hostingu. www.polecaj.home.pl.
W tym odcinku o pracy w międzynarodowej firmie IT opowiemy w następujących kontekstach:
- jakie korzyści z niej płyną dla pracodawcy i pracownika?
- jak fakt pracy z najnowszymi technologiami przyciąga nowych ludzi do firmy?
- jak buduje się w niej atmosferę i poczucie bycia częścią większej całości?
- jak zarządza się w niej komunikacją i zadaniami?
- czy przypominanie o wartościach i misji firmy jest ważne?
- czy powinno się praktykować spotkania w realu?
- jak tworzy się w niej zespoły projektowe?
- jak zarządza się cyklem wytwarzania kodu?
- jaka jest rola i praktyki związane z wewnętrzną dokumentacją?
- czy niedopasowanie kulturowe może być realnym problemem?
- jak sobie radzić z problemem różnicy stref czasowych?
Subskrypcja podcastu:
- zasubskrybuj w iTunes, Spreaker, Sticher, SoundCloud, Spotify, przez RSS, lub Twoją ulubioną aplikację do podcastów na smartphonie (wyszukaj frazę „Porozmawiajmy o IT”)
- ściągnij odcinek w mp3
- poproszę Cię też o polubienie fanpage na Facebooku
Linki:
- Profil na LinkedIn – https://www.linkedin.com/in/piotrdolistowski/
- Instapage – https://instapage.com/
- Historia Instapage w Polsce – https://cyfrowa.rp.pl/biznes/31717-amerykanski-startup-przeniosl-sie-do-polski-to-byl-strzal-w-dziesiatke
- odcinek podcastu o budowaniu software house
Pozostańmy w kontakcie:
- 📧 Jeśli masz jakieś pytania lub komentarze, pisz do mnie śmiało na krzysztof@porozmawiajmyoit.pl
- 📩 Zapisz się na newsletter aby nie przegapić kolejnych ciekawych odcinków.
- 🎙 Subskrybuj podcast w lub
Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner (posłuchaj)
Transkrypcja podcastu
To jest 41. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o pracy w międzynarodowej firmie IT.
Merytoryczne rozmowy o IT wspiera polecaj.home.pl – program partnerski, w którym zyskujesz nawet 400 złotych za polecenie hostingu. www.polecaj.home.pl.
Przypominam, że w poprzednim odcinku poruszyłem temat rekrutacji i pracy zdalnej. Wszystkie linki oraz transkrypcja naszej rozmowy znajdziesz pod adresem porozmawiajmyoit.pl/40.
Chcę poszerzać horyzonty ludzi z branży IT. Wierzę, że poprzez wywiady takie jak ten, publikowane jako podcasty będę to robił z sukcesem. Nazywam się Krzysztof Kempiński i życzę ci miłego słuchania.
Odpalamy!
Krzysztof: Cześć! Moim i waszym gościem jest dzisiaj dyrektor technologiczny polskiego oddziału Instapage w Warszawie. Programista z wieloletnim doświadczeniem, specjalizujący się w aplikacjach webowych. Spiker na konferencjach technologicznych. Współtwórca sukcesu firmy Instapage. Prywatnie lubi grać na bębnach i podróżować. Moim i waszym gościem jest dzisiaj Piotr Dolistowski. Cześć Piotr! Bardzo miło mi Cię gościć w podcaście!
Piotr: Cześć Krzysztof. Jest mi równie miło. Witam słuchaczy.
Krzysztof: Dzisiaj z Piotrem porozmawiamy o temacie pracy w międzynarodowych zespołach IT właśnie na przykładzie firmy Instapage. Piotr, zawsze rozpoczynam od pytania na rozluźnienie – słuchasz podcastów? Jeśli tak, to jakich najczęściej?
Piotr: Muszę się przyznać, że jeszcze nie wszedłem w podcasty i nie mam takich, których słucham regularnie. Czasami jak mnie temat interesuje, to wtedy odsłuchuję. Ostatnio zainteresowało mnie Artificial Intelligence od człowieka, który pracuje w MIT. Jest tam połączenie podejścia naukowego z filozoficznym. Rozmawiają o sztucznej inteligencji, ale też o inteligencji ogólnie w kosmosie. Jest tam taki klimat, że zakochałem się w tym i tego słucham. Tak czasami słucham jakichś podcastów Niebezpiecznika, jako źródło newsów.
Krzysztof: Fajna lista. Mógłbyś krótko opowiedzieć o historii firmy Instapage, bo jest to dobry przykład na pracę w międzynarodowych zespołach IT. Jak to się stało, że amerykański startup przeniósł swój oddział technologiczny do Polski? Jak firma Instapage odnajduje się i działa w międzynarodowych zespołach?
Piotr: Historia Instapage jest bardzo ciekawa. Jest to historia startupu, o którym często można usłyszeć w gazetach. Filmy mogą powstać o takich firmach. Wszystko zaczęło się od naszego założyciela Tysona Quicka. Tyson jak bokser, tylko nasz Tyson ma tak na imię, a nie na nazwisko. On pochodził z Utah i tam miał swój startup, który chciał promować. Chciał użyć do tego landing page, ponieważ one są najskuteczniejsze, aby reklamę internetową wykorzystać. Nauczył się HTML-a, CSS-a, zaczął pisać proste stronki. Szybko zdał sobie sprawę, że landing page to nie tylko kod HTML i CSS, ale fajnie by było tę stronę podłączyć do narzędzi marketingowych, aby zbierać leady, zbierać dane z formularza, które są umieszczone na takiej stronie, aby badać skuteczność strony, poprawić ją. Zaczął szukać w Internecie czy jest takie podobne rozwiązanie. Nic takiego nie znalazł, więc wpadł na genialny pomysł, że on stworzy takie narzędzie. Uwierzył w ten pomysł tak, że przeprowadził się do San Francisco, czyli centrum Doliny Krzemowej. W Juta nie widział siebie i swojej nowej firmy. Wykorzystał na tę przeprowadzę i na te wstępne części kodu wykorzystał wszystkie swoje oszczędności z poprzedniego startupu.
Cały czas był przekonany o sukcesie firmy, że zdecydował się spać w samochodzie. Miał kartę biblioteczną, więc w bibliotece pracował, bo było darmowe Wifi. Higienę realizował na siłowni, bo został mu karnet do siłowni. Tak przeżył dwa miesiące. W tym czasie zrobił rekrutację freelancerów wykorzystując platformę freelancerską. Ona się nazywała wtedy odesk – w tej chwili nazywa się UpWork. Tam znalazł pierwszego programistę z Polski – Marka Dajnowskiego, który do tej pory pracuje w firmie i jest Chief-Architektem. Marek stworzył podwaliny tej firmy, pierwsze funkcjonalności, które później Tyson przekonwertował na coś wartościowego dla potencjalnych klientów. Firma zaczęła się gwałtownie rozwijać. Marek znalazł mieszkanie w centrum w Białymstoku. To było mieszkanie z wyższym standardem. Wtedy ja doszedłem razem z kolegą, który jest na podobnym stanowisku jak ja, tylko on zarządza Białymstokiem, a ja Warszawą. W 6 osób byliśmy wtedy w tym jednym pokoju. Biurko było przyklejone do biurka. Pracowaliśmy nad taskami. Wtedy mieliśmy metodologię waterfallową, więc nie było żadnych podziałów. Byliśmy teamem crossfunckjonalną, troche agile’owym. Nie było to sformalizowane. Byliśmy świadkami ogromnego wzrostu. Każdy skończony task skutkował potężnym wzrostem u klientów. Coraz więcej ich do nas dołączało. Coraz bardziej firma się rozwijała. W tamtym momencie mieliśmy wzrost kilkaset procent miesięcznie. Nawet nie rocznie, tylko miesięcznie. W te 6 osób pracowaliśmy w taki sposób, że aktualny VP of Engineering nie miał miejsca na swoim biurku, więc pracował na stojąco. Znalazł sobie półkę w regale i w ramach ćwiczeń fizycznym przez 3 miesiące pracował na stojąco. Wreszcie musieliśmy zatrudniac więcej pracowników, więc musiliśmy mieć większe lokum. W tym pokoju to nie potrafiliśmy się wszyscy zmieścić. Przeprowadziliśmy się do mieszkania, tylko z bardzo wysokim standardem. Policzyliśmy, że będzie tam miejsce dla 22 osób. Później okazało się, że udało nam się tam zmieścić chyba 26 osób zanim się przeprowadziliśmy dalej. Wszystko było tak samo startupowe jak na początku. Też było to mieszkanie, nie biuro. Mieliśmy dostęp do dachu, więc tam często organizowaliśmy imprezy, które wychodziły spontanicznie. Wszyscy byliśmy skupieni na tym, aby dostarczać niekoniecznie wysokojakościowy kod, ale ważne aby było szybko i aby uzyskać jakąś wartość dla klienta. Takie były początki. W nowym miejscu mieliśmy minimalną wymaganą liczbę osób do tego, aby zacząć myśleć o przypisywaniu tego kodu, który zastaliśmy. Marek z taką samą filozofią, aby kodować, żeby jak najszybciej firma miała jakąś wartość, to rzeczy były pisane z niższą jakością, niż to później zaczęło być potrzebne. Zaczęliśmy przepisywać tę aplikację kawałek po kawałku. Tak naprawdę do tej pory cały czas ją nieustannie przepisujemy. Jeszcze dużo nam zostało tego kodu do przekonwertowania na nowe technologie. Zaczęliśmy myśleć poważnie o mikroserwisach, o architekturze opartej o mikro serwisy. Mniej więcej w tym czasie z ASP 5 przechodziliśmy na ASP 6, co było nowością. Zaczęliśmy myśleć o Angularze. On był wtedy w wersji beta. Jeden projekt pisaliśmy w nim licząc na to, że niedługo będzie wersja stabilna. Udało się tak trafić w czasie, że zanim wypuściliśmy ten projekt na Angularze, to stabilna wersja była wypuszczona przez Google. Udało się to stabilnie zrealizować. Przechodziliśmy powoli na rozwiązania cloudowe. Na początku mieliśmy od kilku do kilkunastu WPS’ów, które tworzyły nasz klaster. Zaczęliśmy przechodzić na rozwiązania chmurowe. Na początku w Amazonie. Później dostaliśmy duży kredyt w Google, więc opłacało się przejść do nich. Te prace transferowe nie były zaawansowane, więc było to opłacalne. W tej chwili mamy architekturę w całości opartą o Google. Wykorzystujemy jeszcze Amazona. Używamy też Verizon i różne inne cloudowe rozwiązania. 95% mamy na Google.
Zaczynaliśmy od małych rozwiązań, aby dojść do 100 programistów w Polsce
Tak to wyglądało. Zaczynaliśmy od 6 osób, w tej chwili mamy 100 programistów w Polsce. Tyson – założyciel, zaufał nam. Mamy pełną wolność w wyborze technologii. To zaprocentowało. Teraz nie mamy dużego problemu, aby znajdować nowych ludzi, którzy mają duże doświadczenie, ponieważ start technologiczny jest dosyć unikalny. Nie jest często spotykany w Polsce.
Krzysztof: Jasne. Bardzo fajna historia. Można powiedzieć, że to historia na film, zwłaszcza z tymi początkami. Wiem, że jesteście firmą działającą w modelu międzynarodowym, bo w różnych geograficznie lokalizacjach znajdują się działy zajmujące się różnymi aspektami. Chciałem Cię zapytać, bo wspomniałeś o tym, że wasz założyciel na początku był programistą od zarania. Później pewnie przejął głównie kwestie biznesowe. Po pierwsze programista, po drugie pracodawca. Jakie korzyści dla tych dwóch stron płyną z pracy w międzynarodowych, rozproszonych geograficznie zespołach?
Piotr: Korzyści jest wiele. Dla polskiego oddziału inżynierów jest to szansa, żeby pracować w firmie z Doliny Krzemowej. Sam ten fakt jest wystarczający, aby taka oferta była interesująca. Można pracować z najlepszymi ludzie w świecie IT. Dzięki temu, że jest to w Dolinie KRzemowej to jest potencjał inwestycyjny. Firma ma pieniądze, dzięki temu nie musi się mocno spieszyć, tak jak oopowiadałem na początku naszej historii. Jest czas, żeby realizować projekty, w oparciu o najnowsze technologie i aktualnie z najwyższą jakością, jaka jest możliwa. To dla programisty jest ogromną wartością. Lista benefitów, fakt, że firma ma stock options 13:31 , czyli każdy pracownik ma kawałek firmy na własność, to też jest ciekawe i nie jest często spotykane w Polsce. Dla strony w Stanach programiści polscy, nie od dziś wiemy, że są bardzo dobrzy. Ciężko znaleźć tak wykwalifikowanych pracowników nawet w Dolinie KRzemowej. Nie jest to takie łatwe. Jakość jest tym, czym Tyson jest zachwycony, tym czego oczekuje. Kolejne rzeczy takie jak komunikacje, programiści polscy nie mają problemu, aby rozmawiać po angielsku nawet na zaawansowane tematy, to też ułatwia wszystko. Nie ma ogromnych różnic w kulturze. To wszystko spina się na to, że współpraca wychodzi bardzo dobrze.
Krzysztof: Wspomniałeś, że korzystacie z innowacyjnych rozwiązań. Powiedziałeś, że ten stack technologiczny nie jest zbyt oczywisty i często spotykany. Często tworzycie takie innowacyjne rozwiązania. Mógłbyś powiedzieć jak ten fakt pracy z takimi fajnymi, innowacyjnymi technologiami wpływa na to, że przyciągacie pracowników z różnych części świata?
Piotr: Mamy 4 biura na świecie. Każde biuro jest na innym rynku pracy i inne rzeczy przyciągają tych pracowników. Biuro w Stanach przyciąga samym faktem, że firma Instapage jeszcze nie jest firmą, która jest na giełdzie. Jest to unicorn, gdzie można szybko się rozwijać. Można awansować. Są stock opcje. To ludzi w Stanach przekonuje do tego, aby dołączyć do nas. Ze względu na to, że tam jest rotacja pracowników bardzo intensywna, bardzo wysoka. Oni szukają czegoś, co pomoże w ich karierze. Pod tym kątem wybierają firmy. Atmosfera, praca z ludźmi jest dla nich istotna. Wszyscy tam patrzą na to, czy to jest korzystne dla ich kariery i co z tego będą mieli na końcu. Takie wartości są tam istotne. W Rumunii podobnie jak w Polsce jest to możliwość pracy w startupie z Doliny Krzemowej, czyli możliwość rozwoju, pracy nad takimi projektami, które są używane przez ogromną rzeszę klientów, co często w tym krajach nie jest takie oczywiste. Można wybrać jakąś dużą korporację, ale są minusy tego, że ta praca jest bardzo usystematyzowana i głos osobnika niekoniecznie ma znaczenie. Mi się wydaje, że wartości są zróżnicowane. Na każdym rynku inaczej się rekrutuje. Teraz rekrutujemy stanowiska potrzebne w Stanach, w Polsce. Tu nie chodzi tylko o programistów, ale też o grafików, UX designerów. Przeprowadzaliśmy takie rekrutacje i różnice są bardzo duże. Jeśli ktoś ma taką chęć, aby coś takiego zrobić, to radzę na początku mocno obgadać temat, przygotować się do niego, ponieważ to jak Stany myślą o rekrutacji, a to jak Polska myśli o rekrutacji, to są dwie różne rzeczy. Tam to zupełnie inaczej wygląda.
Stany myślą o rekrutacji inaczej niż Polska
Krzysztof: Wiem, że zachęcacie nowych pracowników do tego, aby odwiedzili siedzibę w Stanach. Mają czas na zwiedzanie San Francisco, jak się dowiedziałem. Jak to wpływa na moralne, na kształtowanie kultury firmy i poczucie, że nowy pracownik staje się jej częścią?
Piotr: Bardzo pozytywnie, ogólnie na relacje jednostkowe. Wiadomo, że na co dzień komunikujemy się przez Internet wykorzystując Slacka, rzadziej email. Często wideo rozmowy. To nie jest idealne. Nawet jeśli ta technologia dalej będzie szła naprzód, to myślę, że kontakt, energia rozmowy z osobą face to face, która jest blisko, kiedy widać całą mowę ciała, to jest coś innego. Wysyłamy ludzi dlatego, aby mogli poznać się z ludźmi z innych biur. Wiadomo, że dla programisty polskiego wybór jest prosty – jedzie po prostu do San Francisco i realizuje sobie program office exchange, ale teoretycznie mógłby też pojechać do Rumunii i mieć te same zasady, czyli tydzień pracy z tym zespołem, a potem wakacji. To wpływa później jak ludzie są poznają jednostkowo, mogą wyjść na piwo, porozmawiać na luzie nie tylko o pracy. Później w pracy o wiele łatwiej jest im się zrozumieć. Nawet jeśli to jest tekst pisany, który może nastręczać problemów, to po takich wizytach ludzie o wiele łatwiej się komunikują. Bliskość ludzi wpływa na to, że jednoczy nas. Mamy wspólny cel – powinniśmy być zjednoczeni. To też w tym pomaga. Same superlatywy.
Krzysztof: W jaki dodatkowy sposób budujecie atmosferę w firmie? Chodzi mi o relację, o rozwój, o development poszczególnych pracowników, kontakt z kierownictwem. Macie narzędzia, sprawdzone sposoby do tego?
Piotr: Tak. Mamy wiele takich rzeczy. każdy z działów ma swoje, odpowiednie dla danego biura rozwiązania. W Polsce na pewno taką rzeczą, która wspomaga tę atmosferę, tę kulturę, to są początku freelancerskie. Nawet w tym momencie, kiedy mamy bardzo dużo procesów, mamy metodologie zarządzania projektami, mamy ramy, w których można się poruszać, to cały czas mamy taką elastyczność. Mamy luz, który daje tą fajną atmosferę i nie problemu, żeby napisać do CEO czy do lidera wysoko postawionego w firmie i zapytać go o coś albo go skrytykować. Każdy ma taką możliwość i często ją realizuje. Staramy się na podstawie tego feedbacku rozwijać. Do tego mamy rzeczy, które łączą te wszystkie działy. To jest między innymi spotkanie raz w miesiącu, które nazywa się „All hands on deck” i na którym rozmawiamy co się w danym miesiącu działu. Witamy nowych pracowników w firmie. Wyróżniamy tych, którzy pracują dłużej i mają jakąś rocznicę w firmie, czy też tych, których należy wyróżnić ponieważ zrobili coś wyjątkowego i zasłużyli na specjalną pochwałę. Tam jest czas, aby nasz CEO coś mógł powiedzieć o aktualnym kierunku, w którym firma podąża, o tym jakie są najbliższe cele. Oczywiście, to wszystko i tak przekładamy na OKR-y, na KPI-e – na wszystko co jest w tego typu firmach. Fajnie tę bliskość buduje to, że można posłuchać bezpośrednio założyciela czy ludzi, którzy wymyślali te rozwiązania, te cele. To na pewno wiele daje.
Raz w miesiącu mamy spotkania, gdzie jest cały dział. Rozmawiamy o ważnych rzeczach, witamy nowych pracowników i nagradzamy zasłużonych
Krzysztof: Z tego co znalazłem, to w Instapage pracuje 200 osób. To są różne lokalizacje geograficzne. Trochę już o tym powiedziałeś, ale jestem ciekaw, w jaki sposób zarządzacie komunikacją, zadaniami, delegowaniem tasków w takim sporym zespole?
Piotr: Z tym była długa droga. Nie było to kiedyś oczywiste. Kiedyś mieliśmy to podzielone. W Stanach był biznes, który składał się product teamu który wiedział jakie są wymagania biznesowe. Na podstawie tych wymagań tworzył specyfikację do projektów. Później polscy inżynierowie dostawali tę specyfikację i rozpisywali sobie to na taski. Ale to miało niestety dużo wad. Między innymi takie, że proces pisania specyfikacji przez product team był bardzo długi. Oni musieli często się zatrzymywać, mieli dużo blokerów, ponieważ nie wiedzieli czy coś jest trudne do napisania, czy coś jest łatwe. Musieli pytać non stop programistów, ale też programista niewdrożony w tę całą ideę miał problem, aby odpowiedzieć konkretnie ile coś zajmie. To skutkowało tym, że specyfikacje często miały błędy, często miały elementy, który stawały się blokerem, były bardzo trudne do napisania, ponieważ z wielu powodów, często integracyjnych między różnymi częściami aplikacji. Trzeba było te problemy rozwiązywać, a często programiści jako żołnierze i tak to robili, mimo że było to trudno. To wiązało się z tego typu problemami. Też ciężko było programistom znać wizję na daną funkcjonalność, ponieważ nie byli przy wymyślaniu tego, nawet przy wstępnych założeniach. Te wszystkie problemy mieliśmy na początku. Potem wprowadziliśmy Scruma, czyli podejścia agilowe. Wprowadziliśmy tak jak wiele firm wprowadza, mieliśmy cross funkcjonalne zespoły – każdy zespół miał swoje projekty. To jeszcze nie było zbytnio agilowe. Dużo się zmieniło w oczach ludzi, natomiast nie pomagało to mocno przy projektach. Dopiero od jakiegoś roku, może mniej niż roku, już stosujemy bardzo głęboko idące podejście agilowe, czyli wspólnie pracujemy nad projektem od samego początku, od samej idei na daną funkcjonalność. Product team często przyjeżdża do Polski, aby obgadać wstępne rzeczy. My, programiści polscy, często jeździmy do San Francisco, w tym samym celu, aby mieć punkt zaczepny, aby najważniejsze problemy były obgadane. Później proces cały jest taki, że nikt nie pisze specyfikacji projektu na ponad trzy miesiące, tylko koncentrujemy się na dwóch sprintach naprzód, czyli miesiącu w przód. To o wiele lepiej wygląda. Programiści wiedzą, że mają duży wpływ na to jak później finalny produkt wygląda. Dzięki temu ich udziałowi od samego początku w pierwszych założeniach jest pewność, że nie będzie tam rozwiązań zbyt trudnych do napisania, zbyt skomplikowanych. Wspólnie z product teamem i z innymi działami, które są zaangażowane w tym samym momencie, realizujemy ten projekt o wiele sprawniej i staramy się go wypuszczać na świat w małych kawałkach, a nie w ogromnych kobyłach.
Koncentrujemy się na dwóch sprintach naprzód. Programiści mają wpływ na to, jak wygląda produkt finalny
Krzysztof: To już brzmi jak znacznie bardziej dojrzałe, agilowe podejście. Wspomniałeś kilka razy o tym, że programiści jeżdżą do Stanów czy w drugą stronę się odwiedzacie. Rozumiem że język angielski jest oficjalnym językiem, w którym się komunikuje i jest warunkiem zatrudnienia u was. Jaki poziom znajomości języka angielskiego jest wymagany?
Piotr: Tak. Zdecydowanie angielski jest językiem, którym się posługujemy. Każdy team ma swój język, którym się na co dzień posługuje. Natomiast tym, co nas łączy to jest język angielski. Wymagamy tego angielskiego różnie, w zależności od danej roli w firmie. Na pewno płynny angielski, bardzo zaawansowany jest wymagany od product managerów, product ownerów. Od ludzi, którzy w definicji swojej roli będą się kontaktowali z innymi zespołami na świecie. Oni muszą rozmawiać bardzo płynnie. Nie mogą mieć problemów ze zrozumieniem, zwłaszcza. Ludziom się często wydaje, że problem jest z mówienie, natomiast z mojej perspektywy to jest problemem ze zrozumieniem kogoś. To trzeba trenować, bo z samym mówienie nie będzie problemu jak z brakiem zrozumienia ważnego aspektu. Programiści nie mają tak wymaganego angielskiego. Ważne, aby potrafić czytać ze zrozumieniem dokumentację techniczne, potrafili opisy tasków przeczytać ze zrozumieniem. Fajnie, jak potrafią też trochę porozmawiać, bo jeśli ktoś nas odwiedzi z innego teamu, to fajnie żeby na piwie nie siedzieć z zamkniętymi ustami i bać się cokolwiek powiedzieć, tylko nawiązać pozytywne relacje. To nie jest tak zaawansowany angielski jakiego wymagamy od osób, które na co dzień muszą się komunikować z innymi teamami w innych krajach.
Krzysztof: Rozumiem. Powiedziałeś fajne zdanie, że w rozproszonym, międzynarodowym zespole ważne jest to, aby wszyscy mieli poczucie wspólnoty i tego, że grają do jednej bramki. To są rzeczy, o które trzeba aktywnie zabiegać. To się nie dzieje samemu. Chciałem Cię zapytać, czy aby utrzymać poczucie identyfikacji w rozproszonym zespole konieczne jest posiadanie i częste komunikowanie wartości, wizji firmowych. Czy to się u was dzieje systematycznie?
Piotr: Tak, jest to konieczne. Można rozpisać tę wizję, raz powiedzieć. Ludzie będą słuchać, będą starać się zrozumieć, natomiast bez powtarzania jej, bez wdrożenia ludzi w budowanie tej wizji ta skuteczność będzie niewielka. Trzeba cały czas o tym rozmawiać, nawet z prozaicznego powodu takiego, że czasami jak mamy okres zatrudnienia bardzo intensywny, to w jednym miesiącu dochodzi do firmy nawet 15 nowych osób. Aby one miały możliwość nadążania za tą wizją, za tym co się dzieje, to z tego powodu trzeba cały czas powtarzać. Najlepiej ludzi wdrożyć w sam proces tworzenia tych projektów, wtedy jak ktoś weźmie w swoje ręce poszczególne tematy, to najbardziej się wtedy wdroży. On będzie rozumiał te problemy, bo sam ich doświadczy. Będzie je rozumiał na własnej skórze. To jest najlepsze. Samo mówienie częste pomaga, aby uzyskać ten efekt. Aby ludzie byli jednym teamem, mimo że z różnymi projektami, różnymi celami, ale aby to był jeden wspólny cel, który wiąże te wszystkie zespoły, aby nie było problemów komunikacyjnych albo wynikających z niezrozumienia idei czy funkcjonalności.
Krzysztof: Chciałem pociągnąć wątek jednego teamu, o który zahaczyłeś. Kilka razy powiedziałeś o różnego typu spotkaniach, które się u was odbywają. Chciałem zapytać jak wynika z twojego doświadczenie – czy takie praktykowanie spotkań w realu, czy wideorozmowy w większym gronie, to jest coś co ma znaczenie? Warto w to inwestować czas? Mimo wszystko jest to inwestycja ze strony firmy. Czy uważasz, że to sens, że warto w takie rzeczy inwestować?
Piotr: Tak. Myślę, że tak. Te spotkania zbierają bardzo pozytywny feedback. To jest czas dla ludzi, żeby dowiedzieli się co się dzieje w innych zespołach, mimo że mamy narzędzia, które to wspomagają. Fajne jest to, że na tych spotkaniach, ze względu na to, że czas jest ograniczony, to rzeczywiście te update, te statusy są high level’owe. To są najważniejsze rzeczy. Pigułka tego, co się dzieje w firmie i tego, co niedługo będzie się dziać. To jest interesujące i pomocne. Do tego jest to okazja, aby kogoś wyróżnić. Wyróżnienie na forum całej firmy ma zdecydowanie mocniejsze wrażenie niż w jednym teamie. To jest fajne. Właśnie wtedy zespoły mogą się cieszyć ze skończenia projektu. Cała firma im gratuluje i wspólnie się cieszymy, że coś udało się zrealizować. Myślę, że to jest bardzo fajne. To bardzo łączy. Do tego posłuchać na żywo założyciela, który jest w pewnych momentach genialny, ponieważ ma takie pomysły, które zaskakują ludzi. Potem się okazuje, że rzeczywiście miał rację. Posłuchać takiego człowieka na żywo, który opowiada o tym, gdzie widzi firmę za 3 miesiące, rok, dwa lata, jest super interesujące i daje dodatkową motywację, aby zrealizować ten pomysł.
Krzysztof: Czy według ciebie taka firma jak Instapage, firma IT, która jest zbudowana z międzynarodowych zespołów musi świadomie i strategicznie podejmować działania, które mają na celu pokazanie, że jest różnorodność w firmie. Ta różnorodność leży u jej podstaw. Firma akceptuje taką różnorodność i ją wspiera. To jest coś, co trzeba świadomie pokazywać i wspierać?
Piotr: To jest dobre pytanie. Ostatnio nawet dyskutowaliśmy o tym wewnątrz firmy. Firmę mamy różnorodną. Mamy praktycznie każdą kulturę jaka jest możliwa. Zwłaszcza w San Francisco, które jest bardzo zróżnicowane ogólnie. Cała firma stawia na różnorodność. Jedną z takim wartości firmy jest „be unique”, więc zawsze będziemy wspierać każdą różnorodność. Pytanie czy powinniśmy też na zewnątrz takie wsparcie okazywać. Mnie osobiście wydaje się, że tak. Należy wspierać mniejszości. Należy dawać sygnał światu, że Ci ludzie nie są sami, mają wsparcie. Tak też zrobiliśmy wspierając Paradę Równości. Zmieniliśmy logo na tęczowe na naszych portalach społecznościowych, oficjalnych. Sympatyzujemy z ideą, która idzie za tym ruchem. Oczywiście, w Polsce może to być inaczej rozumiane, ponieważ ludzie często zauważają dużo niezgodności z tą główną ideą. Jako firma wspieramy różnorodność. Nie wnikamy aż tak głęboko. Myślę, że należy pokazywać takie rzeczy. Fajnie że my pokazaliśmy. Zwłaszcza myślę, że z ostatnimi wydarzeniami, które miały miejsce w Białymstoku, myślę, że to jest bardzo fajne, że wcześniej zdecydowaliśmy się, aby zająć jakąś stronę.
Krzysztof: Dzięki, że otwarcie o tym mówisz. Chciałbym Cię zapytać o strukturę. Powiedzmy, że jest konieczność, aby został u was tworzony zespół projektowy, który ma być crossfunckjonalny, czyli musi ssię składać z ludzi o różnych umiejętnościach, różnych specjalizacjach. Czy przy tworzeniu takiego zespołu bierzecie pod uwagę, aby były to osoby z różnych oddziałów, lokalizacji? Czy staracie się budować zespoły, które są lokalne i ta komunikacja jest szybsza, prostsza?
Piotr: Ciekawe pytanie. Musimy mieć osoby z różnych krajów, które pracują nad tym samym projektem. Tak jak wspominałem product team jest zaangażowany w to, co robią programiści. Oni ramię w ramię prowadzą dany projekt do przodu. Inaczej wygląda sytuacja z biurami w Polsce. Tutaj akurat nie jest tak łatwo pracować mając osoby z Białegostoku i osoby z Warszawy. Techniczne rzeczy są bardziej wymagające niż design nowego produktu czy projektu. Tutaj zauważyliśmy wiele problemów, które się pojawiają. Programiści nie do końca są przyzwyczajeni do pracy dosłownie na słuchawkach i komunikowania wszystkiego co się dzieje. Jeśli ta komunikacja nie jest bezpośrednia, nie jest naturalna, jak ta osoba, z którą pracujesz nie siedzi obok Ciebie, obok Twojego biurka, to pewne informacje pomijasz, pewne rzeczy nie wydają się, że mogą być interesujące dla drugiej osoby. Z tego powodu unikamy współpracy. Oczywiście ta współpraca istnieje cały czas, ponieważ niektóre działy mamy globalne, na całą Polskę, na przykład dział architektury, który ma ogromne doświadczenie i najważniejsze, aby komunikował się ze sobą, aby mógł proponować najlepsze rozwiązania. Taka praca w projekcie jest bardzo utrudniona. Jest możliwa, ale staramy się unikać, ponieważ zawsze dla takiego Product Ownera jest to o wiele trudniejsze, aby poprowadzić projekt, który jest w dwóch lokalizacjach. Często to wynika z naszej struktury, ponieważ mamy taką strukturę, że kolega Krzyś Majewski jest odpowiedzialny za biuro w Białymstoku, za kilka zespołów tam. Ja jestem odpowiedzialny za warszawski team. Tutaj kłócą się te zależności. Ludzie w Białymstoku, ludzie w Warszawie mają swoich managerów, więc przy projektach, które łączą dwa teamy w różnych miastach istnieje konflikt dwóch managerów. To trzeba jakoś rozwiązywać. Z innymi krajami bardzo współpracujemy, natomiast wewnętrznie staramy się separować projekty.
Musimy mieć różne osoby z różnych krajów, które pracują nad tym samym projektem, ale nie jest łatwo tak pracować
Krzysztof: W jaki sposób w sytuacji, kiedy do projektu kontrybują różne zespoły, zarządzacie cyklem wytwarzania oprogramowania, jego architekturą, deploymentem? Jak to się u was rozwiązuje?
Piotr: To temat bardzo szeroki. Myślę, że jesteśmy na takim etapie, że jeszcze dużo przed nami, zwłaszcza jeśli chodzi o depoyment, CI i wszystkie rzeczy związane z tym, aby wypuszczać kod na produkcję. To, co mamy w tej chwili i co nas blokuje, to jest kawałek monolitu w PHP-ie, starego kodu, który jest przepisywany, ale dopóki nie zostanie do końca przepisany, to jest pewnym blokerem. Każde repozytorium, każdy mikroserwis jest powiązane z tym corem, który jest w PHP-ie. Ten PHP jest wspólnym repozytorium, to musi istnieć kolejka taki releasów. Trzeba sobie zabookować dany termin o danej godzinie i wtedy postarać się, aby bezbłędnie ten release się udał. Zazwyczaj jeszcze dwóch architektów lub dwóch Product Ownerów czeka na wolny slot, bo też chcą coś wypuścić. Staramy się releasować jak najczęściej. Codziennie mamy po kilka lajwów. Tak to było od zawsze. Gromadzenie kodu nie jest niczym dobry, bo robią się konflikty. Ludzie nie mają poczucia, że coś skończyli, tylko mają świadomość, że coś wisi, więc staramy się to wszystko wypuszczać jak najszybciej pomagając sobie przy tym rozwiązaniami, tak, aby wypuszczać każdy projekt tylko do małej części użytkowników, których można sobie włączyć przez panel administracyjny aplikacji. My możemy to robić, ale też Customer Support, który często lepiej wie jakim klientom należy w pierwszej kolejności udostępnić nową funkcjonalność. To tak mniej więcej z ogólnego zarysu to wygląda.
W szczegółach to jesteśmy oparci o Kubernetes, czyli środowisko kontenerowe, dockerowe. Uczestniczymy bardzo często w konferencjach na temat Kubernetes organizowanych przez Google. Google nas traktuje jako ekspertów. Pewnie dlatego, że jak się pojawiamy na takiej konferencji, to mamy wianuszek ludzi, którzy dopytują się o szczegóły integracji. Często nasi ludzie są ekspertami, którzy już mają to za sobą i potrafią odpowiedzieć na każde pytanie. Google jakiś czas temu mówił, że byliśmy największą lub w pierwszej trójce firmą, która najbardziej używała Kubernetesy. Z Google jesteśmy partnerami na różnych płaszczyznach, ze względu, że ścieżka biznesowa jest bardzo podobno. Dużo rzeczy łączy nas technicznie. Kubernetesy wprowadzamy aktualnie terraform , który pomoże nam tworzyć środowiska o wiele sprawniej i ten deployment do nowych projektów będzie o wiele łatwiejszy do zrealizowania. Mamy CI w Gitlabie. Ogólnie wizja na to wszystko jest taka, żeby oddać te rzeczy, takie infrastruktury deweloperom. Takie są aktualne trendy na świecie, między innymi takie tematy jak servelless czy function as a service pokazują, że deweloper bardzo chętnie mógłby wziąć odpowiedzialność za cały proces deployowania i infrastruktury. Wizja jest taka, aby nasza wewnętrzna architektura była instytucją bardziej doradzającą, która może zaproponować najbardziej wydajne rozwiązanie, ale też aby szkoliła deweloperów, żeby oni mogli we własnym gronie, we własnym teamie scrumowym mając dewopsa do wykorzystania, aby mogli samodzielnie się zajmować takimi rzeczami. Myślę, że będzie to fantastyczne rozwiązanie, ale potrzeba na nie trochę czasu. Ogólnie deployment nie jest naszym najlepszym tematem. Jeszcze tego do końca nie ogarnęliśmy, ale droga jest bardzo fajna.
Droga do deploymentu nie jest łatwa, ale idziemy w dobrym kierunku
Krzysztof: Brzmi to nieźle. Kontynuując tematy bardziej techniczne, chciałem Cię zapytać jakie macie praktyki i podejście do wewnętrznej dokumentacji technicznej. Czy to jest dodatkowa praca, narzut, czy może niezbędny element?
Piotr: Oczywiście jest to dodatkowa praca. Jest to bardzo dużo dodatkowej pracy. Niestety trzeba ją wykonać. Zwłaszcza przy dziale technicznym składającym się ze 100 osób niestety jest to rzecz wymagana. Mamy to wpisane w nasze własne definition of done. Każdy projekt musi mieć przynajmniej część automatów, przynajmniej na część ścieżek krytycznych. Najlepiej na wszystkie ścieżki krytyczne. Musi mieć testy performance wykonane. Bez tego żaden kod nie znajdzie się na produkcji. Musi mieć testy jednostkowe. Przynajmniej pokrycie w 85% jak nie więcej. To jest core naszej dokumentacji technicznej. Te rozpisane ścieżki techniczne do tego automatu, performance testy, testy jednostkowe, w całości stanowią coś, co pozwala na pracę w rozproszonych teamach. Dzięki temu każdy team jest w stanie dodać kod do nieswojego repozytorium, do repozytorium, którego nie jest opiekunem. I upewnić się, że ten kod będzie działał, wykorzystując te narzędzia. To wszystko musi być zamknięte we wspólnym coding standardzie, coding stylingu. Bez tego w ogóle nie ma możliwości, żeby pracować. Musimy mieć spójny kod. To jest wystarczające do tego, aby programista był w stanie zrozumieć pewne mechanizmy, funkcjonalności, części kodu, jeśli są napisane niezbyt skomplikowanie. Ze współpracy z product teamem są ustalane rozwiązania, to wtedy jest pewność, że kod jest dosyć prosty. To dają nam dokumentację techniczną. Oczywiście na wspólne części kodu mamy oddzielne dokumenty, które rozpisują poszczególne rzeczy. Takim wspólnym repozytorium jest na przykład nasz własny UIKit, czyli taka warstwa frontendowa – to są komponenty angularowe, zamknięte w material designie. Każdy zespół używa tego jako gotowy UI. Tam są i dokumenty napisane i każdy kod, który wchodzi do tego repozytorium jest sprawdzany przynajmniej przez parę osób, przez trzy osoby. Jest robiony code review, aby się upewnić, że wszystko ma ten sam wspólny standard i nie ma tam czegoś, co wywoła jakiś problem we wszystkich naszych późniejszych projektach. To jest wystarczające. Oczywiście można dalej pisać dokumentację techniczną bardziej szeroko, ale z naszego doświadczenia wynika to, że jest wystarczające.
Krzysztof: Czy w takich międzynarodowych zespołach IT niedopasowanie kulturowe jest realnym i częstym problemem? Czy według Ciebie da się w jakiś sposób temu zaradzić albo zmniejszyć wpływ?
Piotr: To może być problem. Na szczęście Stany Zjednoczone, kultura Amerykanów nie jest tak odległa od kultury europejskiej czy polskiej, czy rumuńskiej. Są to bardzo podobnie ludzie, natomiast na niektóre rzeczy inaczej patrzą. Niektóre rzeczy są dla nich bardziej ważne, a inne mniej. To są często drobnostki, które okazują się w trakcie komunikacji na dany temat. Nie są dużym problemem, natomiast czasami mogą być zalążkiem jakiegoś problemu. Bardzo łatwo jest czegoś nie powiedzieć drugiej stronie, co później okazuje się, że dla tej drugiej strony jest bardzo istotne. Komunikacja ze strony Stanów do Polski może być dla Polaków czasami zbyt bezpośrednia albo zbyt szorstka, pozbawiona empatii. To są skrajności. Tak naprawde nie jest. To jest sposób komunikacji, który nie ma za sobą emocji negatywnych. Jest po prostu komunikacją bezpośrednią. Między Polską a Rumunią nie ma żadnych barier, to jest bardzo podobno kultura. Nie widzę najmniejszych problemów. Całościowo, te problemy kultury nie są istotne. One same się naprawiają czy poprawiają w czasie wspólnej pracy między zespołami. Nawet całościowo jak na to patrzę, nie stanowią wyzwania czy problemu.
Całościowo, różne kultury nie są istotne. Jeśli pojawia się problem, to się rozwiązuje go między zespołami. Różnice kulturowe nie stanowią wyzwań
Krzysztof: Jestem ciekaw jak sobie radzicie z różnicą w strefach czasowych? San Francisco, a Warszawa, to chyba 9 godzin, prawda? Jestem ciekaw czy to ma jakieś przełożenie na to w jaki sposób pracujecie, w jaki sposób się komunikujecie?
Piotr: To ma ogromne znaczenie. Te 9 godzin to wystarczająco dużo, że wymaga planowania i wykorzystywania kalendarza, aby umawiać spotkania. To wpływa całkowicie na pracę, na każdy aspekt tej pracy. Bardzo ściśle pracujemy z product teamem, który jest w San Francisco, więc różnica 9 godzin jest bardzo potężnym czasem, gdzie nie można się skontaktować z nikim. Oczywiście wszyscy są do tego przyzwyczajeni. Ta inna strefa czasowa wymaga od osób, które komunikują się z tym teamem, który jest w drugiej strefie czasowej, tego, aby być dostępnym od godziny 16 do 18 przynajmniej. Mówię przynajmniej, bo czasami są sytuacje, gdzie jakieś spotkanie jest później. Cała firma znając wymagania i stopień poświęcenia danych ludzi odpowiedzialnych za komunikację, to staramy się wszyscy, aby te godziny nie były zbyt późne dla Polski, i zbyt wczesne dla San Francisco. Uzyskujemy kompromis, który jest akceptowalny i nie zaburza lifestyle poszczególnych osób, które są zaangażowane w tę komunikację. Czasami nie da się uniknąć takiego czegoś, że spotkanie jest o 20. Z tego względu, że w tym spotkaniu uczestniczy kilka osób w San Francisco, kilka osób z Polski i nie da się ustawić, nie ma pustego miejsca w kalendarzu, aby zrobić to lepiej, bo każdy jest zajęty zazwyczaj między polskim czasem 16-18, bo ma spotkania projektowe. Jest to duży problem. Dla product ownera jest to często sytuacja, że on ma świadomość, że ma 9 godzin, żeby odpowiedzieć na coś, więc nie odpowiada od razu, tylko ustala sobie to w ToDo dziennym, że musi odpowiedzieć, ale ma jeszcze na to 9 godzin, więc na spokojnie to sobie planuje. Czasami często potrzeba tych informacji ze strony product managera bardzo pilnie, więc wtedy pomaga to, że ludzie są zaangażowani w dany projekt od samego początku. Sami są w stanie odpowiedzieć sobie na większość pytań. Strefa czasowa jest ciężkim tematem i definiuje wiele procesów, które są w firmie.
Krzysztof: Temat znam, bo też miałem projekty robione dla firmy z San Francisco. Wiem na czym to polega. Fajną rzecz powiedziałeś na końcu. Ten pozorny problem, można postrzegać jako zaletę. To myślę, że to całkiem nowe spojrzenie. Zastanawiam się jakie rzeczy związane z pracą w firmach międzynarodowych w IT, o których tutaj nie powiedzieliśmy, o których myślisz, że warto byłoby wspomnieć w tym temacie.
Piotr: Z tych rzeczy rozmawialiśmy dużo o projektach i jak to wygląda. To wszystko spaja komunikacja. To jest największy problem, na którym trzeba się skupić. To nieustanne skupianie się na poprawie komunikacji. W „normalnych” firmach zazwyczaj są problemy komunikacyjne nawet między ludźmi, którzy są w tej samej lokalizacji. Tutaj jesteśmy w innych lokalizacjach, w innych strefach czasowych. Są drobne różnice kulturowe, które mogą spowodować coś nieciekawego. Komunikacja jest czymś, czym ja głównie się zajmuję. Zazwyczaj jeśli jestem blisko jakiegoś projektu, to dlatego, że ten projekt ma jakiś problem. Jak wszystko jest dobrze, to nie jestem potrzebny. Jak jest problem, to on wynika z komunikacji. To 90% i nawet więcej przypadków zajmuje kwestia problemów komunikacyjnych. To jest kluczowe dla działania firm, aby tę komunikację starać się poprawiać cały czas i cały czas dawać jej najwyższą rangę w liście innych problemów. Do tego też tworzyć należy jakies procesy, które to usprawniają – jakieś organizacje tej pracy. Ludzie są w stanie nie rozumieć się na tak wiele sposobów, że to jest nieprawdopodobne. To jedna rzecz, o której chciałem powiedzieć. Druga rzecz jest też trochę związana z komunikacją i jest to słownik pojęć. Trzeba mieć świadomość, że w słowniku pojęć mogą być różne definicje. Tutaj przykład jest taki, że wersja beta dla programisty jest zupełnie czymś innym niż wersja beta dla product managera. Dla product managera wersja beta oznacza skończony, stabilny produkt, który się testuje pod względem UX czy sam design tej funkcjonalności realizuje te potrzeby klientów. Dla programisty wersja beta to jest wersja, która ma błędy.
Krzysztof: Dziurawa.
Piotr: Dokładnie. Tutaj mogą być różnice z pojęciem, które wydaje się oczywiste. To nie jest oczywiste, kiedy nie można porozmawiać na żywo i dogadać się między wierszami. Z tą betą jest o tyle ważne, że może zaważyć na projekcie. Niezrozumienie na tym etapie jest bardzo ciężkie w skutkach. Słownik pojęć warto sobie wyjaśnić. Wspomniałem też o rekrutacji ludzi do działów, teoretycznie w innych miejscach. W Polsce rekrutujemy kogoś do zespołu w San Francisco, albo odwrotnie – w San Francisco rekrutujemy kogoś z gałęzi Polski, jakiegoś programistę. Tutaj trzeba mieć kickoffy przed takimi projektami, ponieważ różnice rynków pracy są tak różne, że bardziej być nie mogą. To jak ludzie na to patrzą, to są zupełnie inne spojrzenia. Głównie komunikacja jest najważniejsza rzecz, na którą trzeba zwracać uwagę.
Krzysztof: Tak jest. Podkreślamy szlaczkiem – komunikacja. Na koniec chciałbym Cię zapytać jakie wyzwania przed Instapage stoją na najbliższą przyszłość pod kątem rozwoju firmy, wzrostu liczby pracowników jak i ekspansji międzynarodowej?
Poznaliśmy naszego klienta idealnego. Wiemy, w którym kierunku idziemy. Jednym z naszych celów jest wejście na giełdę
Piotr: To jest ciekawy moment dla Instapage, bo nareszcie po wielu latach, po 30% życia naszego założyciela Tysona, ponieważ Tyson jest trochę młodszy od nas i u niego jest to 30% życia poświęconego na tę firmę, to po takim czasie wiemy dokładnie czego potrzebuje nasz klient. Taki idealny klient. Wiemy kim jest ten idealny klient. Tym idealnym klientem jest klient enterprise, czyli jest to duża agencja, która ma swoich klientów albo duży klient typu Eurosport, Ebay czy Uber. Oni są naszymi klientami, bo im najbardziej zależy na zwiększaniu skuteczności reklamy w internecie. To oni mają największe budżety i dla nich każdy procent to jest różnica milionów dolarów. Wiemy już na kim się skupiać i wiemy, czego potrzebują do realizacji swoich założeń. Prawda jest taka, że nasi klienci są zmuszeni do poprawiania swoich konwersji, ale nie chcą tego robić. Jeśli by nie musieli tego robić, to by tego nie robili. Naszym zadaniem jest to, aby jak najwięcej rzeczy zautomatyzować i jak najwięcej rzeczy udostępnić im, które sprawiają, że ich praca jest łatwiejsza. To są tak naprawdę cele do końca roku, ale pewnie na najbliższe parę lat. Naszym głównym celem jest pozyskanie jeszcze kilku dofinansowań od inwestorów. Docelowo wejście na giełdę. To jest cel każdej firmy IT w Dolinie Krzemowej, mimo że często firmy nie wchodzą na tę giełdę przez wiele lat, ale taki cel mają, aby zwiększać wartość firmy, ponieważ to jest gra zero jedynkowa. Albo się zwiększa wartość firmy, albo się bankrutuje po jakimś czasie. Nie można sobie przeczekać tego wszystkiego co się dzieje na bezpiecznym siedzeniu, tylko trzeba mocno iść do przodu, albo firmy odpadają. Celem jest rozwój albo te automatyzację. Mamy już podwaliny pod to, więc niedługo będą już powoli wychodzić projekty, nad którymi w tym momencie pracujemy, które będą dosyć innowacyjne i trochę zawojują rynkiem marketingowym. Trochę myślę, że ludzie będą mieli inne spojrzenie na to i wiele firm decyduje się na realizację pomysłów, który bali się wcześniej zrealizować, bo bali się o sprzedaż, o cały ogrom pracy wynikających z tego, aby sprzedać produkt. Z tymi rozwiązaniami będzie im o wiele łatwiej i będą mogli skupić się na prowadzeniu tych swoich biznesów, realizacji pomysłów, a niekoniecznie martwienie się o sprzedanie ich.
Krzysztof: Ambitne plany, trzymam kciuki. Dziękuję za poświęcony czas, za ciekawą rozmowę, w której naświetliłeś cienie i blaski pracy w międzynarodowych zespołach IT. Dzięki wielkie. Gdzie Cię można znaleźć w internecie?
Piotr: Niestety, nigdy nie uczestniczyłem projektach typowo opensourcowych, więc nie mam publicznego repozytorium, ale można mnie spotkać na meetupie ShipIt, który odbywa się w Warszawie mniej więcej raz na miesiąc. Aktualnie jesteśmy w biurze na Prostej 70 i tam zazwyczaj są dwie prelekcje techniczne. Meetup jest dla osób średniozaawansowanych i dla seniorów. Nie jest to zbytnio oryginalne, ale doceniane przez ludzi, którzy zazwyczaj nudzą się na innych tego typu meetupach. Zapraszam serdecznie. Tam można porozmawiać ze mną na żywo, a ogólnie mój profil jest na LinkedInie. Można znaleźć jakieś publikacje z moim udziałem w Internecie. Nie mam niestety jakiegoś linku ze swoją wizytówką.
Krzysztof: Jasne, to wszystko zalinkuję. Jeszcze raz dziękuję i do usłyszenia. Cześć!
Piotr: Dziękuję bardzo. Pozdrawiam.
Krzysztof: I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Praca w międzynarodowej firmie IT daje sporo możliwości poznania nowych kultur i wymiany doświadczeń, ale jest też wyzwaniem w zarządzaniu i komunikacji. Instapage jest firmą, która ma w tym względzie dużo doświadczeń, dlatego warto czerpać wiedzę i inspirację z tego, co mówił Piotr. Jeśli masz jakieś doświadczenia w tym temacie, to napisz na stronie podcastu lub na fanpage na Facebooku, na który serdecznie Cię zapraszam, jak i do kontaktu ze mną pod adresem krzysztof@porozmawiajmyoit.pl. Jeśli spodobał Ci się ten odcinek podziel się nim w Social media lub oceń w aplikacji, w której słuchasz podcastów. Miło mi było gościć w twoich uszach.
Nazywam się Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o pracy zdalnej w międzynarodowej firmie IT.
Zapraszam do kolejnego odcinka już za dwa tygodnie. Cześć!