Коли та як варто підвищувати зарплату розробнику
Привіт, мене звати Віталій Федоркович. В індустрії я починав як C++ розробник, був досвід Team/Tech «лідства». У WePlay Esports, частині холдингу TECHIIA, обіймав посаду Technical Product Manager, а нині — Head of Engineering. Займаюся формуванням технічних команд, розвитком інженерів у компанії, технологічним стеком.
Тема грошей заряджена всюди, а в IT — особливо. Жодна технічна стаття не збере стільки переглядів і коментарів, як чергове дослідження зарплат, історія світчера, який із 3000 грн дійшов до $3000, або поради, як вибити в компанії вищий рейт. Бо ж, як казав Джон Стюарт Мілль, люди не хочуть бути багатими — люди хочуть бути багатшими за інших.
Ця стаття насамперед буде корисною для тімлідів, CTO і тих, хто (під)свідомо будує вертикальну кар’єру. А розробники побачать, на що може звернути увагу їхній керівник під час перегляду зарплати.
Ілюстрація Аліни Самолюк
Кілька слів на старті
Я говоритиму переважно про підходи продуктових компаній, зокрема ті, що ми вже кілька років застосовуємо у WePlay Esports та інших IT-командах холдингу TECHIIA. З певними обмеженнями ці методи можна використовувати в аутсорсингових/сервісних компаніях.
Я не говоритиму про токсичні компанії. Якщо ви маєте досвід роботи з такими, то знаєте, що вони працюють зовсім за протилежними законами.
Отже, спробую охопити базові питання, які виникають у менеджерів та інженерів навколо зарплат:
- Як часто переглядати рейт?
- Як дізнатися про зарплатні очікування розробника?
- Що та як впливає на перегляд зарплати?
- На чому тримається зарплатна політика?
- Що важливіше — гроші чи нематеріальна мотивація?
Основа рейту
Якщо відкинути лірику, є одна причина для підвищення зарплати: у певний момент розробник починає приносити компанії більше цінності.
Мистецтво менеджера — вчасно відстежити цей «певний момент» та адаптувати рейт співробітника до його нового рівня.
«А як же ринок?» — спитаєте ви. Насправді цінність і попит ринку — пов’язані речі. Докладніше про це розповім далі.
Люди мають розуміти: рейт збільшується не тільки тому, що минув час і хліб у магазині подорожчав. Так, індексація від інфляції та інших макроекономічних явищ неминуча. Проте базова складова — це цінність за цінність. Важливо пам’ятати про неї не тільки на рев’ю, а й під час бордингу, навчання, щоденної роботи.
Культура прозорості
Щоб розробники не просто закривали таски, бо так сказав Заратустра продакт, а розкривали свої таланти та пропонували рішення, базове, що має бути в компанії — прозорість і зрозумілість.
Поясню на прикладі. Один з наших продуктів — платформа для організації кіберспортивних турнірів та участі в них. Її фічі приходять інженерам у вигляді задач: створити матчмейкінг, автоматичний флоу для користувачів, реєстрацію тощо. Ми можемо зробити, як на заводі: «Рєбята, ось завдання, ось беклог, вперед. Зробите ефективно — молодці, неефективно — не молодці. А навіщо це все — не ваша справа».
Натомість зараз ми поступово вводимо в роботу фреймворк OKR — Objectives & Key Results. Власники або топменеджмент задають Objectives — тобто куди саме рухається продукт. Далі Objectives розбиваються на конкретні Key Results, надходять до лінійних менеджерів, які фінально розбивають їх на юзер-сторі та фічі.
Загальний результат вимірюється не тільки грошима, які приносить продукт. Це може бути певна стратегічна ціль, користь для користувачів та/або ринку. Щодо турнірної платформи, то наша мета — забезпечити екосистему для проведення ігор із кіберспортивних дисциплін. Ми хочемо, щоб люди могли брати участь у різних змаганнях і зрости до топрівня. На платформі є цілий набір ліг, де, починаючи з матчмейкінгу, людина з нульового рівня може «догратися» до професійного турніру з призовими в кілька мільйонів доларів.
Дуже важливо, щоб повну структуру OKR бачила та розуміла вся команда, а не тільки менеджери. Тільки тоді люди знатимуть можливості і продукту, і власного зростання. Це працює від старту співробітництва. Новачок чітко розуміє: його задачі на випробувальний термін — це конкретні цілі, які допоможуть компанії зрости, якщо він їх виконає.
Прозорість — універсальна характеристика компанії та команди. Клієнти несуть у компанію гроші, а співробітники — час. І перші, і другі розраховують на те, що у цінових і зарплатних політиках усе буде чітко, без позначок дрібним шрифтом.
Індивідуальний підхід
За класикою перегляд навичок і рейтів роблять після випробувального терміну, а потім — на періодичних Performance Review. У середньому в IT-компаніях вони проходять раз на пів року. Менеджер(и) та розробник разом з ейчаром підбивають результати минулих місяців, ухвалюють зарплатні рішення та будують плани на наступний період.
Схема прозора та зрозуміла. Плюс — усі звикають до такої стабільності. Мінус — у тому самому. Розробники розраховують на перегляд у конкретні терміни, тож прив’язують свої зусилля до нього, як до сесій в університеті. Менеджери, своєю чергою, можуть забути про постійний моніторинг команди, а на рев’ю робитимуть поверхові узагальнені оцінки та ставитимуть розмиті цілі.
Свого часу ми переглядали рейти щопівроку та мали яскравий контрпродуктивний приклад. Один з наших інженерів реально починав ворушитися тільки за місяць до перегляду. «На рев’ю він старанно справляв враження, а одразу після того знову розслаблявся до наступного разу.
За такого підходу мотивація рано чи пізно зводиться суто до фінансової. Згодом ми розбили рев’ю на дві паралельні частини.
Перша — Personal Review. Раз на чотири місяці ми влаштовуємо зустріч: інженер, його лінійний та функціональний менеджери, ейчар. Розробник ділиться враженнями від минулого періоду, отримує фідбек за результатами та цінностями.
Далі ми обговорюємо цілі на наступний період. Зазвичай люди самі знають, куди хочуть зростати, інколи треба лише трохи підказати напрямок.
Важливо, щоб цілі були чіткими та зрозумілими. Не просто «підтягнути базу» чи вивчити React, а зробити щось, що принесе більше цінності компанії. Припустимо, ми знаємо, що з часом з’явиться новий продукт/проєкт/технологія і наразі в команді немає експертів з цього питання. Така історія в нас була, наприклад, коли ми переводили інфраструктуру на Kubernetes. Ми завчасно поставили інженеру ціль розібратися у технології.
Цілі можуть бути і «софтові». Приміром, є технічні менеджери, які круто перформлять, але мають деякі проблеми з комунікацією. Через це в команді з’являється непорозуміння, загальна ефективність падає. Ціллю може стати підтягування конкретних навичок взаємодії.
На Personal Review ми встановлюємо контрольні точки, беремо в розробника зворотній зв’язок та синхронізуємося.
Друга частина — це, власне, Salary Review. Як і раніше, ми проводимо його раз на пів року, іноді раніше. На зустрічі аналізуємо, як людина зросла у своїх цілях і цінності для компанії, і вирішуємо, наскільки збільшити зарплату.
Такий підхід допоміг нам відокремити грошову мотивацію від професійної та розподілити робочі зусилля більш рівномірно. Він потребує більшої уваги менеджерів, але враховує індивідуальні плани та внески інженерів.
Постійний контакт із потребами
Продуктивність інженера прямо залежить від його зацікавленості роботою. Тож у проміжках між рев’ю треба бути в курсі бажань розробників. Для цього раз на два-три тижні ми в компанії проводимо one-to-one — напівофіційні особисті зустрічі кожного співробітника зі своїм менеджером.
One-to-one допомагають розуміти загальні та конкретні настрої всередині команди. На них цілком нормально говорити про життя, кіно, плани тощо. Парадоксально, але й робочі питання та проблеми тут розкриваються краще. Наскільки людина задоволена задачами, підходами компанії? Які фактори їй допомагають працювати, а які заважають? Наскільки задоволений менеджмент?
На 1:1 ми періодично торкаємось і очікувань щодо професійного та зарплатного зростання. Не «скільки ти хочеш?», а «куди ти хочеш рухатися та що за це хочеш мати?» — своєрідне локальне Personal Review. Наприклад, розробник відповідає: за наступний рік-два я хотів би розібратися з певною технологією та мені буде окей, якщо я зростатиму на 15% на рік. Інженерні менеджери фіксують собі такі побажання та зіставляють з можливостями.
На основі цих зустрічей можна постійно коригувати послідовність дій. У нас були випадки, коли інженеру, який усе життя займався фронтендом, стало цікаво піти в бекенд. Хтось хоче перевестися в іншу команду, інший продукт, рухатися в управління або архітектуру.
Менеджер має давати розробнику такі задачі, які враховують і його інтереси, і потреби компанії. Якщо людина виконає їх, компанія отримає цінність. Якщо компанія отримує цінність, людину треба заохочувати.
Що впливає на перегляд зарплати
Я умовно розбив фактори впливу на зміну рейту на кілька класичних категорій. Відразу хочу попередити, що немає чітких формул між навичкою та відсотком у грошах. І навіть якщо компанія вводить певні таблички та формули, їх необхідно регулярно переглядати для кожного конкретного випадку.
Нині ми вводимо фреймворк, який враховує п’ять загальних факторів: Mastery, Communication, Impact, Influence, Leadership та їхні розшифрування для кількох рівнів. Це має полегшити роботу менеджерів під час перегляду зарплати, але говорити про результати наразі рано.
Головний пойнт залишається тим самим: зарплата — індивідуальний показник, який залежить від конкретної конфігурації «інженер — керівник — команда — компанія — задачі». Проте нижче я виведу деякі опорні точки для менеджерів і дам підказки для інженерів.
Хард скіли
Перший спосіб для розробника підвищити собі зарплату — зрости технічно та краще перформити. Про всяк випадок уточню: «краще перформити» означає не кількість коду в одиницю часу, а швидкість і якість розв’язання проблем.
Відсоток зростання сильно залежить від рівня розробника.
Приміром, для джуна зарплата збільшуватиметься стрімко. Для нього нормально за перший рік зрости у рейті удвічі, бо він стартує з самого низу. Здебільшого початківці розвивають саме хард скіли, які легше оцінити. Передусім менеджер дивиться на ефективність розв’язання задач. Другий фактор — самостійність: наскільки менше часу та уваги ментора потребує інженер.
Зовсім інша ситуація з досвідченими інженерами з роками кодингу за спиною. Вони вже вміють багато та мають високий рейт. Зрости у хард скілах, та ще й так, щоб цінність для компанії збільшилася у
Хороший варіант зрости в рейті на такому рівні — взяти на себе нову відповідальність. Це може бути як перехід у менеджмент чи архітектуру, так і нова роль при тій самій позиції — наприклад, оунерство чи ініціація технічного проєкту.
Софт скіли
М’які навички багатьом початківцям здаються віртуальною категорією. Проте з часом саме вони визначають професійне зростання інженера. Наскільки злагоджено він працює з колегами? Чи не влаштовує безпредметні розборки? Несе відповідальність за свій шматок роботи та допомагає колегам чи звинувачує в усьому інших?
Коли ж розробник стає менеджером, його досягненнями стають досягнення команди. Тут софт скіли особливо значущі. На результат впливає те, як менеджер:
- формує команду;
- налаштовує взаємодію та розв’язує конфлікти;
- вміє використовувати сильні сторони команди та чи знає слабкі;
- працює з помилками.
Про софт скіли можна писати або дуже багато, або ось так стисло. Їх неможливо розбити на якісь мікроодиниці та кожній присвоїти відсоток рейту. Кожна людина унікальна за своїм набором якостей та життєвого досвіду, і для кожної заохочення буде унікальне.
Ринок
Рівень зарплат на ринку моніторять усі — від ейчарів і менеджерів до самих інженерів. В ідеалі платити розробнику необхідно стільки, скільки б він отримав, якби вийшов на перемовини з іншими компаніями. Є і зворотна залежність: кожна конкретна навичка вважається цінною, коли на неї є попит і в компанії, і на ринку.
При розігрітому IT-попиті певні розбіжності у рейтах невідворотні. Але якщо різниця з ринком становить
Проте у відриві від реальних навичок і результатів спеціаліста ринок — це тільки цифри.
Наприклад, розробник, який нещодавно прийшов джуном, нині вважає себе стронг мідлом та говорить: «Дайте мені зарплату ХХХХ, тому що саме стільки за мій рівень платять на ринку». Різниця з поточним рейтом може бути великою.
У нас такі історії поодинокі, тому що ми постійно відстежуємо якість технічних скілів команди. Якщо вже хтось прийшов зі схожою претензією, значить, менеджер щось проспав. У будь-якому разі ми аналізуємо рівень спеціаліста тут і зараз.
Перевіряти такі заяви краще практикою. На спільній зустрічі ми з розробником вибираємо короткий чекпойнт у місяць-два. Даємо кілька завдань заявленого рівня, на яких людина зможе показати свою експертизу. Важливо: вона має добре розуміти суть завдань і прийняти умови.
Після цього є два варіанти:
1. Людина впоралася. Значить, вона справді вдосконалилася і принесла більше користі компанії. Це прекрасний привід підвищити рейт і давати складніші задачі. Менеджер же надалі більш пильно стежить за розвитком інженера.
2. Задачі виконані частково або не виконані взагалі. Значить, розробник переоцінив свої можливості. Однак це ще видає в ньому амбіції до зростання. У такому разі ми збиралися разом із менеджером, ейчаром і складали план професійного розвитку та дій на наступний період, щоб досягти того, що людина хоче. Можливе також часткове заохочувальне підвищення, якщо інженер таки показав певні успіхи.
Звичайно, на будь-якому етапі людина може відмовитися та ризикнути піти на ринок за вищою зарплатою. Особливо якщо вона має на руках офер від іншої компанії та хоче поторгуватися. Але в такому разі ви навряд чи зміните думку інженера про звільнення, навіть якщо вирівняєте пропозицію.
Цінності
Зарплатну політику неможливо обговорювати окремо від інших процесів компанії. У фундаменті лежить одне — внутрішня культура.
Своя культура є в будь-якій компанії, навіть якщо вона не формалізована. Початково її створюють засновники та власники. У них своє бачення бізнесу, командної взаємодії та інших життєвих правил. Для комфортної роботи вони будуть підбирати людей із схожим майндсетом. Так схожі цінності пронизують топменеджмент, менеджмент і далі до працівників.
Гарна практика — формалізовувати цінності. Щоб не було балагану, їх має бути не більше як п’ять. У WePlay Esports, наприклад, чотири:
- кіберспортивний євангелізм;
- командна робота;
- ініціативність;
- відповідальність.
На перший погляд, загальні слова. Насправді ж цінності — це чіткий інструмент найму та укріплення команди. Перш ніж скласти цей список, менеджери ретельно перевіряли, які ділянки роботи провисають і чому. Ми вивели, на що звертати увагу на співбесідах і що може бути важливо під час перегляду зарплати.
Наприклад, щоб виявити (не)збіг, ще під час найму ми проводимо додаткову стадію інтерв’ю — баррейзинг. Це зустріч у довільній формі з менеджером компанії, який безпосередньо не працюватиме з кандидатом. Ми не тільки перевіряємо софт скіли, а й очима незаангажованої людини дивимось, чи немає критичних розбіжностей у цінностях. Навіть одна з них може спричинити відмову, попри круті хард скіли.
Так ми економимо час і собі, і людям. Припустимо, на нашу вакансію подається розробник, який не дуже цікавиться кіберспортом (ба більше — не любить і не бажає розуміти його). Найімовірніше і людині буде в нас некомфортно, і нам з нею. Відторгнення до домену у кращому випадку призведе до того, що спеціаліст буде працювати тільки за гроші й за будь-якої зручної нагоди піде.
«Перевірка на кіберспорт» більше стосується входу в компанію. А от відповідальність, ініціативність, командна робота — цілком універсальні цінності для роботи та зростання. Якщо людина бачить проблему, яку інші не помічають, і не чекає на кризу, а приходить до менеджера та пропонує рішення, це заохочується підвищенням як посади, так і рейту.
Нематеріальна мотивація
Як би не хотілося спростити, але втримати людей тільки грошима важко. Рано чи пізно на ринку з’являється хтось, кому терміново потрібен спеціаліст певного профілю, і хоча б тимчасово перебиває рейтом. Це поширена проблема аутсорсингових компаній. Нерідко люди йдуть, бо сусідня контора просто запропонувала +$500.
У таких ситуаціях не допомагають безкоштовні обіди, йога чи пиво від компанії у п’ятницю — зрештою це ті самі гроші, просто інакше застосовані. Ключовий вплив робить нематеріальна мотивація. Це те, що інженер не може купити:
- цікавість до домену або конкретного продукту;
- задачі на виріст;
- злагоджена команда;
- сильний менеджер.
Наприклад, продуктовим компаніям дуже важливо, щоб людина горіла сферою. Тоді вона сама закопується в нюанси, пропонує свої ідеї без поштовхів продакта. Звичайно, будь-який HR скаже, що заряджені інтересом люди потрібні всюди. Проте для продуктових вони критичні.
Особисто ми намагаємося наймати людей, для яких зарплата — не єдина мета. Але це не значить, що ми будемо мотивувати бонусами, цікавими проєктами, а зарплату підвищувати не будемо. Якраз навпаки.
Три роки тому ми взяли в команду інженера, який мав закрити один із доменів. Пам’ятаю, що на співбесіді в мене навіть були сумніви щодо технічних навичок спеціаліста. Проте він показав свою зацікавленість кіберспортом, нашими продуктами, підходами.
Жодного разу цей інженер не підходив до мене з проханням про підвищення. Але цікаво: наразі це людина з найбільш стрімким збільшенням зарплатні в компанії.
Він починав як звичайний розробник, а виріс до архітектора. Усі переходи були логічними: він бачив якісь проблеми в напрямі — і пропонував рішення. Колеги зверталися до нього за порадами щодо технології. Його драйвила сама сфера та продукт, а звідти з’явилася ініціативність. Завдяки цьому інженер працював на випередження: починав на своєму місці виконувати задачі, що відповідали новій посаді.
Часто зростання щодо посад і зарплати в нас відбуваються саме так. Для нас головне, щоб людина була зацікавлена і працювати на свій розвиток, і розвивати домен. Тож ми підхоплюємо та заохочуємо — в тому числі грошима.
Тут варто сказати, що не всі хочуть безперервно зростати. І не повинні. Якщо людина стабільно круто перформить, отримує ринкову зарплату та задоволена роботою, не треба її змушувати стрибати вище голови. Менеджер моніторить настрій і дає можливості, але не підганяє.
Висновки
Інженерний менеджер потрібен, щоб тонко розуміти свою команду. Що давати кожній людині, щоб їй було цікаво, які в неї професійні та зарплатні очікування та як це узгоджується з роботою компанії. Не можна просто брати та стабільно раз на пів року підвищувати всім зарплату на 10%. Це має синхронізуватися з цінністю, яку людина приносить компанії.
Можливо, ця довга розповідь має для вас відтінок ідеалізму. Мовляв, не буде роботодавець підвищувати зарплатню, якщо співробітник сам не прийде та не попросить про це. Це ж бізнес-неефективно!
Справді, бізнес завжди шукає способи оптимізувати витрати. Проте своєчасне та доцільне підвищення рейтів і є частиною такої оптимізації. Моє переконання просте: професійні стосунки мають бути взаємовигідними, незалежно від того, з клієнтами вони чи зі співробітниками. Інакше все закінчується швидко та некрасиво. Стежити за взаємовигідністю — завдання менеджера.
