В большей степени это касается нас - HRов. Потому что часть из нас допускает не мало ошибок, которые потом никто не фиксит, т.к. считают, что все норм.

В который раз сталкиваюсь с одним и тем же.

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

Но отправляет резюме в IT-компанию и получает: «Недостаточно опыта именно в IT».

И у меня каждый раз возникает вопрос.

А что именно происходит с управлением людьми после входа в IT? Там появляется какой-то другой управленческий цикл? Планирование перестает быть планированием? Постановка задач работает по другим законам? Обратная связь становится другой? Мотивация, контроль, делегирование, развитие людей внезапно перестают существовать? Или разработчики — отдельный биологический вид? :)

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

Я говорю именно про управление людьми.

И здесь скелет, простите, один и тот же. Цель → план → ответственность → ресурсы → контроль → обратная связь → корректировка → развитие.

Еще Роберт Катц разделял навыки руководителя на технические, человеческие и концептуальные. И чем выше уровень управления, тем меньше решающей становится собственная техническая экспертность и тем больше — работа с людьми и системой.

У Минцберга та же история: руководитель работает через межличностные, информационные и управленческие роли.

Никакого отдельного раздела: «А теперь всё то же самое, но если перед вами программисты....». Почему-то нет.

Давайте на примерах.

Пример 1. Производство. У руководителя 40 мастеров и специалистов. Один сильный, но токсичный. Второй экспертный, но не умеет планировать. Третий перегружен. Четвертый хочет расти. Пятый систематически срывает сроки. Что делает хороший руководитель? Разбирает причину. Ставит понятные ожидания. Распределяет ответственность. Дает обратную связь. Развивает. Контролирует результат. Теперь заменяем слово «мастер» на «разработчик». Что принципиально изменилось?

Пример 2. IT-команда. Есть сильный разработчик, который делает прекрасный результат, но уничтожает коммуникацию внутри команды. Если руководитель начинает спорить с ним про код — это экспертная плоскость. А если решает вопрос поведения, влияния на команду, границ ответственности и допустимых норм взаимодействия — это уже чистое управление людьми. И для этого не нужно десять лет самому писать на Java. Нужно уметь управлять.

Пример 3. L&D. Человек построил корпоративный университет в производственной компании. Диагностика потребности. Матрицы компетенций. Программы развития. Оценка. Кадровый резерв. Аналитика эффективности. Переходит в IT. Что меняется? Контент. Роли. Терминология. Набор компетенций. Но сама система не становится другой. Андрагогика не переписывается только потому, что обучаемый теперь frontend-разработчик. Вот поэтому формулировка:

«Вы не из IT — вы не поймете айтишников» для меня звучит довольно странно.

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

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

Возможно, перед нами очень хороший старший эксперт. А это, простите, разные роли.

Поэтому я бы при подборе руководителей спрашивал не: «Сколько лет вы управляли именно в IT?»

А: «Как вы управляли сильными экспертами, которые знали предмет лучше вас?»

Вот ответ на этот вопрос, на мой взгляд, расскажет о руководителе гораздо больше.