Как создать систему повышения зарплат без несправедливости и субъективизма

В MetaLamp порядка пяти лет действовала система повышения зарплат, привязанная к карте развития компетенций. Сделали три больших грейда: джуниор, миддл и сеньор. Разделили их на «подгрейды», для каждого сформулировали список технических и нетехнических вопросов. И привязали к этим уровням компетенций ставку в час.

Смотрите доклад сооснователя MetaLamp Сергея Черепанова.

Условный пример — если ты разработчик уровня джуниор-3, то ты можешь зарабатывать 450-600 рублей в час. Конкретная цифра зависит от опыта: перешел человек на нужный грейд, получает минимальную ставку из вилки. Поработал какое-то время, взял на себя дополнительные обязанности — увеличиваем ставку, но в пределах вилки грейда.

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

• Сотрудники понимали, как им повысить свою зарплату. Хочешь больше денег — развиваешься.
• Те, кто принимал «экзамены», тоже говорили о пользе этого — они тоже готовились к таким разговорам, вспомнили нюансы, которые могли не использовать на проекте в этот момент времени.

Подробнее мы рассказывали об этом статье Как мотивировать разработчиков развиваться с помощью прозрачной системы повышения зарплат

Когда нас в команде было 10-15 человек, всё работало очень неплохо — люди активно росли в компетенциях, а для нашей компании с духом стартапа это было важно и выгодно. Но постепенно появились проблемы.

Разрыв между уровнем по карте и реальным опытом. Мы регулярно наблюдали сотрудников, которые по карте были условным джуниором-3, а на деле опыта у них было намного больше. Платить им ставку джуниора было несправедливо, а сдавать на новый грейд они не могли: например, банально не хватало времени подготовиться.

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

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

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

Нет системного сбора фидбека. Конечно, мы ввели инструменты, которые помогают понимать мотивацию сотрудника, его моральное состояние — например, у нас есть практика встреч one-on-one, но это скорее история про личное отношение. Но мы же работаем в команде, в бизнесе — значит, на повышение зарплаты должна влиять и обратной связи от коллег и заказчиков о сотруднике.

В итоге мы решили пересмотреть существующую систему повышения зарплат и поменять ее на новую. Для разработки решения вдохновлялись инструментом Performance review. Но при этом постарались сохранить прозрачность и системность для всей команды.

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

У нас две группы критериев: измеримые и неизмеримые. Проще всего работать с измеримыми:

• Технические компетенции — будем использовать карту развития или индивидуальный план развития, в зависимости от специалиста. Тут всё как и было.
• Срок работы в компании. Это показатель не только опыта, но и лояльности, понимания процессов. Человек у нас давно, мы этому рады — значит, это должно сказываться на заработной плате.‍
• Уровень английского языка. Мы сформировали такой критерий: сотрудник может читать, писать, говорить и понимать. Условно говоря, способен ли человек эффективно работать с англоязычной командой.

Эти критерии просто измерить, но строить систему только на них будет несправедливо. Поэтому добавляем неизмеримые критерии, они же субъективные.

Сделать какую-то градацию уровней по ним сложно, а значит, все они будут измеряться фидбэком коллег: менеджеров, тимлидов, возможно, заказчиков. Критериев шесть.

• Софт-скиллы. Это умении давать и принимать фидбэк, дружелюбная и прозрачная коммуникация, когда ты на связи и не пропадаешь.
• Опыт работы с разными технологиями, технический кругозор. Здесь подразумевается не просто срок работы или количество технологий, которые успел пощупать разработчик на проектах. А скорее насколько сильно разработчик перерос свой грейд технических компетенций, заметен ли качественный рост скиллов, изменилось ли сложность задач.‍
• Скорость работы. Насколько быстро разработчик сдает те или иные таски. Сначала этот параметр хотели отнести к измеримым — кажется, что можно попробовать измерять скорость выполнения задач и смотреть на соответствие оценки по срокам и реальному времени выполнения. Но чтобы это сделать, нужен некий эталон задачи, а они ведь часто разные. Нужно создать условную стандартизацию скорости выполнения тасок и инфраструктуру треккинга. Но даже если это и получится, всё равно будут ситуацию, когда задача закрывалась долго не по вине разработчика. А раз этот параметр в итоге всё равно оказывается субъективным, то его проще использовать как неизмеримую метрику.
• Качество. Много ли багов в задачах разработчика, как часто приходится переделывать задачи, насколько сотрудник внимателен к требованиям и насколько грамотно их реализует.
• Инициативность. Видит ли сотрудник проблемы на своем проекте и предлагает ли решения. Нет ли практики замалчивания.
• Взятие ответственности за проект. Готов ли специалист отвечать за проблемы, которые есть на проекте. Этот критерий появился из практики — ребята часто берут на себя роль тимлида, хотя ими не являются, помогают коллегам с меньшим опытом, распределяют задачи. Это классно, мы хотим мотивировать такое отношение к задачам.

Новую систему повышения зарплат назвали Performance Review, хотя это модифицированная версия этого метода. Скелет системы выглядит так.

Запланированное повышение. Пересмотр зарплаты будет проводиться раз в полгода для каждого сотрудника — так мы решаем проблемы с непредсказуемостью. От привязки к уровням по карте развития мы отходим — сотрудники продолжают и дальше повышать по ней грейды, но не только это влияет на рост их дохода. Пересмотр зарплаты будет вне зависимости от того, сдавал он на новый грейд в этом полугодии, или нет.

Сбор данных. За две недели до встречи менеджер собирает фидбэк за полгода работы разработчика: смотрит на продвижение по карте развитие, уточняет уровень английского языка, спрашивает коллег о софт-скиллах.

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

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

Обсуждение потенциала роста. После сбора фидбека менеджер встречается с сотрудником. Они обсуждают точки роста на следующие полгода на основе фидбека. Тут важно уточнить — не менеджер заставляет расти в таком-то направлении, а сотрудник изучает фидбек и определяет, на каких точках роста он хочет сосредоточиться.

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

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

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

Разным критериям соответствуют разные суммы. Например, фидбеку за софт-скиллы может соответствовать сумма в 2,000 рублей, росту в технических компетенциях 15,000. Измеримые приносят больше дохода — так система становится объективнее, потому что неизмеримые хоть и тоже влияют на команду, но их оценка в первую очередь субъективна. Для нас же было важно сделать систему прозрачную и приближенную к объективной, поэтому мы отдали переходу на новый грейд по карте развития, опыту в разных технологиях и знанию английского самые большие суммы.

У каждого критерия есть коэффициент. Он зависит от той оценки, которую сотрудник получил во время фидбека. Например, если оценка софт-скиллов от коллег будет на уровне “нормально” - коэффициент будет 60%, значит вместо 2,000 рублей, человек получит повышение на 1,200. На «хорошо» — значит, в сумму повышения записываем 100% от цены критерия (в данном примере - 2,000).

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

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

Если такая ситуация возникает, то мы сокращаем все коэффициенты до 50%. Например, по измеримым коэффициентам набрал человек повышения зарплаты на 20 тысяч рублей, но получил «плохо» за качество работы. Значит, мы повысим ему зарплату только на 10 тысяч рублей.

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

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

Мы решили поделить всех разработчиков на 4 волны. Каждую волну мы пересматривали в сентябре, октябре, ноябре и декабре 2021 года соответственно. В первую очередь пригласили на встречи сотрудников, которые получали повышение зарплаты довольно давно.

Чтобы оценить, как система мотивирует людей развиваться, нет ли в ней подводных камней, решает ли она проблемы с прозрачностью, нужен хотя бы год. Пока это управленческий эксперимент. Мы хотели сделать объективную систему, которая бы учитывала как можно больше факторов, но при этом она была бы прозрачной и работала на всех сотрудников одинаково. Нам кажется что пока нам это удается. Отзывы о системе от сотрудников хорошие, конфликтных ситуаций не было, несмотря на то, что у нас в коллективе 80 человек. Мы пока что тоже довольны. Сейчас система работает для разработчиков, но мы планируем ее транслировать на все направления компании.

Расскажите, как у вас устроен процесс повышения зарплаты? Как вам эта система? Было бы комфортно работать с такими условиями?

‍