mężczyzna na tle napisu "productivity"

Kiedy podejmujesz decyzję, czy zostaniesz leadem zespołu, lista “za” i “przeciw” potrafi mieć zaskakująco dużo pozycji “przeciw”

Kiedy kilka lat temu Chris, nasz COO zapytał mnie, czy chcę zostać Project Managerem, potrzebowałem dwóch dni na zastanowienie. Minęły kolejne dwa lata, zanim spytał, czy zgodziłbym się zostać leadem wtedy już sporo większego zespołu PM-ów. Tym razem poprosiłem o tydzień.

Maciej Madej

Nie dlatego, że nie lubię wyzwań – wręcz przeciwnie. Wiedziałem natomiast, z czym musi zmagać się każdy PM. Nie tylko czego wymagają od niego co bardziej skomplikowane projekty, ale także to, czego wymaga sama kultura i struktura naszej organizacji. Z jednej strony – pełna swoboda ruchów, z drugiej – maksimum odpowiedzialności. To oczywiście ogromna satysfakcja, ale i nieprzespane nocki, nadgodziny (za które nie chcemy pieniędzy, bo przecież jesteśmy odpowiedzialni), mnóstwo kombinowania i popełnionych błędów.

Żebyśmy się dobrze zrozumieli – gdyby praca PM-a była do bani, to po pierwszych miesiącach wróciłbym do QA. Jest wiele plusów, ale kiedy musisz podjąć decyzję, czy zostaniesz leadem zespołu w organizacji, która ciągle się rozwija, to lista “za” i “przeciw” potrafi mieć zaskakująco dużo pozycji “przeciw”. To dlatego, że od tej pory będziesz odpowiedzialny zarówno za siebie i swoje projekty, jak i za każdego członka zespołu, który przechodzi przez coś podobnego.

Taka decyzja wymaga czasu. Ofertę przyjąłem kolejnego dnia.

Rok później

Trochę ponad rok później nadal jestem leadem. Nasz zespół składa się ze mnie i ośmiu innych osób różnej płci. Szukamy kolejnych.

Zwiększyliśmy produktywność. Mamy relatywnie stabilne procesy. Jesteśmy teamem o największym poziomie zadowolenia w organizacji. W większości przypadków znajdujemy się wysoko w punktacji kwartalnej za performance.

Odkąd wziąłem tę robotę, zatrudniliśmy kilku nowych PM-ów. Nie mieliśmy żadnego zwolnienia ani rezygnacji (przysięgam – nie są tu zakładnikami!). Niewiele w tym mojej zasługi. Project Management to przede wszystkim praca zespołowa i tak też do tego podeszliśmy. W tak pozytywnym rozwoju spraw wzięli udział wszyscy, od wyższych struktur organizacji, HR, przez członków zespołu, na mnie kończąc.

Jakim leadem chciałem być?

Kiedy startowałem na pozycji leada, postawiłem sobie trzy główne cele.

Jestem z tych, którzy od zawsze mieli problemy z autorytetem. Kiedy polecenie przychodzi “z góry”, bez kontekstu, z automatu mówię “nie”, a dopiero potem zastanawiam się nad argumentami. Cały czas uczę się panowania nad tym odruchem i wiem, że nie jest to łatwe. A wiedziałem, że przejmuję zespół takich samych łobuzów.  Co więcej, sam kilkoro zatrudniłem. Tak wyklarował się mój pierwszy cel – sami ustalamy zasady. “My”, nie “ja”. Jeśli mamy pracować sprawnie i bez spięć, musimy (w granicach rozsądku) wspólnie tworzyć zasady, na których prowadzimy projekty.

Cel drugi – zmiany wdrażać szybko i poprawki wprowadzać już na żywym organizmie. Nic nowego dla ludzi z branży – każda chwila poświęcona na pracę nad idealnym rozwiązaniem to czas stagnacji, stresu i poczucia frustracji. Poczucie ciągłej ewolucji sprawia, że wszyscy znamy kierunek, a ten kierunek to zawsze do przodu nawet jeśli z wybojami.

Trzeci cel nie jest chyba celem per se. Wiedziałem, że muszę być otwarty na fakt, że nie jestem najlepszym project managerem w zespole. Wszystkiego nauczyłem się w .intent. Nie mam edukacji w temacie i posiadam ledwie jeden certyfikat. Bycie leadem i bycie najlepszym to dwie osobne sprawy, które często wrzucamy do jednego worka. Dla mnie rozdzielenie ich oznaczało zrozumienie, że moje pomysły i propozycje nie zawsze będą najlepsze i muszę przede wszystkim słuchać.

ZOBACZ TEŻ:  Z HR do UX - czyli o przebranżowieniu w jednej firmie. Wywiad z Alicją Topor

Bycie leadem a presja

Krok pierwszy, choć z natury egoistyczny, był oczywisty – jeśli zespół ma pracować w atmosferze z niewielką ilością stresu (a raczej ze stresem wynikającym z natury pozycji, bez dodatkowych czynników), to lead zespołu również musi mieć przestrzeń. Całe szczęście to ja jestem leadem, więc przyszedł czas się wychillować.

Przede wszystkim potrzebowałem czasu na wykonywanie obowiązków. Ustaliliśmy podział pracy pomiędzy projekt a leadership w formie 50/50. Po ponad roku podział ten wygląda 80/20 dla leadershipu, natomiast większość pracy projektowej oddałem juniorom. Zdaję sobie sprawę, że to nie przejdzie w każdej organizacji. Ale przejdzie w takiej, która rozumie potrzeby zespołów i złożoność obowiązków leada. Jest więcej czynników, które trzeba wziąć pod uwagę, takich jak liczba osób w zespole, wielkość i liczba projektów, dojrzałość organizacji. Dla uproszczenia, 50/50 to dla mnie minimum.

Kolejnym elementem jest work-life balance. Już kilka lat temu podjąłem decyzję, która zmieniła moje życie – wyłączyłem notyfikację ze Slacka i maila. Jak coś się stanie, to zadzwonią. Zdecydowałem też, że nie zajmuję się pracą poza pracą – w jej trakcie daję z siebie wszystko, więc jeżeli nie dałem rady czegoś zrobić, to dlatego, że nie dało się tego zrobić w moim tempie. Po pracy się odcinam i do tematu wrócimy jutro. Oczywiście w tej pracy czasem zdarzają się wyjątki, ale tym razem przynajmniej będą brał kasę za nadgodziny.

Tym samym zostałem z dobrymi kilkoma wolnymi godzinami dziennie. Ale jednak uczucie niedosytu zostało – tak dużo do zrobienia, tyle planów rozwoju i planów naprawczych, a czasu wciąż zdecydowanie za mało. Rozwiązanie jest zabójczo proste – jeśli masz zespół, któremu możesz zaufać i który chce decydować o własnym losie, delegowanie zadań staje się nie tylko sposobem na zwolnienie przestrzeni, ale i potężnym narzędziem.

Zespół

Wszystko pięknie, ale z pustego nie nalejesz. Do rozwoju działu potrzebny jest team, który ma podobne cele i potrzeby w sferze wspólnej pracy i odpowiedzialności.

Nasz miks jest na oko niezgrabny: ludzie z wielu środowisk, ze skrajnie różnymi doświadczeniami i historią wejścia zarówno w branżę jak i w rolę PM-a – mamy byłą stewardessę, eksperta od chińskich klawiatur, ja sam zaczynałem jako QA. Mamy różne poczucie humoru, hobby, rodziny. Inne poziomy doświadczenia, style zarządzania, inaczej radzimy sobie ze stresem. Łączy nas za to potrzeba gry zespołowej, poczucie odpowiedzialności za pracę własną i zespołów projektowych, chęć stabilizacji, rozwoju i wpływu na nasze działanie wewnątrz organizacji.

Właśnie te cechy wspólne pozwalają nam współpracować na bardzo wysokim poziomie i na wielu poziomach.

Rekrutacja

Niezbyt odkrywcze będzie stwierdzenie, że jednym z podstawowych elementów budowania zespołu jest rekrutacja. Udało nam się zebrać zespół pełen indywidualności, ale taki, który chce i lubi spędzać ze sobą czas, potrafi żartować, dyskutować i pracować razem. Brzmi jak utopia – wiem, ale przypomnę: zerowa rotacja przez rok i kwartał.

Nie będę się skupiał na samym procesie, ale warto wspomnieć o najważniejszych założeniach naszej rekrutacyjnej układanki. Rozpocząłem od trudnej decyzji, która nie przysporzyła mi fanów w dziale rekrutacji – przynajmniej na początek szukamy tylko seniorów i juniorów. Z dotychczasowych obserwacji wynika, że praca PM-a w intent jest wymagająca, obowiązków jest pod korek. Potencjalny kandydat musi mieć sporo doświadczenia w podobnym środowisku lub nie mieć doświadczenia, ale pasować kulturowo, a wtedy wszystkiego go nauczymy. Kandydaci na stanowiskach “regular” nie sprawdzali się w dotychczasowej historii organizacji – brakowało dla nich opisów procesów i odpowiedniej siatki wsparcia. Żeby móc swobodnie budować zespół, musiałem powstrzymać niepewność, z którą wiązała się praca z osobami, o których performance się obawiałem.

Kolejny punkt, na który zwracamy uwagę, to skille miękkie, prawdopodobnie najważniejsze w pracy PM-a. Klarowna, rzeczowa komunikacja, czytanie ze zrozumieniem, umiejętność odnalezienia się w stresującej sytuacji o podłożu komunikacyjnym, doskonały angielski.

Na koniec – w trakcie rozmowy, nawet na pozycję seniora, skupiamy się na poznaniu osoby. Kim jesteś, w jaki sposób myślisz, co jest dla ciebie ważne. Zadajemy oczywiście pytania techniczne, ale będę szczery – są stosunkowo proste.

Jesteśmy już w połowie, a nie wspomniałem jeszcze o obowiązkach – swoich bądź członków zespołu. Faktycznie, dzisiaj nie o tym. Wspomnę jednak, że o obowiązkach oraz o stanie firmy i zespołu rozmawiamy bardzo otwarcie podczas rekrutacji. Kandydaci muszą podjąć świadomą decyzję, że chcą tu być, a mogą to zrobić tylko wtedy, gdy mająpełen zestaw informacji. Nie chcemy, żeby nowa osoba odeszła po okresie próbnym, bo poczuła się okłamana na rozmowie i nie spodziewała się tego, co ją czeka. Wydaje się też, że świadoma decyzja buduje poczucie odpowiedzialności i chęć sprawdzenia się, ale to już tylko domysły.

Stabilność i współpraca

Po zebraniu zespołu przyszedł czas zastanowić się, jak pomóc im pracować efektywnie, ale też chętnie i bez zbędnego stresu. Zrobiliśmy to na kilka sposobów.

Relatywnie jasno określiliśmy obowiązki. Sprowadzają się one do listy obowiązków projektowych oraz wewnętrznych dla organizacji, które staramy się opisywać na bieżąco. Budujemy bazę wiedzy procesowej i jesteśmy z niej dumni. Nadrzędnym zadaniem PM-a jest doprowadzenie projektu z punktu A do punktu Z. Poza procesami koniecznymi, PM ma relatywną dowolność w tym, jak prowadzi swój projekt, o ile efekty są pozytywne.

Podczas rekrutacji na seniora często zadaję pytanie: “jaka według ciebie jest odpowiednia liczba projektów, którą powinien prowadzić PM?”. Usłyszałem wiele interesujących odpowiedzi. Od “nie wiem”, przez bardziej sensowne “zależy od projektów” aż do “ja prowadzę dziesięć do piętnastu” (serio, nie wymyślam). W .intent odpowiedź to dwa. Dwa mniejsze projekty po pół etatu każdy, bądź jeden duży na cały etat. Nie rozdrabniamy się bardziej. Czasy, w których każdy z nas miał 4-6 projektów fixed-price i zero czasu na każdy z nich minęły, mam nadzieję bezpowrotnie. Decyzję sprowadzamy do dwóch głównych czynników – liczebność zespołu projektowego oraz dojrzałość Product Ownera po stronie klienta. Równanie nie jest doskonałe, ale z pomocą zespołu sprzedaży oceniającego (na podstawie przygotowanego przez nas dokumentu), co może do projektu wnieść PO – działa wystarczająco dobrze. Przynajmniej na razie.

Ale co, jeśli procesy i propozycje nie działają lub nie są skrojone idealnie? Ważne jest, żebyśmy nie czuli się przytłoczeni i zmuszeni do wykonywania niepotrzebnej pracy. Na cotygodniowych spotkaniach tzw. operacyjnych dajemy sobie przestrzeń na propozycje, dyskusje i usprawnienia. Ich wdrażanie oraz system aktualizowania już zebranej wiedzy rozdzielony jest pomiędzy nas wszystkich. To jedyny sposób, żeby się nie pogubić. Mamy wiki, do tego pliki utrzymaniowe, kanał na Slacku służący tylko do rewizji propozycji procesów i rozwiązań. Jestem ostatecznym ownerem tematu, ale wszyscy czujemy się za niego odpowiedzialni. A związku z tym, że lubię żyć na krawędzi, zapewniam też PM-ów, że poza wyjątkami mogą być elastyczni w tym, jak wdrażają te wymogi w swoich projektach – nie każdy proces to wytrych pasujący do każdego zamka. “Duch reguły” ma większą wagę niż reguła sama w sobie.

Pomimo tego, że projekty są prowadzone samodzielnie, zespół zawsze ma przestrzeń do wspólnej dyskusji. Na Slacku, wspomnianych spotkaniach operacyjnych, czy twarzą w twarz. Młodsi stażem i doświadczeniem mogą podpytać o rozwiązania i zawsze znajdzie się ktoś do pomocy. Czasem mam wrażenie, że wolimy pomóc komuś w teamie niż zajmować się własną robotą. Ja z kolei wiem coś o wszystkich projektach i mogę łatwo wskazać powtarzające się sytuacje, poprzednio wyciągnięte wnioski skierować do osoby, która przechodziła już przez coś podobnego.

Dalsza część artykułu znajduje się na kolejnej stronie.

Zapraszamy do dyskusji

Patronujemy

 
 
More Stories
Google
Google obchodzi 23. urodziny. Jak zmieniał się przez lata?