Своевременное повышение зарплаты как инструмент эффективного управления командой

Директор веб-студии Lodoss team — о том, как и за что нужно повышать зарплату сотрудникам, чтобы это приносило пользу компании.

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

Разработкой ПО занимаются высококвалифицированные специалисты с приличными зарплатами. Для веб-студии затраты на оплату труда — это одна из основных статей расходов.

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

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

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

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

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

Без прозрачной системы метрик каждое решение будет лишь субъективным мнением. Сотрудники не будут понимать, что именно нужно сделать, чтобы заслужить повышение. Со временем это приведёт к снижению эффективности труда.

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

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

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

Может быть, стоит повысить, когда работник показал отличные результаты? Опять нет, за это полагается премия, только нужно чётко определить и объяснить команде, что есть норма, а что — её перевыполнение.

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

Например, на работу был принят младший разработчик. Он четыре месяца сидел на коммерческом проекте и выполнял задачи, которые ему ставил тимлид.

Сначала это были совсем маленькие задачи, затем крупнее, и наконец он смог в оговорённые сроки самостоятельно создавать довольно крупные модули. Теперь у него есть полезное для компании умение, которое отличает его от других младших разработчиков.

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

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

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

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

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

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

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

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

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

Кроме того, зная что следующая возможность представится нескоро, на процедуру подтверждения пойдут и специалисты, которых пока и так всё устраивает. Если остановиться на этом варианте, то для предотвращения bottleneck-эффекта процедуру стоит равномерно распределить по временному интервалу, например, привязать её к дате трудоустройства.

Этот вариант полностью избавляет нас от минусов предыдущего. Но нужно защищаться от попыток сломать или обойти систему. Не забываем, с каким контингентом мы работаем.

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

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

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

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