Открываю в блоге новую рубрику — «Управленческие задачи». Здесь не будет теории из учебников MBA. Кейсы про команду, клиентов, ответственность и выбор, который приходится делать ежедневно в реальной работе. Почти всегда не содержит правильного ответа, но позволяет задуматься как можно повести себя в той или иной ситуации.

Сегодняшний кейс — о талантах, карьерном росте и страхе потерять сотрудника, сделав его слишком крутым.

Описание ситуации

Дано: Вы тимлид в ИТ-подразделении и взяли на работу на 1-ю линию сотрудника — Руслана (имя вымышлено). Его задача — отвечать на вопросы техподдержки, помогать тестированием функционала и писать документацию по продукту.

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

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

Вы вспоминаете про Руслана, т.к. именно в текущий момент это win/win.

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

Вы разговариваете с Русланом и предлагаете ему эту должность. Он соглашается.

Спустя время вы понимаете, что Руслан отлично справляется со сменой должности и уже в роли разработчика 1С прекрасно себя показывает. Через год Руслан уже Middle+ и к нему начали поступать задачи на проектирование и разработку отдельных подсистем. Т.е. потенциально мы имеем Senior.

Развитие и финал (примерно через год)

На очередном Performance Review, Руслан сказал, что хотел бы уволиться. Причина не в деньгах (контр-оффер не сработал). Причина в стеке. Компания пишет собственный продукт (самописная конфигурация). Руслан осознал: работая над уникальным отраслевым решением, он теряет квалификацию по рынку. Рынок требует знания типовых конфигураций (Бухгалтерия, ERP, Управление торговлей, ЗУП и т.п.), а он «варится» в кастомном коде. Он бы хотел заниматься типовыми решениями 1С, а наша компания не может ему этого дать. Он увольняется и уходит в компанию на типовые проекты, чтобы оставаться ликвидным специалистом.

Альтернативное мнение: «Ты сам виноват»

Обсуждая эту ситуацию с коллегой-руководителем, я неожиданно услышал жесткую критику. Его позиция была такой:

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

Для меня такое решение вопроса спорное. Да и с этической стороной есть проблемы.

Вопросы для обсуждения

1. Насколько верным управленческим решением было предлагать Руслану перейти в разработку из техподдержки? Если бы мы тогда этого ему не предложили, у нас мог остаться хороший специалист 1-ой линии поддержки, и, возможно, он бы вырос в руководителя и не покинул бы компанию.
2. Верите ли вы в стратегию «искусственного сдерживания»? Если бы Руслан остался в поддержке, не ушел бы он еще раньше от скуки и отсутствия перспектив?
3. Если ваша компания разрабатывает «нетленку» (собственный уникальный софт), как вы удерживаете разработчиков, которые боятся отстать от рынка и потерять квалификацию в типовых решениях (ERP / Spring / React и т.д.)?
4. Вы понимаете, что перед вами сотрудник-бриллиант пока без знаний, но с огромным потенциалом. Как лучше организовать развитие такого сотрудника, чтобы он не покинул компанию досрочно и принес максимум пользы?
5. Какие риски вы видите для остального коллектива, если кто-то из сотрудников переходит на другое направление?