Чем более грамотные и толковые ваши специалисты, тем, при должной организации труда, больше выгоды они приносят компании.
Компания никогда не разделяет полученную выгоду от работы сотрудника поровну с сотрудником, стало быть, от увеличения грамотности сотрудника компания получает выгоды больше, чем сам сотрудник.
Следовательно, если разработчик просит развития или обучения, вы делаете что-то не так — ведь если его развитие и обучение важнее для компании, то это самое обучение и развитие должны предлагать и просить вы.
Для компании уход разработчика — прямые потери: нужно искать нового человека, адаптировать его и ждать, пока он не станет столь же продуктивным, как ушедший.
Для разработчика увольнение всегда сопряжено со стрессом — поиск новой работы, волнения про разговоры с руководителем и проч.
Когда есть стресс — продуктивность интеллектуальной деятельности падает.
То есть, для компании мало того что уход разработчика стоит много денег (от 2 до 12 окладов судя по слухам), так ещё и чем более внезапен этот уход, тем дороже обходится его обслуживание.
Значит, руководитель прямо заинтересован в том, чтобы сотрудник работал дольше и продуктивнее.
При этом мир таков, что сотрудник всё равно рано или поздно покинет компанию — очень мало компаний, в которых сотрудники в среднем работают дольше 3 лет.
Выходит, уход — натуральный процесс жизненного цикла сотрудника, и стоит его обслуживать максимально эффективно, не пряча голову в песок в надежде, что такого события не наступит.
Уход сотрудника подразумевает его замену. Если сотрудник уходит внезапно, замену готовить придётся в отсутствии сотрудника. Значит, лучше узнавать об уходе сотрудника заранее.
Некоторые компании мониторят резюме своих сотрудников на job-сайтах в надежде “поймать” тот момент, когда сотрудник обновит своё резюме. Однако, чем более квалифицированный сотрудник, тем больше вероятность, что его просто “схантят” без всякого резюме на job-сайте.
Кажется очевидным, что гораздо более достоверным источником информации о намерении сотрудника уйти является сам сотрудник.
Ждать и верить, что разработчик придёт обсуждать такую тему сам — высокорисковая стратегия.
Стало быть, нужно стартовать такое обсуждение менеджеру самому.
Если просто сказать что-то из серии “приходи обсуждать если чо” — ничего не изменится.
Проще всего такое выполнить, рассказав разработчику, какой takeaway package он получит при уходе (reference, историю роста/развития/достижений/участия в разработке).
Логичнее всего рассказать об использовании этой концепции ещё на собеседовании, а то и в вакансии описать.
Если разработчик понимает, что потенциальный уход можно нормально обсуждать, он, во-первых, проработает дольше (с нормальными руководителями приятно работать), во-вторых, придёт обсуждать будущий уход сильно заранее.
Подробнее тут.