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

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

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

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

• Всё, что действительно часть нашего рва, например проприетарное преимущество в данных или ощутимая клиентом скорость, мы строим и глубоко им владеем.
• Всё, что нужно каждой компании, но не вознаграждается клиентом, например аутентификация, биллинговая обвязка или observability, мы покупаем или берём open source и отказываемся вылизывать до блеска.
• Дисциплина в том, чтобы пересматривать эту границу ежегодно, потому что сегодняшнее отличие становится завтрашним commodity, как только рынок догоняет.

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

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

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

• Если мы продаём в enterprise, дорожная карта рано приоритизирует сертификации по безопасности, SSO и аудит-логи, потому что они закрывают сделки дороже любой фичи.
• Если мы product-led и self-serve, я вкладываюсь в онбординг, надёжность и юнит-экономику, потому что виральное движение снизу вверх умирает от трения и плохой валовой маржи.
• Провал, который я видел, это изящная платформа, игнорирующая то, как компания реально зарабатывает, поэтому я делаю CRO и CFO совладельцами приоритетов, касающихся выручки.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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