Как создать систему повышения зарплат без несправедливости и субъективизма
Прозрачно, с фидбеком и понятными аргументами для сотрудников и руководителей
Если вы руководите коллективом, в котором больше трех человек, то наверняка знаете эту боль — зарплату сотрудникам повышать надо, но непонятно, как сделать это прозрачно и справедливо. Если ориентироваться только на субъективные ощущение, можно забыть про кого-то из сотрудников, спровоцировать токсичность и недовольство в команде. И получить вместо энтузиастов, желающих развиваться, сотрудников, обиженных друг на друга и на руководство.
Поэтому приходится формировать систему, понятную и полезную как сотрудникам, так и руководителю. Мы в MetaLamp недавно поменяли ее во второй раз — пришлось ее усложнить, но мы старались сохранить прозрачность и справедливость для всей команды. Сделать так, чтобы коллеги понимали, зачем им развиваться и как это делать.
Я, Роман Штых, CEO в MetaLamp, расскажу в этой статье, как всё устроено. Надеюсь, материал пригодится, и вы сможете использовать подобную практику у себя в командах.
Почему мы решили пересмотреть работающую систему повышения зарплат
В MetaLamp порядка пяти лет действовала система повышения зарплат, привязанная к карте развития компетенций. Сделали три больших грейда: джуниор, миддл и сеньор. Разделили их на «подгрейды», для каждого сформулировали список технических и нетехнических вопросов. И привязали к этим уровням компетенций ставку в час.
Смотреть доклад сооснователя MetaLamp Сергея Черепанова
Условный пример — если ты разработчик уровня джуниор-3, то ты можешь зарабатывать 450-600 рублей в час. Конкретная цифра зависит от опыта: перешел человек на нужный грейд, получает минимальную ставку из вилки. Поработал какое-то время, взял на себя дополнительные обязанности — увеличиваем ставку, но в пределах вилки грейда.
Если разработчик хотел зарплату больше, нужно было договориться о встрече с разработчиками желаемого грейда и ответить им на вопросы, которые есть в карте развития. Получилось прекрасно:
- Сотрудники понимали, как им повысить свою зарплату. Хочешь больше денег — развиваешься.
- Те, кто принимал «экзамены», тоже говорили о пользе этого — они тоже готовились к таким разговорам, вспомнили нюансы, которые могли не использовать на проекте в этот момент времени.
Подробнее мы рассказывали об этом статье:
Зарплату нужно повышать всем и справедливо — научился новому, денег будет больше. Стоишь на месте — рост минимальный.
Привет! Я Роман Штых, директор студии разработки MetaLamp. Когда мы только начинали расти, главное, что нас волновало — как мотивировать наших разработчиков профессионально развиваться, чтобы мы могли брать проекты сложнее и дороже. Конечно, энтузиазм и любовь к саморазвитию у коллег нам помогали, но хотелось добавить еще и материальных поощрений.…
Когда нас в команде было 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 человек. Мы пока что тоже довольны. Сейчас система работает для разработчиков, но мы планируем ее транслировать на все направления компании.
Расскажите, как у вас устроен процесс повышения зарплаты? Как вам эта система? Было бы комфортно работать с такими условиями?
Вроде всё здорово и интересно, но вообще не учтён вопрос ситуации на рынке. Как минимум, по-хорошему, надо поднимать на уровень инфляции. В целом, многое зависит от ситуации на рынке и того, за сколько сотрудника могут захантить.
А тут выходит так, что на сколько договорились, столько и будет, и повышения только за заслуги. Скажем, будет у вас 20%, а на рынке легко найдёт на +50%. Конечно, это лучше чем ничего и дурацких ревью, как обычно бывает, но может статься так, что со временем ваши уйдут на высокие зарплаты, а вы никого на ваш уровень не найдёте.
Почему-то на практике «прозрачные» системы ревью с этим настолько плохо справляются, что чаще служат объяснением, почему не будут повышать зарплату.
Блин, so true
Мне кажется вопрос с зп по рынку решается индексацией
Я вижу тут идею сделать "по справедливости". Непонятно, зачем это бизнесу в целом. Его задача - зарабатывать деньги. Если сотрудник хочет "вот столько" - он идёт и обсуждает. Не обсуждает - его устраивает. А его руководитель посмотрит на рынок труда и принимает решение: платить эти "вот столько", чтобы не провалить КПЭ, или отправить на улицу.
Ну и самое главное заключается в том, что прямая денежная мотивация - худшая из возможных. Это банальное неумение выстраивать отношения в коллективе. Плюс возникает множество вопросов. Что будет, когда зарплатный фонд перевалит расчетный? Зачем держать стафф с ЗП выше рынка? Для чего собственнику лишние расходы?
По материальному стимулированию есть много исследований. Оно будет основным до порога удовлетворения среднестатистических потребностей - то есть нет смысла говорить всерьез о роли нематериальных методов при зп 20 000 в руб. А вот при достижении уровня, достаточного для нормальной жизни, дальнейшее повышение не всегда работает. Зп выше рынка обычно держат компании, ориентированные на долгосрочный найм. Это прямо совсем азы.
поддерживаю. заниматься зп и мотивацией программистов должны не программисты, ато это превращается в гейм-сценарий по накоплению артефактов и манны.
ну и по опыту. работники, в том числе программисты, которые дают самый качественный результат и могут решать нетривиальные задачи - это люди, которые всегда просят меньше, чем ты готов им дать. поэтому легко находятся деньги на их премирование и поощрение, ты просто даешь им то, что итак хотел дать.
а вот эти вот пляски с бубнами - от лукавого. правила рынка как b2b , так и кадрового - заказчик всегда готов платить выше средней цены за решение проблем. если исполнитель создает новые проблемы, исполнителя за борт. если заказчик не готов, значит это не заказчик.
возможно, когда у меня будет 100+ сотрудников, я заговорю иначе.