Однажды я услышал утверждение, что тимлид нужен, чтобы пинать людей. Если не пинать, они будут забивать на работу и саботировать результат.
Мне это убеждение претит. В творческой работе погонщик чаще ухудшает ситуацию: люди привыкают выполнять указания и перестают брать ответственность за то, что находится за рамками команды «сделай».
Задача руководителя - построить систему, в которой команда способна стабильно доводить работу до результата. Для этого приходится разбираться со своими убеждениями, потерями в процессе и незавершённой работой.
Начать со своей модели управления
Руководитель не управляет людьми напрямую. Сотрудник всё равно сам решает, как реагировать на указание и сколько ответственности брать. Давление может заставить выполнить конкретную задачу, но не создаёт устойчивую рабочую систему.
Убеждение «команде нужен погонщик» особенно опасно тем, что объясняет любую проблему одинаково. Срок сорван - люди плохо работали. Качество упало - люди невнимательны. Задачи застряли - нужно сильнее надавить.
Такая модель экономит руководителю размышления, но скрывает реальные причины.
Убеждения работают как линза. Кто-то перенял директивный стиль у прежнего начальника, кто-то вдохновился книгой, а кто-то просто не видел других способов управлять. Источник у каждого свой, результат похож: руководитель выбирает решения, которые подтверждают его исходный взгляд.
Поэтому перед тем, как «чинить команду», полезно проверить собственное объяснение проблемы. Если неудовлетворительный результат показывает вся команда, версия о внезапном нашествии лоу-перформеров выглядит слабее версии о плохой системе работы.
Искать потери, а не виноватых
Даже сильная и сработанная команда будет работать посредственно, если среда постоянно мешает ей заканчивать задачи. Один из самых заметных источников потерь - незапланированная работа.
К ней относится всё, чего команда не собиралась делать:
- поднять упавший прод;
- срочно исправить критический баг;
- взять в спринт очередную ASAP-задачу;
- переделать решение из-за пропущенного требования;
- потратить два дня на релиз, который должен был занять два часа;
- помочь «на десять минут», которые незаметно съели полдня.
Каждый такой эпизод забирает ресурс у запланированного результата. Команда срывает срок, закладывает больше времени, снова сталкивается с теми же рисками и постепенно накапливает техдолг.
Но незапланированная работа тоже не является корневой причиной. Её создают ненадёжные релизы, технический долг, слабое планирование, неясные требования и договорённости, которые позволяют в любой момент менять приоритет.
Поэтому первым шагом я бы сделал незапланированную работу видимой. Сколько времени она забрала? Откуда пришла? Повторялась ли раньше? После этого можно искать причину с помощью «Пяти нахрена», а не просто добавлять запас к следующей оценке.
Хватит начинать, начните заканчивать
Следующая ловушка - попытка загрузить работой каждого человека. В вытягивающей системе новая задача начинается, когда для неё появилась свободная пропускная способность. Иногда это означает, что отдельный специалист временно не берёт новую работу.
Со стороны такой простой легко принять за потерю. Но производительность системы определяется законченным результатом, а не числом одновременно занятых людей. Если тестирование стало ограничением, ещё одна начатая разработчиками задача только увеличит очередь.
Принцип Stop Starting, Start Finishing переносит внимание на завершение уже начатого. На практике это может выглядеть так:
- разработчик пишет автотесты вместо новой задачи;
- свободный инженер помогает коллеге закончить работу;
- тимлид защищает лимит незавершённой работы от очередной срочной задачи;
- команда направляет усилия на своё ограничение, даже если другие этапы временно простаивают.
Подробнее работу с такими ограничениями я разбираю в лонгриде «Как найти ограничение и ускорить поставку».
Чем тогда управляет руководитель
Руководитель управляет условиями, в которых команда делает работу:
- способом постановки и подготовки задач;
- правилами смены приоритетов;
- количеством одновременно начатой работы;
- инструментами и средой разработки;
- обратной связью о результате;
- процессом поиска и устранения повторяющихся потерь.
Лоу-перформеры существуют, и иногда проблема действительно находится в конкретном человеке. Но это версия, которую нужно проверить, а не универсальный ответ.
Пинать людей проще, чем разбираться с системой. Управленческая работа начинается там, где руководитель перестаёт объяснять результат характером команды и смотрит на процесс, который этот результат производит.
Если команда работает без руководителя
Через несколько месяцев после первого перехода в тимлиды я почувствовал, что не нужен команде. Я пришёл в уже работающую систему: люди были наняты, процессы настроены, результат поставлялся. Казалось, что меня можно убрать и ничего не изменится.
С похожим страхом я позже встречался у тимлидов, которым помогал входить в роль. Когда всё работает, начинающий руководитель легко начинает доказывать свою полезность: набирает задачи, вмешивается в решения и превращает себя в обязательный узел процесса.
Но автономность команды — не доказательство бесполезности руководителя. Наоборот, это один из результатов его работы.
Опытный руководитель постепенно убирает себя из операционного контура: делегирует задачи, передаёт контекст и создаёт договорённости, которые не требуют его постоянного присутствия. Так люди осваивают новые навыки, а команда перестаёт зависеть от одного человека.
Полное самоустранение тоже не является целью. Кто-то должен видеть систему целиком, готовить её к изменениям и брать ответственность в ситуации, для которой ещё нет процесса. Разница в том, что руководитель включается по необходимости, а не поддерживает собственную занятость.
Если ощущение ненужности всё равно грызёт, его полезно проверить обратной связью. Спросить команду и своего руководителя, что в моей работе помогает, чего не хватает и где я, наоборот, стал ограничением. Такой разговор калибрует роль лучше, чем очередная задача, которую я забрал у команды ради спокойствия.