Личный опыт наставничества и развития сотрудников
Всем привет, меня зовут Виталий, я тимлид в KTS. Последние несколько лет я идентифицирую себя не только фронтенд-разработчиком и лидом, но ещё и наставником нескольких сотрудников: от стажёров до синьоров.
В этой статье в 2 частях я поделюсь своим опытом наставничества, и, что самое важное, тем, как мы в KTS превращаем личный опыт наставников в систему.
Чтобы сформировать подобную систему, вам понадобится:
🎯 определить цели наставничества
⤴️ предложить векторы, по которым можно вести работу с подопечными
🧰 сформировать артефакты, которые помогут масштабировать в компании эту систему
Это во многом личная статья — желание делиться знаниями лежит где-то на верхушке моей персональной пирамидки потребностей. Это желание реализуется и через наставничество и через написание этой статьи. Приятного чтения 😌
Содержание 1-й части:
Продолжение про нетехнические навыки во второй части.
С чего всё началось
Моё наставничество пошло с появления первого стажёра. Сейчас, спустя годы, я рассматриваю ведение своего первого подопечного скорее как негативный опыт — на мой взгляд, я допустил ошибки, из-за которых сотрудник выгорел и уволился.
Эти промахи случились потому, что я без опыта ведения сотрудников получил дополнительную ответственность, но не представлял, как с ней справляться. На тот момент в компании стажёры были всего у нескольких людей. Наставники постоянно общались между собой, но процессы не были зафиксированы и задокументированы. Не было системы для воспроизведения наставничества. Не было базовых практик вроде регулярных встреч с наставником наедине. В результате было просто невозможно получить достаточную обратную связь: как наставнику, отсутствие встреч 1x1 не давало мне получить фидбек от стажёра, а как подопечный, я не мог получить советов от своего наставника и заметить эту проблему.
Сейчас нехватка коммуникации мне кажется очевидным недостатком, но к этому пониманию пришлось прийти со временем.
Благодаря первому фейлу я однозначно понял, насколько важны налаженные процессы по росту, развитию и просто постоянному отслеживанию состояния подопечных.
Вскоре после этого мы в KTS решили нанять сразу нескольких стажёров по результатам нашей школы по фронтенду и бэкенду. На тот момент этот опыт был уникальным, поскольку сразу 5 человек становились наставниками впервые. Тогда в KTS работали чуть более 40 человек. Стало ясно, что для наставничества нужны чёткие гайды и правила. Иначе этот процесс сложно масштабировать, контролировать и отслеживать его эффективность.
С этого момента мы сформировали рабочую группу: комитет развития наставничества. Несколько раз эта группа переформировывалась, включала разных людей, но с момента появления мы собираемся +- регулярно.
Цели наставничества
Перейдём к делу. Прежде чем описывать, как мы его формализовали, сначала определим, для чего это нужно.
На самом верхнем уровне предлагаю разделить цели компании и сотрудника. Во многом они пересекаются и выгодны всем.
Для компании важнейшие цели — удержание и рост сотрудников. С одной стороны, это важно из-за дефицита кадров на рынке. Стоимость поиска нового специалиста может быть очень высокой. С другой, высокий уровень специалистов позволяет более эффективно решать сложные технические и управленческие задачи. Компания становится более конкурентоспособной.
Для сотрудника самая очевидная польза в том, что более быстрый профессиональный рост позволяет ему быстрее расти финансово. Чем больше ответственности человек готов взять → тем больший спектр потребностей компании он эффективно закрывает → тем больше пользы приносит компании. Соответственно, и ЗП растёт быстрее.
Общая важная цель состоит в предотвращении выгорания сотрудника. Для компании это производная от удержания, а для сотрудника эта цель одна из важнейших. На мой взгляд, потребность в профессиональном росте скорее исходит из неё, а не наоборот. Согласитесь, для личного комфорта очень важно заниматься любимым делом и интересными задачами, чувствовать свою пользу и ощущать рост.
Чтобы защитить подопечного от выгорания, нужно не только работать на достижение целей сотрудника, но и отслеживать его эмоциональное состояние, делиться обратной связью, помогать решать рабочие проблемы, иногда настоять на отпуске. При работе с новичками часто нужно отдельно контролировать их work-life balance, чтобы молодые энтузиасты не сгорели от ночных коммитов. Нужно быть внимательным, поскольку ваш подопечный может не жаловаться на проблемы, потому что сам их не замечает.
Важно понимать, что наставничество приносит пользу не только подопечному, но и самому наставнику. Наставник повышает уровень своей абстракции и умение контролировать косвенные процессы.
Структура развития
Предлагаю разбить структуру развития сотрудника на составляющие:
Векторы — направления роста сотрудника.
Артефакты — набор инструментов, материалов и подходов, которые позволяют развитие планировать и структурировать:
регулярные встречи 1×1;
полугодовые performance review;
матрица грейдов;
базы домашних заданий, курсов, материалов и т.д.;
практики по сбору фидбека;
формализованные цели сотрудника.
Для любого человека в каждый момент времени можно определить зону его ответственности. Тогда профессиональный рост можно разбить на горизонтальный и вертикальный:
улучшение компетенций в текущей зоне ответственности → сотрудник умеет ещё лучше то, что уже умел
расширение зоны ответственности через получение новых компетенций
Соответственно, совокупность компетенций и глубина их использования определяют доступную сотруднику зону ответственности.
В KTS все направления, в которых можно развивать сотрудника, определены в матрице грейдов. Это важнейший артефакт, который позволяет формализовать и масштабировать наставничество. Матрица публична и периодически обновляется. Она специфична для каждой компании, потому что её содержание зависит от задач и потребностей бизнеса. Вы можете изучить наш вариант:
Cтруктура
В первой строке описаны все грейды в компании на сегодня.
В первой колонке перечислены в сгруппированном виде компетенции, которые может развивать сотрудник в KTS.
На пересечении описано, на каком уровне должна быть развита текущая компетенция у выбранного грейда.
Интерпретация. При переходе сотрудника на новый грейд его скилы должны соответствовать новой колонке. Соответствие матрице — это необязательный критерий для повышения. Несоответствие ей не должно быть причиной отказа в повышении, ведь у сотрудника какие-то скилы могут не дотягивать до его грейда по матрице, а некоторые, наоборот, сильно опережать.
Как использовать. Матрица должна подсказать сотруднику и его наставнику, где искать пробелы, и самое важное: куда ещё можно развиваться. Как наставник, при выстраивании работы со своим подопечным я в первую очередь опираюсь на матрицу грейдов.
Использование при работе с новыми сотрудниками. Новички должны адаптироваться в компании. Первые месяцы их работы уходят на то, чтобы соответствовать своему текущему грейду. Для остальных сотрудников в работе с матрицей ориентируемся на следующую колонку — т.е. на целевой грейд.
Использование при работе с адаптировавшимися сотрудниками. На регулярных встречах 1×1 мы можем вместе пройтись по матрице и для каждого скила целевого грейда обсудить: в каком состоянии он сейчас и как его прокачать. Ставим локальные цели к следующей встрече. Лучше всего их формулировать в виде конкретной задачи. Также можем адаптировать глобальные цели — те, которые нужно достичь к ближайшему performance review.
Нужно понимать, что матрица предлагает лишь общие направления, в которых можно развиваться техническому сотруднику. Эти направления не единственные и достаточно обобщённые, поэтому задача наставника — увидеть, как эти абстрактные скилы можно конкретизировать и адаптировать под подопечного.
⤴️ Векторы развития сотрудника
Обобщённо я могу выделить следующие векторы, которые отслеживаю при работе с сотрудниками:
Технические навыки
Код-ревью
Командная работа
Влияние сотрудника на компанию
Взаимодействие с заказчиком
Клуб писателей
Участие в школе KTS
Ведение стажёра
Помощь в наставничестве
Участие в найме
В этой части статьи я расскажу про первые два.
Технические навыки
Чтобы определить, куда сотруднику развиваться технически, я использую таблицу технических требований к фронтендеру в KTS. Ей не делюсь, т.к. она довольно специфична и, на мой взгляд, еще не до конца доработана. В этой таблице собраны темы и материалы, которыми наставник может делиться со своим подопечным.
Важная мысль, от которой я отталкиваюсь, пытаясь повлиять на сотрудника: это влияние должно быть максимально комфортным и не превосходить его возможностей в текущий момент. Обязательно нужно учитывать эмоциональное состояние подопечного, уважительно относиться к его времени, не нагружать чрезмерно. Мы же не хотим, чтобы он выгорел.
Большую часть технических скилов нужно стараться закрывать в рамках рабочих задач в рабочее время. Например, от фронтендера я ожидаю глубокие знания React, но стажёр или просто новичок может ими не обладать. Это значит, что я как лид должен дать сотруднику задачи, которые прокачают его в этом направлении. Либо, если я не являюсь лидом своего подопечного, я должен сообщить об этом его лиду.
В KTS тимлид и наставник — это разные роли: за развитие сотрудника всегда отвечает один человек. Наставником сотрудника необязательно является его тимлид. Им может быть человек из другой команды или даже юнита.
Мне нравится такой подход. В течение нескольких лет работы сотрудника в компании он может успеть поработать на нескольких проектах и в разных отделах. Но из-за того, что за подопечным закреплен один наставник, всегда есть человек, который знает весь его контекст и подход. Формируется стабильный тандем.
Наставник вынужден регулярно собирать фидбек у лида, менеджера и команды своего подопечного, общаться с ними, узнавать о процессах. С другой стороны, наставник делится своим опытом, который во многом не похож и уникален. В общем, результат — взаимное обогащение и развитие горизонтальных связей в компании. Наставник и подопечный расширяют свой кругозор и больше узнают о процессах в других частях компании. Так наставник может увидеть больше возможностей для своего подопечного и предложить новые направления развития.
Домашние задания
Некоторые скилы проблематично прокачать через рабочие задачи. Например, если стажёр приходит на уже развитый проект, ему не удастся хорошо освоить инструменты сборки фронтенда. Также можно долго ждать инфраструктурных задач, а развиваться хочется. Для таких целей мы в комитете проработали ряд ДЗ, которые сотрудник выполняет во внерабочее время.
Пример ДЗ для новичка-фронтендера
Теоретическая база
Посмотреть первые 8 лекций плейлиста по веб-технологиям в Технопарке (это базовая база, близкая сердцу и мозгу). Теорию можно изучать до выполнения технического задания, но лучше её сразу же подкреплять практикой, изучая материалы параллельно.
Многие сотрудники KTS в свое время учились в Технопарке Mail.ru при МГТУ им. Н.Э. Баумана. Сейчас этот проект называется VK Образование. Название меняется, но суть остается — супер-профессионалы дают студентам очень качественные знания. Лично я отношусь к Технопарку с большой теплотой.
Практика. Неделя 1. Изучаем веб-серверы
Засетапить свой проект с помощью CRA, сделать любой запрос к API, например, к открытому API Github.
Установить и настроить у себя Nginx, который раздаст статику собранного фронтенда и запроксирует запрос к API.
Практика. Неделя 2. Изучаем инструменты сборки
Переписать сборку с CRA на свои инструменты: Webpack, Babel, TypeScript, SCSS, линтеры и т.д.
Практика. Неделя 3. Изучаем контейнеры
Завернуть сборку и Nginx в Docker-контейнер.
В зависимости от успехов недели можно двигать.
Подобные домашки можно развивать в любом направлении, куда сотруднику интересно расти. Можно задавать просмотр технических плейлистов, изучение курсов и статей и т.д.
Думаю, что ДЗ стоит использовать только для стажёров и новых сотрудников. В общем, для тех, кто пылает энтузиазмом и готов что-то делать вне работы. Для познавших жизнь мидлов это точно не работает, надо было раньше 🙂 Конечно, всегда есть те, кто готов учиться без остановки и по выходным, и вы должны всегда уметь что-то предложить подопечному вне зависимости от его грейда, но по моему опыту, чем старше грейд, тем меньше у сотрудника желание тратить свое время на что-то вне рабочего времени. Остаётся лишь понять и отнестись к этому с уважением.
Что важно помнить про домашние задания:
Если скил можно закрыть через рабочие задачи, лучше не задавать ДЗ. Например, если сотрудник хочет изучить технологию, можно предложить с её помощью решить уже существующую проблему на проекте или в масштабе всей компании в рабочее время.
Все внерабочие активности строго опциональны. Если сотрудник не может, не хочет, не успевает, не нужно его грузить и заставлять. Задача наставника — заинтересовать.
Внерабочие активности не должны приносить прямую коммерческую выгоду компании. Вы развиваете сотрудника, а не эксплуатируете его, поэтому не давайте рабочие задачи в качестве ДЗ!
Код-ревью
На мой взгляд, код-ревью лежит на стыке софт- и хард-скилов. С одной стороны, сотрудник должен быть достаточно компетентен, чтобы заметить проблемы в коде. С другой, должен чувствовать уверенность в себе, уметь грамотно структурировать и доносить свои мысли. Помимо этого, код-ревью — отличный инструмент для обмена опытом внутри команды / юнита / компании, снижения bus-фактора. Поэтому наставник должен контролировать, что все задачи подопечного проходят ревью, и он, в свою очередь, регулярно ревьюит кого-то.
На встречах 1×1 стоит отдельно сказать, что подопечный не должен стесняться оставлять глупые комментарии и задать нерелевантные вопросы. По моему опыту, разработчики часто стесняются написать замечание, т.к. не уверены в своей компетенции. Вы должны помочь преодолеть этот барьер, транслируя открытость команды — вопросы кажутся глупыми только тому, кто их задает.
Если на ревью проверяющему что-то не понятно, это явный повод либо переписать код более ясно, либо добавить подробный комментарий с обоснованием выбранного решения. Покажите подопечному, что вопросы на ревью — не только способ преодолеть стеснение, но и шанс внести ясность в общее дело.
Ну и конечно, участие в ревью вызывает диалог, а значит, позволяет сотруднику лучше адаптироваться в команде.
Задача наставника — обеспечить, чтобы на всех проектах его подопечные получали качественное код-ревью и сами кого-то ревьюили. Например, если это небольшой проект с одним фронтенд-разработчиком, то нужно организовать кросс-ревью между несколькими проектами, или можно пригласить разработчика в качестве ревьюера на другой проект.
На сегодня пока всё
Во второй части:
Векторы развития:
Командная работа
Влияние сотрудника на компанию
Взаимодействие с заказчиком
Клуб писателей
Участие в школе KTS
Ведение стажёра
Помощь в наставничестве
Участие в найме
Последние советы
Спасибо за прочтение 🙏 Пожалуйста, делитесь своими мыслями и практикам, как вы развиваете своих сотрудников!
