Первый технический советник: кто решает что и когда

Почему эта роль быстро превращается в хаос

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

Первый технический советник может начать с простого запроса: помогите выбрать стек, проверьте дорожную карту и разберитесь с несколькими проблемами в поставке. Через неделю этого же человека уже зовут на ежедневные стендапы, разбор багов, собеседования, разговоры с подрядчиками и вопросы в Slack по мелким решениям. Основателю спокойнее. Команда работает медленнее.

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

Обычно это выглядит так:

Что должен решать ваш советник

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

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

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

Обычно первый технический советник должен отвечать за такие решения:

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

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

Senior-найм требует того же уровня суждения. Ваш советник не должен просто участвовать в собеседованиях и кивать. Он должен сказать: «да, этот человек сможет вести backend-команду» или «нет, этому человеку потребуется слишком много поддержки». Размытый ответ бесполезен.

Умение разруливать тупики — тоже часть работы. Если backend-лид хочет один подход, а product engineer — другой, советник должен выслушать, принять решение и вернуть работу с одним владельцем, одним сроком и одной причиной выбора. Так сохраняется темп, и каждое разногласие не превращается в длинное совещание.

Что должно остаться у основателя и команды

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

Основатель сохраняет за собой рыночные ставки. Это включает то, кому компания продаёт, как она назначает цену и какие обещания даются клиентам. Временный CTO может сказать: «Если вы пообещаете это к следующему месяцу, команде придётся убрать два других сценария». Но основатель всё равно решает, стоит ли такой обмен того.

Product lead отвечает за backlog и выбор объёма внутри продукта. Советник может оспорить приоритеты, указать на скрытую сложность или показать, где команда строит слишком много слишком рано. Но product lead всё равно решает, что поднимается выше, что вырезается и что выпускается в более маленькой версии.

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

Team lead отвечает за «как», когда стандарты уже ясны. Если все согласны со стеком, правилами ревью и уровнем надёжности, лид сервиса или функции должен выбирать детали реализации. Он решает, как будет выглядеть API, как разбить работу на задачи и когда более простой подход уже достаточен.

Небольшой пример хорошо показывает разделение:

• Основатель обещает enterprise SSO, чтобы закрыть сделку.
• Product lead убирает менее приоритетную панель, чтобы освободить место.
• Engineering manager меняет план поставки и распределение людей.
• Team lead решает, что лучше подходит текущей системе: SAML или OIDC.

Такое разделение сохраняет чистую ответственность за решения. Советник может оспаривать, предупреждать и объяснять последствия. Основатель и команда сохраняют контроль над бизнесом, планом и ежедневной работой.

Какие встречи им стоит пропускать

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

Ежедневные статус-звонки — первое, что стоит убрать. Если команда только отчитывается о прогрессе, зачитывает задачи вслух или повторяет обновления, уже написанные в Slack или Jira, советнику там делать нечего. Он может прочитать заметки позже за пять минут.

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

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

Планёрки — ещё одна частая ловушка. Если команда уже согласна по объёму, приоритетам и компромиссам, советнику не нужно сидеть на всём обсуждении. Достаточно передачи: «Мы выбрали вариант B, ожидаем две недели работы, и эта зависимость может сдвинуться».

Советник должен подключаться, когда одна сложная развилка тормозит прогресс. Обычно это значит:

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

Рабочее правило простое: нет решения — нет советника. Перед каждым приглашением задайте один вопрос: «Что именно нам нужно, чтобы этот человек решил?» Если никто не может ответить ясно, уберите его из встречи.

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

Как установить правила принятия решений в первую неделю

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

Сначала выпишите десять решений, которые создают больше всего суеты. Выберите те, из-за которых повторяются споры, пинги в Slack или зависшие задачи. Для большинства стартапов первые пять выглядят знакомо:

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

Продолжайте, пока не дойдёте до десяти. Включите и мелкие раздражающие вещи, потому что мелкие повторяющиеся задержки съедают много времени.

Напротив каждого решения укажите одного владельца. Одно имя, а не «основатель и советник» или «команда». Если архитектурой владеет временный CTO, так и запишите. Если бюджет и найм — у основателя, так и запишите. Если срок релиза определяет инженерный лидер, сделайте это явным.

Затем для каждого пункта обозначьте роль советника. Используйте простые метки: «решает», «даёт input» или «смотрит только если попросят». Именно здесь большинство команд начинает халтурить. Советники должны отвечать за узкий набор решений и не лезть в остальное.

Установите сроки ответа ещё до первой настоящей пожары. Достаточно короткого набора правил:

• срочные вопросы получают быстрый ответ, часто в течение 15 минут на подтверждение и 2 часов на решение
• обычные вопросы получают ответ к следующему рабочему дню
• если владелец не отвечает вовремя, подключается запасной владелец

Принесите список на короткий разбор с основателем и лидерами команды. Спросите только два вопроса: «Мы согласны с владельцем?» и «Мы согласны со сроком ответа?» Если кто-то начинает снова поднимать старые споры, остановите это и вернитесь к списку.

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

Простой пример стартапа

У небольшого софтверного стартапа есть типичная проблема. В billing flow сидит баг, а текущий код запутан. Команда может закрыть дыру за несколько дней или остановиться и перестроить этот кусок продукта в течение следующего месяца.

Здесь первый технический советник должен отвечать за рамку решения, а не за решение всей компании. Он смотрит на компромисс и пишет короткую заметку для основателя и team lead. Текст простой, не в формате презентации: «Патч сейчас: низкая стоимость, быстрый релиз, выше шанс, что мы вернёмся к этому через 6–8 недель. Перестроить сейчас: выше стоимость, медленнее релиз, ниже нагрузка на поддержку после запуска». Такая заметка помогает, потому что превращает расплывчатый спор в ясный выбор.

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

Основатель всё равно отвечает за обещание клиенту. Если клиенты уже ждут исправление к пятнице, именно основатель решает, сохранять ли это обещание, сдвигать ли дату или сужать ли объём. Это решение принадлежит тому, кто несёт бизнес-риск и общается с клиентами.

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

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

Ошибки, которые тратят время впустую

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

Частая ошибка — просить советника утверждать каждый pull request. Это замедляет выпуск и приучает инженеров ждать разрешения. Если баг в checkout небольшой и команда уже отвечает за эту область, мержить должен tech lead. Советник должен вмешиваться только тогда, когда изменение влияет на архитектуру системы, безопасность, стоимость или сложный компромисс, которого команда раньше не видела.

Ещё одна потеря времени — звать советника на встречи только потому, что никто не хочет принимать решение. Это не лидерство. Это задержка с дополнительными приглашениями в календаре. Временный CTO должен участвовать только в тех обсуждениях, где на столе действительно есть выбор, а остальное пропускать.

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

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

Последняя ошибка — менять роль каждый месяц. Если советник сначала отвечает за стандарты найма, а потом его втягивают в планирование sprint'ов, разговоры с подрядчиками и продуктовые споры, команда перестаёт понимать, кто за что отвечает. Держите роль стабильной достаточно долго, чтобы люди успели ей доверять.

Если вам нужен советник на каждом code review, на каждой планёрке и в каждом продуктовом споре, проблема обычно не в советнике. Проблема в том, что внутри команды всё ещё нет ясной ответственности за решения.

Быстрая еженедельная проверка

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

Используйте каждую неделю одни и те же пять вопросов:

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

Первый вопрос важен, потому что технический долг очень быстро размывается. Если один инженер говорит, что за него отвечает советник, другой — что основатель, а никто точно не знает, это не делегирование. Это расползание ответственности. Назначьте одного окончательного владельца, а остальные пусть дают input.

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

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

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

Записывайте каждое открытое решение в одном месте до конца недели. Одной строки на пункт достаточно: решение, владелец, срок. В понедельник команда должна понимать, что уже решено, что ещё открыто и кто говорит последним.

Что делать дальше

До найма кого-либо запишите решения, которые всё время застревают. Уместите это на одной странице. Если выбор влияет на архитектуру, безопасность, риск поставки, выбор подрядчика или найм на senior-технические роли, укажите, кто принимает решение. Если выбор касается приоритетов клиентов, бюджета или направления компании, оставьте его за основателем или team lead.

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

Короткий пробный период работает лучше, чем размытое долгосрочное соглашение. Попробуйте роль на 30 дней и следите, куда уходит время. Вам не нужна сложная система. Достаточно короткой заметки после каждого звонка: решение принято, встреча проведена, блокер снят или работа возвращена команде.

За этот месяц проверьте четыре вещи:

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

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

Хороший временный CTO не должен становиться запасным менеджером на каждый открытый вопрос. Он должен вмешиваться там, где ошибки стоят дорого, принимать решение, объяснять почему и оставлять команду с понятным путём. В этом разница между полезной ответственностью за решения и бесконечной консультационной болтовнёй.

Если вам нужна внешняя помощь в настройке этого процесса, Oleg Sotnikov может подключиться как временный CTO и помочь определить, кто за что отвечает, где проходят границы встреч и как делать чистые передачи работы, не забирая команду под себя. Начните с карты на одной странице, проведите 30-дневный тест и оценивайте роль по принятым решениям, а не по количеству высказанных идей.