Открываю в блоге новую рубрику — «Управленческие задачи». Здесь не будет теории из учебников MBA. Кейсы про команду, клиентов, ответственность и выбор, который приходится делать ежедневно в реальной работе. Почти всегда не содержит правильного ответа, но позволяет задуматься как можно повести себя в той или иной ситуации.
Сегодняшний кейс — о талантах, карьерном росте и страхе потерять сотрудника, сделав его слишком крутым.
Описание ситуации
Вы тимлид в ИТ-подразделении и взяли на работу на 1-ю линию сотрудника — Руслана (имя вымышлено). Его задача — отвечать на вопросы техподдержки, помогать тестированием функционала и писать документацию по продукту.
Спустя время, вы понимаете, что парень талантливый и потихоньку это ведет его вперед. Те вопросы, которые ему поручаются он выполняет достаточно хорошо и качественно. То, что отдано в работу Руслану, всегда выполняется в срок и качественно. Время идет, он растет и набирается опыта. Основной стек разработки — это 1С, и вы занимаетесь разработкой собственного решения на 1С. Получается так, что Руслан иногда сам в 1С отладчиком находит проблемы клиентов и разработчикам передает эту информацию. Т.е. парень прям серьезно вырос.
Тут случается непредвиденная ситуация. Два программиста одновременно решают уйти из компании. Перед вами появляется дилемма: как быстро закрыть эту потребность без потери качества, чтобы человек был сразу в теме и мог хотя бы частично эту потребность закрыть.
Вы вспоминаете про Руслана, т.к. именно в текущий момент это win/win.
- Для вас: вы получаете лояльного, мотивированного сотрудника, который уже знает продукт изнутри и готов развиваться.
- Для Руслана: он получает возможность расти дальше, но уже в роли разработчика и с другой мотивацией.
Вы разговариваете с Русланом и предлагаете ему эту должность. Он соглашается.
Спустя время вы понимаете, что Руслан отлично справляется со сменой должности и уже в роли разработчика 1С прекрасно себя показывает. Через год Руслан уже Middle+ и к нему начали поступать задачи на проектирование и разработку отдельных подсистем. Т.е. потенциально мы имеем Senior.
Развитие и финал
На очередном PR, Руслан сказал, что хотел бы уволиться. Причина не в деньгах (оффер не сработал). Причина в стеке. Компания пишет собственный продукт. Руслан осознал: работая над уникальным отраслевым решением, он теряет квалификацию по рынку. Рынок требует знания типовых конфигураций (Бухгалтерия, ERP, ЗУП и т.п.), а он «варится» в кастомном коде. Он бы хотел заниматься типовыми решениями 1С, а наша компания не может ему этого дать. Он увольняется и уходит в компанию на типовые проекты, чтобы оставаться ликвидным специалистом.
Альтернативное мнение: «Ты сам виноват»
Обсуждая эту ситуацию с коллегой-руководителем, я неожиданно услышал жесткую критику. Его позиция была такой:
Ты совершил ошибку. Таких людей нельзя переводить в разработку, если у тебя «самописная конфигурация». В поддержке он был бы звездой. Он чувствовал бы себя нужным, у него была бы стабильная зарплата, и ему некуда было бы деваться, потому что навыки саппорта специфичны. А ты дал ему в руки профессию, которая позволяет ему выбирать. Мы у себя намеренно ограничиваем вертикальный рост таких кадров, чтобы они дольше приносили пользу на своем месте.
Для меня такое решение вопроса спорное. Да и с этической стороной есть проблемы.
Вопросы для обсуждения
1. Насколько верным управленческим решением было предлагать Руслану перейти в разработку из техподдержки?
2. Верите ли вы в стратегию «искусственного сдерживания»? Если бы Руслан остался в поддержке, не ушел бы он еще раньше от скуки и отсутствия перспектив?
3. Если ваша компания разрабатывает собственный уникальный софт, как вы удерживаете разработчиков, которые боятся отстать от рынка и потерять квалификацию в типовых решениях (ERP / Spring / React и т.д.)?
4. Вы понимаете, что перед вами сотрудник-бриллиант пока без знаний, но с огромным потенциалом. Как лучше организовать развитие такого сотрудника, чтобы он не покинул компанию досрочно и принес максимум пользы?