POIT #272: Jak umiejętności miękkie, liderskie i managerskie pomagają developerom w codziennej pracy?

Witam w dwieście siedemdziesiątym drugim odcinku podcastu „Porozmawiajmy o IT”. Tematem dzisiejszej rozmowy jest to jak umiejętności miękkie, liderskie i managerskie pomagają developerom w codziennej pracy.

Dziś moimi gościem jest Jakub Kubryński – od niemal 20 lat aktywnie działa w branży IT, zdobywając doświadczenie na wielu stanowiskach: od programisty i architekta systemów, przez lidera zespołu, po menedżera i CEO. Specjalizuje się w zarządzaniu IT, optymalizacji procesów oraz architekturze systemów rozproszonych, łącząc to z leadershipem technologicznym i podejściem agile.

Sponsor odcinka

Sponsorem odcinka jest Devstyle.

W tym odcinku o soft skills dla programisty rozmawiamy w następujących kontekstach:

  • jakie soft skills pomagają najbardziej w awansie od developera do konsultanta i managera?
  • czy brak umiejętności miękkich może ograniczać rozwój kariery programisty?
  • jakie kompetencje miękkie są absolutnym “must-have”?
  • jak umiejętności miękkie mogą poprawić jakość codziennej pracy programisty?
  • czy programiści są dobrzy w soft skille?
  • czy programista, który nie chce być liderem, nadal powinien inwestować w rozwój tych umiejętności?
  • jak się doskonalić w tych umiejętnościach?
  • jak szkolenie „Horyzont Lidera” może pomóc w rozwoju soft skills w przypadku programisty?

Subskrypcja podcastu:

Linki:

Wsparcie na Patronite:

Wierzę, że dobro wraca i że zawsze znajdą się osoby w bliższym lub dalszym gronie, którym przydaje się to co robię i które zechcą mnie wesprzeć w misji poszerzania horyzontów ludzi z branży IT.

Patronite to tak platforma, na której możesz wspierać twórców internetowych w ich działalności. Mnie możesz wesprzeć kwotą już od 5 zł miesięcznie. Chciałbym oddelegować kilka rzeczy, które wykonuję przy każdym podcaście a zaoszczędzony czas wykorzystać na przygotowanie jeszcze lepszych treści dla Ciebie. Sam jestem patronem kilku twórców internetowych i widzę, że taka pomoc daje dużą satysfakcję obu stronom.

👉Mój profil znajdziesz pod adresem: patronite.pl/porozmawiajmyoit

Pozostańmy w kontakcie:

 

Muzyka użyta w podcaście: „Endless Inspiration” Alex Stoner (posłuchaj)

Transkrypcja podcastu

To jest 272. odcinek podcastu Porozmawiajmy o IT, w którym z moim gościem rozmawiam o tym, jak umiejętności miękkie, liderskie i managerskie pomagają developerom w codziennej pracy. 

Wszystko, co potrzebujesz, notatka, linki, transkrypcja czekają na Ciebie na porozmawiajmyoit.pl/272. 

Sponsorem tego odcinka jest Devstyle. 

Dzisiaj mam coś wyjątkowego dla każdego, kto chce podnieść swoje umiejętności na nowy poziom, niezależnie czy jesteś seniorem w IT, czy dopiero zaczynasz myśleć o rozwoju w kierunku lidera. Chciałbym przedstawić Ci pierwsze tak kompleksowe szkolenie z zakresu soft skills i przywództwa w polskim IT, które już teraz podbiło serca ponad 700 osób w przedsprzedaży. Mowa o Horyzoncie Lidera – szkoleniu przygotowanym przez dwóch topowych ekspertów Jakuba Kubryńskiego, ex-developera, lidera, CEO DevSkiller oraz Marcina Dakowskiego, który zdobywał doświadczenie w InPost i McKinsey, a obecnie jest doradcą zarządów firm. 

To osoby, które wiedzą, co robią, i co ważniejsze wiedzą, jak przekazać tę wiedzę Tobie. Czego możesz się spodziewać? 14 tygodni praktycznej nauki, która obejmuje wideo, audio, ćwiczenia oraz dostęp do społeczności na Discordzie. Dzięki temu nie tylko zdobędziesz wiedzę, ale od razu nauczysz się ją wdrażać w codziennej pracy. A w czasach, gdy AI zmienia rynek, to właśnie ludzkie umiejętności jak komunikacja, współpraca i przywództwo decydują o Twojej wartości. 

Co więcej, to szkolenie jest dla każdego. Nie musisz być liderem zespołu ani chcieć nim zostać, by skorzystać z tych kompetencji. Będą one przydatne przez całą Twoją karierę w IT. 

Pierwsza edycja startuje w lutym 2025, a jakość tego projektu gwarantuje zespół Devstyle pod wodzą Macieja Aniserowicza, twórcy takich hitów jak Domain Drivers czy Droga Nowoczesnego Architekta. Nie przegap tej szansy na inwestycję w siebie i swoje kompetencje. Wejdź na horyzontlidera.pl i zapisz się już dziś. 

Ja się nazywam Krzysztof Kempiński, prowadzę ten podcast oraz jestem autorem książki Marka osobista w branży IT. Mam misję polegającą na poszerzaniu horyzontów ludzi w branży IT. Tak się składa, że możesz bardzo mi pomóc w jej realizacji poprzez wystawienie oceny w aplikacji, w której tego słuchasz, lub podzielenie się odcinkiem w social mediach. A teraz zapraszam Cię już do odcinka. 

Odpalamy! 

 

Cześć! 

Mój dzisiejszy gość od niemal 20 lat aktywnie działa w branży IT, zdobywając doświadczenie na wielu stanowiskach. Od programisty i architekta systemów, przez lidera zespołu, po managera i CEO. Specjalizuje się w zarządzaniu IT, optymalizacji procesów oraz architekturze systemów rozproszonych, łącząc to z leadershipem technologicznym i podejściem Agile. Moim i Waszym gościem jest Jakub Kubryński. 

Cześć, Kuba, bardzo miło mi gościć Cię w podcaście. 

 

Cześć, Krzysiek, mi również jest miło, dzięki za zaproszenie. 

 

Przyjemność po mojej stronie. A dzisiaj wraz z Kubą będziemy odczarowywać mit o tym, że na stanowisku developera absolutnie niezbędne i jedynie niezbędne są umiejętności techniczne. Powiemy o umiejętnościach tzw. miękkich, liderskich, managerskich i jak one mogą się przełożyć na lepszą codzienną pracę, a także myślę sobie w dłuższym terminie na wzniesienie tej naszej kariery developerskiej na wyższy poziom. 

Zanim do tego jednak przejdziemy, to chciałbym Cię, Kuba, standardowo jak to u mnie, bywa zapytać, czy słuchasz podcastów i może masz jakieś ciekawe audycje, o których chciałbyś tutaj powiedzieć, zachęcić słuchaczy do słuchania? 

 

Jeśli chodzi o podcasty, to raczej skupiam się na pojedynczych odcinkach, które mnie gdzieś tam zainteresują, a tak to ten czas taki, który ludzie z reguły poświęcają na podcasty, staram się poświęcać na audiobooki i to raczej takie nie zawodowe, a jakieś szpiegowskie czy kryminalne, więc jestem bardziej fanem Vincenta Severskiego i Marcina Ciszewskiego niż takich podcastów merytorycznych, tak w ramach takiego, wiesz, work-life balance, który można by zachować. 

 

Bardzo słusznie, rozrywka też jest nam niezbędna. Dobrze, wiesz, na początku chciałbym rozpocząć trochę od Twoich takich doświadczeń związanych z karierą, z Twoim właśnie rozwojem zawodowym, bo łatwo się mówi po iluś tam nastu czy 10 latach, jak w Twoim przypadku, że wiesz, idź w tym kierunku, wybierz ten sposób rozwoju, bo to będzie miało dla Ciebie dobre przełożenie i wpływ na Twoją karierę, ale znacznie trudniej jest być tego świadomy, kiedy stoisz na początku tej kariery.

Więc rozpocznijmy od tego, jak to wyglądało w Twoim przypadku, jaką rolę te nasze tytułowe umiejętności miękkie, liderskie, managerskie odegrały w Twojej karierze i czy od samego początku wiedziałeś, że inwestowanie swojego czasu albo rozwijanie tych kompetencji, tych umiejętności ma sens i będzie miało istotne znaczenie? 

 

To tylko jeszcze dygresja, ja się zgadzam z tym, co teraz powiedziałeś, dlatego też warto słuchać bardziej doświadczonych ludzi, którzy nam mówią, jak się rozwijać na tym początku, bo w innym wypadku możemy tylko liczyć na szczęście. Ja akurat trochę tego szczęścia miałem. 

Zaczynałem w 2004 roku swoją profesjonalną karierę, to były zupełnie inne czasy. Ja zacząłem od pracy w takiej małej firmie, która robiła soft dla urzędów różnego rodzaju, urzędów powiatowych, gminnych itd. I z racji tego my tak naprawdę byliśmy od samego początku zmuszeni trochę do tego, żeby jeździć do tych urzędów, do naszych klientów i rozmawiać z nimi, robić im demonstracje jakiegoś tam programu, pytać co im pasuje, co nie pasuje itd. 

W związku z tym ja trochę nie miałem wyboru i te kompetencje miękkie musiałem budować już od samego początku i tam szef nas strofował, jak wy wyglądacie, nie można tak jechać do klientów, jechać do domu się przebrać i wracać mi tutaj za chwilę. I potem też jak tam ktoś coś powiedział, że nie, no to tak nie może działać, to on mówi: zamknij się, co ty tam wiesz o tym. Skile miękkie miał rozwinięte bardzo biznesowo, niekoniecznie w kontekście też tam zarządzania ludźmi, natomiast faktycznie bardzo prokliencko działaliśmy w tej firmie i myślę, że ja generalnie na takim podejściu proklienckim zbudowałem gdzieś tam w dużej mierze swoją karierę. 

Dlatego że to mi pokazało, że to ludzie używają tego softu. Ja w ogóle wtedy miałem taki pierwszy raz przeświadczenie, że ci ludzie to dużo lepiej znają ten soft niż ja, gdzie ja ten soft pisałem. I oni często takie haki tam znali i takie obejścia robili, a byli tak szybcy, wiesz, to byli ludzie, którzy pracowali na tym softie 8 godzin dziennie. Więc oni wszystkie skróty klawiszowe mieli w głowie i po prostu jak ja widziałem, jak te okienka się przełączają, to był taki soft desktopowy, to byłem w szoku, że po prostu oni byli dużo lepsi w tym ode mnie. 

I to zbudowało takie poczucie pokory i później, jak pracowałem w jakimś tam Telekomie, to rozumiałem, że ci sprzedawcy, dla których robimy soft, to to jest nasz klient, oni muszą być zadowoleni, jak oni się czują, jeżeli ktoś tam czeka, aż się długo przeprocesuje coś, bo się kręci. I też wtedy prosiłem, żebyśmy mogli odwiedzać salony, rozmawiać z tymi ludźmi, patrzeć na to, jak się dzieje, bo to takie bardzo duże zdziwienie, że ale jak to co, chcę zobaczyć. Chcę zobaczyć, jak oni z tego korzystają, pogadać z nimi. O, ty się nie wtrącaj, to nie twoja rola, wiesz, jak to w korpo. Koniec końców tam nam pomogli, więc wydaje mi się, że to było u mnie kluczem, jakby jeśli chodzi o początek, że faktycznie od razu byłem wrzucony w tego klienta.

I nawet teraz jest często tak, że ludzie z IT nie chcą rozmawiać z klientami i uciekają od tego, a wydaje mi się, że to jest kluczem i te wszystkie umiejętności miękkie, o których mówimy w tej chwili, to jest tak nawet coś, co pomaga gdzieś tam właśnie ludziom być bliżej klienta, bliżej tego biznesu i budować taką partnerską relację, a nie władca i podwładny, gdzie tym władcą jest IT, żeby było jasne. 

 

No tak. Okej, to są takie, wiesz, zupełne początki, które opisałeś. Za chwilę będę chciał trochę rozpakować ten worek podejścia proklienckiego, bo myślę, że to jest tutaj zbiór różnych umiejętności, który ładnie zamknąłeś w tym stwierdzeniu, ale idąc dalej w Twojej karierze, bycie menedżerem, bycie CEO, domyślam się, że to jeszcze bardziej wymaga pogłębienia tych umiejętności, które tutaj na początku wymieniłeś, prawda? 

 

Tak, to są w ogóle jakby dwie zupełnie inne role, bo rola managera to jest bardzo skupianie się na ludziach i to jest taki nasz sweet spot. Natomiast z rolą CEO jest trochę inaczej, bo CEO jest odpowiedzialny za ludzi i oczywiście ten leadership tutaj jest bardzo ważny, ale CEO też w bardzo dużej mierze jest sprzedawcą, i to CEO odpowiada też za wyniki firmy, z reguły te największe deale też są dopinane przez CEO, więc to było dla mnie takie, jakby wiesz, kolejne, że teraz ja muszę, kurde, robić znowu coś innego i tak jak już w miarę ogarnąłem tę pracę z ludźmi, jakieś takie umiejętności bardziej managerskie niż liderskie, to teraz muszę skupić się na sprzedaży.

I na pewno jest tak, że są pewne rzeczy, które są wspólne. Na pewno empatia, taka na zasadzie, żeby widzieć czy rozumieć zachowanie odbiorcy, to jest coś, co przydaje się w pracy trenera. Kiedy widzisz, że coś mówisz i ktoś się z Tobą nie zgadza i mówisz, okej, to jest ten moment, kiedy ja muszę powiedzieć: okej, widzę, że tutaj mamy różne zdanie, z czym się nie zgadzasz z tego, co powiedziałem? I ludzie: nie no, ja się zgadzam. Dobra, wydaje mi się, że nie, więc masz ostatnią szansę. Dobra, uważam, że to jest bez sensu, u nas się nie sprawdzi itd. Więc to jest jedna rzecz. 

Tak samo ta empatia ma znaczenie w przypadku pracy z ludźmi, kiedy gadamy z kimś, przydzielamy komuś zadanie, wrzucamy w nowy obszar, też musimy wyczuć, jak ten ktoś reaguje. I tak samo na spotkaniach sprzedażowych, gdzie jak ja sprzedaję komuś, to muszę zobaczyć, czy to, co mówię, rezonuje, sprawdzić itd. 

Ja też uważam, że to nie jest tak, że człowiek się albo rodzi z empatią, albo się nie rodzi z empatią. To jest po prostu pewna kompetencja, którą można zdekomponować do umiejętności. Jeżeli ja np. miałem kiedyś empatię na poziomie zero i miałem zerowe wyczucie tego, jak ktoś reaguje, to po prostu mówili mi: to pytaj, zapytaj kogoś, jak się z tym czujesz, czy to jest to, co ci zależało, czy na pewno jesteś z tym okej, tak? Nawet w spotkaniach sprzedażowych, czy to, co mówię do Państwa, to jest to, co Państwo chcieliby usłyszeć, czy to nie jest za wysoko albo za nisko, czy ja nie mówię za szczegółowo, za mało szczegółowo, tak? Czy mówię o tych use case’ach, które Was interesują, więc tego się można nauczyć, nie? Więc tak, to ta empatia. 

Druga rzecz, która się z tym łączy, to jest też umiejętność komunikowania się w języku odbiorcy. I tu znowu nie mówię tylko o języku takim, że nie wiem, w DevSkillerze akurat mamy dużo ludzi z zagranicy, nasz szef marketingu jest Australijczykiem, szef obsługi klientów sprzedaży jest Amerykaninem itd., ale kwestia właśnie dogadania się, jak Sławek Sobótka mówił w języku obcych form inteligencji. 

I tutaj z mojego doświadczenia super działają metafory, bo jeżeli komuś tłumaczę frontend, backend, to to ktoś nie załapie. Muszę znaleźć jakąś taką metaforę, gdzie jestem w stanie do ich świata, ich języka to odnieść, i to jest coś, co mi super pomagało, zwłaszcza w pracy konsultanta, jak byłem w stanie podejść do kogoś i powiedzieć: słuchajcie, no bo z tym to jest tak jak u Was tam z czymś, albo to jest trochę tak jak z samochodem itd., czyli szukać czegoś takiego, co jest zrozumiałe dla każdego.

 

Wymieniłeś całkiem sporo tych różnych umiejętności. Oczywiście domyślam się, że nabywałeś je, że tak powiem, sukcesywnie, prawda? To pewnie wymaga czasu, wymaga doświadczenia, wymaga też ekspozycji właśnie na tego typu sytuacje. Pewnie jeszcze sobie chwilę o tym porozmawiamy, żeby próbować, jeśli nie mamy takiej możliwości w naszych zespołach, samemu gdzieś wychodzić trochę może przed szereg, żeby mieć szansę do rozwijania tych kompetencji. 

Ale jeszcze ostatnim momentem zatrzymajmy się na rozwoju Twojej kariery, bo mówiłeś o tym podejściu proklienckim. Zechciałbyś rozpakować trochę, jakie z tych umiejętności miękkich najbardziej według Ciebie zaważyły i czy można przełożyć takie podejście proklienckie na zespoły, na wewnętrznego klienta, o tak bym go może nazwał?

 

Na wewnętrznego klienta na pewno, bo tak jak właśnie pracowałem w Orange, to tamtym wewnętrznym klientem byli ludzie z naszej sprzedaży, którzy sprzedawali nasze usługi i wydaje mi się, że tutaj to, co mówiłem trochę o empatii, ale też taka empatia w kontekście takiego postawienia się w roli drugiej osoby. Jak ja bym się czuł, gdybym był na miejscu tego człowieka. 

Czasem są takie sytuacje, że mówimy, że tam jakiś error wyskakuje. No dobra, wyskakuje, ale to można go zamknąć. No fair enough, ale jak klikam to 300 razy dziennie, to może mnie to irytować. Czyli jakby tak postawić się trochę w tej roli, i ja też zawsze jak choćby w DevSkillerze dostaję jakieś requesty od klientów, nawet jak one są jakieś takie dziwne i czujesz mentalnie, że się z nimi nie zgadzasz, to też, zamiast im mówić, że to jest bez sensu, nie będziemy tego robić, to staramy się zrozumieć, okej, opowiedzcie mi, z czego wynika ta potrzeba, co takiego się dzieje, że wy coś takiego musicie zrobić, bo może znajdziemy po prostu jakieś inne rozwiązanie tego. 

Bardzo często klienci przychodzą z pewnym pomysłem na rozwiązanie, a nie problemem i to Ty musisz dojść do tego, jaki tam faktycznie jest problem i czy to na pewno jest dobre rozwiązanie. To jest trochę taki, wiesz, case tzw. technicznych product ownerów, którzy przychodzą i mówią, słuchajcie, taki feature musimy zrobić, ja to już zaprojektowałem i sobie myślę, że tutaj damy taką tabelkę i tak… Nie, stary, nie zaprojektowałeś, powiedz nam, co trzeba zrobić, a zespół wykmini, jak to zrobić, czy to będzie tabelka, czy to nie będzie tabelka, czy to będzie w tej bazie, czy w innej, nie wpierdzielaj się, tylko powiedz nam, o co chodzi. 

I często ludzie mają tak, że fiksują się na jakieś rozwiązanie, Ty nie do końca znasz problem i zaczynasz rozwiązywać ten case, o którym oni mówią, potem to jeszcze okazuje się, że oni to trochę rozwiązali i to modyfikujesz, i okazuje się, że po tej modyfikacji tego rozwiązania już zupełnie inny problem rozwiązujesz i można go zupełnie inaczej rozwiązać, więc wydaje mi się, że to jest kluczowe. 

I to podobnie też będzie w przypadku ludzi, bo jeżeli masz jakieś konflikty w zespole, czy jakieś problemy, zespół nie dowozi itd., to zespół często przychodzi z jakimś rozwiązaniem, a okazuje się, że problem jest w zupełnie innym miejscu i ja to nazywam takim root cause analysis, to jest moim zdaniem taka umiejętność, która jest bardzo uniwersalna i ona jest wymagana zarówno przy jakiejś tam, nie wiem, optymalizacji pracy zespołu, zmiany struktur, jak i właśnie przy pracy z biznesem, czy to wewnętrznym, czy zewnętrznym, gdzie faktycznie ryjesz do gleby, żeby zobaczyć, gdzie jest ten prawdziwy problem, który powinieneś rozwiązywać.

Czasem są takie sytuacje, że mówimy, że tam jakiś error wyskakuje. No dobra, wyskakuje, ale to można go zamknąć. No fair enough, ale jak klikam to 300 razy dziennie, to może mnie to irytować. Czyli jakby tak postawić się trochę w tej roli, i ja też zawsze jak choćby w DevSkillerze dostaję jakieś requesty od klientów, nawet jak one są jakieś takie dziwne i czujesz mentalnie, że się z nimi nie zgadzasz, to też, zamiast im mówić, że to jest bez sensu, nie będziemy tego robić, to staramy się zrozumieć, okej, opowiedzcie mi, z czego wynika ta potrzeba, co takiego się dzieje, że wy coś takiego musicie zrobić, bo może znajdziemy po prostu jakieś inne rozwiązanie tego.

 

Dobrze, to idźmy dalej. Jak się popatrzy na wiele takich opisanych ścieżek kariery w różnych firmach, jak się możesz rozwijać, jak tam możesz awansować, to dla tych stanowisk technicznych tam masz morze różnych właśnie tematów związanych z językiem programowania, z frameworkiem, bibliotekami, architekturą itp. Mnóstwo tych hard skill jest tam wymienionych, ale mam wrażenie, że coraz bardziej też tam się zaczynają pojawiać różne umiejętności z gatunku tych miękkich. 

Może to jest tylko moja bańka informacyjna, ale mam wrażenie, że coraz bardziej firmy zauważają jednak istotność tych zespołów. Oczywiście pracujemy w zespołach, więc trudno by było, żeby tylko tam roboty pracowały, ludzie też nie muszą ze sobą dogadywać. 

Czy w związku z tym myślisz, że takie niezadbanie o ten rozwój umiejętności miękkich może ograniczać rozwój kariery programisty? 

 

Tak, tutaj trafiłeś w temat, bo ja się zawodowo zajmuję mapowaniem i zarządzaniem umiejętnościami kompetencji i to jest nasz konik. Ja jestem w ogóle bardzo dużym fanem takiego podejścia skills-based organizations, czyli organizacji opartych na umiejętnościach, a nie na rolach zawodowych, czyli nie interesuje nas, że to jest tam starszy programista Java, to jest tam młodszy inżynier chmury, jest zadanie do zrobienia, robi to ten, kto umie, czyli trochę takie, wiesz, drugie podejście do tego, że korporacje chcą być startupami. Najpierw był Agile, to nie zadziałało i teraz jest takie podejście, może skills-based będzie, też jest trudne, ale jakby ma sens, tak jak Agile ma sens. 

Tutaj są dwa wątki, takie jak ja ze swojego doświadczenia zawodowego obserwuję. Przede wszystkim umiejętności twarde są dużo prostsze do zarządzania, do zmapowania, do opisania itd., bo tutaj mówimy często o umiejętnościach, czyli czegoś, co ma jakąś konkretną wiedzę, uczę się tego i ogarniam. Mam się nauczyć konfigurowania jakichś tam filtrów w Springu, ok, szkolenie, konfiguracja filtrów w Springu, jazda, ogarnięte, odhaczone, jakiś test zrobię, zadanie domowe. 

 

Weryfikowalne, no nie? 

 

Tak, i bardzo takie jasne, klarowne itd. Z umiejętnościami miękkimi tak naprawdę my mówimy o umiejętnościach miękkich, ale bardziej tak naprawdę mówimy wtedy o kompetencjach, czyli o czymś, co łączy już wiedzę, umiejętność z pewną postawą, doświadczeniem, zachowaniem itd. To jest już dużo trudniejszy temat. 

I teraz to, co my robimy, pracując z klientami, i to z reguły jest druga iteracja tego, czyli zaczynamy od tych umiejętności twardych po to, żeby dać coś namacalnego szybko, a później dekomponujemy to, o czym mówimy, czyli te postawy, do konkretnych umiejętności. Dlatego, że bardzo trudno uczy się postaw. 

Ciężko jest kogoś nauczyć asertywności. No bo wiesz stary, musisz bardziej się tutaj stawiać. No nie, to tak nie działa. Ciężko jest uczyć asertywności. Mogę uczyć pewnych umiejętności, które pomagają być bardziej asertywnym. Czyli mogę uczyć szacowania, priorytetyzacji, jakiegoś tam aktywnego słuchania, umiejętności odmawiania itd. I to wszystko buduje w sobie taką asertywną postawę. Natomiast zarządzanie tym jest dużo trudniejsze. 

To jest tak samo jak performance ludzi. Czasem masz ludzi, którzy wszystko wiedzą, ale jakoś kurde nie idzie, to nie mają tego performance’u i z czego to wynika. I teraz takie świadome HR głównie się tym zajmują w tej chwili, że próbują wybadać ten potencjał i performance ludzi i zobaczyć, z czego to wynika, co takiego mają wspólnego ze sobą ci ludzie, którzy dowożą, versus ci, którzy są super wyskillowani twardo, a nie dowożą, jestem taki black box, siedzę w piwnicy, robię kod, zamieniam kawę na kod. No i to nie działa. 

I z tymi umiejętnościami miękkimi właśnie bardzo często okazuje się, że my jesteśmy w stanie nawet to zmapować, ale cały czas w IT jest duży opór dotyczący tego, że co tam ja będę gadał z biznesem, jak oni nic nie wiedzą, oni nic nie rozumieją, jakby gdybyśmy nie my, to by ta firma padła itd. I to jest gdzieś tam wymaganie. 

Więc moim zdaniem jest świadome, że te kompetencje miękkie są potrzebne i że je trzeba budować, ale po pierwsze trudno jest to zrobić, bo właśnie trzeba wykonać trochę pracy i zdekomponować postawy do kompetencji, a kompetencje do umiejętności, wiedzy, doświadczenia, nauczyć się to nabywać, a po drugie trzeba przekonać też ludzi, którzy jeszcze mają to podejście: nie po to kończyłem informatykę, żeby gadać z ludźmi, że to jest the way to go. 

 

To wobec tego, jakie umiejętności są, z tych miękkich oczywiście, tutaj z tego worka, jakie według Ciebie są takim zupełnym must have, bez których ciężko byłoby sobie wyobrazić takiego dobrze zdefiniowanego programisty w dzisiejszych czasach?

 

Tak, bo to jakby też warto powiedzieć, że trochę inne będą umiejętności dla lidera czy dla managera, inne dla programisty. Bo tak jak w kontekście lidera, managera, jakbym miał powiedzieć, jaka jest jedna taka kluczowa rzecz, to, żeby po prostu być autentycznym, czyli brać odpowiedzialność za to, co robię i jeżeli ja nie chcę czegoś zrobić, to nie zasłaniać się innymi, nie mówić: wiesz, no ja bym ci tutaj wysłał na to szkolenie, ale tam dział szkoleń mnie bardzo… No nie, jeżeli Ty uważasz, że ktoś nie powinien jechać na jakąś konferencję, to mu to powiedz, a nie zasłaniaj się innymi. I to jest taka kluczowa rzecz, bez której, jak tego nie masz, to ludzie po prostu nie będą Cię szanowali. 

A w przypadku programistów wydaje mi się, że właśnie kluczowe będzie po pierwsze umiejętność aktywnego słuchania, czyli że potrafię się zamknąć i posłuchać. I to jest pierwsza rzecz. Z tym się też wiąże często umiejętność przyjmowania, dawania feedbacku. Często my mamy w IT tak, że jak ktoś nam zaczyna dawać feedback, to ja się zaczynam kłócić, że Ty nie masz racji, to wcale tak nie jest, ja się wcale tak nie zachowuję. Kiedy się tak zachowałem? Weź mi tutaj, nie insynuuj. I to jest druga rzecz. 

A trzecia to właśnie ta umiejętność postawienia się w roli użytkownika, czy też jakiegoś tam partnera itd. i zrozumienia jego potrzeb. Nie tego co on chce, bo to często ma niewiele wspólnego z potrzebami, tylko dojście do tego, co tak naprawdę dla nich jest ważne, i spełniania tych potrzeb.

I last but not least umiejętność takiego komunikowania się, żeby to wszystko zadziałało, bo jak ja do biznesu będę mówił twardym językiem, takim, że oni nie będą rozumieli, o co mi chodzi, to nawet jak będę próbował ich zrozumieć, ale będę to mówił w taki sposób, że do nich to nie dotrze, to to niewiele przyniesie. 

 

Wspomniałeś, że świadome HR-y coraz bardziej wierzą w to i widzą sens rozwoju właśnie umiejętności miękkich wśród developerów, wśród osób technicznych. Ci na końcu wspomniani niekoniecznie zawsze są świadomi, że to jest no właśnie chyba już must have, tak można byłoby śmiało tutaj powiedzieć, więc poruszając się w takiej bardzo pragmatycznej branży, jaką jest IT, może gdybyśmy spróbowali w jakiś sposób zareklamować programistom potrzebę rozwijania tych kompetencji miękkich, to myślę sobie, że najłatwiej by to było zrobić poprzez powiedzenie albo wymienienie tych właśnie umiejętności, które zwyczajnie przydadzą im się w codziennej pracy, które spowodują, że ta ich praca będzie bardziej satysfakcjonująca, te efekty będą bardziej zadowalające, że będzie im się zwyczajnie lepiej na co dzień pracowało. 

To jeśli byśmy mieli właśnie takie podejście tutaj takie ćwiczenie sobie zrobić, to które umiejętności według Ciebie przyczynią się, przełożą się w taki dość jednoznaczny, bezpośredni sposób na to, że po prostu zwyczajnie na co dzień będzie nam się lepiej pracowało? 

 

Tak jak ja rozmawiam z biznesem i to już od wielu, wielu lat, od nastu lat, to biznes ogólnie nie lubi IT. Uważają, że IT to jest często taka banda dupków, którzy chcą wszystkim udowodnić, że inni są debilami. To jest cytat i to nie jeden, tylko wiele razy to słyszałem. I mi też często mówili, że oni lubią ze mną rozmawiać, bo ja im nie udowadniam, że oni nic nie wiedzą. I to jest kluczem, czyli trochę takiej pokory, ale nie na zasadzie takiej, że teraz będę ludzi traktował jak dzieci. Tak, tak, ja wam zaraz tutaj wytłumaczę, siadajcie, tylko nie przerywajcie itd., tylko faktycznie zrozumienia, że ja jestem ekspertem w jakiejś dziedzinie i niekoniecznie inni są tacy sami. 

Mnie gdzieś tam po raz kolejny uświadomiła to budowa domu, gdzie pytania, które dostawałem, albo których nie dostawałem, gdzie gość mi mówił, wiesz co, bo tutaj mamy taką decyzję do podjęcia, ale to raczej cię nie będzie interesowało, bo rozmawiamy o tym, czy zbroić to z oczkami 18 czy 16 centymetrów, i jak będziemy wiązać, czy najpierw poziomy, czy pionowe itd., fakt się mnie to nie interesuje, i od razu taka refleksja, kurde, a ile razy IT przychodzi do biznesu i zadaje im takie pytania, i jeszcze wiesz, patrz, a jak zareaguje, ciekawe co zrobi. 

I ten mój gość też mnie czasem podpuszczał, mówi, a tutaj jaki beton byś lał, C10 czy B10? Przecież ja nie mam pojęcia o tym. A, sprawdzałem tylko, czy będziesz się wymądrzał, bardzo często ludzie mi mówią, że C10 trzeba lać, a nie mają pojęcia, więc często tak jest i to jest kluczem. 

I teraz, jeżeli to nam się uda zmienić, a to nie wymaga jakichś specjalnych umiejętności, po prostu wymaga umiejętności niebycia dupkiem, to okaże się, że ta współpraca z biznesem czy z jakimiś tam klientami wewnętrznymi itd., ona już zacznie zupełnie inaczej wyglądać. I jeżeli do tego jeszcze zbudujemy taką kulturę feedbacku, to już bardziej kwestia managementu, leadershipu firmy niż tych poszczególnych programistów, chociaż oddolnie też można dużo zrobić, to jesteśmy w stanie dostać te wskazówki, czego powinniśmy się uczyć i gdzie mamy te największe braki od biznesu. 

Nie chcę znowu powiedzieć, że to zależy, czego mamy się uczyć, ale trochę zależy od tego, gdzie jesteśmy. Bo my jako programiści nie musimy mieć tych kompetencji miękkich na jakimś super wysokim poziomie. Nie jesteśmy ludźmi, którzy mają teraz wyjść przez dwa tysiące ludzi, jak tam, nie wiem, Jeff Bezos czy Elon Musk i zrobić show. Po prostu nie możemy ich mieć dramatycznie nisko. 

I ludzie często nie mają tej samoświadomości jakby jakie kompetencje już mają i na jakim poziomie. W związku z czym nie możemy powiedzieć do wszystkich: budujcie asertywność, bo może są ludzie, którzy już są wystarczająco asertywni, tylko trochę o tym nie wiedzą. A może na przykład dużo bardziej oni akurat powinni, jakaś Kasia, Jurek itd., powinni się zaangażować w jakieś inne umiejętności, na przykład w umiejętność komunikacji, czyli doboru słów, które trafią do adresata. 

Więc jeżeli ja sobie zbuduję taką nić z tym moim interesariuszem, stakeholderem itd., który pozwoli im, czy da im tę przestrzeń dodawania mi feedbacku, to oni mi sami powiedzą, co im najbardziej przeszkadza. 

Ja jestem fanem nawet, tak jak mówiłem, oddolnie zbierania feedbacku, takiego nawet na zasadzie odpowiedzcie mi na cztery pytania. Po prostu wysyłasz maila do kogoś, z kim współpracujesz: słuchajcie, odpowiedzcie mi na takie cztery pytania. Pierwsze, co potrzebujecie w tej naszej współpracy i ja to robię dobrze? Czyli tutaj jest super, jesteście z tego zadowoleni, dostajecie to, co potrzebujecie. Druga rzecz, co jest takiego, czego Wy potrzebujecie, ale ja tego nie robię? Trzecie pytanie, to co takiego ja robię, ale wy bardzo nie chcecie, żebym ja to robił? I czwarta rzecz, co takiego jest, czego ja nie robię i Wy się bardzo cieszycie, że ja tego nie robię? 

Czyli mamy dwie takie rzeczy continue doing that, czyli jakby rób to dalej i nie rób tego dalej, super, że tego nie robisz, super, że się nie spóźniasz na przykład, nie? Bo to takie rzeczy się tam pojawiają. Często jest takie pytanie, jak to nie potrzebuję, nie dostaję, bo o co ci chodzi? No na przykład tam się pojawia często, że ktoś się nie spóźnia na spotkania, że nie przerywa itd. I to jest super, bo to jest coś, co dostajesz, że ludzie doceniają to, że tego nie robisz. 

A te dwie pozostałe ćwiartki Ci pokażą tak naprawdę, jak powinieneś się rozwijać. Czyli właśnie Ci powiedzą: nie próbujesz nas zrozumieć. Takie mamy wrażenie, że nie próbujesz postawić się w naszej roli. Okej, to jest coś, co muszę robić. A z drugiej strony na przykład nie dajesz sobie powiedzieć feedbacku. My potrzebujemy coś przekazać, a ty od razu się bronisz. Nie dajesz nam skończyć. To nam się nie podoba. I to jest taka macierz need-get tak naprawdę, z tego wychodzi, gdzie mamy w kolumnach potrzebuje, nie potrzebuje, a w wierszach dostaje, nie dostaje. Więc mamy takie właśnie, co potrzebuje i dostaje, co potrzebuje, ale nie dostaje, a z drugiej strony czego nie potrzebuje, a dostaje, albo czego nie potrzebuje, nie dostaje. 

I to jest super opcja, która bardzo pomoże developerom, managerom itd. właśnie w takim samorozwoju, ale świadomym, gdzie ja trochę rozwijam się, biorąc pod uwagę potrzeby mojego współpracownika. 

Ja jestem fanem nawet, tak jak mówiłem, oddolnie zbierania feedbacku, takiego nawet na zasadzie odpowiedzcie mi na cztery pytania. Po prostu wysyłasz maila do kogoś, z kim współpracujesz: słuchajcie, odpowiedzcie mi na takie cztery pytania. Pierwsze, co potrzebujecie w tej naszej współpracy i ja to robię dobrze? Czyli tutaj jest super, jesteście z tego zadowoleni, dostajecie to, co potrzebujecie. Druga rzecz, co jest takiego, czego Wy potrzebujecie, ale ja tego nie robię? Trzecie pytanie, to co takiego ja robię, ale wy bardzo nie chcecie, żebym ja to robił? I czwarta rzecz, co takiego jest, czego ja nie robię i Wy się bardzo cieszycie, że ja tego nie robię?

 

Myślę, że to jest świetne ćwiczenie, żeby zobaczyć, które umiejętności mamy, które potrzebujemy rozwinąć w kontekście pracy w grupie, wyciągania od tego klienta zewnętrznego, wewnętrznego wymagań, które później przełożą się na to, że nasza praca będzie lepiej zrealizowana na koniec dnia, z lepszą jakością, lepszym wynikiem. 

Ale myślę sobie, że można też na to wszystko spojrzeć z takiej perspektywy bardzo egoistycznej albo nawet merkantylnej, że wiesz, nabywanie tych kompetencji spowoduje, czy może spowodować, że będę, no nie wiem, awansował, że potencjalnie będę więcej zarabiał, że będę, oczywiście biorąc większą odpowiedzialność, też dostawał dużo większe wynagrodzenie z tego tytułu. 

Chciałbym Cię zapytać, bo pracujesz, pracowałeś z wieloma firmami, wiele zespołów doświadczyłeś, widziałeś, czy faktycznie zauważyłeś, że programiści, developerzy z takimi bardziej rozwiniętymi kompetencjami miękkimi szybciej awansują, zdobywają zaufanie organizacji? To się przekłada jakoś realnie na rozwój ich kariery? 

 

Jak najbardziej. I to dotyczy nie tylko programistów. Takim drugim końcem tego kija są politycy, nie? To są ludzie, którzy mają wreszcie tylko kompetencje miękkie bardzo często. Świetnie sprzedają siebie, mówią Ci to, co chcesz usłyszeć i potem zostają tak naprawdę premierami, prezydentami itd. Często tam nie ma tego merytorycznej aspektu. 

Często też prezesi niektórych firm to są ludzie, którzy bardziej lub mniej chętnie przyznają się do tego, że oni wcale nie są ekspertami od tego, po prostu potrafią dobrać dobrych ludzi i wyciągnąć z tych dobrych ludzi maksimum. I tak samo to ma znaczenie w przypadku programistów. 

Na pewno jest tak, że jeżeli biznes będzie w Tobie widział partnera, czyli kogoś do kogo może przyjść, kto ich nie oleje, kto wysłucha ich, będzie chciał rozwiązać ich problem, to oni to będą doceniać. Bardzo często to są osoby, które są awansowane, które dostają podwyżki, których jakby pozycja w organizacji bardzo wzrasta. I to są też sytuacje, gdzie ludzie po latach tak naprawdę utrzymują z Tobą kontakt. 

Ja mam tak, że kilka firm temu jeszcze jak pracowałem z ludźmi, to ci ludzie sobie potrafią do mnie dzisiaj dzwonić. I na przykład ostatnio do mnie dzwoniła właśnie Patrycja i mówi, słuchaj, mam taki temat do przegadania, bo tam myślę o takiej aplikacji, masz dla mnie chwilę? Pewnie, że mam. Super, dzięki. I to jest taka sytuacja, gdzie widzisz, że to nie jest tak, że ci ludzie po prostu muszą z Tobą pracować, tylko oni chcą z Tobą pracować, a jak chcesz z kimś pracować i widzisz, że ten ktoś jakby przynosi Ci wartość, to bardzo często nie będziesz miał jako biznes węża w kieszeni, zwłaszczazwłaszcza że biznes też mentalnie odróżnia koszt od inwestycji. 

W związku z czym możesz być programistą kosztem, a możesz być programistą partnerem, którego bardziej traktują w kontekście inwestycji i tam się okazuje, że dostanie dużo lepszej pensji niż inni, nie jest jakimś ewenementem. 

Mnie się zdarzały takie sytuacje, gdzie tam miałem prawie dwukrotnie wyższą stawkę niż inni, czy tam niż średnia w firmie. Nie dlatego, że byłem super wymiataczem technicznym, z tą częścią sobie radziłem, ale to było dlatego, że oni mogli mnie zabrać na przykład na spotkanie, gdzie z klientem negocjowałem jakieś warunki i wiedzieli, że ja tam będę na tym spotkaniu, że będę merytorycznie w stanie argumentować, i będę trochę, wiesz, walczył o tę wycenę, tak jakbym walczył o swoje pieniądze, nie? Więc to super działało. 

Na pewno też właśnie to, co jakby takie pokazanie biznesowi się przejmujesz tym i że dbasz też o ich kasę, to działa super. Bo zespoły IT są drogie. Jak sobie weźmiesz pod uwagę, że tam masz w zespole, nie wiem, sześciu czy siedmiu deweloperów, którzy średnio zarabiają po dwadzieścia parę koła, to ten zespół kosztuje Cię dwieście koła miesięcznie, więc tak naprawdę to jest dwa i pół miliona złotych rocznie, tak? Mniej więcej. To jest kupa kasy, nie? Możesz sobie dom wybudować za pensję takiego zespołu. 

I teraz, jeżeli taki zespół jest roszczeniowy, ma pretensje itd., to będzie pierwszy do cięcia. A jeżeli w takim zespole masz kość, to przychodzi, słuchajcie, wiecie, co tu wymyśliliśmy, jak moglibyśmy coś tam poprawić biznesowo, albo jak moglibyśmy oszczędzić Wam dwa etaty w dziale obsługi klienta, bo tutaj zauważyliśmy, że jest bardzo dużo takich transakcji, one trwają tyle, my możemy to przyspieszyć itd., albo tutaj jesteśmy w stanie coś zautomatyzować, jest zupełnie inna rozmowa. W ogóle zaczynają Cię od razu traktować jako takiego prawdziwego partnera, z którym można rozmawiać o szczegółach. 

Ja miałem kiedyś taką sytuację, gdzie jako dostawca, zewnętrzny kontraktor w firmie, poszliśmy do biznesu, który zlecił nam jakieś tam zadanie i ja pytam, a ile chcecie na tym zarobić? I tam na początku było wielkie oburzenie, jak w ogóle dostawca śmie przychodzić do nas z takimi pytaniami, zamknij sieć i koduj. 

I mówię, że to nie jest tak, że ja teraz próbuję wykraść Wam jakieś tajemnice, tylko po prostu ten temat wygląda na prosty z Waszego punktu widzenia, ale to jest niezła orka w tych systemach i mówię, że nam zajmie sprint do dwóch sprintów, samo przeanalizowanie, co trzeba zmienić. Nie zmiana, tylko przeanalizowanie. Więc tak naprawdę liczymy się z tym, a praca kontraktorów to były zupełnie inne stawki, mówię, że zapłacicie 400 koła za to, żeby się dowiedzieć, ile to będzie kosztowało, a potem prawdopodobnie się okaże, że jeszcze z bańka pójdzie na to, żeby to określić, więc stąd pytam. To my wrócimy do was. 

I potem przyszli, jak sobie to policzyli, dopiero po tym naszym pytaniu, się okazało, że 300 koła by z tego wyciągnęli. To była jakaś zmiana regulacji i tam musieli coś zrobić. I powiem Ci, że po tym spotkaniu zupełnie inne podejście do nas było. Oni przychodzili do nas i mówili, słuchajcie, mamy taki plan, tutaj biznesowo byśmy chcieli zrobić to, to i to. Planujemy, że to będzie miało takie i takie efekty, co o tym myślicie? Oni po jednym spotkaniu zrozumieli, że tutaj mają trochę inne podejście. 

 

No właśnie, traktowanie się po partnersku. To jest tak, że tak jak wspomniałeś, osoby, które są w stanie nieco więcej zrobić niż tylko zakodowanie czegoś albo zaprojektowanie architektury, mam wrażenie, że wnoszą taką podwójną wartość w tej firmie. Nie tylko te kompetencje techniczne, twarde, ale też całą tę otoczkę biznesową, która, tak jak tutaj wspomniałeś, niekiedy może być nawet ważniejsza i istotniejsza, bo jest mniej zastępowalna chyba. 

No właśnie, ale jak to wygląda z drugiej strony? Czy deweloperzy, czy programiści poważnie w ogóle traktują rozwój tych kompetencji miękkich, czy w ogóle widzą w tym jakąś wartość dla siebie? I czy Ty widzisz jakąś różnicę pomiędzy tutaj naszym polskim poletkiem versus zagranica? Czy jest jakaś różnica, czy my jeszcze nie dostrzegamy może czegoś? 

 

Wydaje mi się, że to się trochę zmienia, ale dalej ta chęć rozwoju umiejętności miękkich jest niewielka i to raczej jest taka stricte pod moje potrzeby, na zasadzie takiej naucz mnie sprzedawać refaktoring biznesowi. Ja mówię, okej, tylko jeśli twierdzisz, że chcesz być partnerem, to zastanów się, czy biznes potrzebuje tego refaktoringu w tym miejscu, czy Ty tego potrzebujesz. 

Więc na razie wydaje mi się, że jak jest chęć tej faktycznie budowy kompetencji miękkich, to ona jest taka bardzo, jak powiedziałeś wcześniej, egoistyczna, ale nawet nie w kontekście mojej kariery, że ja będę bardziej partnerski, tylko właśnie na zasadzie takiej, że a tutaj wiesz, będę sobie robił, co będę chciał, bo będę umiał im nawijać makaron na uszy. Więc wydaje mi się, że taka świadomość tego, że faktycznie postawienie się w tej roli klienta, że to ma efekty, to to się bardzo powoli zmienia. 

Ja pamiętam, jak 10 lat temu Kuba Nabrdalik opowiadał o takiej swojej sytuacji, gdzie tak naprawdę dostał propozycję przejścia trochę z IT do biznesu z trochę otwartą stawką. Na zasadzie powiedz, jak chcesz zarabiać, i tyle dostaniesz. I to nie wynikało z jego super kompetencji programistycznych, tylko z tego, że bardzo dobrze poznał domenę, zaangażował się w zrozumienie biznesu i w rozmowy z biznesem, rozmowy z klientami. To było docenione tekstem typu: powiedz, ile chcesz zarabiać, tyle dostaniesz. 

Więc nie kojarzę za bardzo poza naprawdę pojedynczymi przypadkami, gdzie ktoś ze względu na swoje umiejętności techniczne dostawałby taką propozycję. Takie rzeczy oczywiście się dzieją, sam mam kolegę, który dostał taką propozycję za bycie developerem, rzucił jakąś absurdalną stawkę i powiedzieli mu okej, ale to jest branża high frequency trading, jest to jeden z kilku specjalistów na świecie, który optymalizuje kod na poziomie nanosekund, jest tam na poziomie jakichś, wiesz, tam VP of coś tam w jakimś wielkim banku inwestycyjnym i takie rzeczy się dzieją, ale ja znam trzy takie przypadki. A tych ludzi naprawdę sporo poznaję, gdzie programista po prostu za te umiejętności techniczne dostawał naprawdę gigantyczne pieniądze. 

Raczej jest tak, że to jest taka średnia branżowa. Ludzie też często się frustrują, że jestem takim super developerem, a tu mnie w tej firmie nie doceniają. Bo może właśnie nie chodzi tylko o bycie koderem, a bardziej o development i właśnie takie świadomie robienie tego, co trzeba zrobić. 

 

Tak, na początku naszej rozmowy nazywaliśmy sobie te umiejętności miękkimi, managerskimi, liderskimi i myślę sobie, że to może być takie mylące, bo może się wydawać, że tylko będąc właśnie tym managerem czy liderem, warto by było, żebyś te umiejętności gdzieś tam posiadł. Nie każdy może, nie każdy chce być tym managerem i liderem. Wiele osób będzie się rozwijało właśnie w tej gałęzi technicznej. To też jest okej, takie osoby oczywiście też są potrzebne. 

Czy myślisz, że jednak stawiając na ten rozwój kariery, taki mocno techniczny, nadal warto rozwijać umiejętności miękkie? Nadal ma to sens? 

 

Myślę, że 80% umiejętności miękkich, które musi mieć lider, powinien mieć programista. Bo takich umiejętności stricte liderskich, managerskich, nie jest jakoś super dużo. I teraz popatrzmy na przykładach. Na pewno lider, manager musi umieć w feedback, musi umieć zebrać feedback, przyjąć feedback, ale już sobie powiedzieliśmy wcześniej, że jak chcesz się świadomie rozwijać jako programista, konsultant, specjalista, to dobrze, żebyś umiał zebrać feedback, przeanalizować ten feedback i nie kłócić się od razu, że wcale tak nie jest, że ja tego nie robię, ja uważam, że tutaj się pomyliście i nie będę was więcej o to pytał. A takie rzeczy się zdarzają. 

Więc to jest pierwsza rzecz. Umiejętność takiej właśnie, wiesz, jakby trochę zrozumienia odbiorcy. Lider to musi mieć, bo jest twarzą zespołu, ale programista też bardzo dobrze, żeby to miał, dlatego że jak idzie na spotkanie z biznesem, to jest w stanie trochę określić, kto jest kim na tym spotkaniu, na czym tym ludziom zależy, jak im ten przysłowiowy refraktoring sprzedać, bo jak widzę, na czym komuś zależy, to oczywiście nie chodzi o to, że będę teraz manipulował, tylko jeżeli widzę, że ktoś ma fioła na punkcie bezpieczeństwa, a ja wiem, że mnie wkurza to, że podbicie teraz wersji Springa zajmuje mi 4 tygodnie, to mówię, słuchajcie, teraz nam to zajmuje 4 tygodnie, jak będzie jakiś błąd krytyczny, który nie będzie poprawiony w tej starej wersji, to mamy problem, mamy 4 tygodnie dziurę na produkcji, czy to jest dla Was okej, czy jednak powinienem poświęcić ten czas, ja przy okazji też sporo zyskam, ale to jest jakiś taki argument, który po prostu mówię do Was, więc to jest kolejna rzecz. 

Właśnie to jest też związane z tą umiejętnością komunikowania się w stosunku do odbiorcy. Ale dalej mamy tak, że lider na pewno musi umieć pracować w zespole, w grupie itd. Ale znowu pracuję z ludźmi i teraz jeżeli ci ludzie też będą to potrafili, to będzie nam łatwiej. Idąc jeszcze dalej, lider na pewno musi umieć świadomie planować pracę zespołu. 

Właśnie ta umiejętność przeprowadzania dobrej retrospektywy, zastanowienie się, czy to, co robimy, ma sens. Znowu, jak mam super lidera w swoim zespole, no to on to za mnie zrobi. Jak nie mam tego lidera, to mam pracować bez sensu? No nie, no dobrze, żebym ja sam umiał się zastanowić, czy to, co robimy teraz, to nam rozwiąże jakikolwiek problem, a nie tylko w IT, ale ogólnie ludzie mają tendencję do łatania objawów, a nie przyczyn. 

Nawet jak idziesz do lekarza, to często leczą Ci objawy, a nie przyczyny, nie? Boli mnie gardło, bardzo proszę, tutaj jest lek na bolące gardło, nie? A nie wnikają, że na przykład to gardło cię boli, bo masz, nie wiem, kurde, zepsute zęby i tam jakieś bakterie z tych zębów idą do tego i bierzesz te tabletki, no już jakby lepiej, ale za dwa tygodnie znowu to samo. I to samo się dzieje jakby w pracy, więc jeżeli ja umiem dotrzeć do tego, umiem zadawać pytania, umiem aktywnie słuchać, to będzie mi dużo łatwiej. 

Lider musi być asertywny, bo ludzie non-stop do niego przychodzą i mówią: słuchaj, jak mi nie kupisz tego komputera i sześciu monitorów, to ja nie mogę pracować. I taki lider musi umieć na to odpowiedzieć. Nie stary, no bez jaj, bądźmy poważni. I tak samo programista, gdzie często biznes przychodzi do nas naprawdę z absurdalnymi prośbami, też często warto im powiedzieć, nie słuchajcie, nie będziemy tego robić w ten sposób. Albo jakiś techniczny product owner, który mówi: tutaj dołożymy taką tabelkę. Nie, nie dołożymy tabelki, powiedz mi, co trzeba zrobić, ja to dowiozę, ale nie mów mi, gdzie robić tabelkę.

Lider musi być asertywny, bo ludzie non-stop do niego przychodzą i mówią: słuchaj, jak mi nie kupisz tego komputera i sześciu monitorów, to ja nie mogę pracować. I taki lider musi umieć na to odpowiedzieć. Nie stary, no bez jaj, bądźmy poważni. I tak samo programista, gdzie często biznes przychodzi do nas naprawdę z absurdalnymi prośbami, też często warto im powiedzieć, nie słuchajcie, nie będziemy tego robić w ten sposób. Albo jakiś techniczny product owner, który mówi: tutaj dołożymy taką tabelkę. Nie, nie dołożymy tabelki, powiedz mi, co trzeba zrobić, ja to dowiozę, ale nie mów mi, gdzie robić tabelkę.

 

Właśnie, zgadza się. Czyli jasno na podstawie tych doświadczeń, które tu powiedziałeś, widać, że warto rozwijać te umiejętności, bo to się zwyczajnie niesamowicie mocno przekłada na to, jak na co dzień w zespołach pracujemy, jak się dogadujemy z ludźmi, z naszym liderem, z tym właśnie przysłowiowym biznesem itd. 

Myślę sobie, że takie kluczowe pytanie jest, jak wobec tego te kompetencje rozwijać, zwłaszcza w takim środowisku, gdzie dostajemy zadania techniczne, zakoduj to, rozeznaj jakiś tam temat techniczny, zrób jakąś architekturę, coś wyklikaj itd. W jaki sposób znaleźć ten czas, to jedno, ale też okazję do tego, żeby właśnie te umiejętności miękkie rozwijać? 

 

I to jest trudny temat, dlatego że, o ile do szkoleń technicznych jest po prostu multum tego, jest multum książek itd., to tutaj jest słabo. Ja na przykład jak szedłem do Allegro 12 lat temu i zaproponowano mi stanowisko kierownicze, to odmówiłem w pierwszym rzucie. 

Powiedziałem, że ja się na tym nie znam w ogóle i nie chcę być kolejnym dobrym developerem, który zostanie beznadziejnym managerem itd. I oni mnie przekonali tym, że wtedy w Allegro 12 lat temu już funkcjonował taki projekt jak Akademia Managera, i tam developer albo specjalista, bo to dotyczyło też innych działów, który zostawał liderem bądź managerem, miał kilkunastotygodniowe, to było chyba 14-tygodniowe szkolenie z taką firmą Inżynieria Personalna, w ogóle nazwa mnie tak chwyciła, że mnie kupili tą nazwą. Ale to było dokładnie to, co odwzorowywało to, jak oni działali. 

Oni po prostu mówili, że to nie jest żadna sztuka, to jest inżynieria. Masz po prostu nauczyć się pewnych mechanizmów i umieć je wykorzystywać. I to mi mega dużo dało. To było od wiedzy teoretycznej na zasadzie, jakie są fazy formowania się zespołów i że to, że ludzie zaczynają się kłócić, to jest normalne i Ty nie masz nic z tym robić, bo tak po prostu będzie, bo to jest taka faza stormingu, gdzie ludzie po prostu trochę jak te barany z rogami tam ustalają hierarchię, i to będzie, i po prostu Ty musisz usiąść z boku i patrzeć na to itd., do ćwiczenia scenek na zasadzie takiej, że przychodzi ktoś po podwyżkę, a Ty nie chcesz mu dać tej podwyżki. 

I to mi mega dużo dało, bo my ćwiczyliśmy, ja siedziałem po prostu z innymi ludźmi mojego pokroju i tam każdy, wiesz, a ci zaraz dowalę, teraz zobaczysz, mnie to nie zwolnisz, nie? Jak mieliśmy na przykład rozmowę ze zwolnieniem i tam pracownik miał się bronić, to bywało tak, że po prostu, wiesz, tam tak zapędził tego lidera, w końcu mówi, ja już nie wiem, co mam mu powiedzieć, bo ja się z nim zgadzam. 

Ale to mega dużo pomagało, bo ja później pamiętam, że jak miałem taką sytuację, gdzie faktycznie przyszedł do mnie developer po podwyżkę, ja powiedziałem, że nie będzie tej podwyżki, no ale to co HR-y się nie zgodziły czy coś? Ja mówię, kurde, no kusi, ale mówię: nie, ja uważam, że nie zasługujesz jeszcze teraz na podwyżkę i jeżeli chcesz na nią zasłużyć, to jeszcze to i to i to musisz zrobić. Ale ta pokusa była ogromna, jak on powiedział o tych HR-ach. Nie, to ja. Okej, dziękuję ci bardzo, doceniam szczerość, to się w takim razie wezmę za to i to się nauczę. Tam miałem ten luksus. 

Na pewno jest tak, że powiedzenie w firmie, że potrzebujemy rozwijać kompetencje miękkie, często nie mamy katalogu szkoleń miękkich itd. Natomiast są ludzie i są firmy, są organizacje, które szkolą w zakresie kompetencji miękkich, i to można zrobić. Też nasz plan w ogóle na szkolenie, które ostatnio wypuszczaliśmy, czyli Horyzont Lidera, To było właśnie takie brakujące ogniwo na umiejętności miękkie. 

Od dawna się gdzieś tam przymierzałem do tego, nie miałem z kim tego robić. Teraz gdzieś tam się dogadałem z Marcinem, z którym pracuję od paru lat w DevSkillerze. Po prostu mnie coachował i mnie też rozwijał. To to zrobiliśmy i jakby to jest w ogóle super pomysł, czyli coachowanie. 

Ja tak naprawdę takich ludzi, którzy doradzali mi w tym kontekście miękkim, miałem od Allegro. Czyli w Allegro jak pracowałem z tą Inżynierią Personalną i tam był Kacper Godlewski, który jakby prowadził większość tych szkoleń, to ja później przez lata pracowałem z Kacprem. I to było tak, że on chodził ze mną na spotkania w firmie, a potem po spotkaniu siadałem z nim i dostałem zjebkę, co zrobiłem źle i jak nie mogę się zachowywać, co powinienem zrobić inaczej, czego nie zrobiłem itd. I to budowało nie jakąś tam jedną konkretną umiejętność, tylko cały zestaw. 

Później pracowałem z jeszcze inną osobą, potem właśnie pracowałem z Marcinem przez długi czas nad tym rozwojem i to jest na pewno super efektywne, tylko no niestety drogie, bo ci ludzie często mają stawki po półtora koła za godzinę i to niestety kosztuje, natomiast no to jest super inwestycja, więc jeżeli kogoś stać na to, żeby sobie jakby zatrudnić takiego trenera z prawdziwego zdarzenia umiejętności miękkich, to to jest w ogóle the way to go. 

Tylko, no mówię, trzeba się liczyć z tym, że jak masz 4 godziny taką osobę miesięcznie, to kosztuje Cię to 5-6 tysięcy, więc nie każdy chce. 

 

No tak, ale jakby potraktować to w kontekście właśnie inwestycji, tak jak powiedziałeś, to może ma to sens, ale zobaczyłeś tutaj o temat szkolenia, tak sobie zerknąłem przed naszą rozmową, że jest tam bardzo fajne hasło, mianowicie; Same twarde skille już nie wystarczą. To jest coś, co jest na stronie szkolenia Horyzont Lidera, które właśnie razem z Marcinem Dakowskim i pod wydawnictwem Maćka Aniserowicza stworzyliście. Myślę sobie, że to też jest doskonała forma, doskonały sposób, żeby właśnie w ten temat rozwoju tych soft skilli wejść, prawda? 

 

Dlatego to zrobiliśmy, bo to dla nas było takie brakujące ogniwo. Natomiast ten tekst Maćka, że już nie wystarczą, to wiesz, ja pamiętam jak 6 czy 7 lat temu Wojtek Seliga miał taką prezentację na kilku konferencjach bodajże o plantacjach programistów, czy coś takiego, że to podejście takie, to już nie działa, że programista nie może być tak proksowany przez jakiegoś tam product ownera, który gada z biznesem, a programisty się nie pokazuje nikomu, bo to wstyd, to już się skończyło. I oni jak budowali Sparteza, czy później kolejny odłam, to bardzo mocno zwracali uwagę właśnie na to, żeby ludzie myśleli biznesowo. 

Tam hackatony, które były organizowane, one też były organizowane w kontekście jakichś feature’ów biznesowych. Więc ja w Allegro tak naprawdę pracując lata temu, to jak zaczynałem tam pracę, to też jeszcze hackatony były bardziej techniczne. Na zasadzie dowieźmy nowy silnik bazy, coś tam, i sam w tym uczestniczyłem, i później to zaczęliśmy zmieniać na zasadzie takiej, że może jakiś feature biznesowy. 

Bo tak to wiesz, biznes potem siedzi na demo i mówi, ale what the fuck w ogóle, co wy mi pokazujecie, co mnie to interesuje, czy tam jest jakiś aerospike, który jest super, że jest taki szybki, ale to w ogóle nam nic nie zmienia. Może tam coś optymalizuje, ale to nie o tym rozmawiamy. 

Więc jak najbardziej. Teraz w momencie, kiedy jest AI, to faktycznie się robi krucho, dlatego że tutaj bardzo dużo głosów jest w internecie, że o tam AI nie zastąpi programistów itd., ale to jest gówno prawda. Jak ja widzę, jaka jest efektywność jednego developera, który korzysta świadomie z narzędzi i ja mówię tak naprawdę o seniorze, to on jest w stanie teraz robić pracę trzech, czterech seniorów bez problemu. Dlatego, że zawsze to nie jest tak, że te zajęcia seniorskie to było 8 godzin dziennie. Tam były dwie godziny rozkminy, jak coś zrobić, a potem było trochę takiej, wiesz, po prostu żmudnej roboty. I teraz tą żmudną robotę robi AI. 

My na przykład mieliśmy duże plany rekrutacyjne w DevSkillerze i stwierdziliśmy, że nie będziemy tego robić, bo nie ma potrzeby takiej. Jesteśmy w stanie po prostu dowozić przy pomocy narzędzi AI-owych dużo więcej tą samą liczbą ludzi. 

I teraz okazuje się, że jak masz developera, który przy pomocy narzędzi AI-owych jest w stanie naprawdę bardzo podnieść swoją efektywność, to robi robotę. Nawet takie techniczne rzeczy, jak my na przykład w DevSkillerze używamy takiej biblioteki JOOQ, To jest Java Object Oriented Query, jest coś, co pozwala Ci pisać natywnie type-safe zapytania SQL-owe. 

Kiedyś, żeby przepisać takie zapytanie 2-stronicowe SQL-owe na JOOQ-a, to musiałeś siedzieć 2 dni. A teraz jest tak, że wrzucasz to w Chata GPT, on Ci wyrzuca coś, co prawie działa, i okej, musisz poświęcić godzinę, żeby to poprawić, ale to jest kurde godzina, a nie 2 dni. I to jest mega techniczny kod, gdzie on to czai, generuje itd. 

Więc jeszcze bardziej okazuje się, że istotne są te umiejętności miękkie. Bo skoro tak naprawdę Chat GPT w tej chwili jest w stanie wykonywać bez problemu pracę juniora i pod nadzorem seniora pracę mida, to gdzie zaczyna być ta różnica? 

My jak pracujemy z klientami w DevSkillerze, to często firmy teraz mówią, że jednym z głównych rozkmin, które oni mają, to jest to, jak sztuczna inteligencja zmieni ich położenie w tzw. competitive landscape, czyli w całej perspektywie ich konkurencji. 

Bo teraz mamy dwie możliwości. To robisz tak, że analizujesz sobie mocne, słabe strony firmy, czyli taki swot robisz dla firmy, a potem zastanawiasz się, które z tych stron są zastępowalne przez AI. Jeżeli jest tak, że zbudowałeś mocne strony swojej firmy w obszarze, który będzie zastąpiony przez AI, to masz problem, dlatego że cała Twoja przewaga konkurencyjna może nie z dnia na dzień, ale bardzo szybko zacznie topnieć, bo AI pozwoli konkurencji dogonić to, co Ty robisz w tej chwili. 

Natomiast jeżeli jesteś firmą, która ma przewagę konkurencyjną zbudowaną w obszarze, którego się nie da automatyzować łatwo, a swoje słabe strony ma w miejscach, które z kolei przejmie AI, to masz super, dlatego że wzmacniasz jeszcze bardziej swoją przewagę konkurencyjną i topisz przewagę konkurencyjną konkurentów dzięki zastosowaniu AI. 

I teraz dokładnie taki sam mechanizm działa w przypadku programistów. Czyli to jest tak, że ja swoją wartość jako programisty zbudowałem w obszarze, który zastąpi AI, bo jestem świetny w pisaniu zapytań JOOQ-a, to masz problem, bo AI też jest świetny w pisaniu zapytań JOOQ-a, a za dwa tygodnie będzie w ogóle wybitny. I teraz masz problem, bo generalnie, sorry Winnetou. Jeżeli teraz zbudowałeś swoją karierę na przenoszeniu konfiguracji z XML do Java, to z dnia na dzień straciłeś pracę, bo AI zrobi zajebiście dobrze, zajebiście szybko i super tanio, i bezbłędnie. I nie będzie marudził, że robi to 16 dzień z rzędu bez spania. 

Natomiast jeżeli jako specjalista, programista, developer zbudowałeś swoją przewagę konkurencyjną właśnie na umiejętności skutecznej analizy, rozmowy z biznesem, analizy wymagań, optymalizacji procesu itd., to super, dlatego że to też jest coś, co AI będzie wspierał, ale nie przejmie tego od początku do końca. AI robi bardzo dużo błędów i nikt normalny nie odda AI-owi decyzyjności. 

Więc jeżeli Ty jako developer byłeś w stanie porozmawiać z ludźmi, zaprojektować rozwiązanie, przygotować, wdrożyć, dać im do przetestowania, zrobić to w formie Agile’owej itd., to Twoja wartość super wzrasta, a może niekoniecznie słaba strona, ale efektywność jesteś w stanie podnieść właśnie wykorzystaniem AI. 

Więc trochę wracając, bo się rozgadałem, jakby tutaj to jest to miejsce, gdzie te kompetencje miękkie zaczynają tak naprawdę pomagać ludziom wygrywać. Bo to jest coś, co nas różni od sztucznej inteligencji, czy właśnie od ludzi, którzy są zastępowalni przez AI. 

 

I tu postawmy kropkę. Myślę, że jest jednak trochę takiego pozytywnego wydźwięku w tym, co powiedziałeś na końcu, że mamy szansę z AI wygrać na różnych polach. Jednoznacznie też wskazałeś i udowodniłeś, że umiejętności miękkie to jest ten obszar, który warto rozwijać, warto w niego inwestować, ponieważ może świadczyć właśnie o naszej przewadze. Rynek pracy, myślę, coraz bardziej będzie doceniał właśnie znaczenie tych umiejętności. Zresztą każdy, kto spróbował je rozwijać, wie, że satysfakcja z pracy jest zwyczajnie większa. Warto więc w tym kierunku iść. 

Kuba, bardzo Ci dziękuję za spotkanie i za tę wartościową rozmowę. 

Dzięki wielkie. 

Powiedz jeszcze, proszę, na końcu, gdzie Cię możemy znaleźć w internecie, gdzie możemy słuchaczy odesłać. 

 

Na pewno LinkedIn to jest w tej chwili takie medium, gdzie najwięcej jestem, gdzie najwięcej postuję, i to jest pierwszy obszar. Drugi obszar to można ze mną porozmawiać na Discordach, czyli na Discordzie DNA, czyli naszego szkolenia architektonicznego i na Discordzie, który będzie od gdzieś lutego pewnie Horyzontu Lidera. Ostatnio, jeśli chodzi o konferencję, to byłem głównie na Beyond Code, a tak to konferencje bardziej właśnie w obszarze learning and development, HR-u, gdzie trochę też promujemy to podejście skills-based organization i mówimy, że skupiaj się na umiejętnościach, dawaj ludziom szansę itd. 

Więc LinkedIn, Discord i Beyond Code i konferencje HR-owe. 

 

Super, oczywiście linki będą w notatce do odcinka. 

Kuba, jeszcze raz bardzo Ci dziękuję. Do usłyszenia. Cześć!

Dzięki, hej!

 

I to na tyle z tego, co przygotowałem dla Ciebie na dzisiaj. Więcej wartościowych treści znajdziesz we wcześniejszych odcinkach. Masz pytania? Napisz do mnie na krzysztof@prozmawiajmyoit.pl lub przez social media. 

Przypominam o najnowszym szkoleniu Horyzont Lidera autorstwa Jakuba Kubryńskiego i Marcina Dakowskiego, a wydawanym przez organizatora takich hitów jak Droga Nowoczesnego Architekta czy Domain Drivers, czyli Maćka Aniserowicza. 

To więcej niż kurs, to możliwość czerpania z doświadczeń osób, które z tematem soft skills i przywództwa związane są od dawna. Niezależnie, czy planujesz ścieżkę liderską czy techniczną w swojej karierze, umiejętności miękkie będą bardzo pomocne. 

Ja się nazywam Krzysztof Kempiński, a to był odcinek podcastu Porozmawiajmy o IT o tym, jak umiejętności miękkie, liderskie i managerskie pomagają developerom w codziennej pracy.

Do usłyszenia w następnym odcinku. 

Cześć!

+ Pokaż całą transkrypcję
– Schowaj transkrypcję
mm
Krzysztof Kempiński
krzysztof@porozmawiajmyoit.pl

Jestem ekspertem w branży IT, w której działam od 2005 roku. Zawodowo zajmuję się backendem aplikacji internetowych i zarządzaniem działami IT. Dodatkowo prowadzę podcast, występuję na konferencjach i jestem autorem książki "Marka osobista w branży IT". Moją misją jest inspirowanie ludzi do poszerzania swoich horyzontów poprzez publikowanie wywiadów o trendach, technologiach i zjawiskach występujących w IT.