Парадокс технического руководителя: как оставаться техническим специалистом, руководя командой
Вас повысили. Поздравляем! Теперь вы технический руководитель. Ваше звание выглядит лучше в LinkedIn, зарплата увеличилась, и вдруг все смотрят на вас в ожидании «технического руководства».
Затем, примерно через три недели, вы понимаете, что утопаете в совещаниях. Стендапы, синхронизации, обзоры архитектуры, обновления для заинтересованных сторон, планерки и какие-то «совещания по согласованию», которые никто толком не может определить. Между 9 утра и полуднем вы посетили четыре видеозвонка и не написали ни одной строки кода. Ваша IDE стала декоративным окном на рабочем столе.
Добро пожаловать в парадокс технического руководителя: чем больше полномочий вы получаете, тем легче потерять то, что сделало вас достойным этой роли — техническое мастерство.
Крутая ирония в том, что большинство технических руководителей попадают в эту ловушку не из-за злого умысла или неумелого управления, а из-за добрых намерений. Кто-то должен посетить это архитектурное совещание? Вы технический руководитель, конечно, вы должны. У инженеров есть вопросы по проектированию системы? Это буквально ваша работа. Заинтересованной стороне нужен технический контекст? Кто ещё объяснит это?
Но вот в чём дело: если вы не пишете код, не просматриваете PR и не участвуете в технических решениях, вы больше не технический руководитель. Вы случайно стали менеджером по проведению совещаний с техническим названием.
Давайте это исправим.
Понимание того, кто вы на самом деле (а кто вы не)
Прежде чем мы поговорим о том, как оставаться техническим специалистом, давайте будем предельно честными в отношении того, чем на самом деле занимается технический руководитель — и чем он не должен заниматься.
Технический руководитель это:
- авторитет в области технической архитектуры и проектных решений вашей команды;
- активный участник, который пишет код вместе с командой;
- тот, кто просматривает код и даёт технические отзывы;
- человек, который помогает инженерам продумать сложные технические задачи;
- коммуникатор, который переводит между техническим и бизнес-контекстами;
- тот, кто сообщает о технических рисках и всплесках.
Технический руководитель НЕ:
- менеджер проектов, отслеживающий диаграммы Ганта и темпы сгорания;
- менеджер по работе с персоналом, занимающийся оценкой эффективности и развитием карьеры (это работа менеджера по разработке);
- тот, кто фиксирует посещаемость стендап-совещаний;
- человек, чей календарь полностью занят совещаниями;
- узкое место для каждого решения, которое должно принадлежать команде.
Различие важно, потому что вас повысили, чтобы руководить технически, а не управлять расписаниями людей. Если вы занимаетесь последним, что-то пошло не так.
Вот практический пример, как это работает на практике:
Технический руководитель должен делать:
├── 60% практической технической работы
│ ├── Написание кода для критических путей
│ ├── Просмотр PR с технической глубиной
│ └── Проектирование архитектурных решений
├── 25% наставничества по техническим вопросам
│ ├── Парная работа с инженерами над сложными задачами
│ ├── Проведение технических обсуждений
│ └── Обмен знаниями и лучшими практиками
└── 15% необходимой коммуникации
├── Критические согласования с заинтересованными сторонами
├── Совещания по обзору архитектуры
└── Координация технических вопросов между командами
Технический руководитель не должен делать:
├── 40% блокировки календаря совещаниями
├── 20% отслеживания проектов и обновлений статуса
├── 15% обязанностей по управлению персоналом
└── 25% разных «просто присутствовать» сессий
Математика проста: если вы тратите более 20% своего времени на совещания по «коммуникационным накладным расходам», ваше техническое участие сокращается. А когда ваше техническое участие сокращается, вы теряете авторитет, способность держаться на плаву и — в конечном итоге — возможность вообще технически руководить.
Ловушка: как вы становитесь менеджером по проведению совещаний
Это происходит постепенно, что делает это таким коварным.
Первая неделя: вы взволнованы. Вы посещаете большинство совещаний, потому что хотите быть вовлечённым и задать тон. Вполне разумно.
Третья неделя: у команды есть вопросы. Вы участвуете в трёх-четырёх совещаниях ежедневно, объясняя архитектурные решения. Всё ещё нормально — это часть работы.
Восьмая неделя: ваш календарь — это игра в «Тетрис». У вас есть время на подготовку к совещаниям в календаре. Вы начали проводить «предварительные встречи» перед фактическими встречами. Вы отвечаете на сообщения в Slack о решениях во время совещаний. Вы не выпустили значимого коммита за две недели, но вы определённо посетили много совещаний по выпуску кода.
Четвёртый месяц: вы понимаете, что не можете вспомнить, когда в последний раз загружали репозиторий и фактически запускали код локально. Вы принимаете технические решения, основываясь на памяти и отчётах, а не на практическом понимании. И как-то, несмотря на все эти совещания, люди всё ещё говорят: «Нам нужно больше коммуникации».
Ловушка не в том, что совещания плохи. Ловушка в том, что они расширяются, чтобы заполнить пространство, которое вы им позволяете занять. Без явных границ и жёсткой приоритизации «необходимая коммуникация» перерождается в «ненужное членство в комитете».
Шаг 1: Жёсткая архитектура календаря (да, вам нужно спланировать своё расписание)
Вы бы не позволили своему кодовому базису стать неуправляемым беспорядком. Так почему же вы позволяете своему календарю стать таким?
Принцип первый: по умолчанию — нет
Каждый запрос на совещание — это по умолчанию «нет», если только он не соответствует этим критериям:
- Требуется ваше техническое решение;
- Это разблокирует кого-то в критической работе;
- Это регулярные согласования, напрямую влияющие на техническое направление вашей команды;
- Вас явно нужно привлечь, чтобы объяснить техническую сложность нетехническим заинтересованным сторонам.
Всё остальное? Делегируйте. Пошлите представителя. Попросите заметки. Мир продолжает вращаться.
Принцип второй: Тематические дни
Это звучит просто, но это преобразует. Выберите определённые дни для определённых видов работ:
Понедельник: технические согласования команды + обзоры архитектуры
(Коммуникационно-насыщенный день, нормально, это понедельник)
Вторник-четверг: глубокая работа + кодирование
(Заблокируйте свой календарь. Установите Slack в режим «в фокусе»)
Пятница: координация между командами + ретроспективная коммуникация
(Догоняйте по сообщениям, асинхронные обсуждения)
Это негибко, и в этом вся суть. Гибкость — это то, как ваш календарь становится заложником приоритетов всех остальных.
Принцип третий: Ограничьте синхронную коммуникацию по времени
У каждого регулярного совещания должно быть ограничение по времени. Не длительность — а ограничение по времени. Это означает:
- Вы планируете с 10:00 до 10:30 утра всю неделю для стендапов и сортировки;
- Ваше совещание по обзору архитектуры — вторник с 14:00 до 15:00, всегда, не переносите;
- У вас есть 30-минутное окно для внеплановых технических вопросов (может быть, с 15:00 до 15:30).
Когда эти окна закрываются, они закрываются. Люди учатся работать в рамках ограничений.
Вот как это выглядит на практике:
# Реальный пример архитектуры еженедельного календаря технического руководителя
Понедельник:
09:00–10:00: встреча один на один с менеджером по разработке (техническое направление)
10:00–11:00: еженедельный стендап команды + обсуждение архитектуры
11:00–12:00: глубокая работа (без совещаний)
13:00–14:00: обзор архитектуры (асинхронно подготовлено, обсуждение только синхронно)
14:00–16:00: глубокая работа
16:00–17:00: межкомандная техническая синхронизация (если нужно)
Вторник:
Весь день: глубокая работа (кроме обеда)
16:00–16:30: внеплановые технические вопросы/парное программирование
Среда:
Весь день: глубокая работа (кроме обеда)
10:30–11:00: обзор и ответ на асинхронные сообщения
Четверг:
Весь день: глубокая работа (кроме обеда)
15:00–16:00: предоставление технического контекста заинтересованным сторонам (запланировано заранее)
Пятница:
09:00–10:00: завершение недели и догоняние по асинхронным сообщениям
10:00–12:00: глубокая работа
13:00–14:00: планирование технических приоритетов на следующую неделю
14:00–17:00: глубокая работа или командный отдых (опционально)
Принципы:
- Понедельник и пятница занимаются коммуникационными накладными расходами
- Вторник-четверг — священные блоки для глубокой работы
- Совещания запланированы, регулярные и ограниченные по времени
- Принятие решений происходит асинхронно, где возможно
Это звучит жёстко, но попробуйте две недели. Вы будете шокированы, сколько «срочных совещаний» на самом деле не были срочными — им просто нужно было произойти когда-нибудь, и никто не заблокировал «когда-