Кто владеет архитектурой, когда приходит первый инженерный менеджер?

Почему это быстро становится хаотичным

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

Звучит аккуратно. Внутри небольшой команды это редко так и ощущается.

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

Именно поэтому вопрос «кто владеет архитектурой» так быстро запутывается. Архитектура — это не только диаграммы или личный вкус. Она влияет на сроки, найм, объём продукта, расходы в облаке, нагрузку поддержки и насколько болезненным будет следующий релиз. Инженерный менеджер отвечает за доставку. Старший инженер защищает систему. Основатель по‑прежнему чувствует ответственность за итог. Все трое смотрят на одно и то же решение с разных сторон.

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

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

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

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

Что на самом деле включает владение архитектурой

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

Тот, кто владеет архитектурой, должен принимать решения о стеке, основных сервисах и шаблонах, которым команда будет следовать. Это включает выбор: монолит или микросервисы, Postgres или нишевая БД, очереди или прямые вызовы, и действительно ли новый инструмент решает реальную проблему или просто добавляет подвижных частей.

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

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

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

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

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

Где должно заканчиваться управление людьми

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

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

Это не значит, что он должен выбирать базу данных, утверждать каждую границу сервиса или отменять техлида потому что дизайн «кажется проще». Если менеджер хочет другой подход, ему стоит попросить объяснить компромиссы простым языком: что станет быстрее, что станет рискованнее, что сломается через полгода? Такой вопрос помогает. Диктовать ответ обычно не помогает.

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

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

Ещё один простой тест: если вопрос «Кто это сделает, к какому сроку и с какой поддержкой?» — отвечает менеджер. Если вопрос «Как должна себя вести система и почему?» — отвечает техлид. Если никто не может точно сказать, к какому типу вопроса относится обсуждение, обычно отсюда и начинаются споры.

Где лидерство по техчасти должно вести

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

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

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

Хороший техлид также объясняет компромиссы простыми словами: «Это будет стоить дороже каждый месяц, но даст более безопасные релизы.» «Это быстрее построить сейчас, но менять позже будет больно.» «Это снижает риск, потому что меньше частей может упасть.» Людям не нужна лекция по архитектуре. Им нужна понятная причина выбора.

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

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

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

Запишите права принятия решений на одной странице

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

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

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

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

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

Держите страницу простой. Вам не нужен меморандум. Нужен ясный ответ до того, как следующий спор начнётся в планировании, перейдёт в Slack и вернётся после инцидента.

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

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

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

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

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

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

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

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

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

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

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

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

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

Обычно это и есть начало утраты доверия. Техлид думает, что дизайн всё ещё его. Менеджер считает, что ответственность за команду даёт ему право утверждать дизайн. Если оба могут сказ��ть «нет», команда не получает ясности. Она получает политику.

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

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

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

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

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

Самая распространённая ошибка — воспринимать архитектуру как статус. Это не награда за старшинство или менеджерский титул. Это работа. Кто‑то должен принимать компромиссы, ясно их объяснять и нести ответственность за результат после запуска.

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

Быстрая проверка перед каждым крупным решением

Самый быстрый способ уладить «кто владеет архитектурой» — перестать обсуждать владение в абстрактной плоскости и вынудить каждое крупное решение быть зафиксированным в краткой записи. Пять минут письма могут сэкономить две недели расплывчатых споров.

Начните с проблемы, а не с предложенного решения. Опишите её простым языком с одним конкретным симптомом. «Деплой занимает 35 минут и блокирует срочные исправления» — ясно. «Наш стек нуждается в улучшении» — слишком расплывчато.

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

После этого укажите, кто должен дать вводные до решения. Держите эту группу маленькой. Продукт должен сказать своё, если есть влияние на клиентов. Операции должны высказаться, если изменится аптайм или on‑call. Инженер, который будет поддерживать код, тоже должен быть услышан. Вводные важны, но вводные — не вето.

Поставьте дедлайн. Команды плывут по течению, если не знают, исследуют ли они ещё или уже выбирают. Настоящий дедлайн может быть простым: «Решить к четвергу после разбора инцидента» или «Выбрать до планирования спринта». Дата должна соответствовать бизнес‑давлению, а не чьему‑то настроению.

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

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

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

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

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

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

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

Простой шаблон помогает: опишите решение, кто решает, кто даёт вводные, какой дедлайн и когда команда пересмотрит выбор.

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

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

Иногда внешний взгляд достаточно быстр для урегулирования ситуации. Oleg Sotnikov at oleg.is работает со стартапами по вопросам владения архитектурой, границ основателя и поддержке Fractional CTO, когда эти линии ещё формируются.