Project manager, engineering manager, product owner, product manager to role często odpowiedzialne za zatrudnianie osób technicznych w IT, a także zlecanie im pracy w imieniu własnym oraz klienta wewnętrznego lub zewnętrznego. W zakresie obowiązków tych ról jest także zarządzanie zbudowanym zespołem. Przez lata pracy na stanowisku inżynierskim zgromadziłem kilka ciekawych doświadczeń z tym związanych oraz anegdot, którymi dzielili się ze mną inni inżynierowie. W tym artykule, w zwięzły sposób, zaprezentuję kluczowe aspekty współpracy na linii inżynier – manager oraz podzielę się dobrymi praktykami, które zaobserwowałem.
Finanse
Każdy chciałby lepiej zarabiać, jednak wyciskanie „ostatniego grosza” z pracodawcy przez kandydata, wykorzystując rynek pracownika, ma również swoje minusy. Dla inżyniera optymalnie byłoby, aby osoba go zatrudniająca brała pod uwagę ważne z jego perspektywy scenariusze, jak na przykład:
- zmieniające się (na lepsze) stawki w kontraktach podpisywanych z zewnętrznymi klientami,
- pracownik przynoszący kontrofertę z rynku celem uzyskania podwyżki,
- porównywanie zarobków pomiędzy pracownikami, zachęcające innych do ubiegania się o wyższe stawki,
- przyrost obowiązków w sytuacji zmniejszenia liczby programistów w zespole projektowym,
- niechęć do obejmowania stanowisk liderskich przez najbardziej kompetentnych inżynierów.
Aby nauczyć się czegoś nowego, osoba techniczna musi pracować dłuższy czas z daną technologią. Ważne jest również, aby pracować w gronie kompetentnych osób, które ufają sobie nawzajem. Budowanie zaufania, jak wiemy, także wymaga sporo czasu, dlatego uważam, że rozsądnie jest rozważać finanse danego stanowiska i pracownika z szerszej i długoterminowej perspektywy, uwzględniającej potencjalne zawirowania.
Druga strona medalu
Ludzie w tzw. „górnych widełkach”, wyświetlają się na czerwono w różnych raportach, zwłaszcza w okresach redukcji zatrudnienia. Dlatego, gdy zależy Ci na stabilności zatrudnienia, nie warto „wyciskać ostatniego grosza”. Myślę, że ta świadomość będzie rosła wśród programistów oraz innych osób technicznych w miarę przechodzenia z rynku pracownika na rynek pracodawcy. Jednocześnie, osoba zatrudniająca również odgrywa tu ważną rolę, jeżeli przekonująco wytłumaczy kandydatowi, dlaczego agresywne maksymalizowanie przez niego wynagrodzenia, może działać na jego niekorzyść w długim terminie. Oczywiście wszystko jest kwestią indywidualnych priorytetów kandydata, natomiast taka argumentacja nie powinna zostać zignorowana.
Odpowiedzialność
Coraz częściej organizacje inwestują w programy mentoringowe dla swoich
Czasami próbuje się „wyciągnąć” inżyniera z jego/jej aktualnej firmy. Czasem po to, aby przygotować staffing pod nowy projekt lub aby pokazać klientowi, że dysponujemy ekspertami w danej dziedzinie, a kiedy indziej, żeby przygotować się na fuzję firmy czy po prostu pokryć otwarty wakat. Jak to często bywa, zwłaszcza ostatnimi czasy, wiele z tych wydarzeń nie dochodzi do skutku. Negocjacje są zrywane, ludzie przestają odpisywać czy oddzwaniać, a wysłane umowy nie są podpisywane. Choć żadna ze stron nie chciała takiego obrotu spraw, tak się czasem dzieje, a powody bywają zgoła prozaiczne, jak na przykład cofnięcie budżetu.
Poza zmarnowanym czasem, przepalonym budżetem na farming i dziurą w P&L na dany rok pozostaje jeszcze kwestia zatrudnionych ludzi. Niestety, czasami sytuacje bywają jeszcze bardziej prozaiczne, jak na przykład nagłe cofnięcie budżetu na otwarcie stanowiska, co zaskakuje wszystkich zaangażowanych. Czasem może też zaistnieć najgorszy scenariusz, czyli konieczność zwolnienia jednego bądź, co gorsza, wielu inżynierów. To zawsze jest spory cios.
Uważam, że w takich sytuacjach kluczowa jest transparentność. W dążeniu do „dopięcia” kolejnego dealu pamiętajmy o jego ludzkim aspekcie. Znalezienie kolejnego projektu czy pracy może zwalnianej osobie zająć sporo czasu, pozostawiając ją bez źródła dochodu. Istnieją managerowie obdarzeni tak dużą charyzmą, że mogą jej ulec nawet bardzo doświadczeni inżynierowie. Nie teoretyzuję – osobiście dotknęła mnie sytuacja w której projekt, do którego byłem rekrutowany, rzekomo pewny na 99%, ostatecznie nie wystartował.
Ryzyko
Starając się zarządzać ryzykiem w takich sytuacjach, uważam, że warto mieć plan B. Można ustalić z wyprzedzeniem możliwość wchłonięcia zrekrutowanych ludzi przez inne projekty bądź działy. Sieć kontaktów to kolejne wartościowe narzędzie, z którego można skorzystać, aby otworzyć „poszkodowanym” drzwi w innych działach bądź firmach. Można na to spojrzeć w ten sposób, że oferując naszej sieci kompetentnych i dostępnych specjalistów, oferujemy wartość osobom, które w danym momencie takich specjalistów szukają.
Nikt tego lepiej nie sprzeda od PM-a
Podobno kura znosząca złote jajka powinna najgłośniej gdakać. Jeśli tak, to niektórzy eksperci IT powinni zacząć cierpieć na chroniczny problem ze strunami głosowymi. Niestety nie każdy potrafi sprzedać swoje umiejętności i prawdziwą wartość dostarczanej pracy. Co więcej, wielu z nas nie widzi takiej potrzeby. Jest to problematyczne na kilku płaszczyznach, które poniżej scharakteryzuję.
Po pierwsze: optyka. Brak entuzjazmu może być zaraźliwy i udzielać się interesariuszom. Uważam, że nieoceniona jest pomoc inżynierom w „sprzedaniu” efektów ich pracy. Zwłaszcza w ujęciu monetarnym, który niesie mierzalną wartość, na przykład: „nowe rozwiązanie zaproponowane i wdrożone przez Kamila, zmniejszy czas finalizacji zamówienia o połowę, przez co o co najmniej tyle zmniejszy się liczba porzuconych koszyków o wartości X w sklepie internetowym”.
Projekt, którego wdrożenie zostało odnotowane jako sukces przez kluczowych stakeholderów, można wykorzystać jako idealny moment do zebrania najlepszego feedbacku o pracy inżynierów oraz firmy. Ten feedback może potem posłużyć przy staraniu się o awans, dostaniu się do kolejnego projektu, czy po prostu poprawić czyjąś samoocenę. Jeżeli istnieje miejsce w firmie, gdzie są dostępne profile pracowników, bardzo dobrze jest podzielić się otrzymaną pochwałą również tam. Jest to wartościowa informacja dla innych managerów o jakości pracy inżyniera i współpracy, jaką nawiązał z biznesem na swoim projekcie.
Interakcja z ludźmi
Postcovidowa rzeczywistość przyzwyczaiła nas do pracy z domu. Często można spotkać sytuacje, gdzie pewne osoby wolą nie pokazywać się na kamerce, a niektóre nawet nie mają swoich zdjęć profilowych. Ostatecznie, może dojść do tego, że znamy wyłącznie głos, imię i nazwisko osoby, z którą pracujemy każdego dnia.
Ponieważ dobre relacje w zespole są dla mnie ważne, bardzo doceniam, gdy PM w miarę możliwości stara się organizować team building, zwłaszcza fizycznie. Teraz jest to ważniejsze niż przed pandemią. Daje to poczucie przynależności do konkretnej grupy, pomaga zbudować relacje, które często są w stanie przetrwać dłużej od samego projektu. Owszem, niektórym może na tym nie zależeć, ale nawet takie osoby przyznają, że lepiej współpracuje się z kimś, kogo się spotkało.
Jedna z moich ulubionych gier typu team building to prawda czy kłamstwo. Każda osoba z zespołu przygotowuje trzy informacje na swój temat, z których dwie są fałszywe. Po prezentacji wszystkich trzech reszta zespołu typuje prawidłową odpowiedź. Każde poprawne odgadnięcie warte jest jeden punkt. Najlepiej zgadujący trafiają na podium. Prosta, prowadząca do wielu ciekawych rozmów aktywność na około pół godziny.
Empatia
Usłyszałem kiedyś od pewnej mądrej emerytowanej Brytyjki, że „każda praca ma swoje wyzwania”. To był jej komentarz na moje spostrzeżenie, że usługa tapetowania, którą dla niej wykonywałem podczas wakacyjnej pracy, była dla mnie mniej interesująca od pracy inżyniera, do której przygotowywałem się na Politechnice Wrocławskiej.
Praca managera i praca inżyniera zdecydowanie różnią się typem wyzwań, z którymi przychodzi mierzyć się osobom wykonującym te zawody. Niemniej jednak, powinniśmy darzyć się wzajemnym szacunkiem i pomagać sobie nawzajem w osiąganiu celów. Istnieje wiele synergii, które możemy wypracować, lepiej rozumiejąc, z czym przychodzi się mierzyć każdej ze stron. Mam nadzieję, że tym artykułem pomogłem Ci lepiej zrozumieć pracę z perspektywy inżyniera.
Inżynier oprogramowania specjalizujący się w aplikacjach internetowych. Przez lata swojej pracy pomagał klientom budować, testować, deployować i utrzymywać wiele aplikacji na AWS, GCP i Azure. Do IT dołączył jako project manager bez wiedzy technicznej. Zafascynowany programowaniem, rozpoczął naukę JavaScriptu i konsekwentnie kontynuował edukację, aż dołączył do swojego pierwszego projektu w roli inżyniera. Pamiętając, jak to jest zaczynać w IT z zerową wiedzą, zbudował kurs dla osób spoza IT, w którym w prosty sposób naucza kluczowych pojęć i konceptów z programowania, architektury i budowy aplikacji oraz wielu innych obszarów, aby pomóc osobom nietechnicznym odnaleźć się w gąszczu programistycznego żargonu.