Как руководить командой и не растерять hard’ы?
Практическая статья с советами и техниками
Автор — Александр Пряхин
Технический руководитель Авито Подработка
Роль TeamLead часто воспринимается людьми как полный переход от кодинга ко встречам и отчетам, но это вовсе не приговор технической экспертизе. Тимлид вполне может сохранять глубокое понимание технологий, не тратя часы на ежедневный код.
Конечно же, серебряной пули тут не существует. Без практики технические навыки со временем слабеют. Теряется видение паттернов архитектуры, нюансов масштабирования или выбора стека. С другой стороны исследования показывают, что лиды с техническим бекграундом лучше управляют командами.
Конечно же, серебряной пули тут не существует. Без практики технические навыки со временем слабеют. Теряется видение паттернов архитектуры, нюансов масштабирования или выбора стека. С другой стороны исследования показывают, что лиды с техническим бекграундом лучше управляют командами.
Как же тогда продолжать эффективно работать, уделяя достаточно времени менеджменту, но не теряя скилов?
Решением тут может стать структурированный подход к делегированию рутины и фокус на высокоуровневые задачи.
System design как основной инструмент
Одним из основных инструментов тимлида в данном случае становится System design. Но уже не с интервью, а в прикладном виде. Очевидно, что программирование на ежедневной основе будет занимать много времени, не совместимого с работой менеджера.
Вместо кодинга регулярно проводите 1−2 сессии в неделю по проектированию систем.
Event Storming и работа с архитектурой
Хорошим подходом тут может стать Event storming. Он ускоряет переход от хаотичных требований к четкой модели: выявляет события, команды, агрегаты и bounded contexts для DDD. Его можно использовать как на старте проекта, так и для рефакторинга или анализа систем.
Проводится такая сессия на стене или Miro-доске с привлечением разработчиков, Product Owners, архитекторов. Более подробно можно почитать об этом процессе в книге Альберто Брандолини «Introducing EventStorming».
Проводится такая сессия на стене или Miro-доске с привлечением разработчиков, Product Owners, архитекторов. Более подробно можно почитать об этом процессе в книге Альберто Брандолини «Introducing EventStorming».
Если опыта работы с Event Storming пока нет, то просто регулярно разбирайте части системы:
- Делайте whiteboard-сессии с командой: разберите работу какого-либо модуля в системе
- Пробуйте архитектурные каты: например, «архитектура чат-системы как в Telegram»
В таком случае лид не кодит фичи, но ведет system design для новых частей системы. Этим он и развивает понимание системы, и держит экспертизу на уровне principal engineer.
Делегирование с менторством
Еще один инструмент — это делегирование. Но не в формате «свалил на junior», а передача с менторством.
Ваша задача задать архитектурный фреймворк, который команда имплементирует:
Ваша задача задать архитектурный фреймворк, который команда имплементирует:
- Задача → кто делает → ваш вклад
- Написание CRUD → Middle dev → Архитектура (схемы БД, API-контракты)
- Оптимизация → Senior → проектирование нагрузочного теста
- Деплой → DevOps → Code review архитектуры
Так вы остаетесь в курсе стека, но не тонете в аспектах.
Тайм-боксинг для программирования в небольших командах
Если у Вас есть не очень большая команда (до 4 человек), то можно позволить себе выделять время на программирование. Но к этому стоит подходить уже не как к основной работе, а как к сопутствующей.
Таймбоксинг спасает от спорадического программирования и кодинга до ночи.
Выделите фиксированные слоты:
Таймбоксинг спасает от спорадического программирования и кодинга до ночи.
Выделите фиксированные слоты:
- Утро, 2 часа: исследовательские задачи (прототип новой фичи)
- Пятница 16:00: 1 час на неключевой проект
- Итого: 8−10h кодинга в неделю вполне достаточно для того, чтобы сохранять погруженность
Важно понимать, что нельзя брать в работу ключевые задачи в команде. Если вас отправят на долгие встречи с бизнесом, где очевидно не получится программировать, то вы не заблокируете достижение целей командой.
Применяйте календарь с блокерами. В BigTech компаниях это вполне норма — лиды кодят не более 20−30% времени.
Код-ревью как источник информации
Еще один хороший вариант — это регулярный код ревью. Но смотрите, на что тратите время:
- Архитектурно значимые PR (миграции, новые сервисы)
- Рандом 10% от команды — ловите паттерны ошибок
- Фидбек в стиле «почему этот дизайн не масштабируется?»
Так Вы будете в курсе реального кода без ежедневной разработки.
Метрики для контроля нагрузки и роста
Выделяя свой ресурс на технические задачи, отслеживайте метрики, чтобы экспертиза росла без ущерба основной работе. Ведь вас наняли как менеджера, а не как программиста:
- Метрика → Target
- PR с вашим кодом → 3−5 штук/мес
- System design сессии → 4 сессии/мес
- Время на код+ревью → <20%
- Архитектурные decisions → 2/спринт
Совет в заключение
Сохранить экспертизу, будучи Тимлидом, реально. Главное — работать по плану и с дисциплиной.
Начните с аудита своего времени. Сколько реально уходит на технические задачи? Попробуйте уйти от кодинга, но добавьте регулярные сессии system design, и уже через месяц почувствуете разницу.
Начните с аудита своего времени. Сколько реально уходит на технические задачи? Попробуйте уйти от кодинга, но добавьте регулярные сессии system design, и уже через месяц почувствуете разницу.
Другие статьи