Pieniądze w IT to gorący temat. Jak zresztą w każdym zawodzie. W branży cyfrowej jednak o tyle gorący, że pieniądze są zwykle większe. Podwyżka programisty może być równa jednej trzeciej albo i połowie pensji kelnera, więc jest się czym emocjonować…
Kto zyska, kto straci?
W książce Negocjacje z potworami Igor Ryżow przytacza ciekawą anegdotę. Miał się on udać wraz z szefem ekipy remontującej jego mieszkanie do sklepu w celu nabycia materiałów. Sprzedawca sprzeczał się z remontowcem na temat jakości kabli, namawiając go na inne. Ten jednak uparcie odmawiał. Nagle pracownik sklepu odezwał się do właściciela mieszkania: „Zdaje sobie pan sprawę, co się stanie, jeżeli te kable się zapalą?”.
Anegdota ta uczy nas, że negocjować należy z tymi, którzy mają najwięcej do stracenia w wyniku podjętej decyzji. Przypomina mi to pozornie sprytną strategię jednej z firm IT w Polsce. Wynajmowała ona programistów klientom końcowym, zarabiając na pośrednictwie. Popularny model biznesowy, wygodny dla wszystkich stron. Do procesu negocjacji podwyżek nie włączano jednak klientów. Rozmowa odbywała się między pośrednikiem, a programistą. Dawało im to doskonałą pozycję – w zdecydowanej większości przypadków twardy negocjator zbywał prośby inżynierów o podwyżki. Na krótko wygrywał.
Co tracił manager z firmy pośredniczącej odmawiając programiście? Nic. Czy coś ryzykował? Niewiele. W najgorszym dla niego przypadku deweloper po jakimś czasie się zwalniał i odchodził do konkurencji, a klient zlecał zatrudnienie kolejnego. Uzasadniało to istnienie sporego działu rekruterów, dawało im pracę, a nawet w pewnym sensie pozwalało zatrudniać kolejnych inżynierów drożej. Bo w końcu łatwiej wytłumaczyć klientowi, że nikogo taniej nie sposób było znaleźć, niż że ten, który pracował rok za x PLN na godzinę, teraz chce x + 20 PLN. A wyższa stawka to większy zysk dla firmy pośredniczącej, pobierającej pewien procent wynagrodzenia kodera.
Z pozoru przegrywał programista – w końcu musiał się godzić na pracę za niesatysfakcjonującą stawkę lub zmianę pracy w poszukiwaniu większej miski deweloperskiego ryżu.
Kto jednak tracił tak naprawdę? Czy nie klient? Wdrożenie programisty w projekt – szczególnie, że w tym przypadku były to projekty dość złożone – zajmuje sporo czasu. Odnalezienie się w strukturach przedsiębiorstwa również. Nawiązanie kontaktów też. Mówiąc krótko – nowo zatrudniony inżynier jest dość nieefektywny. Z punktu widzenia klienta lepiej byłoby mieć zespół składający się z ludzi obeznanych z firmą, sprawdzonych w boju i usatysfakcjonowanych z pracy. Każda nowa osoba wprowadza do projektu nieco chaosu, a także niesie ryzyko niedopasowania, a nawet katastrofy.
Warto zatem – dla skuteczności własnych negocjacji, ale i dla dobra tej części biznesu, która nas żywi – rozmawiać o podwyżkach najpierw i przede wszystkim z tymi, których to najbardziej dotyczy. To klienta, to lidera zespołu programistów, w którym pracujemy dotknie nasze potencjalne odejście albo demotywacja. Nie ważne z kim podpisaliśmy umowę, z kim formalnie jesteśmy związani. Ważne kto jest ostatecznym odbiorcą naszych usług.
Potrzeba matką podwyżki
Pewnym ideałem promowanym w środowisku programistów jest to, że dobrze zorganizowany projekt pozwala nowemu inżynierowi na szybkie dołączenie do zespołu. Oczywiście jest to nieco utopijne, bo w przypadku złożonych produktów musi upłynąć nieco czasu, nim nowy pracownik go pozna, ale generalnie przyjemnie jest szybko po zatrudnieniu czuć się efektywnym i wykonywać zadania. Jest to też pozytywne dla biznesu – możemy spokojnie udać się na urlop nie będąc niezbędnym, jesteśmy wszak tylko małym, zastępowalnym trybikiem w wielkiej maszynie projektu.
Niestety, z punktu widzenia naszej pozycji negocjacyjnej taka zastępowalność jest fatalna. Zastanówmy się – jeśli każdego programistę da się szybko wymienić, po co dawać nam podwyżkę?
Większość artykułów w internecie pełna jest sztampowych porad w stylu – najpierw pokaż, że jesteś więcej wart, bierz na siebie więcej obowiązków, rób szkolenia, bądź pozytywny itp. Jest to oczywiście pewna droga, ale też prawdę mówiąc niewielu w IT ona interesuje. Po co programista ma się przesadnie wysilać przez kilka miesięcy, udowadniać swoją wysoką wartość i wykazywać się nadzwyczajnym zaangażowaniem, skoro może iść na rozmowę kwalifikacyjną do konkurencji i dostać 20 procent podwyżki za 30-45 dni?
Poza powyżej opisaną, pozytywną ścieżką, istnieją dwie ciemne i makiaweliczne. Wbrew pozorom jednak obierane przez sporą część naszych kolegów i koleżanek i wcale nie kończące się wygnaniem z zawodu. Pierwsza to groźba natychmiastowego odejścia, a druga to stanie się niezbędnym w projekcie.
„Rzucenie papierami” często jest zaskakująco efektywne. Poradniki zazwyczaj twierdzą, że jest to najgorsze co możemy zrobić i już następnego dnia pracodawca będzie szukał zastępstwa na nasze miejsce. Być może w innych zawodach tak jest, natomiast w branży IT widywałem już wielu szantażystów, którzy pracowali przez wiele miesięcy po uzyskaniu podwyżki tym brutalnym sposobem. Zastanówmy się zresztą, jak to w praktyce może wyglądać…
Szantażysta może zażądać mniej, tyle samo lub więcej, niż oferuje obecnie rynek. Jeśli mniej – świetnie. Owszem, było niemiło, ale zasadniczo nadal zyskujemy. Jeśli zażąda tyle, ile rynek – wciąż nieźle, nadal zyskujemy. W końcu jest doświadczonym pracownikiem, a nowego w tej samej cenie będzie trzeba wyszkolić. Jeśli więcej – możemy dać tyle, ile oferuje rynek lub zwyczajnie odmówić. Więcej nie damy. Innymi słowy – jeśli dojdzie do porozumienia, to zawsze będzie ono korzystne dla managementu. Tylko z punktu widzenia emocji może być niekorzystne. Czy jednak możemy zakładać, że kierownicy nic innego nie mają do roboty, niż ignorować interes firmy i pielęgnować własne negatywne emocje? Być może. Sądzę jednak, że spora część myśli trzeźwo…
Drugą makiaweliczną opcją jest stanie się niezbędnym. To wbrew pozorom bardziej ryzykowna opcja, bo kiedy management zorientuje się, że jeden pracownik jest wąskim gardłem i jego brak oznacza katastrofę, z pewnością podejmie próbę zaradzenia takiej sytuacji. Jest to też opcja bardziej czasochłonna. Powinniśmy się zatem uzbroić w cierpliwość i przygotować na kontratak. Trzeba jednak zdawać sobie sprawę, że jest to ścieżka możliwa do realizacji tylko w długo trwających projektach i raczej w małych firmach bez procedur i ustalonego ładu korporacyjnego. O ile jednak uda nam się stać członkiem zespołu, bez którego projekt się posypie – uzyskujemy doskonałą pozycję do negocjacji podwyżki. To my możemy odejść od stołu, a druga strona straci bardzo wiele. Nie tylko możemy odejść, ale najpewniej też przez jakiś czas będziemy błagani o powrót i przekazanie wiedzy. O ile scenariusz ten jest mocno emocjonalny i ryzykowny, o tyle na małą skalę stanie się niezbędnym może dobrze działać. Wystarczy, że będziemy zwyczajnie dużo bardziej użyteczni od większości innych programistów, że będziemy mieli jakieś specjalne umiejętności, dużo większą wiedzę o projekcie, że będziemy na szczycie piramidy, że każdy to z nami będzie konsultował pracę. Powinno to być wręcz celem każdej osoby, która planuje długotrwałą karierę techniczną w danym projekcie. I samo to powinno wystarczyć do uzyskania przewagi w negocjacjach.
