Семь лет назад тимлидом в hh.ru становился тот, кто быстрее всех пишет код и катит его на прод. Спойлер: этого оказалось недостаточно. Так началась история создания модели компетенций, которая пережила десятки команд, несколько волн роста компании и до сих пор влияет на то, как мы понимаем лидерство.

Привет, Хабр! Меня зовут Александр Блинов, я технический руководитель B2C направления в hh.ru. В моей зоне ответственности 14 команд и более 80 сотрудников. Эта статья выросла из моего доклада для TeamLead Conf, и в ней я поделюсь нашим опытом оценки управленческой зрелости тимлида в крупной продуктовой компании. В hh.ru мы прошли путь от хаотичных обсуждений в Google Docs до живой модели компетенций с GitHub-ревью, оценкой 360 и управленческими грейдами. Я поделюсь, какие уроки мы извлекли, какие шишки набили, что делать стоит, а что точно обречено на неудачу.

Сегодня hh — большая компания с серьёзной экспертизой. У нас больше 700 человек только в IT, data и product направлениях. Но так было далеко не всегда. Семь лет назад во всей компании было 20 команд. При этом тимлидов, как тогда было принято в индустрии, выбирали из разработчиков, которые хорошо и быстро пишут код. Скоро мы осознали, что такой подход не работает: мы не получали сильных руководителей, зато теряли отличных разработчиков. Нам же хотелось, чтобы были и те, и другие. 

Поэтому мы решили растить руководителей своими силами. Для этого нужно было  измерить их текущий уровень и планомерно его повышать. Так родилась идея создать модель компетенции руководителя.

Как появилась модель компетенций

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

Это было хорошее начало. Но как измерить, насколько хорошо проявляется компетенция у тимлида? Потребовалась шкала для оценки.

Мы внедрили несколько уровней проявления компетенций:

0 — Негативное влияние при отсутствии компетенции. Тимлид не помогает что-то делать, а, наоборот, мешает.

A — Компетенция не проявляется никак.

B — Интуитивные действия. Это эпизодическое проявление, когда тимлид что-то делает, но без системы.

C — Знает теоретические основы и применяет их на практике. Есть успешные кейсы, система, и её наличие заметно в процессах.

D — Эксперт и наставник. Может проводить мастер-классы, выступать с докладами, влияет на развитие процессов, делится знаниями с другими. 

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

• Где фиксировать? Мы взяли Google Docs, чтобы туда всё записывать.

• Как обсуждать? В Google Docs есть встроенные комментарии.

• Как решать разногласия? У нас это происходило очно на встрече рабочей группы.

На практике оказалось, что большой документ в Google Docs — это неудобно. Версии путались, комментарии терялись, что-то случайно удалялось. В итоге участники начинают заново комментировать, писать то же самое по второму или третьему кругу.

Тогда мы попробовали решать разногласия на очных встречах. Времена были доковидные, поэтому мы  физически собирались в переговорке и выясняли, кто прав. Казалось бы, план был надёжным, как швейцарские часы. Но мы сразу же столкнулись с проблемой: когда несколько умных людей (тогда — человек шесть!) собираются вместе, обсуждение затягивается, потому что договориться очень сложно. Это превращалось в бесконечные споры.

Расскажу, как с этим боролись.

Решение №1. Прийти к консенту, а не консенсусу. 

Про понятие «консент» я узнал не так давно. Часто говорят: «Прийти к консенсусу». Консенсус — это когда всем всё понравилось. Но на самом деле не всегда нужно, чтобы всем всё нравилось. Часто достаточно такого MVP в мире решений, который называется консент. Это означает, что нужно найти решение без критических противоречий. Запомните, консент — это круто, когда вы пытаетесь договориться с большим числом людей.

Решение №2. Понять истинную мотивацию. 

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

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

Решение №3. Использовать систему контроля версий. 

Решение проблемы объёмных Google Docs было на поверхности. Система контроля версий GitHub как будто была придумана для нашей модели компетенций. Делим модель на части по принципу: одна компетенция — один Pull Request. Теперь у вас есть всё для обсуждения, и комментарии больше не потеряются.

Итак, мы выбрали инструменты: обсуждаем задачи на GitHub через pull request со стандартным процессом ревью. Если в pull request возникают непреодолимые разногласия, созваниваемся с ревьюером, чтобы понять его позицию. Так разбираемся в деталях и приходим к общему решению.

Когда мы вооружились этим набором инструментов, всё пошло бодро и продуктивно. Мы выделили 38 попугаев компетенций — внушительный список для оценки. Компетенции выглядели примерно так. 

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

А судьи кто? Оттачиваем процесс оценки 360

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

15+ респондентов

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

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

Решение лежало на поверхности — для каждой компетенции нужно определить, кто может её оценить. После этого делаем в опроснике ветки для каждой роли — тимлид, продакт, руководитель тимлида и т. д. 

Так мы перестали задавать все вопросы всем подряд. Теперь респондентам задаём всего несколько вопросов — в рамках их компетенций.

Проблема RACI

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

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

Проблема определения уровня

Новая проблема — тяжело определить уровень, когда есть проявления полного уровня полностью и частично следующего. Например, кажется, что тимлид застрял между B и C, критерии по B — закрыты, по C — тоже, но не полностью.

В этой ситуации решение такое: просить ставить минимальный подтверждённый уровень, — то есть между B и C выбирать по умолчанию B. Но при этом обязательно добавить в поле комментариев, что у тимлида уже получается из уровня C.

Проблема полей

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

Кроме того, на GitHub формат, близкий к markdown. Но в markdown очень тяжело визуально различить, что пишешь — нет заметного форматирования.

Поэтому мы изменили формат на тот, в котором удобно записывать — YAML. Нам он понравился максимальной лаконичностью в сочетании с удобством  написания и ревью. Затем мы настроили переход в MD-файлы, а также добавили проверку PR,  все ли поля заполнены корректно — инженеры, куда же без этого? 

Так мы поняли, как составлять модель компетенции, какие у неё поля и как мы её ведём. Настала пора решить, как запустить саму оценку. 

Механика оценки: от таблиц Excel к собственному ПО

Первая идея — использовать публичные опросники. Плюс в том, что они уже есть и не нужно разрабатывать ничего самим. С помощью скриптов и макросов можно выгрузить оценку в Excel и как-то предобработать. Для MVP этого достаточно.

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

Работая с условными Яндекс-формами, приходится постоянно добавлять респондентов вручную, проверять e-mail. Ты расшарил доступ, а потом кто-нибудь уволился и нужно у него доступ отбирать. С этим есть проблемы. Поэтому мы решили делать своё ПО, которое будет лишено этих недостатков.

В hh есть Школа программистов, куда мы набираем стажёров и делаем из них крепких джунов. Мы предложили одной из команд в  качестве финального проекта разработать это решение. Они его сделали, а мы потом отдали его на поддержку подрядчикам. Оно до сих пор живо. Если бы мне сказали сделать что-то сейчас, то можно было бы навайбкодить, но тогда пошли таким путём.

Как мы оцениваем результаты

Дальше нам нужно было оценить результаты. Первая мысль — посчитать среднее. То есть взять оценки A, B, C, и посчитать среднее арифметическое. Получится B — кажется, всё хорошо. Но это не так, ведь кто-то оценил на A, то есть заявил, что компетенция не проявляется совсем, а кто-то оценил на C, то есть компетенция проявляется системно. Среднее не работает.

Мы придумали такую методику оценки.

Сначала разбили людей на группы:

1. Команда (прямые подчинённые)

2. Продукт (продакт, проджект, дизайнер, аналитик)

3. Технари (техдир, руководитель тимлида, архитектор, другие коллеги)

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

• Все оценки одинаковые — берём её.

• Отличие на один уровень (например, B и C) — берём доминирующую оценку со знаком +/- (например, C- или B+)

• Отличие на два и более уровня (A, B, C) — система помечает оценку как «невозможно принять решение». И тут начинается ручная работа того, кто подводит итоги.

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

• Если разница в уровнях — два, то вы созваниваетесь с оценивающими и задаёте уточняющие вопросы. При этом плохой паттерн спрашивать: «Ты оценил на B, почему не на C?». Хорошие варианты: «Расскажи, как у вас вообще происходит процесс делегирования?» или «Как вы оцениваете задачи?». Человек рассказывает, как он видит процесс, а на основе  этого корректируем оценку и выставляем итоговый уровень.

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

• Если поставили оценку 0 — это огромный красный флаг, бегите и узнавайте, что происходит. Нужно созваниваться и выяснять, в чём дело.

• Если один участник стабильно занижает оценки. Часто это знак того, что у человека с тимлидом конфликт. Нужно созвониться и узнать, что у них происходит: «Расскажи в общих чертах, как работает тимлид Вася, что вы делаете, как взаимодействуете». Возможно, вы как раз узнаете про конфликты. В этом случае мы иногда оценки корректируем: «Ок, давайте оценки Пети учитывать не будем, между ним и тимлидом есть какая-то проблема».

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

Оценка результатов

Итак, оценки собрали. Что дальше?

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

Грейдирование

Со временем мы поняли, что этого мало. Существует управленческий грейд — решили перейти от простой модели оценки к грейдам. Мы ввели грейды Junior, Middle и Senior и для каждого зафиксировали ожидания. Может так случиться, что на уровне Junior у нас нет ожиданий по конкретной компетенции. На уровне Middle ожидаем оценку B, а на Senior — C. 

Закономерный вопрос: почему сразу не вписать, что именно мы ожидаем для грейда Junior, чтобы модель компетенции грейд и выставляла. Действительно, так можно делать. Но наш подход  к системе оценки сложился исторически. Мы шли через уровни проявления компетенций. К тому же, удобно, когда вы берёте конкретную компетенцию и можете логически разложить её на части: что у вас A, что B, а что C. Это хороший способ понять, что развивать.

Когда мы стали выписывать, чего ожидаем от тимлидов, у нас получилось не так просто: для Junior A, для Middle B, для Senior C. Иногда в некоторых компетенциях мы, например, ожидаем для Junior сразу же B, но и на Middle уровень B подойдёт, а на Senior ожидаем уже не ниже C. По таким причинам у нас осталась модель компетенции именно в таком виде — отдельно уровни проявления и отдельно маппинг на управленческие грейды.

Финализация результатов

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

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

Бывает, что компетенции корректируются. К примеру, могут сказать, что тимлид конфликтный, много жестит. Я спрашиваю: «Василий, что происходит?». А он говорит: «Так это же я принимаю специальные меры». После этого разговора оценка ещё может быть скорректирована. 

Далее итоговые оценки мы собираем в матрицу.

Здесь в первой колонке сами компетенции, во второй — уровень, который есть у тимлида, а дальше — наши ожидания на каждом для каждого грейда.

Цветовое кодирование:

• Зелёный, если тимлид лучше, чем ожидания на этом уровне

• Жёлтый, если он ровно в него попадает

• Красный, если сильно не дотягивает

• Полутона — различия менее, чем в один уровень

Глядя на табличку внимательно, можно экспертно определить грейд тимлида. Здесь, например, можно определить, что Junior почти полностью закрыт и есть заделы на Middle. Значит, грейд как минимум Junior+. Судя по следующей колонке, у него ещё не полный Middle, а что-то ближе к Middle-. Так как красных полутонов многовато, я бы выставил уровень Junior+. Так с помощью простого цветового кодирования мы можем оценить управленческий уровень тимлида.

Но нам важна не только статика, но и динамика. Мы хотим понять, насколько тимлид вырос за определённый период, или наоборот — это не прогресс, а стагнация или регресс.

Для этого можно посмотреть, насколько тимлид прокачался. Цветовое кодирование примерно такое же, но без жёлтого — только красное и зелёное.

Конкретно для этой модели компетенции мы видим, что тимлид — красавчик, прокачался в 4−5 компетенциях. За это его можно похвалить. Но также замечаем регресс в одной из компетенций, и тут нужно задать вопрос, а что случилось, почему вдруг просели архитектурные решения, что произошло?

История изменений

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

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

От отчёта к плану действий

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

Здесь цветовое кодирование кричит: а давай возьмём эти «низковисящие фрукты» и закроем уровень.

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

Вы отмечаете, что нужно сделать в следующий период:

• P0 — должны были сделать ещё вчера

• P1 — хотите это сделать за ближайший период

• P2 — было бы неплохо, но на этом можно не акцентировать внимание

По результатам работы отслеживаем процесс. Если тимлид реально закрыл уровень, то возвращаемся к PDF и прямо указываем, что уровень вырос.

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

Кейсы из реальной жизни

Я рассказал про то, как мы делали модель компетенций, как она устроена. Теперь — несколько кейсов, как мы её использовали.

Кейс №1

Мы два года оцениваем тимлида по модели компетенций: где-то у него регресс, где-то — прогресс, но при этом он застрял на уровне между Junior и Junior+. А когда спрашиваешь о нём у продуктовой команды, все довольны. При этом иногда приходит продакт и говорит, что он делает что-то не то.

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

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

Кейс №2

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

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

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

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

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

Что бы я сделал по-другому?

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

• Отказался от уровней проявления (А, B, C и D). С одной стороны, составлять по ним очень удобно, но модель компетенций — это продукт для других людей, которые ей пользуются. Проще оценивать под другим углом, когда явно выставляются уровни Junior, Middle, Senior.

• Я бы не делал большие компетенции (что делает на A, что на B), а сделал бы ряд утверждений, которые можно легко и однозначно оценить — «да», «нет», «не знаю». Этих критериев достаточно. С одной стороны, кажется, что раньше нужно было поставить один уровень (A, B или C), а тут их получается 10, и стало легче. На самом деле, когда люди читают модель компетенций, они всё равно в голове компилируют, ставят мысленно галочки и потом выставляют итоговый уровень. Чек-лист из утверждений просто избавляет их от этой лишней работы. 

• Чтобы закрыть уровень, надо закрыть все предыдущие. Например, чтобы достичь уровня Middle, нужно получить все галочки в Junior и в Middle. Я бы сделал так, но вы используйте этот подход на свой страх и риск. Возможно, вам подойдёт классический подход, о котором я рассказал выше.

Дальнейшее развитие модели компетенций

Сейчас мы занимаемся радаром практик. Он похож на модель компетенций тимлида. Отличается он тем, что есть две части:

1. Личная — что делает непосредственно сам тимлид

2. Командная — какие практики есть в команде

В будущем командные практики я хотел бы вынести в Practice Radar. А персональные тимлидские практики (например, one-to-one или Accessible, Responsible в RACI)  оставил бы в модели компетенций тимлида. Итоги я бы оценивал вместе. Собрал бы результаты по Practice Radar и личным проявлениям, и все заслуги по зрелости команды и её фейлы приписывал тимлиду.

Вместо заключения

10 ключевых тезисов:

1. RACI должна быть «под капотом», но стоит избегать использования в явном виде

2. Уровни проявления (0,A,B,C,D) помогают составить модель компетенций, при этом не обязательно оставлять их в явном виде

3. Позиция → интерес — поможет решить противоречия, как и личные обсуждения

4. Замена консенсуса на консент поможет сделать MVP

5. Удобно хранить в системе контроля версий

6. Спрашивайте только то, что человек в каждой роли может ответить

7. Формулировки должны быть недвусмысленными, сформулированы как проявление компетенций

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

9. Оценки должны быть открытыми, должна быть возможность скорректировать их или вообще удалить

10. Начинать лучше всего с каких-либо форм, а потом уже делать специальный софт

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