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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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