Сегодня продолжу тему про работу с тимлидами. В последние годы работы в PT я руководил отделом, в нём было несколько команд, соответственно - несколько тимлидов. Благодаря этому опыту у меня есть что сказать про управление тимлидами.

При переходе на следующий уровень, когда ты начинаешь руководить руководителями, многие навыки перестают работать. Нельзя руководить ими как разработчиками. Такое управление превратит тимлида либо в дорогой ретранслятор идей, либо вызовет постоянные пустые споры, пагубно влияющие на команду.

Я для себя вывел несколько правил, как лучше руководить руководителями:

1. Управление через контекст и цели Тимлиду нужно давать бизнес-проблематику и контекст, рассказать, куда движется бизнес, какие цели у смежных подразделений, какие приоритеты у компании. Имея контекст, тимлид сам поймёт, какие задачи и как команда должна делать. Например, плохо ставить задачу: "Понизь количество error-логов сервиса A". Хорошо - "В этом периоде мы должны обеспечить доступность наших сервисов на уровне 99,9%".

2. Задавать вопросы, а не приносить решения Когда руководитель приходит с проблемой: «Игнат постоянно конфликтует с Кондратом из тестирования», - хочется сразу выдать решение. Сам грешил этим периодически. Но лучше выступить коучем и помочь человеку найти решение самому: "Как ты думаешь, почему так? Что уже пробовал сделать? Какие варианты есть?" Тимлид должен учиться сам находить такие управленческие решения.

3. Не прыгать через голову Очень хочется по старой привычке напрямую заскочить к разработчикам и узнать, как идут дела по задаче. Плохая идея. Обход прямого тимлида подрывает его авторитет. Вопросы по статусу и архитектуре нужно задавать тимлиду. Задачи тоже всегда ставятся через тимлида - он лучше знает, кому их поручить.

Единственное исключение - периодические skip-level 1-1, когда для понимания обстановки хочется пообщаться с разработчиками. Я считаю это хорошей практикой, но делать это надо открыто.

4. Хорошая работа команды ≠ хорошая работа разработчика Оценка работы тимлида носит системный и комплексный характер. Нужно оценивать результаты всей команды. Это уже не строки кода и не количество закрытых задач. На первый план выходят метрики системы: процессные (Cycle Time, Velocity), командные (team barometer, уровень текучки в команде), самостоятельность команды. Если команда исправно поставляет ценность, а сам тимлид может спокойно уйти в отпуск и ничего не сломается - значит, он делает работу хорошо.

Управление руководителями - это управление через доверие и контекст. Ты больше не контролируешь работу напрямую, ты создаёшь условия, в которых тимлиды могут принимать правильные решения сами. Это сложнее, чем управлять разработчиками, но и интереснее.

#mgmt #team