Матрица управленческих компетенций: Тимлид#

О роли Тимлида#

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

Ключевые принципы#

1. Двумерная модель: Тимлид имеет как техническую позицию (07-20), так и управленческий уровень
2. Баланс 50/50: Примерно половина времени на код/тестирование, половина на управление командой
3. Минимальный технический уровень: Роль доступна с позиции 07 (Middle)
4. Обратимость: Можно вернуться на чисто техническую роль без потери технической позиции

Области ответственности Тимлида#

1. Управление командой (People Management)
2. Техническое лидерство (Technical Leadership)
3. Процессы и планирование (Process & Planning)
4. Коммуникация с бизнесом (Business Communication)

Матрица управленческих компетенций#

Управленческий уровень Тимлида зависит от технической позиции и опыта в управлении.

Баланс код/менеджмент: Проценты времени на код в описании каждого уровня соответствуют типичному размеру команды для этого уровня. Если размер команды отличается от типичного — ориентируйтесь на таблицу баланса по размеру команды.

Начинающий Тимлид (позиции 07-10)#

Технический уровень: Middle (позиции 07-10)

Типичные задачи: Ведение небольшой команды (2-4 человека) на проекте, координация разработки фич, решение технических вопросов, ведение командных процессов, менторинг младших.

Опытный Тимлид (позиции 09-12)#

Технический уровень: Middle/Senior (позиции 09-12)

Типичные задачи: Ведение команды (4-7 человек), управление delivery проектов, развитие команды, найм, техническое лидерство, взаимодействие с продуктом.

Сильный Тимлид (позиции 11-14)#

Технический уровень: Senior (позиции 11-14)

Типичные задачи: Ведение большой команды (5-10 человек), управление сложными проектами, стратегическое планирование, развитие технических лидеров, влияние на продукт, формирование культуры.

Ведущий Тимлид / Engineering Manager (позиции 14-20)#

Технический уровень: Senior/Staff/Principal (позиции 14-20)

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

Руководитель отдела (Head of Department)#

Отличие от Ведущего Тимлида: Это не просто следующий уровень тимлида, а отдельная роль с другим фокусом ответственности.

Типичный масштаб: 15-25 человек (включая 2-4 команды с тимлидами)

Технический грейд: Обычно позиции 11-14 (Senior)

Ключевые обязанности:

• Определение технической и продуктовой стратегии отдела
• Развитие и менторинг тимлидов
• P&L ownership за продукт/направление
• Найм ключевых позиций (тимлиды, Senior+)
• Координация с другими отделами департамента
• Представление отдела на уровне руководства компании

Специальные темы#

Баланс между кодом и менеджментом#

Ключевой принцип: Баланс зависит от размера команды, а не только от грейда тимлида.

Реалистичный баланс по размеру команды#

Формула: Management time ≈ 15-20% × количество подчинённых + 10% overhead

Почему именно такой баланс?#

Баланс основан на практических наблюдениях:

1. Менее 20% на менеджмент — тимлид не успевает вести команду качественно: редкие 1-on-1, пропуски ретро, слабое планирование
2. Более 80% на менеджмент — тимлид теряет техническую глубину, не может помочь в сложных вопросах, code review поверхностный
3. Ключевой фактор — размер команды: см. таблицу выше. Баланс определяется не грейдом, а количеством людей

Правило: При команде 8+ человек тимлид физически не может кодить 50%. Либо делегирование (buddy/техлид), либо перегрузка.

Пример:

Команда 5 человек:
- 1-on-1: 5 × 1ч/2 недели = 2.5ч/неделю
- Найм/развитие: ~2ч/неделю
- Координация: ~3ч/неделю
- Планирование: ~2ч/неделю
= ~10ч/неделю на менеджмент = 25% времени

Реальность: с учётом переключений контекста → 40-50% на менеджмент

Риск деградации технического грейда#

Проблема: Тимлид, долго управляющий большой командой (5+ человек, 3+ лет), теряет техническую глубину.

Признаки деградации:

• Code review поверхностный (не ловит архитектурные проблемы)
• Технические решения полностью делегированы
• Не может самостоятельно решить сложную техническую задачу
• Отстал от технологического стека (.NET, C#, новые фичи)

Превентивные меры:

1. Технический минимум: 20% времени на код для любого размера команды

   • Архитектурно-значимые участки
   • Критичные компоненты
   • Не только code review

2. Ежегодная верификация: На калибровке проверяем сохранение технического грейда

   • Примеры технических решений за год
   • Участие в сложных проблемах
   • Актуальность знаний

3. Честная коммуникация: Если грейд не соответствует — обсуждаем:

   • Downgrade технического грейда (с сохранением управленческой надбавки)
   • Возврат к меньшей команде (2-3 человека) для восстановления
   • Переход в чистый Engineering Manager трек

Правило 8+: При команде 8+ человек:

• Обязателен вложенный тимлид/техлид
• Или переход к EM-структуре (без требования к техническому коду)
• Или разделение команды

Важно: Тимлид продолжает быть техническим экспертом и не может полностью уйти от кода. Но ожидания должны быть реалистичными относительно размера команды.

Оптимизация нагрузки на people management#

Проблема: При команде 7+ человек нагрузка на people processes может достигать 10-12 часов в неделю, что создает конфликт с техническими обязанностями.

Buddy система и делегирование#

Senior как buddy для Junior:

• Senior (позиция 11+) назначается наставником для 1-2 Junior
• Берет на себя: ежедневную помощь, code review, первичные консультации, техническую часть onboarding
• Тимлид сохраняет: 1-on-1 (реже), карьерные беседы, оценку performance

Peer mentoring (Middle -> Junior):

• Middle менторит Junior в рамках конкретных проектов
• Помогает с code review и техническим обучением
• Тимлид координирует и контролирует качество

Различия buddy и peer mentoring#

Buddy-система не заменяет, а дополняет peer mentoring. Junior может иметь одного buddy и нескольких peer mentors на разных проектах.

Пример распределения для команды 8 человек:

Тимлид (позиция 11+):
├── Senior A (buddy для Junior 1, Junior 2)
├── Senior B (buddy для Junior 3)
├── Middle A (peer mentor для Junior 1 на проекте X)
├── Middle B
├── Middle C
├── Junior 1
├── Junior 2
└── Junior 3

Экономия времени тимлида:
- 1-on-1 с Junior: раз в 2 недели вместо еженедельно
- Code review Junior: делегировано buddy
- Техническая помощь Junior: делегировано buddy/peer mentor

Реалистичные временные ожидания#

Красные флаги перегрузки:

• Регулярные пропуски 1-on-1
• Дневники достижений не обновляются
• Карьерные беседы откладываются на месяцы
• Burnout, падение качества кода

При появлении красных флагов:

1. Обсудить с Head of Department
2. Внедрить buddy систему
3. Рассмотреть разделение команды или вложенного TL
4. Приоритизировать: 1-on-1 > карьерные беседы > 360°

Размер команды#

Переход на роль Тимлида#

Требования:

1. Техническая позиция минимум 07
2. Демонстрация лидерских качеств
3. Желание заниматься менеджментом
4. Успешное прохождение пробного периода (3-6 месяцев)

Процесс:

1. Обсуждение карьерных планов с руководителем
2. Демонстрация базовых управленческих компетенций (менторинг, лидерство в проектах)
3. Пробный период: ведение 2-3 человек с поддержкой руководителя
4. Оценка управленческих компетенций
5. Формальное назначение на роль Тимлида

Возврат с роли Тимлида#

Переход обратно на чисто техническую роль возможен и не считается понижением:

• Технический грейд сохраняется
• Теряется управленческая надбавка
• Можно вернуться к роли Individual Contributor (IC)
• Опыт управления ценится и для IC роли

Причины возврата:

• Понимание, что менеджмент не подходит
• Желание сфокусироваться на технической экспертизе
• Личные обстоятельства

Развитие управленческих компетенций#

Для перехода на роль Тимлида:#

1. Покажите лидерство:

   • Ведите проекты
   • Менторьте младших коллег
   • Помогайте в организации работы команды

2. Развивайте soft skills:

   • Коммуникация и презентации
   • Решение конфликтов
   • Эмпатия и эмоциональный интеллект
   • Давание обратной связи

3. Изучайте менеджмент:

   • Читайте книги по менеджменту
   • Проходите курсы
   • Общайтесь с действующими тимлидами

4. Обсудите с руководителем:

   • Ваше желание стать тимлидом
   • План развития управленческих компетенций
   • Возможности попробовать управление

Для роста как Тимлида:#

1. Постоянное развитие:

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

2. Фокус на результатах:

   • Развитие команды (рост позиций членов команды)
   • Delivery (выполнение планов, качество)
   • Здоровье команды (настроение, текучесть)

3. Расширение влияния:

   • От управления задачами к управлению проектами
   • От координации к стратегии
   • От своей команды к нескольким командам

Оценка Тимлида#

Тимлид оценивается по двум измерениям:

1. Технические компетенции#

Оцениваются по стандартной матрице разработчика/тестировщика (см. соответствующие файлы).

2. Управленческие компетенции#

Оцениваются по 4 областям из данной матрицы:

• Управление командой
• Техническое лидерство
• Процессы и планирование
• Коммуникация с бизнесом

Показатели успешности:#

Команда:

• ✅ Настроение команды (оценка удовлетворенности)
• ✅ Текучесть команды (удержание)
• ✅ Развитие членов команды (рост позиций)
• ✅ Качество найма

Delivery:

• ✅ Выполнение планов (цели спринта, обязательства)
• ✅ Качество работы (bugs, технический долг)
• ✅ Скорость работы команды
• ✅ Время выхода на рынок

Влияние:

• ✅ Impact на продукт и бизнес
• ✅ Улучшение процессов
• ✅ Техническое качество
• ✅ Развитие культуры

Зарплатная модель для Тимлида#

Зарплата Тимлида = Базовая зарплата технической позиции + Управленческая надбавка (фиксированная)

Часто задаваемые вопросы#

Q: Могу ли я быть тимлидом с позицией Junior? A: Нет, минимальная техническая позиция — 07 (Middle).

Q: Что важнее для тимлида - технические или управленческие навыки? A: Оба одинаково важны. Тимлид должен быть сильным технически И хорошим менеджером. Баланс примерно 50/50.

Q: Если я стану тимлидом, смогу ли я потом вернуться к чисто технической роли? A: Да, это абсолютно нормально. Техническая позиция сохраняется, теряется только управленческая надбавка.

Q: Как я могу показать, что готов стать тимлидом? A: Начните с менторинга, ведения небольших проектов, помощи в организации работы команды. Обсудите планы с руководителем.

Q: Тимлид QA команды - это тот же уровень, что и тимлид разработчиков? A: Да, управленческие компетенции одинаковые, независимо от технического направления команды.

Q: Может ли Senior разработчик быть тимлидом Middle разработчиков? A: Да, это нормальная ситуация. Важно, чтобы тимлид был технически сильнее или на уровне большинства команды.

Q: Сколько времени тимлид должен писать код? A: Зависит от размера команды: 2-4 человека — 50-60%, 5-6 человек — 40-50%, 7-8 человек — 30-40%. Но код всегда должен оставаться частью работы.

Q: Что делать если нет кандидатов на тимлида, а команда растёт? A: Несколько вариантов:

1. Временное увеличение нагрузки на текущего TL с планом выращивания преемника (макс. 6 месяцев)
2. Внешний найм тимлида (риск: адаптация, незнание продукта)
3. Разделение команды на две меньшие с одним TL на обе (50% времени на каждую)
4. «Играющий тренер»: Senior берёт часть TL-обязанностей без формального назначения (tech lead)

Не рекомендуется: давать начинающему TL команду сильно больше «максимального размера» — это путь к burnout.

Примечание: Данная матрица описывает ожидания от роли Тимлида. Конкретные обязанности могут варьироваться в зависимости от размера команды, проектов и контекста компании.