Про матричные роли и делегирование
Одна из самых больших ошибок, которую я допускал как руководитель большой команды и несколько раз видел у других менеджеров:
Самостоятельное ведение (читай: не-делегирование) проектов, которые не укладываются полностью в зону ответственности одного из подчинённых.
Например:
У меня есть три команды.
1. Продуктовая команда бэка
2. Продуктовая команда фронта
3. Команда инфры
Мы затеваем большую перестройку, прошивающую почти весь продукт и задевающую кусочек инфры. Распределение нагрузки между ними: 40-40-20.
У меня возникал следующий ход рассуждений:
– В проекте будут участвовать инженеры из разных предметных областей, с очень различающейся экспертизой
– Человеку, ответственному за проект, нужно хотя бы понемногу понимать, что делает каждый из этих людей
– Человеку, ответственному за проект, потенциально придётся спорить/давить/договариваться со всеми этими людьми, решающими супер-разные проблемы на проекте
– Кажется, кроме меня, как наименьшего общего руководителя, никто не сможет нормально выполнить предыдущие пункты. Будет неправильно отправлять кого-то на такую работу
––
На самом деле, последний пункт рассуждений – ошибочный. Он ограничивает в возможностях роста твоих прямых подчиненных, препятствует появлению полноценных заместителей и, вообще говоря, деструктивен и для руководителя, и команды
––
Если в команде есть ребята, которым интересно расти по менеджерскому треку, вполне нормально в рамках проектов давать им матричные управленческие роли.
Матричный руководитель – это человек, которому ты в рамках проекта даёшь все полномочия и ответственность, чтобы проект случился. Прийти на дейлик к команде (или предложить организовать новый) / пнуть по статусам / почелленджить решение / позвать ребят вместе подумать, как срезать угол и тд. Полномочия распространяются на активности, связанные с конкретным проектом и не распространяются на остальное
Интуитивно кажется, что люди не примут человека, который, формально говоря, начальником не является, в качестве матричного хеда и репортить ему не захотят, но, на практике, когда ты говоришь что-нибудь в духе:
Ребята, у нас есть большой и сложный проект. Нам нужно, чтобы один человек взял на себя головную боль ведения этого проекта, собрал большую картинку, как технически работает система end to end и проследил, что мы правда к этой картинке придём. Этим займётся Вася и станет матричным руководителем проекта. Пожалуйста, всячески содействуйте ему, не игнорируйте вопросы и предложения, и будьте командой, В случае конфликта – эскалируйте в меня
– проходит абсолютно нормально.
Такая практика ведения проектов очень сильно прокачивает перспективных людей в команде. Они, хоть по началу и спотыкаются (когда начинаешь внедрять матричное управление, нужно обязательно стоять рядом и страховать на первых этапах), в итоге приобретают огромное количество управленческого опыта в короткие сроки и узнают, хотя бы поверхностно, про новые технические области.
Помимо этого, матрично-управляемые проекты делает команду более самодостаточной и стабильной – люди привыкают решать напрямую друг с другом более сложные проблемы и вообще начинают больше общаться.
Матричное управление применимо не только на уровне тимлидов. Оно вполне может работать и с несколькими IC.
Важные пререквизиты:
1. Между людьми в команде должны быть доверительные отношения. Если сотрудники находятся в состоянии политической борьбы, матричные роли не работают
2. Со всеми ключевыми участниками проекта нужно в явном виде проговорить конфигурацию и ожидания друг от друга
3. Делегируя проект, ты не должен терять его детали и контекст
––
Про выстраивание доверительных отношений в команде и про то, как, делегируя, не упускать важное, будут отдельные посты 🙂