Когда и как следует повышать зарплату разработчику

Когда и как следует повышать зарплату разработчикуМеня зовут Виталий Федоркович. В индустрии я начинал как 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 и их расшифровки для нескольких уровней. Это должно облегчить работу менеджеров при просмотре зарплаты, но говорить о результатах пока рано.

Главный пойнт остается прежним: зарплата — индивидуальный показатель, который зависит от конкретной конфигурации «инженер — руководитель — команда — компания — задачи». Однако ниже я выведу некоторые опорные точки для менеджеров и дам подсказки для инженеров.

Хард скиллы

Первый способ для разработчика повысить себе зарплату — вырасти технически и лучше перформить. На всякий случай уточню: «лучше перформить» означает не количество кода в единицу времени, а скорость и качество решения проблем.

Процент роста сильно зависит от уровня разработчика.

К примеру, для джуна зарплата будет увеличиваться быстро. Для него нормально за первый год вырасти в рейте вдвое, потому что он стартует с самого низа. В основном начинающие развивают именно хард скиллы, которые легче оценить. Прежде всего менеджер смотрит на эффективность решения задач. Второй фактор — самостоятельность: насколько меньше времени и внимания ментора требует инженер.

Совсем другая ситуация с опытными инженерами с годами кодинга за спиной. Они уже умеют много и имеют высокий рейт. Вырасти в хард скиллах, да так, чтобы ценность для компании увеличилась в 2-3 раза — уже не так просто. Поэтому мало кто резко перейдет с $4000 до $7000-9000.

Хороший вариант вырасти в рейте на таком уровне — взять на себя новую ответственность. Это может быть как переход в менеджмент или архитектуру, так и новая роль при той же позиции — например, оунерство или инициация технического проекта.

Софт скиллы

Мягкие навыки многим начинающим кажутся виртуальной категорией. Однако со временем именно они определяют профессиональный рост инженера. Насколько слаженно он работает с коллегами? Не устраивает ли беспредметные разборки? Несет ответственность за свою часть работы и помогает коллегам или обвиняет во всем других?

Когда разработчик становится менеджером, его достижениями становятся достижения команды. Здесь софт скиллы особенно значимы. На результат влияет то, как менеджер:

  • формирует команду;
  • настраивает взаимодействие и решает конфликты;
  • умеет использовать сильные стороны команды и знает слабые;
  • работает с ошибками.

О софт скиллах можно писать или очень много, или вот так кратко. Их невозможно разбить на какие-то микроединицы и каждой присвоить процент рейта. Каждый человек уникален по своему набору качеств и жизненного опыта, и для каждой поощрение будет уникальным.

Дополнительное влияние на пересмотр: рынок

Уровень зарплат на рынке мониторят все — от эйчаров и менеджеров до самих инженеров. В идеале платить разработчику необходимо столько, сколько бы он получил, если бы вышел на переговоры с другими компаниями. Есть и обратная зависимость: каждый конкретный навык считается ценным, когда на него есть спрос и в компании, и на рынке.

При разогретом IT-спросе определенные различия в рейте неизбежны. Но если разница с рынком составляет 50-100%, даже в случае супермотивации и суперинтересных задач инженер от вас уйдет. Это дополнительные расходы на привлечение и адаптацию нового специалиста. Мы вместе с эйчарами считали стоимость найма нового человека с заменой - обычно это 7-9 его месячных зарплат.

Однако в отрыве от реальных навыков и результатов специалиста рынок — это всего лишь цифры.

Например, разработчик, который недавно пришел джуном, считает себя стронг мидлом и говорит: «Дайте мне зарплату ХХХХ, потому что именно столько за мой уровень платят на рынке». Разница с текущим рейтом может быть большой.

У нас такие истории единичны, потому что мы постоянно отслеживаем качество технических скиллов команды. Если кто-то пришел с похожей претензией, значит, менеджер что-то проспал. В любом случае мы анализируем уровень специалиста здесь и сейчас.

Проверять такие заявления лучше практикой. На совместной встрече мы с разработчиком выбираем короткий чекпойнт в месяц-два. Даем несколько задач заявленного уровня, на которых человек сможет показать свою экспертизу. Важно: он должен хорошо понимать суть задач и принять условия.

После этого есть два варианта:

1. Человек справился. Значит, он действительно усовершенствовался и принес больше пользы компании. Это прекрасный повод повысить рейт и давать более сложные задачи. Менеджер же в дальнейшем внимательнее следит за развитием инженера.

2. Задачи выполнены частично или не выполнены вообще. Значит, разработчик переоценил свои возможности. Однако это еще выдает в нем амбиции к росту. В таком случае мы собирались вместе с менеджером, эйчаром и составляли план профессионального развития и действий на следующий период, чтобы достичь того, что человек хочет. Возможно также частичное поощрительное повышение, если инженер таки показал определенные успехи.

Конечно, на любом этапе человек может отказаться и рискнуть пойти на рынок за более высокой зарплатой. Особенно если держит на руках офер от другой компании и хочет поторговаться. Но в таком случае вы вряд ли измените мнение инженера об увольнении, даже если выровняете предложение.

Дополнительное влияние на пересмотр: ценности

Зарплатную политику невозможно обсуждать отдельно от других процессов компании. В фундаменте лежит одно — внутренняя культура.

Своя культура есть в любой компании, даже если она не формализована. Изначально она создается основателями и владельцами. У них свое видение бизнеса, командного взаимодействия и других жизненных правил. Для комфортной работы они будут подбирать людей с похожим майндсетом. Так схожие ценности пронизывают топ-менеджмент, менеджмент и дальше к сотрудникам.

Хорошая практика — формализовывать ценности. Чтобы не было балагана, их должно быть не более пяти. В WePlay Esports, например, четыре:

  • киберспортивный евангелизм;
  • командная работа;
  • инициативность;
  • ответственность.

На первый взгляд, общие слова. На самом деле ценности — это четкий инструмент найма и укрепления команды. Прежде чем составить этот список, менеджеры тщательно проверяли, какие участки работы провисают и почему. Мы вывели, на что обращать внимание на собеседованиях и может быть важно при просмотре зарплаты.

Например, чтобы выявить (не)совпадение, еще при найме мы проводим дополнительную стадию интервью — баррейзинг. Это встреча в произвольной форме с менеджером компании, который непосредственно не будет работать с кандидатом. Мы не только проверяем софт скиллы, но и глазами незаангажированного человека смотрим, нет ли критических расхождений в ценностях. Даже одна из них может повлечь отказ, несмотря на крутые хард скиллы.

Так мы экономим время и себе, и людям. Допустим, на нашу вакансию подается разработчик, который не очень интересуется киберспортом (более того — не любит и не желает понимать его). Скорее всего и человеку будет у нас некомфортно, и нам с ним. Отторжение к домену в лучшем случае приведет к тому, что специалист будет работать только за деньги и при любой удобной возможности уйдет.

«Проверка на киберспорт» больше касается входа в компанию. А вот ответственность, инициативность, командная работа — вполне универсальные ценности для работы и роста. Если человек видит проблему, которую другие не замечают, и не ждет кризиса, а приходит к менеджеру и предлагает решения, это поощряется повышением как должности, так и рейта.

Нематериальная мотивация

Как бы ни хотелось упростить, но удержать людей только деньгами трудно. Рано или поздно на рынке появляется кто-то, кому срочно нужен специалист определенного профиля, и хотя бы временно перебивает рейтом. Это распространенная проблема аутсорсинговых компаний. Нередко люди идут, потому что соседняя контора просто предложила + $500.

В таких ситуациях не помогают бесплатные обеды, йога или пиво от компании в пятницу — в конце концов это те же деньги, просто иначе примененные. Ключевое влияние оказывает нематериальная мотивация. Это то, что инженер не может купить:

  • интерес к домену или конкретному продукту;
  • задачи на вырост;
  • слаженная команда;
  • сильный менеджер.

Например, продуктовым компаниям очень важно, чтобы человек горел сферой. Тогда он сам закапывается в нюансы, предлагает свои идеи без подталкиваний продакта. Конечно, любой HR скажет, что заряженные интересом люди нужны всюду. Однако для продуктовых они критичны.

Лично мы пытаемся нанимать людей, для которых зарплата — не единственная цель. Но это не значит, что мы будем мотивировать бонусами, интересными проектами, а зарплату повышать не будемо. Как раз наоборот.

Три года назад мы взяли в команду инженера, который должен был закрыть один из доменов. Помню, что на собеседовании у меня даже были сомнения насчет технических навыков специалиста. Но он показал заинтересованность киберспортом, нашими продуктами, подходами.

Ни разу этот инженер не подходил ко мне с просьбой о повышении. Но интересно: сейчас это человек с самым стремительным увеличением зарплаты в компании.

Он начинал как обычный разработчик, а вырос до архитектора. Все переходы были логичными: он видел какие-то проблемы в направлении — и предлагал решения. Коллеги обращались к нему за советами по технологии. Его драйвила сама сфера и продукт, а отсюда появилась инициативность. Благодаря этому инженер работал на опережение: начинал на своем месте выполнять задачи, которые соответствовали новой должности.

Часто рост по должностям и зарплате у нас происходит именно так. Для нас главное, чтобы человек был заинтересован и работать на свое развитие, и развивать домен. Мы подхватываем и поощряем — в том числе деньгами.

Здесь нужно сказать, что не все хотят непрерывно расти. И не должны. Если человек стабильно круто перформит, получает рыночную зарплату и доволен работой, не нужно заставлять его прыгать выше головы. Менеджер мониторит настроение и дает возможности, но не подгоняет.

Выводы

Инженерный менеджер нужен, чтобы тонко понимать свою команду. Что давать каждому человеку, чтобы ему было интересно, какие у него профессиональные и зарплатные ожидания и как это согласуется с работой компании. Нельзя просто брать и стабильно раз в полгода повышать всем зарплату на 10%. Это должно синхронизироваться с ценностью, которую человек приносит компании.

Возможно, этот долгий рассказ имеет для вас оттенок идеализма. Мол, не будет работодатель повышать зарплату, если сотрудник сам не придет и об этом не попросит. Это же бизнес-неэффективно!

Действительно, бизнес всегда ищет способы оптимизировать расходы. Но своевременное и целесообразное повышение рейтов — как раз часть такой оптимизации. Мое убеждение простое: профессиональные отношения должны быть взаимовыгодными, независимо от того, с клиентами они или с сотрудниками. Иначе все заканчивается быстро и некрасиво. Следить за взаимовыгодностью — задача менеджера.


Оригинал статьи на dou.ua

Подписаться на новости
Последние новости
Проєкт оновлення обладнання в лікарнях «Одужуй швидше!» став одним з переможців конкурсу «Відповідальна країна» у номінації «Власні проєкти благодійних фондів» від видання Marketing Media Review.
01.02.2023
Преміум локації найбільшої мережі кіберклубів Вʼєтнаму CyberCore обрали SENET від ENESTECH програмною платформою для управління клубами. Це початок великого партнерства, адже у CyberCore – понад 700 клубів по всій країні.
12.01.2023
В течение года детские и взрослые больницы разных специализаций в семи городах Украины получили новое современное медицинское оборудование и расходные материалы стоимостью более 6,5 млн. грн.
05.01.2023