Наш опыт, как не надо растить тимлидов (не делайте как мы)

Тимлидом у нас часто становился не обученный человек, а тот из разработчиков, который меньше всего не хотел. Потому что часто было надо. Исторически у нас в Skyeng очень много автономных команд (мы работали полностью на удалёнке в разных географиях до того, как это стало модным, и имели репутацию общества интровертов, в котором можно не развивать софт-скилы).

А потом мы обнаружили, что хороший тимлид отличается от вынужденного ещё и производительностью команды. Точнее, умением выдавать стабильный хороший результат и при этом не выжигать команду. А ещё правильно объяснять задачи, правильно объяснять происходящее в компании и правильно вообще общаться, что влияет на настроение людей и, как следствие, текучку — в командах с хорошими тимлидами люди почти не уходили из-за комфорта рабочего процесса.

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

Как было раньше

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

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

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

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

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

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

Что было не так

Не заходило у вчерашних разработчиков потому, что им доставалась команда (знакомая, понятная и часто любимая, но всё же целая команда), а дальше никто ничего не рассказывал про то, как её вести. Естественно, дальше либо человек сам находил знания, либо, чаще, пытался вытащить проект усиленной работой и немного сгорал. После этого он уходил кодить в какую-то другую часть компании, в другую команду.

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

1. От продакта, который управлял тимлидами: у него было внутреннее ощущение сильных и слабых сторон своих подчинённых.
2. От команд, конечно.
3. От руководителей подразделений.
4. И от HR-подразделения, делавшего регулярные оценки по тому, какие у кого навыки внутри компании.

Матрица: начало

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

Тогда мы решили собрать классическую матрицу компетенций: набор навыков и умений сотрудника на позиции тимлида. Посмотрели, что они сейчас делают в компании, покастдевили продактов, спросили их подчинённых и сдобрили своим замечательным прошлым опытом. И, конечно, не забыли посмотреть на фундаментальные результаты работы Егора Толстого и Стаса Цыганкова.


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

1 — не знает, не делает.
2 — знает теорию, но не делает.
3 — знает и выполняет частично либо с ошибками.
4 — знает и полностью выполняет.
5 — знает, выполняет и может учить других.

В итоге мы получили две важные вещи:

1. Быструю оценку каждого сотрудника и понимание, кто у нас тут супергерой, а кому пора на выход.
2. Группировку по компетенциям, которая показала нам, какие из них у нас просажены в компании больше всего.

Наши грустные результаты

«Хм… Странно, — подумали мы, — а почему у нас просажена компетенция «Техническая экспертиза»? Мы же технологическая компания и все тимлиды выходцы из разработчиков». По результатам кроме технической экспертизы, как видно из картинки, были просажены ещё две компетенции: выстраивание процессов и управление людьми. Но к этому мы морально были готовы, а вот к плачевному состоянию технической экспертизы — нет.

И поэтому тогда мы сделали ещё одну интересную штуку: посчитали не только среднюю оценку по каждой компетенции, но ещё и стандартное отклонение. И тут нас ждал сюрприз: компетенции с низкой оценкой разделились на два типа:

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

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

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

Что должен делать тимлид вообще

Для начала мы решили выровнять ожидания от тимлидов на уровне всей компании: какими компетенциями он должен обладать, за какие зоны нести ответственность. У нас сформировалось три больших направления:

• Люди: тимлид должен уметь собирать команду, работать над ростом её производительности, работать на индивидуальном уровне с каждым сотрудником для его мотивации и развития.
• Процессы: тимлид должен обеспечить качественно настроенный процесс разработки. Неважно какую методологию он использует, но команда должна давать стабильный и предсказуемый результат. Должны быть качественно настроены: работа с техдолгом, инцидент-менеджмент, работа с продакшен багами и так далее.
• Команда должна качественно проектировать и реализовывать свои решения и непрерывно заниматься их эксплуатацией. Тимлид отвечает за архитектуру и инженерные практики.

Как пытались исправить

Решили устроить внутреннее обучение для повышения квалификации тимлидов по тем компетенциям, которые были просажены больше. Мы же занимаемся образованием, правильно? Можно же делать это и внутри. Ну и у нас несколько тысяч человек и мы точно сможем найти экспертов. Получилось 26 тем, например, «Мотивация и 1:1», «Работа с входящими задачами», «Как правильно проводить встречи», «Онбординг и проведение испытательного срока». Выбрали 6 самых важных для обучения, по каждой из этих топ-6 нашли экспертов, подготовили материалы, составили расписание и отправили анонс на всю команду тимлидов. Тимлиды сами выбирали, какой интенсив посетить (иногда их туда отправляли их руководители), исходя из своих интересов. Каждый интенсив — это 1–2 семинара по 1–2 часа с обязательной домашней работой. В течение года удалось провести несколько итераций по каждой теме.

За прошедший год через интенсивы прошло примерно 20 человек (они оставили хорошие отзывы). Мы регулярно собирали обратную связь и улучшали программу, расписание, домашки, темы и так далее. Интерес к темам был, польза от них тоже.

Но основную проблему мы не решили.

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

У тех, кому реально нужно было обучение, обычно что-то горело. То есть времени на обучение не было. Вообще. Если они всё же выкраивали время, то не могли нормально учиться из-за отсутствия практики. Домашка и практическое применение навыков в команде — это разные вещи. Опять же, мы прекрасно понимаем, что в том, чему мы учим клиентов компании, теория — 20%, практика — 80%. Сапожники оказались без сапог. Дважды, потому что мы ещё не измеряли прогресс и не заложили никаких критериев успеха новой программы. Смотрели на посещаемость, смотрели на обратную связь от тимлидов и иногда от их менеджеров. Но у нас не было системы.

От матрицы знаний к навыкам

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

Поэтому мы задумались над грейдированием, которое бы отражало реальное развитие специалиста. Вот, например, есть молодые и неопытные тимлидики, к ним отдельные требования и отдельные ожидания, у них своя вилка зарплаты и им можно поручать небольшие и несложные команды. А есть нормальные сильные ребята, которые уже пару лет поварились в этой роли и теперь могут взять на себя полноценную команду со всеми её сложностями и проблемами и успешно их решать. Разумеется, что у них и зарплата повыше, и ответственность серьёзнее. А ещё есть вообще монстры, которые пошли на уровень выше в межкомандное взаимодействие, превратившись в «юнитлид-стажёров» (юнитлидами мы называем engineering managers, у которых в подчинении группа тимлидов).

В первой версии матрицы этого не было, поэтому после раздумий мы с прекрасными HR родили версию 2.0 с тремя уровнями:

1. Навык недостаточно развит.
2. Развит на уровне базовых ожиданий.
3. Навык развит с превышением ожиданий.

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

И знаете что? Всё это не помогло.

Потому что матрица нацелена на знания, а не на то, что сотрудник реально делает изо дня в день в своей работе.

Знать-то я могу многое: изучить все книги по менеджменту и пройти стопятьсот спецкурсов. Но при этом на работе буду как валенок: сотрудники будут бежать, сервисы сыпаться, а процессы стоять. Ну и самое главное, эта матрица не отвечает на вопрос «А что мне надо делать-то?»

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

Например, вместо абстрактного «Делает осознанный выбор методологии разработки и внедряет её» сформировали такие критерии:

• Осознанно выбирает методологию.
• Воркфлоу в Джире отражает реальный процесс.
• Корректирует процессы, опираясь на метрики, регулярно следит за ними.
• Исполнение завязано не на конкретных людей, а на ролях и т.д.

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

Что дальше?

1. Нужна понятная система оценки навыков тимлида. Для этого мы прямо сейчас прорабатываем конкретный набор скилов и под каждый из них описываем набор критериев — как та или иная компетенция проявляется в работе конкретного сотрудника. Это даст нам хорошую опору для оценки всей команды и, что самое важное, возможность отслеживать прогресс конкретного сотрудника. Примерно похожее мы делали для английского языка, но там это используется для другого.
2. Нужно больше практики. Для этого даём тестовый период. Новый тимлид пробует менеджмент в безопасных для себя и команды условиях. Руководитель формирует конкретные ожидания, ставит измеримые цели на какой-то период (обычно полгода), сотрудник пытается их реализовать при полноценной поддержке руководителя. Очень важно, чтобы менеджер регулярно давал обратную связь и помогал новобранцу достигать результата в новой роли. И вот в том случае, если он хорошо справился с новыми задачами, тогда можем давать ему промо и отдавать команду в управление, не боясь случайных выстрелов в ногу.
3. Нужно переделывать всю программу в практико-ориентированную. То есть не «вот такая методология, вот так она применяется к команде», а «вот такая ситуация, вот так можно поступить, вот методология, которая лежит за логикой принятия решения».
4. Нужна полноценная связанная программа обучения. Например, темы про управление людьми очень тесно между собой переплетены и давать одну без другой не разумно: мы должны говорить и про правильный найм команды, и про регулярную 1:1 работу, и про мотивацию, развитие, и про дачу обратной связи, и про командную динамику, и про индивидуальный менеджмент, и даже про увольнения. Если тимлид прослушает только одну тему, то у него не сложится полноценной картины в голове, будет разрозненное лоскутное одеяло.
5. Привлекаем методологов делать систематику.
6. Будем вводить в программу не тех, кто хочет, а тех, кому это нужно.

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

To be continued, в общем… Хотя я надеюсь, что на все классические грабли мы уже понаступали.