Как организовать процесс развития и роста в команде

Что проверяют

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

Как отвечать

Каркас, который стоит наполнить своим опытом:

• диагностика: матрица компетенций фронтенда, где расписаны уровни по JavaScript и TypeScript, фреймворку, производительности, тестам, доступности, архитектуре и работе с командой. По ней видно, где человек сейчас и что нужно для следующего грейда;
• индивидуальный план: две-три цели на квартал, привязанные к реальным задачам. Не «изучить Web Vitals», а «довести LCP страницы каталога до зелёной зоны и рассказать команде, как»;
• регулярные 1:1: раз в одну-две недели, с разговором о прогрессе по плану, а не только о статусе задач;
• обучение в работе: код-ревью с объяснением, а не с приказом, парное программирование, ротация по областям (сборка, CI, дизайн-система), чтобы снизить bus factor;
• задачи на вырост: делегировать то, что чуть сложнее текущего уровня, и страховать, а не забирать себе;
• обмен знаниями: внутренние доклады, разборы инцидентов, чеклист онбординга для новичков;
• оценка результата: повышения, скорость онбординга, сколько людей могут поддерживать каждую часть кода, удержание.

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

Где спотыкаются

Сводят развитие к бюджету на курсы и конференции. Без привязки к задачам знания не применяются и быстро забываются.

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

Лид оставляет все интересные задачи себе. Он становится бутылочным горлышком, а команда не растёт.