Как я запускал внутреннюю школу тимлидов в IT-компании

Привет, меня зовут Владимир, я работаю техническим директором в EdTech компании. Сегодня я хотел бы поделиться своим опытом запуска внутренней школы тимлидов, рассказать, какие цели я при этом ставил и каких результатов удалось достичь.

Когда я пришел в компанию в июне 2022 года, у меня в подчинении оказалось около 40 человек, а именно:

1. 5 команд разработчиков Ruby + React.
2. 1 команда QA.
3. 1 команда DevOps/SRE.

В каждой команде был свой тимлид, но все они скорее выполняли роль техлидов и были слабо подкованы в менеджменте. Они обладали высоким уровнем технической экспертизы, но знания и навыки управления, которые у тимлидов имелись, были очень неоднородными — почти все из них разбирались в Scrum, кто-то даже проходил курсы, а тимлид DevOps команды знал ITIL и ITSM. При этом почти никто из тимлидов не был знаком с основами управления, многие не знали, как работать и эффективно взаимодействовать со стейкхолдерами. Проектному менеджменту также никто специально не обучался.

В результате нагрузка, связанная с people management и управлением ИТ-инициативами, ложилась на плечи CTO. Это приводило к тому, что я не мог как следует сфокусироваться на других важных задачах, например, на внешних взаимодействиях с партнерами и поставщиками. На работе тимлидов все это тоже сказывалось отрицательно. Они не понимали своих задач, не знали, каких результатов от них ждут, не осознавали свои сильные стороны и не понимали, какой стиль управления им подходит, не могли отстоять свою позицию перед стейкхолдерами, что неизбежно приводило к стрессу и выгоранию.

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

• ознакомится с классическими подходами к менеджменту;
• освоить новые полезные инструменты;
• получить инсайты от более опытных руководителей-экспертов;
• обменяться опытом;
• сформировать понимание своих сильных сторон и стиля работы;
• «выровняться» относительно друг друга по уровню навыков и знания методик управления.

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

Во-первых, вовлеченность. Мне было важно, чтобы каждый принимал активное участие в обучении, высказывал мнение, делился инсайтами и кейсами из практики.

Во вторых, открытость к новому, а именно стремление самостоятельно что-то изучать, применять новые знания на практике, а если что-то не получалось, проводить работу над ошибками и пробовать снова.

И, наконец, выполнение домашних заданий в срок.

К сожалению, кризис ограничил возможности выбора курса. В компании на тот момент отсутствовал бюджет на внешнее обучение для сотрудников, поэтому я обратился к бесплатному курсу от Стратоплана. Я связался с менеджерами школы, зарегистрировал на курс всех участников и зарегистрировался сам.

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

Приведу список всех материалов, которые я использовал:

1. Видеолекции от Стратоплана.
2. Карта компетенций тимлида.
3. Статьи от Harvard Business Review по теме лидерства и проектного менеджмента.
4. Книги Ицхака Адизеса «Идеальный руководитель» и «Управление жизненным циклом корпораций».
5. Тест PAEI на определение стиля управления (модель Адизеса).
6. Книга Эдварда Фримана по управлению стейкхолдерами «Strategic Management: A Stakeholder Approach».
7. Прочие статьи по ситуационному лидерству и уровням делегирования.

К каждой лекции из видеокурса Стратоплана я подобрал дополнительные материалы из списка выше и составил домашние задания. Структура курса создавалась на ходу — на каждом практическом занятии мы совместно решали, что будем обсуждать в следующий раз. Вот что у нас получилось в итоге:

• роль и задачи тимлида;
• работа с вовлеченными сторонами;
• постановка и контроль задач;
• уровни делегирования;
• стили лидерства;
• встречи 1 на 1 с сотрудниками;
• модель стилей управления Адизеса.

Разрабатывая домашние задания, я преследовал две главные цели. Во-первых, я старался придумать такие задания, которые соотносились бы с текущими задачами тимлидов, а также имели бы практическую пользу для них и команды.

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

Например, задание по занятию «Роль и задачи тимлида» также затрагивало темы «Работа с вовлеченными сторонами» и «Модель стилей управления Адизеса», в другом задании я совместил такие темы как «Постановка и контроль задач» с «Уровни делегирования» и «Стили лидерства».

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

Вот одно из заданий на курсе, пошагово:

1. Составить список сотрудников в своей команде.
2. Оценить их склонности по системе PAEI.
3. Составить список стратегических и тактических задач команды на следующие 1—3 месяца.
4. Распределить задачи по сотрудникdам в соответствии с их склонностями. Не обязательно распределять все задачи — какие-то из них останутся на вас.
5. Оценить сотрудников относительно их задач согласно фреймворку ситуационного менеджмента.
6. Для каждой задачи описать итоговый подход к ее постановке (формулировка для сотрудника, тип и вид контроля, частота контроля).

Иногда, в дополнение к домашним заданиям, я просил участников курса подготовить презентацию или выступление на основе проделанной самостоятельной работы.

Например, задание могло быть таким:

1. Составить список основных задач тимлида, как их видит участник курса.
2. Посмотреть видеолекцию.
3. Сравнить собственный список с задачами, озвученными в видео. Ответить на вопросы: какие задачи я указал, которых нет в видео? Почему я считаю их важными? Какие задачи указаны в видео, но я их не записал? Почему я не указал их? Как я их выполняю (если выполняю)?
4. Выступить с результатами перед другими тимлидами.

Важный компонент курса — решение кейсов. Работа с кейсами велась следующим образом: все участники делились на 2 группы, каждая получала свой собственный кейс, который нужно было решить за отведенное время. Затем команды презентовали решение, после чего получали решения от меня, и после мы все вместе обсуждали результаты.

Приведу примеры кейсов с курса.

Кейс 1: «Управление стейкхолдерами». Николай, тимлид, работает в компании уже более 3-х лет. Изначально он пришел на позицию бекенд-разработчика, но за активную позицию полгода назад его назначили руководителем команды из двух фронтенд-разработчиков и трех других бекендеров.

Месяц назад к команде присоединился новый продакт-менеджер — Виктория. По мнению команды, Виктория склонна к микро-менеджменту и постоянно «влезает» в реализацию. Программисты регулярно жалуются на неё и тратят слишком много времени на преписку, отвечая на её вопросы. Прошлый же менеджер утверждал, что доверяет команде, и поэтому появлялся лишь на этапах планирования и приемки. Однако сроки проектов постоянно срывались, и в итоге его уволили.

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

Задание:

1. Составить список вовлеченных сторон.
2. Выявить их боли.
3. Распределить стейкхолдеров на матрице 2х2 (в двух вариантах, для состояний As-Is и To-Be).
4. Предложить план изменения состояния и заполнить план коммуникаций.

Кейс 2: «Постановка и делегирование задач». Тимлид Николай недавно сменил своё место работы на более привлекательное. Его новая команда состоит из 6 человек: 2 фронтендера (Виталий и Кристина), 2 бекенд-разработчика (Мария и Кирилл), 1 QA-инженер (Борис), 1 DevOps (Михаил). Команда была сформирована в момент выхода Николая на работу. До этого сотрудники трудились в других командах, ожидая выхода тимлида.

Николай уже успел навести справки у разных коллег про свою команду. Вот что ему удалось узнать:

1. Виталий — senior frontend. На короткой ноге со всеми проджект-менеджерами в компании. Ратует за качество.
2. Кристина — junior frontend. Учится на последнем курсе института, но работает полный день. Очень ответственная.
3. Мария — senior backend. Долгое время переписывала бекенд с одного фреймворка на другой. Уважаема в коллективе за профессионализм. Отлично знает систему изнутри. Считает, что команда слишком часто созванивается, и вообще «нужно дела делать».
4. Кирилл — middle backend. Ведет журнал созвонов по собственной инициативе. Первым пришел к Николаю спрашивать про цели на следующий год. Предлагает мигрировать с REST на GraphQL.
5. Борис — senior QA. За него больше всего переживает HR-директор, говорит, что тот выгорел. Борис работает уже 5 лет, становился лидом QA, но что-то пошло не так, и он решил вернуться в рядовые инженеры. Очень последовательный, продуктивный, но избегает ответственности.
6. Михаил — senior devops. Активно продвигает совместные активности. Внедряет DevOps-практики. «Заводила».

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

Задание:

1. Оценить примерные склонности сотрудников (по системе PAEI).
2. Выделить возможного заместителя (опционально).
3. Распределить задачи между сотрудниками и замом в соответствии с их склонностями. Не обязательно распределять все — что-то останется на вас.
4. Примерно оценить сотрудников относительно их задач согласно фреймворку ситуационного менеджмента.
5. Для каждой назначенной задачи описать итоговый подход к её постановке (формулировка для сотрудника, тип и вид контроля, частота контроля, уровень делегирования).

Вариант 1. Николай — PAei (т. е. функции P (producer) и A (administrator) — его сильные стороны).

Задачи команды:

1. Настроить автоматизированный сбор endpoint’ов сервисов в единый список.
2. Разработать механизм A/B тестирования.
3. Переписать бизнес-логику одного из сервисов.
4. Внедрить практику ретро в конце спринта.
5. Внедрить использование Test Management System в команде.
6. Внедрить TDD.
7. Составить карты компетенций.

Вариант 2. Николай — paeI (его самая сильная функция — I (integrator)).

Задачи команды:

1. Мигрировать БД из одного инстанса в другой без downtime.
2. Внедрить библиотеку журналирования ошибок на фронте.
3. Выделить модуль логирования на бекенде в отдельную библиотеку.
4. Собрать список «побед» команды для отчета начальству.
5. Составить roadmap развития бекенда.
6. Внедрить парное программирование.
7. Составить карты компетенций.

Курс помог тимлидам понять ожидания от их работы со стороны руководителей и других менеджеров, определить собственный стиль руководства и наметить стратегию дальнейшей работы с командой в соответствии с ним. Работа над кейсами показала, что у задач может не быть «правильных» и «неправильных» решений. И, что не менее важно, курс имел эффект тимбилдинга — мы все отлично провели время на занятиях.

Мои отношения с тимлидами также сильно выиграли. Я смог делегировать часть people management тимлидам, заручиться их уважением и поддержкой.

Возрос уровень доверия к команде со стороны продукта, где отметили рост компетенций тимлидов. Специалисты из HR со своей стороны отметили рост вовлеченности тимлидов и снижение уровня стресса.