Вопросы на собеседовании: Технический директор

Я бы сначала прояснил владение по чётким доменам, а не трогал хедкаунт, ведь дублирование обычно проблема структуры.

• Я бы за первый месяц привязал каждый сервис к одной владеющей команде и названному ответственному менеджеру.
• Я бы свёл три пересекающихся усилия в одну платформенную команду, а остальных перенаправил на продуктовую работу.
• Я бы опубликовал устав команд и каталог сервисов, чтобы владение было видимым и не расползалось обратно.

Я бы выровнял границы команд и квартальные цели по исходам, на которые ставит бизнес, а не по легаси-системам.

• Я бы выделил две-три ключевые бизнес-ставки и укомплектовал команду или группу, явно отвечающую за каждую.
• Я бы выразил мандат каждой команды как исход, вроде снижения отвала на оплате, а не список тикетов.
• Я бы пересматривал структуру каждый цикл планирования, чтобы она следовала за стратегией по мере смены ставок.

Я веду организацию на предсказуемом ритме планирования, обзоров и расшивки блокеров, чтобы решения не зависели от моего присутствия в каждой комнате.

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

Я бы отнёсся к этому как к системному пробелу и выстроил регулярные честные каналы, а не разовый all-hands.

• Я бы проводил ежемесячный апдейт организации, где делюсь решением, его логикой и тем, от чего мы отказались.
• Я бы фиксировал решения в долговечном месте, чтобы контекст переживал встречу.
• Я бы открыл skip-level 1:1 и письменный канал вопросов, чтобы слышать, где сообщение не доходит.

Я централизую то, что общее, высоко-рычажное и дорого дублировать, а продуктовую специфику оставляю командам, которые к ней ближе всего.

• Я переношу общие заботы вроде CI/CD, наблюдаемости и аутентификации в платформенную команду, чтобы все перестали изобретать их заново.
• Я оставляю доменную логику и продуктовые эксперименты в продуктовых командах, сохраняя их скорость и владение.
• Я отношусь к платформе как к внутреннему продукту со своими пользователями и метриками принятия, а не как к директиве.

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

• Я бы набросал три-четыре принципа, привязанных к настоящим компромиссам, вроде выбора обратимых решений вместо аналитического паралича.
• Я бы встроил их в нормы код-ревью, разборы инцидентов и критерии промоушена, чтобы они меняли поведение.
• Я бы пересматривал их, когда они перестают отражать то, как здесь реально работают сильные инженеры.

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

• Я читаю дизайн-доки и разборы инцидентов и участвую в архитектурных обсуждениях, чтобы держать модель актуальной.
• Я задаю острые вопросы и даю стафф-инженерам владеть ответами, а не переопределяю их.
• Я зарабатываю авторитет качеством решений и инженерами, которых развиваю, а не тем, что кого-то перекодирую.

Я бы представил сбалансированную картину поставки, качества, людей и стоимости, а не одну тщеславную цифру.

• Я бы показал предсказуемость поставки и метрики DORA вроде частоты деплоев и доли неудачных изменений.
• Я бы показал надёжность относительно SLO, тренды инцидентов и состояние критического техдолга.
• Я бы показал текучесть, здоровье пайплайна найма и стоимость на исход, чтобы люди и деньги были в одном виде.

Я делаю компромисс явным и заложенным в бюджет, а не даю долгосрочному здоровью тихо голодать.

• Я резервирую постоянную долю мощности, часто около 15-20 процентов, под надёжность и техдолг.
• Я делаю цену срезанных углов видимой продукту и руководству, чтобы выбор в пользу дедлайна был осознанным, а не скрытым.
• Я отслеживаю опережающие индикаторы вроде времени сборки и частоты инцидентов, чтобы деградация всплывала до кризиса.

Я слежу за сигналами, что стоимость координации растёт быстрее выпуска, и реорганизую осознанно, а не реактивно.

• Я смотрю на хронические кросс-командные зависимости, замедление поставки и решения, требующие слишком многих людей.
• Я проверяю, не стали ли зоны ответственности менеджеров слишком широкими и не ушли ли команды от исходного мандата.
• Я реорганизую вокруг ясного тезиса и объясняю зачем, ведь реорг без причины разрушает доверие.

Я бы масштабировал менеджмент и процессы с опережением хедкаунта, чтобы рост не обогнал способность организации его переварить.

• Я бы сначала нанял и развил слой менеджеров и стафф-инженеров, ведь команда без лидеров будет буксовать.
• Я бы усилил онбординг, чтобы новички выходили на продуктивность за недели, а не месяцы, при таком темпе.
• Я бы рос стабильными командными юнитами, а не разбрасывал найм, и притормозил бы, если качество найма падает.

Я стремлюсь к командам примерно из шести-восьми человек и менеджерам с пятью-восемью подчинёнными, корректируя на сеньорность.

• Команды около шести-восьми остаются сплочёнными и владеют ясным доменом без тяжёлых накладных на координацию.
• Менеджер с пятью-восемью подчинёнными успевает реальные 1:1 и коучинг; сверх этого работа с людьми деградирует.
• Я расширяю нормы для сеньорных автономных команд и сужаю там, где людям нужно больше развития.

Я борюсь с координационным налогом, который приходит с ростом, держа команды автономными, а зависимости редкими.

• Я проектирую границы команд так, чтобы большинство работы отгружалось без ожидания других команд.
• Я вкладываюсь в платформу и тулинг, чтобы общие возможности были self-serve, а не очередью тикетов.
• Я слежу за cycle time и числом зависимостей, трактуя рост как проблему дизайна, а не как данность размера.

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

• Я бы нашёл, где кодовая база и ответственности уже расходятся, и провёл границу там.
• Я бы дал каждой новой команде ясный мандат, владельца и сеньорных инженеров, чтобы она была самодостаточной.
• Я бы явно определил интерфейсы между ними, чтобы разделение снижало координацию, а не прятало её.

Я задаю общие стандарты и ограничители, оставляя командам свободу внутри них, чтобы автономия не означала хаос.

• Я определяю несколько неоспоримых базовых требований вроде безопасности, тестирования и наблюдаемости, которые выполняет каждая команда.
• Я использую лёгкие механизмы вроде архитектурного ревью и платформы-мощёного-пути, чтобы распространять хорошие дефолты.
• Я даю командам выбирать внутри ограничителей, ведь навязанное единообразие убивает скорость, которую даёт автономия.

Я делаю онбординг спроектированной системой с ясными вехами, а не опытом "выплыви сам", который зависит от менеджера.

• Я задаю структурированный план 30-60-90 с первым осмысленным коммитом на первой неделе.
• Я назначаю бадди по онбордингу и держу поддерживаемый, проверенный гайд для старта и dev-окружение.
• Я измеряю время до первого PR и время до продуктивности, чтобы видеть, когда онбординг деградирует под нагрузкой.

Я проектирую под асинхронную работу и ясное владение, чтобы расстояние не становилось налогом на каждое решение.

• Я по умолчанию фиксирую решения письменно и в доках, чтобы работа не застревала в ожидании общего времени встречи.
• Я по возможности собираю команды внутри одного часового пояса, чтобы ежедневная работа оставалась синхронной.
• Я задаю явные нормы по времени ответа, передаче дежурств и часам пересечения, чтобы ожидания были общими.

Я делаю культуру явной и переносимой многими лидерами, а не надеюсь, что она передастся сама собой.

• Я записываю поведения, которые заставляли команду работать, и подкрепляю их в онбординге и ревью.
• Я продвигаю и нанимаю менеджеров, которые воплощают культуру, ведь культура масштабируется через лидеров, а не меморандумы.
• Я слежу за сигналами вроде падения качества код-ревью или размывания безвинности и правлю рано.

Я покупаю недифференцирующие возможности и строю только там, где это ключевое или ни один вендор не подходит нашему масштабу.

• Я покупаю commodity-тулинг вроде CI-раннеров или мониторинга, ведь их поддержка редко окупается.
• Я строю платформенный слой там, где наши воркфлоу, масштаб или потребности интеграции делают коробочное решение плохо подходящим.
• Я взвешиваю полную стоимость, включая команду на эксплуатацию, а не только лицензию, до решения строить.

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

• Я определяю, как выглядит каждый уровень и что такое сильный сигнал, чтобы интервьюеры судили по рубрике.
• Я обучаю интервьюеров, провожу калибровки и использую хайринг-комитет, чтобы решения были согласованными.
• Я отслеживаю долю прошедших и пост-найм результаты, чтобы видеть дрейф планки и корректировать её.