Jak motywować informatyków?

Każdy manager chciałby zarządzać zespołem ludzi, którzy są bardzo zmotywowani do swojej pracy. Zespołem, który z entuzjazmem realizuje swoje zadania, podejmuje niebanalne wyzwania, mobilizuje się do pracy w obliczu trudności. Zespołem, który – podobnie jak maszyny Boba Budowniczego – mówi: „damy radę!” i zabiera się z uśmiechem za pracę.

Jak wzmacniać motywację zespołu? Na temat motywacji jest ponad milion stron w sieci, napisano tysiące książek i jest dostępnych tysiąc szkoleń. A jak wygląda sprawa motywacji zespołów informatycznych w praktyce?

Tak jakoś jest, że pierwszą rzeczą, która przychodzi nam do głowy, kiedy pojawia się hasło „motywacja” jest wynagrodzenie oraz różnego rodzaju bonusy. Zawsze można komuś dać więcej. Więcej pieniędzy co miesiąc, premia za zakończenie projektu, lepszy abonament medyczny, kartę na basen czy siłownię, lepszy laptop, telefon, samochód służbowy… Czy ta metoda działa? I tak, i nie. W przypadku wynagrodzenia możemy mówić o trzech sytuacjach:

• Pracownik czuje, że zarabia mniej niż powinien i jest tym sfrustrowany. Tutaj niewystarczająca pensja jest bardzo silnym czynnikiem demotywującym.
• Pracownik zarabia adekwatnie do swojej pracy (mówimy tutaj cały czas o subiektywnym poczuciu pracownika!). Tutaj podwyżka lub bonus jest czynnikiem motywującym („o, docenili mnie i dostałem coś dodatkowego za swoją pracę, ale fajnie”) – ale, uwaga, jest czynnikiem motywującym krótkoterminowo. Tak jakoś jest, że szybko przyzwyczajamy się do dobrego – do większej kwoty wpływającej na konto, do nowego telefonu czy karty na basen. „Dali mi – a więc widocznie mi się należy”.
• Pracownik zarabia dużo więcej niż tego oczekuje (tak, bywają takie sytuacje!). Tutaj pieniądze przestają być czynnikiem motywującym, gdyż potrzeby finansowe pracownika są zaspokojone i dając mu jeszcze więcej nie powodujemy, że zaczyna pracować lepiej. W takiej sytuacji pracownik może nie szukać innej pracy („bo tam tyle mi nie zapłacą”) – ale nie znaczy to wcale, że w obecnej pracy będzie pracował bardzo efektywnie!

Także, dopóki poruszamy się w środkowej strefie, podwyżka wynagrodzenia może nam podnieść morale zespołu – ale na krótko. Także głównym zadaniem managera jest tutaj dbanie o to, aby wynagrodzenie było adekwatne do wyników i pilnowanie, aby nie stało się czynnikiem demotywującym. A nie jest to wcale proste.

Innym sposobem na motywowanie pracowników jest awansowanie. Bardzo często awans na stanowisko kierownicze postrzegany jest jako nobilitacja i czynnik motywujący. Ale z awansami w IT mamy kłopot. Bardzo często – wychodząc z założenia, że informatykami musi zarządzać osoba, która rozumie, co oni robią –  na kierowników zespołów są awansowani ich najzdolniejsi członkowie. Na przykład najlepszy programista zaczyna zarządzać zespołem programistów. I tutaj pojawia się problem: kierowanie i przewodzenie zespołem ludzi wymaga zupełnie innego zestawu umiejętności niż umiejętności techniczne – jest to zresztą temat na osobny artykuł. W najgorszym przypadku zespół traci świetnego programistę i zyskuje kiepskiego managera… A drugi problem z awansami polega na tym, że ilość stanowisk związanych z zarządzaniem jest ograniczona, a wakaty na stanowiskach kierowniczych zdarzają się tylko czasami. Czy zatem metoda motywacji przez awansowanie działa? Z reguły tak, ale możliwości stosowania tej metody są z reguły mocno ograniczone.

W tym momencie często pojawia się pojęcie „awansu poziomego”, czyli wprowadzenie usystematyzowanej ścieżki kariery z nazwanymi etapami na tej ścieżce – czyli wciąż jesteś programistą, ale już nie zwykłym, tylko starszym.

Na pierwszy rzut oka koncepcja jest bardzo kusząca. Opisujemy dokładnie kryteria oceny pracowników i pewne progi, które muszą przekroczyć, aby stać się kimś „ważniejszym”. Z każdym poziomem możemy stowarzyszyć pewien zakres korzyści czy przywilejów. Zresztą, o ile dobrze to wymyślimy, to sam tytuł stanowiska będzie swoistym wyróżnieniem i profitem, który ludzie chętnie wpiszą do swojego resume czy CV. Niestety, choć koncepcja jest ciekawa, to jej praktyczne realizacje często są mocno kulawe. Stoimy bowiem przynajmniej przed kilkoma zagrożeniami. Po pierwsze, jeśli zbyt szczegółowo wyspecyfikujemy wymagania – na przykład „musisz zdać certyfikat OCJP” albo „musisz zakończyć 10 projektów”, to istnieje ryzyko, że ludzie zamiast naprawdę pracować lepiej, skupią się tylko na zbieraniu punktów i suchym wypełnianiu wymogów. Oczywiście nie wszyscy i nie zawsze – dlatego jest to ryzyko, a nie konieczność. Drugie ryzyko jest inną skrajnością, kiedy wymogi będą zbyt luźno opisane. Wtedy tak naprawdę od naszej decyzji zależy kto już jest „super expert”, a kto wciąż „junior”. Jak tylko ludzie to zrozumieją to… zamiast motywacji możemy mieć totalną demotywację. „Skoro to tylko zależy od widzimisię szefa, to po co się starać?”. No i w końcu kolejne ryzyko – moim zdaniem najważniejsze – na ile zmiana nazwy stanowiska wpływa na charakter pracy. Na papierze oczywiście możemy to naszkicować bardzo pięknie –  ale na ile  w praktyce zestaw codziennych obowiązków „senior super master experta” będzie różnić się od pracy zdolnego studenta na stanowisku „junior”? Znów – jest to ryzyko, a nie konieczność. Jeśli dobrze to opracujemy i będziemy konsekwentnie stosować – super. Jeśli nie, to – co jest charakterystyczne dla tej metody – osiągniemy zupełnie odwrotny skutek, czyli wielką demotywację!

Wprowadzenie solidnej, rzetelnej i skutecznej ścieżki kariery jest trudne i ryzykowne. Niepowodzenie może być bolesne i kosztowne. Zresztą wprowadzanie wielkiego ciężkiego narzędzia metodą „up-front” – czyli najpierw długo myślimy i planujemy, opisujemy, projektujemy i potem jednym rzutem wrzucamy – z reguły źle się kończy. Zarówno jeśli chodzi o projektowanie systemów IT, jak i zarządzanie ludźmi… Alternatywą jak zwykle jest proces iteracyjny, z prototypami, próbami i rozwojem stopniowym.

Przykładem innego rozwiązania jest „wynagradzanie” wyróżniających się pracowników możliwością wyboru zadań do wykonania dla siebie. Działa to szczególnie w miejscach gdzie mamy dość obszerny worek projektów czy większych zadań do wykonania. Jeśli dobrze pracujesz, to zyskujesz pewność, że nie trafisz do najnudniejszych i uciążliwych prac – chyba, że sam to sobie wybierzesz. Realizacja tego pomysłu jest dość prosta. Przy każdej okazji, kiedy przychodzi nowa porcja zadań do rozdzielenia, wybrane osoby mogą to zrobić same dla siebie. Jedyna poważna trudność pojawia się odnośnie tego, jak wybrać te osoby. Nie ma oczywiście złotej recepty, ale zawsze można skorzystać z głosu zespołu i zapytać ludzi, kto ich zdaniem najlepiej sobie radził w ostatnim czasie, kto się wyróżniał, kto najbardziej pomagał innym… Jeśli taka metoda zadziała, można z czasem ją rozbudowywać i na tej bazie iść w stronę bardziej formalnego podejścia ze rzeczywistą ścieżką kariery i bardziej szczegółowym „planem rozwoju” dla danej osoby. A jeśli nie zadziała… to wciąż trzeba szukać dalej i próbować modyfikować metodę.

Idealnie oceniać się nie da i nie można się łudzić, że nasza ocena będzie w 100% obiektywna – ale można się starać słuchać głosów z dołu i góry, samemu patrzeć na efekty pracy (np. na powstający kod lub liczbę defektów) naszych ludzi i po wybraniu osób wyróżniających się dać im możliwość bezpośredniego wpływu na kształt swojej codziennej pracy w następnym tygodniu, miesiącu, kwartale. To jest właśnie mój typ na podejście nieidealne – ale bardzo obiecujące. Dlaczego? Bo nic nie motywuje do dobrej pracy tak, jak dobra praca.

A jakie są Wasze pomysły i metody? Albo jak Wami zarządzają wasi przełożeni? Co działa, co nie działa? Zapraszam do dyskusji w komentarzach.

Powyższy tekst jest pracą zbiorową. Pierwszy szkic napisał Witek, liczne poprawki i rozwinięcia dodał Stasiu.