Управление тимлидами сильно отличается от управления инженерами. Это логично, ведь перед вами теперь руководители, а не обычные сотрудники. Тимлиды не любят излишний менеджмент и контроль. И зачастую, сами знают как сделать ту или иную задачу. Поэтому подход должен быть иным.
В статье поделюсь своим мнением о том, как это делать и какие инструменты использовать.
• • •
Привет! Меня зовут Илья Прахт, я преподаватель в OTUS и руководитель нового курса Delivery Manager. Я прошел классический путь тимлид → delivery manager → CTO, и прекрасно помню чувства, которые испытывал на каждом переходе. Состояние, когда старые инструменты перестали работать, а новые – еще не появились.
По себе помню, что сложнее всего дается переход с тимлида на руководителя тимлидов. Поэтому я решил написать эту статью. Вдруг кому-то мои рекомендации помогут и облегчат этот переход.
Почему тимлидами сложно управлять
Жил себе да был некоторый тимлид. Была у него команда, не много не мало, а 10 человек инженеров. Управлял он ими грамотно, все делал так, как в умных книжках написано.
Задачи формулировал четко, старался описывать каждый шаг подробно. Встречался с ними 1/1, про жизнь и работу разговаривал. Развитием занимался, цели ставил, прогресс проверял. Ну и код-ревью проводил, за каждой задачей следил, вовремя везде вмешивался, если что не так. В общем, держал руку на пульсе и сам был глубоко погружен в работу команды. Хороший тимлид.
А потом его повысили. Сделали его delivery manager-ом и дали еще 3 команды в подчинение. И вот тут-то все и началось.
Времени и сил держать на контроле каждую задачу уже не хватает. В каждый проект не залезешь, на каждый дейлик не сходишь. Тимлиды рассказывают не все, вовремя вмешиваться не получается, в итоге на проектах постоянные кризисы . И четко сформулированные задачи тимлиды делать отказываются.
Загрустил бывший тимлид, задумался, а надо ли ему вообще в эти delivery manager-ы… Болезнь самозванца одолевать его стала. Но не сдался он, стал рефлексировать и разбираться. И вот до чего додумал.
Тимлиды – менеджеры. И управлять ими нужно по-другому, как менеджерами. Не любят они четких инструкций и ограничений. Свобода им нужна, чтобы было место для креатива. Следить за ними пристально не нужно, но нужно смотреть за проектами. Чтобы было свое видение каждой ситуации, чтобы реально помогать мог тимлидам своим, а не только спрашивать каждый час “ну что, как там?”. И делегировать нужно научиться по-настоящему. Делегировать и доверять.
Типичные ошибки в управлении тимлидами
Говоря в общем, причины ошибок начинающих delivery manager-ов и CTO понятны – переход на новый уровень менеджмента. Это требует серьезного изменения mind-set-а, а также нового набора знаний и инструментов. Если подробнее, это:
- Старые привычки тимлида
- Прежние подходы и инструменты
- Неумение делегировать
- Недостаток доверия сотрудникам
- Неправильная система мотивации
- Размытые границы ответственности
Хочу обратить внимание, что все ошибки строятся вокруг дефицита доверия. Чтобы дать больше свободы, нужно доверие. Чтобы не бояться делегировать, нужно доверие. Чтобы не включать микроменеджмент, нужно доверие. Чтобы не сваливаться в гиперопеку и контроль, нужно доверие.
Как надо управлять тимлидами
Решить проблему доверия, это не просто “начни доверять” и все заработало. Никакие мантры тут не помогут. Нужна система, четкая система прозрачности и безопасности, благодаря которой это самое доверие и будет появляться.
Как же его повышать? Концептуально, есть 2 основных фактора, над которыми следует поработать:
- Безопасность – нужно создать среду, безопасную для ошибок. Дайте вашим тимлидам определенную свободу, но контролируемую свободу. Заменить контроль на ограничения: процессы, регламенты, бюджеты и т. п.
- Прозрачность – нужно создать среду, в которой любая информация, необходимая вам, будет в доступности. При этом, достоверность данных не будет подвергаться сомнениям. Разного рода метрики и репорты очень помогут в этом.
Ну а кроме всего этого, нужно выработать набор новых привычек:
- Управлять не людьми, а отделом, единой системой, механизмом.
- Ставить цели вместо конкретных задач.
- Давать проблемы вместо решений.
Еще раз обращаю внимание. Перед вами тимлиды. Они сами руководители. И они должны нести ответственность за свои участки работы, сами. Если этого не происходит, то зачем они вам нужны? Можно тогда самостоятельно управлять всеми проектами и всеми сотрудниками. Только вот это нереально для одного человека. Поэтому приходится строить иерархию и привыкать в ней жить.
Инструменты в управлении тимлидами
Разберем основные инструменты, которые помогают правильно управлять тимлидами. По описанным выше категориям.
Цели вместо задач
Конечно же, пресловутые SMART/PURE/CLEAR. Про них много написано, повторяться не буду.
Коммитмент. Элемент западной бизнес-культуры. Подразумевает, что при постановке задачи нужно добиться коммитмента от исполнителя. А его коммитмент будет означать, что он сделает все возможное, чтобы с задачей справиться, а если что-то вдруг пойдет не по плану – сразу же сообщит. В тоже время, чтобы закоммититься, исполнитель может потребовать у вас дополнительных ресурсов. И имеет полное право не коммититься на задачу, если ресурсов ему не выдали. Получается честный партнерский подход в работе.
“Принцип яйца”. Метафора из ПМБУКа, смысл тот же. Когда вы ставите задачу, нужно определять “скорлупу” – некоторый финальный результат, которого нужно достичь. А все внутренности яйца следует оставлять на выбор тимлиду. Можно дать ему совет, можно убедиться, что он знает, как решать задачу. Но не нужно выдавать ему готовый рецепт. “Принцип яйца” оставляет простор для креатива.
Дерево целей. Если ваша задача или цель проистекает от целей отдела или даже целей компании, важно это явно показывать. Это добавляет смысла тому, над чем будет работать ваш тимлид. И как итог – повышает мотивацию.
Ограничения вместо контроля
Бюджеты. Самый удобный и, в то же время, недооцененный инструмент. Бюджеты нужны не только для финансов. С помощью бюджетов можно контролировать объем внепроектных активностей, расходы на обучения сотрудников, затраты на развитие. Нужно обеспечить возможность посчитать всего 3 цифры: план, факт, прогноз. Тимлид может делать в рамках бюджета все, что посчитает нужным. Та самая свобода. Но за рамки бюджета он выйти не сможет. Тот самый контроль с вашей стороны.
Бизнес-процессы. Чем более высокого уровня руководителем вы являетесь, тем больше внимания следует уделять работе с процессами. Процессы – отличная возможность делегировать. Как минимум, повторяющиеся рутинные действия. А чтобы держать руку на пульсе, оставьте себе в процессе некоторый шаг с финальным согласованием. Тогда все будет работать без вас, тимлиды смогут выполнять задачи и самостоятельно за них отвечать, но необходимого контроля вы, опять же, не лишитесь.
Прозрачность и безопасность
Метрики. Лучший способ знать, что происходит с вашими проектами, с вашими командами – это данные. Цифры, которые показывают состояние. В Scrum есть много хороших метрик для проекта. В Kanban тоже. В любой методологии, которая используется у вас, есть уже предустановленный набор показателей “из коробки”. Начать стоит с них. Далее можно добавлять метрики тимморали, финансовые показатели и т д.
Отчеты и репортинг. По сути, это процесс, в рамках которого вы будете за метриками следить. Какие-то метрики могут собирать тимлиды каждый день и присылать вам на почту. Какие-то собираются автоматически и их можно увидеть в любой момент в онлайн-репорте. Здесь, конечно же, чем больше автоматизации, тем лучше.
Почему так сложно?..
Новая роль руководителя тимлидов (это может быть delivery manager или CTO) требует серьезной перестройки сознания и формирования нового управленческого подхода. Меняется уровень погружения и форма взаимодействия с сотрудниками. Меняется вообще фокус с “сделать хорошо проект” в “создать систему, в которой можно хорошо делать проекты”. Ну и прямые подчиненные: раньше были инженеры, теперь – тимлиды.
Взглянуть на ситуацию, хотя бы, через модель Адизеса. Код для среднестатистического тимлида PaeI. У delivery manager-а это уже pAEi. Хорошо видно, что нужно прокачивать и развивать в себе администратора и стратега. Но это полбеды. Ко всему прочему, нужно сознательно “приглушать” в себе производителя и интегратора. А это уже куда сложнее.
Чтобы все это пройти, есть 2 пути:
- Пробовать и набивать шишки.
- Учиться, пробовать и набивать шишки.
И в том, и в другом случае ошибки неизбежны. Но во втором их меньше попадет в production.