Переход из тимлида в менеджеры менеджеров: вредные советы

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

🎤Автор предлагает с первого месяца в новой роли ворваться в хайринг – разобрать все открытые вакансии, выяснить как они ложатся в общую стратегию, подключиться к процессу интервью самостоятельно. Цель всего этого – получить общую картину по тому, насколько здоровый в команде процесс найма.
💬Найм – это инструмент. До того, как пытаться его чинить, надо понять, а есть ли с ним вообще проблема. Наличие проблемы не определить, пока ты не понял, а что и зачем в командах разрабатывается. Поэтому я бы построил план по-другому:
1. Разобраться с общей стратегией компании, поговорив с релевантными людьми.
2. Выяснить, в чем заключается успех работы каждой из команд.
3. Поговорить с заказчиками и сотрудниками и собрать список известных им проблем, которые мешают достижению успеха.
4. Вместе с тимлидами своих команд оценить влияние этих проблем друг на друга, выделить корневые.
5. В зависимости от того, в чьей зоне влияния находятся проблемы, делегировать их решение тимлиду или заняться этим самостоятельно.

Найм – не обязательно самая горящая проблема. Без понимания контекста вы будете еще одним бесполезным ценным мнением, которое будет толтко мешать.

🎤Автор советует организовать регулярные встречи со всеми, с кем только можно – 1/1 с заказчиками, синки с коллегами, еженедельные митинги с прямыми подчиненными.
💬Синхронное общение – отличный инструмент для тех случаев, когда требуется соединить картины мира и знания нескольких людей чтобы быстро прийти к общему решению. Это очень дорогой инструмент – он сильно вырывает людей из рабочего контекста, причем в то время, которое удобно автору встречи, а не им.

Заводить кучу встреч без явной агенды с целью «посинкаться про статус» – вредно для всех участников. Вместо этого я бы рекомендовал следующий подход:
1. Асинхронное общение по умолчанию. Если вам нужно узнать статус каких-то проектов – настройте общение в чате или в проектном трекере.
2. Если требуется регулярное общение с одними и теми же людьми в рамках решения какой-то конкретной проблемы – регулярные встречи рабочих групп с внятной повесткой – тоже нормально.

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