Меня зовут Виталий Федоркович. В индустрии я начинал как 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%. Это должно синхронизироваться с ценностью, которую человек приносит компании.
Возможно, этот долгий рассказ имеет для вас оттенок идеализма. Мол, не будет работодатель повышать зарплату, если сотрудник сам не придет и об этом не попросит. Это же бизнес-неэффективно!
Действительно, бизнес всегда ищет способы оптимизировать расходы. Но своевременное и целесообразное повышение рейтов — как раз часть такой оптимизации. Мое убеждение простое: профессиональные отношения должны быть взаимовыгодными, независимо от того, с клиентами они или с сотрудниками. Иначе все заканчивается быстро и некрасиво. Следить за взаимовыгодностью — задача менеджера.
Оригинал статьи на
