Przejdź do treści

Jak motywować informatyków?

MotywacjaKaż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.

9 komentarzy do “Jak motywować informatyków?”

  1. Elementem motywującym, który bardzo dobrze działa, jest positive feedback. Powiedzenie komuś po zakończonym zadaniu „dobra robota” czy „świetnie to wymyśliłeś” jest często bardzo ważne. Niestety z niewiadomego powodu jest to sposób stosowany bardzo rzadko. Często jedyną odpowiedzią na wykonane zadanie jest milczenie managera i przydzielenie kolejnego tasku…

    1. Znam kilka firm, ktora placi grosze, kaze zostawac po godzinach, a na koniec rozdaje „good job’y” :). Zgadzam sie ze lechtanie EGO programistow jest wazne, ale OPROCZ dobrego wynagrodzenia finansowego i warunkow pracy, a nie ZAMIAST.

      1. Mam nadzieję, że nikt nie twierdzi że dobre słowo, albo przydzielanie dobrego zadania to JEDYNA metoda motywacyjna. Ogólnym, niepisanym założeniem tego tekstu było, że mówimy o uczciwej sytuacji, gdzie pracodawca szanuje swoich ludzi i płaci im tyle ile trzeba. Jeśli tak nie jest, to nie ma co się motywować – trzeba zmieniać robotę;)

    1. Przeczytałem… ksiazka jest nie tyle przeswietna co przegenialna. Naprawde warto przeczytac. Dawno nie spotkalem sie z tak swiezym spojrzeniem na temat, ktory wydaje sie byc oklepany. Wzajemne obdarowywanie sie „good job’ami” traci nagle na znaczeniu.

  2. Ze skromnego doświadczenia mogę powiedzieć, że dużo lepiej też pracuje się w miejscu gdzie można znaleźć wsparcie merytoryczne. Kiedy jednak mam możliwość zweryfikowania swoich pomysłów i konsultacji z kimś bardziej doświadczonym – jest ekstra. Ludzie lubią wiedzieć jakie są motywacje stojące za pewnymi zadaniami.

    Jedną z najgorszych wytycznych jest stwierdzenie „zrób tak żeby było dobrze”, bo to sprawia wrażenie, że powierzający zadanie ma gdzieś efekt.

    To co mi dużo daje to podziękowania i rzetelna krytyka za konkretną pracę, konkretne zadanie. „Ty fajnie pracujesz” to za mało. Ale już stwierdzenie „ten moduł wykonałeś naprawdę świetnie, widać że to to i to zostało przemyślane” jest bardzo dowartościowujące :)

  3. Na ten wpis trafiłem dopiero teraz:) Oczywiście każdy z nas jest inny, inne rzeczy są dla nas ważne i motywujące na naszych stanowiskach, rzeczy które odnoszą się nie tylko do kwestii finansowych czy obowiązków, ale też do samej firmy jak stabilizacja czy bezpieczeństwo zatrudnienia np w gorszych czasach. Trafnie zauważyłeś „zaspokojenie podstawowych potrzeb finansowych”, bez czego ani rusz:) Znalazłem taki cytat „Unless you’re some kind of mentalist, you’re not going to know what motivates your employees unless you ask them.” i to jest na pewno klucz do sukcesu. Dla mnie osobiście ważne jest zidentyfikowanie mojego wkładu w rozwiązanie, możliwość wykazania się i cel, dla którego to rozwiązanie powstaje. Ważne jest też dla mnie zidentyfikowanie umiejętności, doświadczenia które dzięki temu rozwiązaniu nabyłem.

Skomentuj Kuba M. Anuluj pisanie odpowiedzi

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.