Wymuszone zaangażowanie

czyli dlaczego programistom przestaje zależeć

Stałym wyzwaniem w organizacjach, z którymi pracowałem jest osiągnięcie zaangażowania pracowników. Zaangażowanie rozumiem jako coś podobnego do odpowiedzialności, ale posiadającego inne źródło. O ile odpowiedzialność to coś, co wynika z opisu stanowiska pracy, kultury danej organizacji, lub warunków zawartych w umowie, zaangażowanie wypływa z wnętrza człowieka i odpowiada za to, jak podchodzi się do powierzonych zadań.

Według mnie, kluczem do zaangażowania jest jednoczesna obecność trzech aspektów:

Chęć wpływu na swoje najbliższe otoczenie;
Otwartość na stawanie się lepszym w tym co się robi (co wiąże się z nauką, ale również popełnianiem błędów);
Przekonanie, że praca, którą się wykonuje jest potrzebna i wartościowa – tak dla mnie, jak dla innych.

Jeśli zarządzający nie chcą zrezygnować z części swojej władzy (przekazać ją osobom niżej w formalnej strukturze), bardzo trudno jest je osiągnąć. Sam spotkałem się niejednokrotnie z sytuacją, w której kierownictwo deklarowało chęć zaangażowania pracowników do pracy, podczas gdy nie rozumiało (czy nie akceptowało), że to wiąże się z oddaniem pewnego zakresu decyzji osobom będącym niżej w strukturze.

Różni ludzie, różne potrzeby

Pamiętam jak Piotr – jeden z pierwszych mądrych ludzi, z jakimi miałem przyjemność pracować – mawiał, że “Ludzie różnią się między sobą”. Wtedy wydawało mi się to truizmem (okazało się, że po prostu tego nie rozumiałem), ale z biegiem lat widzę, dla jak wielu osób zrozumienie tej prawdy jest bardzo trudne. Sam często łapię się na tym, jak błędnie projektuję swoje przekonania i interpretacje na innych.

Wspomniane w tytule zaangażowanie wiąże się nieodzownie z terminem motywacji – którą sam rozumiem w bardzo uproszczony sposób jako napięcie pomiędzy stanem faktycznym, a niezrealizowaną potrzebą. Dążenie do wyeliminowania tego napięcia popycha do działania. Oba te pojęcia opisują wewnętrzne nastawienie do działania. O ile motywacja popycha do działania, zaangażowanie umożliwia jego skuteczne zrealizowanie.

Ludzie w organizacji zdają się dzielić na różne grupy pod względem tego, do czego dążą

Jednym zależy na pensji, innym na podwyżce, jeszcze innym, żeby robić coś, co przynosi realną korzyść nie tylko im, ale również innym ludziom – zarówno klientom, jak i współpracownikom. Według mnie idealną sytuacją jest nawet pewne połączenie tych nastawień – np. osoba, która chce zbudować wartościowy produkt i jednocześnie zostać za to należycie wynagrodzona, zarówno finansowo, jak również przez możliwość nauczenia się czegoś nowego i zrealizowania swoich mocnych stron, czy ambicji.

Gdzieś tu majaczy mi piramida potrzeb Maslowa. Pomimo wielu lat krytyki, wciąż jeszcze nieźle opisująca rzeczywistość. Albo przypomina mi się badanie Fredericka Hertzberga i jego koncepcja czynników higienicznych (co ciekawe do nich zalicza się wynagrodzenie;)) i motywacyjnych (jak słynna samorealizacja – cokolwiek miałaby znaczyć). Ale to co najbardziej pomaga mi w zrozumieniu tego zagadnienia, to też klasyczny już “Drive” Daniela H. Pinka i koncepcja 3 składników: Autonomii, Mistrzostwa i Celu, jako składowych potrzebnych do wyzwolenia przedsiębiorczego działania. Chciałbym skupić się na pojęciu autonomii (możliwości decydowania o swoim najbliższym otoczeniu w firmie), która jest jedną ze składowych zaangażowania i w bardzo dużym stopniu zależy od osób zarządzających czy organizujących pracę.

Wymuszone zaangażowanie na przykładzie gildii

Nie wiem, czy mieliście kiedyś do czynienia z koncepcją gildii, albo chapterów. Pomysł wywodzi się bodajże z podejścia zaproponowanego przez Spotify. Jak rozumiem ten pomysł, to jego realizacja powinna umożliwić działanie ekspertów pomiędzy zespołami, czy innymi jednostkami organizacyjnymi (działami, departamentami), aby mogli oni nawzajem uczyć się od siebie oraz inspirować do rozwiązywania pojawiających się problemów. Gildie powinny umożliwiać realizowanie inicjatyw, które rozwiązują realne wyzwania w szybki i skuteczny sposób. Bo oddolnie – pracownicy (często programiści) sami zgłaszają swoje problemy i pomagają im je rozwiązać ich koledzy; rozwiązanie nie jest narzucane „z góry” i łatwiej je przekuć w czyn, wszak jego autorami są osoby, które realnie będą wykonywały daną pracę.

Wyobraźcie sobie gildię zrzeszającą programistów front-end*, której powstanie zostało “zarządzone” przez jednego ze Scrum Masterów**. Nie byłoby to pewnie poważnym problemem, gdyby nie fakt, że Scrum Master ten aktywnie “proponuje” (no dobra – narzuca) tematy, które gildia ma poruszać i problemy nad którymi ma pracować. Co więcej – obecność na niej jest obowiązkowa.

Czy brzmi to dla Was znajomo? Czy spotkaliście się z koncepcją oddolnej z definicji inicjatywy, która została wprowadzona przez Waszych przełożonych?

*Małe wyjaśnienie dla czytelników spoza bańki programistycznej;) w dużym uproszczeniu, front-end to część systemu z którą użytkownik wchodzi w bezpośrednią interakcję – np. układ i sposób działania aplikacji mobilnej banku; ze względu na specyfikę tej pracy wykształciła się grupa programistów, którzy specjalizują się właśnie w pisaniu front’u.

**Scrum Master to odpowiedzialność, ale często też oddzielna rola w zespołach programistycznych. W dużym uproszczeniu to lider zespołu odpowiedzialny za jego efektywność.

Czy to się może udać?

Według mnie tak. Jeżeli rzeczony Scrum Master naprawdę aktywnie włączyłby się do działań gildii i wspierał swoją pozycją realizację zaproponowanych działań. On tymczasem głównie narzuca jej tematy oczekując, że programiści sami zorganizują sobie pracę. To znaczy dodatkowe zadania, które muszą być wykonana obok obowiązków w ich zespołach. Co więcej programiści muszą negocjować ze swoim Product Ownerem wykonanie pracy wynikającej z postanowień gildii obok innych zadań wynikających ze zobowiązań dla biznesu. Czas nie jest z gumy i nikt nie lubi przesiadywać na bezpłatnych nadgodzinach. Wszystko sprowadza się do priorytetów – i w takim układzie zadania z gildii na ogół przegrywają.

Czyli rzeczywistość jest taka, że Developerzy pojawiają się na gildii, bo muszą. Nie mają też swobody w wyborze tematów, którymi mieliby się zajmować – są one narzucane „z góry”. Jakoś też tak wychodzi, że nie przejawiają specjalnej aktywności na samych spotkaniach. Nie wspominając o tym, że same zadania też “nie mają kiedy” być wykonane, bo trzeba dostarczyć kolejne funkcjonalności dla biznesu.

Gildia jeszcze “zipie” siłą rozpędu, czy może raczej zrządzeniem Outlook’a, który trzyma jeszcze serię spotkań, ale czy ma szansę realnie pomóc w poprawie kodu, produktu i jakości pracy Developerów?

Czego zabrakło?

Chyba przede wszystkim rozumienia, że aby oddolna inicjatywa mogła zadziałać nie może być ona przedmiotem źle zrozumianej aktywności kogoś kto jest postrzegany jako kierownik. Zabrakło programistom autonomii do decydowania o sobie. Ktoś kto czuje się odpowiedzialny za rozwiązywanie problemów przyszedł z rozwiązaniem, zamiast zweryfikować najpierw, czy któryś z programistów chciałby taką gildię prowadzić i jak wielu jego współpracowników chciałoby aktywnie się w nią włączyć. Czy są wśród pracowników dostateczne kompetencje, aby samemu rozwiązywać swoje problemy? Czy sami mają umiejętności i chęci do negocjowania priorytetów, aby móc pracować jednocześnie nad zadaniami przychodzącymi nie tylko od biznesu, ale też a gildii? Zabrakło w końcu odpuszczenia władzy. Zabrakło zaufania, że programiści dobrze zainwestują swój czas i pieniądze firmy.

To każe również zadać słuszne pytanie o rolę Scrum Mastera w tej sytuacji – czy nie jest tak, że ta odpowiedzialność sprowadzona właśnie do roli nie tworzy systemu w którym Developerzy nie są po części ubezwłasnowolnieni? Ale to temat na zupełnie inny artykuł.

Co zrobić, aby programistom jednak zależało?

Kierownictwo inicjując oddolne inicjatywy musi posiadać dwa kluczowe atrybuty:

Zaufanie do uczesntików inicjatywy, że ci na poważnie zabiorą się do tego zadania;
Gotowość do dania swobody w realizowaniu prac wynikających z postanowień gildii.

Zaufanie zakłada poniesienie ryzyka. Zaproszone osoby mogą niepoważnie podejść do tej inicjatywy, poniesie ona fiasko i promotor musi liczyć się z kosztami, co najmniej w zakresie jego wizerunku.

Władza to temat jeszcze poważniejszy. Oddanie jej w ręce członków oddolnej inicjatywy oznacza pozbycie się jej z własnych rąk. Wszak to nie ja już coś robię, ale pracę i jej potencjalne pozytywne rezultaty zostaną przypisane do kogoś innego. Jeżeli jest się kimś przywiązanym do swojej roli oznacza to zredukowanie własnej pozycji w organizacji – przynajmniej w perspektywie osoby utożsamiającej się ze “stopką” w swoim mailu.

Gildia wymaga właściwych uczestników. Dobrym pomysłem byłoby zasięgnięcie języka u samych zainteresowanych – zdefiniowanie problemu i jego skali. Kolejno wyszukanie reprezentanta danej grupy, który chciałby poprowadzić inicjatywę. Nie jako ktoś z “zarządzających” powołany do tego “z urzędu”, ale właśnie bezpośredni uczestnik grupy, znający i rozumiejący jej problemy. Należałoby znaleźć osobę, która: chce rozwiązywać problemy, nie boi się wpływać na swoje otoczenie, widzi sens i wartości potencjalnych działań w ramach gildii oraz posiada pasję do tego co jest jej przedmiotem – w tym przypadku programowania frontu aplikacji.

Jest też oczywiście miejsce na dobrze rozumianą rolę kierownictwa – powinno ono włączyć się na prośbę członków gildii – pomagając im w realizowaniu zadań, które wymagają np. decyzji budżetowych związanych z zakupem licencji na potrzebne narzędzia, lub wdrożenia zmian procesowych, wymagających szerszych konsultacji.

Dobrym pomysłem jest też, aby gildia (czy jakakolwiek inna inicjatywa) działała w sposób transparentny i miała otwartą formułę.

Kończąc truizmem – dla każdego jest miejsce, ale trzeba dobrego rozumienia swojej roli, szczerej komunikacji oraz odrobiny ryzyka i zaufania, że się ono opłaci, tak jednostkom, jak większej organizacji.