Тимлид или ведущий дейликов?
«У меня не тимлид, а просто ведущий дейликов!» — с горечью однажды воскликнул мой знакомый, и эта фраза послужила для меня поводом к написанию этой статьи. Ведь я тоже уже давно замечаю, что с ролью тимлида в последние годы происходит что-то не то. Причем как со стороны самих лидов, так и со стороны их руководителей.
Понимаю, что над созданием статьи я думал очень долго, и точно не окажусь уникальным. Но хочу подсветить некоторые проблемы и услышать мнение профессионального сообщества.
Представлюсь
Меня зовут Паша, я IT-лид в Туту. Моя деятельность включает в себя 3 основных направления:
Архитектура и техническое видение, планирование
Процессы разработки продукта
Пипл менеджмент технических сотрудников
В этом году я отмечу 15 летний юбилей работы в IT. Руковожу тимлидами последние 4 года. Пришел к этому по классическому пути от руководителя группы разработки до руководителя нескольких команд, которые отвечают за один бизнес-домен. А до этого 9 лет был бэкендером и 2 года тимлидом.
С описанными в статье проблемами я сталкивался сам на протяжении своей карьеры, и параллельно наблюдал их же в других компаниях через опыт коллег.
За эти долгие годы в индустрии я оброс достаточно большим количеством контактов: мои бывшие коллеги работают в биг/фуд/фин техе и множестве диджитал-студий, средних е-коммерс продуктов. Я постоянно поддерживаю связь практически со всеми этими замечательными людьми, в том числе для обмена опытом и многочисленными кейсами. Чтобы из статьи не вышло накидывание на вентилятор без какого либо полезного контекста, формат подачи будет следующим:
Суть проблемы.
Последствия, которые взяты не «с потолка», а основаны на реальном опыте.
Профилактика, опробованная на деле.
Надеюсь, что статья будет полезна как тем, кто руководит тимлидами, так и самим тимлидам.
Проблема: текущий уровень лида и его зарплатные ожидания не сопоставимы с реальной картиной
Многие тимлиды всерьез считают, что переход на следующий грейд должен осуществляться чуть ли не раз в пол года на фоне (только лишь) выполненных проектов. Либо сразу после получения новых знаний на рандомных курсах или прочтения профессиональной литературы. Такое ощущение, будто люди всерьез перестали понимать, что изучить навык не равно его освоить и начать применять.
Лишь после применения изученного навыка на практике, причем не один раз, в полной мере можно утверждать, что человек его освоил. Выполнение и сопровождение проектов в деливери процессе — это лишьодна из обязанностей тимлида. Считать количество выполненных проектов и использовать эту цифру в качестве аргумента для повышения грейда — это все равно, что считать мидлом разработчика, который написал (допустим) 10 тысяч строк кода.
Последствия проблемы. Для сотрудника — это необоснованное перескакивание по грейдам, которое не подкреплено обучением, практикой и обобщением опыта, приведет к ситуации, когда в рамках компании тимлид дорастет до уровня senior и упрется в потолок финансовых возможностей работодателя.
А главное — к кризису дальнейшего роста. В этот момент тимлиду нужно вовсю обучаться самому, а он окажется в ситуации, когда от него будут ждать обучения других людей в команде. Как правило в погоне за деньгами такой лид пойдет мониторить рынок и столкнется с горькой правдой о том, что навыки все же нужно систематизировать и оттачивать. Для остального рынка такой лид в лучшем случае окажется менеджером джуно-мидлового уровня.
Для работодателя проблема, если максимально кратко — платим больше, получаем меньше ожидаемого результата. Раздувание ФОТ сами знаете к чему приводит. К сожалению, результат у многих компаний сейчас — за окошком.
Профилактика проблемы
Внедрить полноценную матрицу компетенций и привязать к ней перфоманс-ревью. У Авито в открытом доступе лежит крутой материал с подробным описанием ожиданий от менеджера каждого уровня. В свое время мы с товарищами скорректировали его под себя и получилась матрица, которую завернули в перфоманс ревью для лидов. Перфоманс ревью рекомендуется проводить не чаще одного раза в год. Дополнительный по запросу провести допустимо, если человек действительно за пол года успел что-то освоить и применить на практике. По ссылкам можете забирать инструменты.
Проводить смену грейда только по итогам перфоманс ревью. Исключите хаос в этом вопросе. Никаких пересмотров из разряда «по ощущениям я вырос». Также, чтобы иметь возможность индексировать зарплату тимлиду, рекомендация для того, кто держит ФОТ — выделять коридор в вилке для каждого грейда. Так вы сможете поощрять сотрудника за частичные достижения и результаты, не меняя сам грейд.
После перфоманс-ревью проводить тщательный анализ результатов и составлять индивидуальный план развития. Рекомендую составлять ИПР по SMART с четким закреплением definition of ready — цели должны быть прозрачными, четкими и достижимыми. Я уже третий год использую этот шаблон, из множества вариантов он мне больше всего пришелся по душе. Взращивайте компетенции взвешенно, с пониманием как их можно применить чтобы работа действительно стала эффективней.
Руководителю тимлида необходимо на 1–1 стараться раскапывать внутри собеседника мотиваторы, которые пока ярко не проявляются, и раскрывать их. Не зацикливаться исключительно на инструментальном типе мотивации.
Проблема: ошибка в анализе мотивации и навыков во время выбора лида из кадрового резерва
Так происходит, когда на роль тимлида выбирают линейного сотрудника, который сам пришел и об этом попросил, но основная его мотивация — это деньги. При этом человек не обладает управленческим потенциалом, лидерскими качествами, должным уровнем эмпатии, желанием развиваться в сторону управления.
Здесь совершают ошибку и будущий тимлид, и его руководитель. Первый безответственно считает, что управлять командой — это «халява», и не представляет, какие навыки для этого требуются. Второй закрывает глаза на красные флаги в надежде на то, что управленческие навыки волшебным образом появятся из воздуха. Оба при этом не готовы по каким либо причинам их развивать.
Это все на первый взгляд может показаться какой-то нелепой ситуацией — корнер-кейс в мире менеджмента. Но на самом деле такое случается часто. Яркий пример, когда из команды резко уходит тимлид, и на его место утверждают старшего разработчика. Разработчик видит в этом назначении единственную возможность повысить себе зарплату, а его руководитель — быстро залатать дыру.
Последствия проблемы. Команда получит не тимлида, а того самого ведущего дейликов, который своими неумелыми действиями доведет ее до выгорания, если вовремя не принять меры. Огромные ресурсы, которые менеджер такого тимлида попытается в него вложить, с большой вероятностью не окупятся. В итоге — потеря времени и даже возможно части команды. Такой тимлид не будет видеть ценности во внедрении многих инструментов, возможно обладает низким уровнем эмпатии, будет тяжело управляемым.
Профилактика проблемы
Научиться анализировать мотивацию сотрудников. Один из способов — проработать типы мотивации по Герчикову и выявить людей без навыков с одним лишь инструментальным типом. В случае, если мотиваторы другие, попробовать подтянуть сотрудника в знаниях
Если потенциала нет, то лучше сперва поработать над ожиданиями сотрудника. Например, показать ему, как должен выглядеть процесс проведения 1–1 (большое число управленцев вообще не воспринимают серьезно этот инструмент), проверить навыки взаимодействия (попросить «продать» какое либо нововведение в команде) и так далее. А также дать материалы для самостоятельного обучения и вернуться к этой теме только в случае, если он действительно прокачается.
Если сотрудник по всем параметрам не готов стать менеджером, не бояться аргументированно об этом сказать. Красные флаги все-таки игнорировать не стоит. В таком случае лучше пойти на рынок и попробовать найти подходящего кандидата там.
Создание центра экспертиз, который будет через себя прогонять весь кадровый резерв. Это отдел, который отвечает за проработку матриц компетенций каждого стека в отдельности. Берет на себя ответственность за развитие сотрудников, отвечает за критерии найма и за сам найм.
Со стороны работника, который идет предлагать себя на должность лида: погружаться в нюансы работы, проверять свои навыки на соответствие этой должности, трезво оценивать свои силы.
Проблема: инвалидизация должности тимлида
Эту проблему можно разделить на две части.
Первая — путаница в зонах ответственности. Тимлид — это в первую очередьруководитель. Однако меня крайне удивляет, как во многих организациях бигтеха практически по каждому вопросу тимлид скован в своих действиях. Он не может принимать финальные решения о найме или увольнении собственных подопечных, не принимает участия в проработке архитектуры своего контура, не всегда понимает зону ответственности и из-за этого не проявляет инициативы. Это практически во всех случаях происходит из-за вышестоящего руководства тимлида. Я не говорю даже о непосредственном руководителе, потому что бывает, что такая модель управления навязана вообще по всей компании.
Вторая — нет единых стандартов и требований к роли. Team lead (er) или дословно с английского руководитель команды (далее прямая цитата с Википедии) — это человек, который обеспечивает руководство, инструктаж, направление и лидерство для группы лиц с целью достижения ключевого результата или группы согласованных результатов.
На деле обычно получается так: держи пачку людей, держи пачку задач или контур и сделай так, чтоб все сработались и выполнили поставленные задачи. В целом — не вижу противоречий. Но как же много есть нюансов!
В каких то компаниях тимлид отвечает исключительно за деливери-процесс с точки зрения успеваемости и пипл‑менеджмент, за технику же отвечает техлид. В других компаниях эти роли совмещает один человек
У одних тимлид обязательно часть времени должен кодить, у других такой потребности нет. Да и должен ли вообще этот человек уметь хорошо кодить и проектировать? Есть же программисты и архитекторы.
Где то тимлид имеет практически неограниченные возможности в плане принятия решений — он ответственен за найм и увольнение, архитектуру контура, выбор решений, развитие сотрудников и многое другое. А где то все эти решения замкнуты на компании или руководителе выше.
На самом деле все эти навыки и обязанности должен и главное может совмещать один человек. Роль лида, на мой взгляд, обязательно нуждается в определенной стандартизации.
Последствия проблемы. Если руководитель замыкает все решения на себе (особенно связанные с командой), то он отнимает у подопечного тимлида ответственность. В глазах команды такой тимлид выглядит как человек, который по любому вопросу вынужден бегать «наверх» за итоговым апрувом. Это может привести к ситуации, когда линейные сотрудники идут через тимлида напрямую к его руководителю. Иногда тимлид даже не в курсе таких походов. На мой взгляд, это не здоровый паттерн. Тимлид теряет тягу к проактивности и экспериментам, гасится его творческий потенциал.
В итоге руководитель такого тимлида начинает заниматься микроменеджментом, становится «бутылочным горлышком» и получает подопечного, который оттягивает огромную долю внимания. Команда с таким управленцем быстро теряет мотивацию и начинает работать неэффективно.
Профилактика проблемы
Менять модель управления и отдать ответственность за решения по поводу команды тимлиду. Именно он руководит этой ячейкой, а задача вышестоящего менеджера — быть наставником, помогать в любых ситуациях (где его об этом просят), а также заниматься направлением в целом. Верхнеуровневая архитектура всего домена — зона ответственности руководителя, а архитектура сервисов команды — это зона ответственности тимлида. В любых вопросах стоит воспринимать собеседника как эксперта-партнера, а не подопечного, которому легко что то можно навязать.
Внедрить RACI-матрицу. Матрица помогает исключить проблемы с пересечением зон ответственности. Часто из-за ее отсутствия тимлид начинает выполнять работу PO или начальника и наоборот. Делюсь матрицей, которую везде использую и внедряю.
Принять тот факт, что тимлид должен быть играющим тренером. Это я сейчас про «уметь программировать, архитектурить» и вот это вот все. Команде нужен полководец, который сам умеет драться на поле боя. В моей практике были тимлиды, которые стали руководителями, проработав разрабами по 1–1.5 года в своей жизни. Во всех случаях команда была демотивирована слабой технической подкованностью руководителя, фактически он просто выполнял роль второго project owner.
Вопросы к сообществу
Вам знакомы эти проблемы? Считаете их важными и релевантными?
Поделитесь личным опытом, как еще можно решить описанные в статье проблемы?
Буду благодарен каждому комментарию. Надеюсь, что был полезен!
