Оргструктура стартапа для нового CTO в первые 30 дней

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

Новый CTO часто попадает в команду, где оргструктура на бумаге говорит одно, а ежедневная работа — совсем другое. Фаундер пишет инженеру с просьбой от клиента. Sales обещает кастомную доработку, чтобы удержать сделку. Product просит другое изменение, потому что дорожная карта уже сдвинулась. У одного человека теперь три начальника, и ни один из них не согласен с другим.

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

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

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

Уже в первую неделю обычно видны несколько признаков:

• Инженеры получают задачи из Slack, по email и в разговорах в коридоре вместо одного общего потока.
• У одной и той же функции два разных дедлайна — в зависимости от того, у кого спросить.
• Sales говорит клиентам «да» ещё до того, как product или engineering оценили работу.
• Фаундеры пропускают тимлидов и идут прямо к отдельным инженерам.
• Люди чаще одного раза говорят: «Я думал, это твоя зона ответственности».

Startup org chart не может быть просто списком должностей. Он должен совпадать с тем, как работа попадает в команду, кто может менять приоритеты и кто принимает итоговое решение, когда запросы сталкиваются. Если этого нет, новый CTO первую неделю не ведёт команду, а тушит пожары.

За что должна отвечать каждая роль

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

Для большинства ранних команд разделение довольно простое. Фаундер или CEO отвечает за цели компании, бюджет и крупные ставки. Он может оспаривать приоритеты, но не должен переписывать спринт в чате. Product lead отвечает за дорожную карту и повседневные продуктовые решения. CTO или engineering lead отвечает за архитектуру, технические стандарты, реакцию на инциденты и за то, как строится продукт. Найм на технические роли тоже должен иметь одного понятного владельца, даже если фаундеры тоже участвуют в собеседованиях. Объём спринта требует такой же ясности. В совсем маленькой команде product lead или CTO может фиксировать неделю, но всем должно быть понятно, кто принял это решение.

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

Когда маленькие команды совмещают роли

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

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

Одно простое правило помогает: один владелец для дорожной карты, один владелец для объёма спринта, один владелец для архитектуры и один владелец для инцидентов. Имена могут повторяться. Ответственность — нет.

Как переделать оргструктуру за две недели

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

Начните с коротких встреч, а не с длинных воркшопов. Сядьте с фаундерами, product lead, engineering lead и человеком, который держит операционную работу в движении. Каждый раз задавайте одни и те же вопросы: какие решения возникают каждую неделю, кто принимает их сейчас, кого подключают слишком поздно и где работа тормозит.

Паттерны проявляются быстро. Фаундер всё ещё может утверждать изменения в дорожной карте через личные сообщения. Engineering может отвечать за деплой, а operations — по-прежнему контролировать доступ. Product может писать спецификации, а sales — менять приоритеты после разговоров с клиентами.

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

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

Хорошая startup org chart помещается на одну страницу. В ней должно быть видно:

• каждый человек по имени и роли
• кому он подчиняется
• какие решения он принимает
• на каких встречах эта ответственность особенно важна

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

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

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

Как закрыть обходные каналы фаундера

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

Фаундеры по-прежнему должны влиять на продукт. Просто им нужен один вход. Выберите одного product owner, или одного фаундера, если команда совсем маленькая, и сделайте его единственным маршрутом для продуктовых запросов, изменения приоритетов и идей, идущих от клиентов. Инженеры могут спрашивать фаундеров о контексте, но не должны брать задачи напрямую из Slack, email или личных сообщений.

Сначала это кажется жёстким. К концу второй недели обычно воспринимается как облегчение.

Достаточно короткого набора правил:

• Фаундеры отправляют каждый новый запрос одному product owner.
• Инженеры на прямые просьбы о задаче отвечают: «Пожалуйста, отправьте это через product owner, чтобы мы могли правильно поставить это в очередь».
• Только один назначенный человек может утверждать срочные исключения.
• «Срочно» — это риск для выручки, риск безопасности, юридический риск или production problem, который уже влияет на пользователей.

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

Фаундерам также нужен быстрый способ дать обратную связь, не ломая спринт посреди недели. Хорошо работает короткая ежедневная заметка со входящими запросами или 15-минутный блок на ревью. Идеи попадают в систему быстро, команда видит их быстро, а текущий спринт остаётся стабильным, если только назначенный утверждающий не объявит исключение.

Представьте фаундера, который во вторник пишет инженеру: «Можешь просто добавить это поле сегодня?» Инженер не должен спорить. Он перенаправляет запрос, product owner фиксирует его, и команда оценивает влияние до того, как кто-то тронет спринт. Одна такая привычка закрывает большую часть обходных каналов, прежде чем они превращаются в теневое управление.

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

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

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

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

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

Короткий шаблон помогает держать привычку:

• Дата
• Владелец решения
• Что решили
• Что осталось без изменений
• Причина и кто утвердил

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

Для изменений дорожной карты нужна ещё одна строка: какой сигнал от клиента или какая бизнес-цель привели к изменению. Может быть, три trial user попросили SSO. Может быть, activation упал, и команда решила выбрать работу над onboarding вместо новой интеграции. Такой контекст не даёт одному и тому же спору возвращаться каждую пятницу.

Небольшой пример хорошо показывает суть. Команда планирует в этом спринте улучшить onboarding. В середине недели фаундер просит analytics export, потому что он нужен одному prospect. Если команда зафиксирует запрос, владельца, причину и утверждение, все увидят trade-off. Onboarding сдвигается на неделю, export поднимается выше, и выбор привязан к цели продаж. Никакой мистики. Никакого теневого владельца.

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

Представьте стартап из 12 человек: два фаундера, один product manager, шесть инженеров, один дизайнер, один руководитель поддержки и один sales. Небольшие команды часто думают, что могут жить только на доверии и быстрых чатах. На неделю этого хватает. Потом работа начинает съезжать в сторону.

До изменений оба фаундера пишут инженерам в личку. После звонка по продажам появляется обещание, а потом кто-то пишет: «Можешь сегодня это втиснуть?» Product manager ведёт backlog, но половина запросов туда так и не попадает. Инженеры берут работу из личных сообщений, пингов от support и быстрых звонков фаундеров. К пятнице backlog расползается, согласования выглядят случайными, и никто не может объяснить, почему запланированная работа сдвинулась.

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

В этой команде фаундеры отвечают за цели компании, бюджет и обещания клиентам выше определённого размера. Product manager отвечает за backlog и порядок запланированной работы. CTO отвечает за технические решения, правила поставки и экстренные исключения. Инженеры берут работу либо из backlog, либо из инцидентов, которые CTO помечает как срочные.

Команда также меняет несколько привычек. Фаундеры перестают назначать работу в личных сообщениях. Если запрос влияет на дорожную карту, его выносят на короткий ежедневный продуктовый triage с product manager и CTO. Если sales нужен feature, salesperson сначала в одном месте фиксирует потребность клиента, срок и влияние на сделку, и только потом команда что-то оценивает.

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

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

Ошибки, которые создают теневых владельцев

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

Одна частая ошибка — назвать лида, хотя реальные решения принимает кто-то другой. Product manager на бумаге владеет дорожной картой, но фаундер меняет приоритеты в чате. Engineering lead отвечает за поставку, но senior engineer решает, что именно реально выйдет. Команда быстро это считывает. Она перестаёт спрашивать у назначенного владельца и начинает следовать за человеком с неформальной властью.

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

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

Команды также создают теневых владельцев, когда меняют ответственного каждый раз, как релиз сдвигается. Релиз пропускает дату — фаундер забирает контроль. Следующий проект задерживается — CTO забирает его обратно. Потом маркетинг тоже получает право голоса, потому что поменялась дата кампании. Это учит команду, что ответственность временная и зависит от того, кого потом будут винить. Люди перестают вести себя как владельцы, потому что ждут, что кто-то другой всё равно всё перехватит.

Тот же вред приносит и размытая оргструктура. Фаундеры часто держат её неясной, потому что команда ещё маленькая и все совмещают много ролей. На первый взгляд это практично, но обычно приводит к переделкам. Маленьким командам нужны более чёткие границы, а не более мягкие.

У вас, скорее всего, есть теневые владельцы, если вы видите такой паттерн:

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

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

Короткий еженедельный чек-лист

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

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

Пять проверок на каждую неделю

• Спросите у каждого члена команды, кто даёт финальное согласование по его текущей работе. Если двое думают, что это они, исправьте это сразу.
• Посмотрите, как фаундеры отправляли запросы на этой неделе. Они должны использовать тот же путь, что и все остальные, а не личные чаты и не прямые сообщения инженерам.
• Возьмите последние три продуктовых изменения и спросите по каждому один вопрос: может ли команда найти, кто запросил изменение, почему оно было важно и кто его утвердил?
• Найдите инженеров, которые брали работу у двух менеджеров в одну и ту же неделю. Обычно это значит, что схема говорит одно, а поведение в реальности — другое.
• Просмотрите все открытые продуктовые вопросы и назначьте одного человека, который их закроет. Общая ответственность звучит вежливо, но она оставляет хвосты.

Это не должна быть длинная встреча. Десяти-пятнадцати минут достаточно, если заметки в порядке. Цель не в том, чтобы спорить о старых решениях. Цель — заметить неясную ответственность, пока её ещё дёшево исправить.

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

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

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

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

Начните с малого. Одностраничная оргструктура работает лучше, чем большая реорганизация, когда новый CTO только учится, как команда устроена на самом деле.

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

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

Первые 30 дней

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

• Запишите схему на одной странице с именами, ролями и прямыми владельцами.
• Назначьте человека, который каждую неделю говорит «да» или «нет» по объёму продукта.
• Перенесите запросы фаундеров в один поток, одну встречу или один документированный канал.
• Фиксируйте продуктовые решения в одном месте, которое команда может проверить.
• Через 30 дней пересмотрите схему и уберите лишние уровни, которые замедляют решения.

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

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

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

Если вам нужен следующий шаг уже сегодня, сделайте одностраничную схему, введите правило для запросов фаундеров и начните журнал решений до следующей sprint planning встречи.