Техническое направление для инженерных менеджеров: почему команды дрейфуют

Как это выглядит в реальных командах

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

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

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

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

Путаницу обычно видно далеко за пределами кода. Планирование становится расплывчатым, потому что оценки зависят от скрытых рисков. Найм идет тяжело, потому что никто не может объяснить, какой инженер понадобится команде дальше. Повседневная работа становится шумной, потому что одни и те же споры возвращаются в design review, на planning и даже в standup.

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

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

Управление людьми и техническое направление — это разные задачи

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

Техническое направление отвечает на другие вопросы. На чем мы строим продукт? Каких стандартов придерживаемся? Какие компромиссы принимаем? Какой системой мы хотим пользоваться через шесть месяцев?

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

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

Несколько областей находятся прямо посередине:

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

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

На этом этапе команде обычно нужно более четкое лидерство выше менеджера. Иногда это hands-on CTO. Иногда — staff engineer или fractional CTO, который задает направление, пересматривает крупные решения и не дает архитектуре расползаться, пока менеджер фокусируется на людях и поставке.

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

Как начинается архитектурный дрейф

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

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

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

Сигналы тревоги легко пропустить, потому что сначала ничто не выглядит драматично:

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

Код — это только половина истории. Привычки команды тоже смещаются.

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

Вот где отсутствие технического направления особенно болезненно. Менеджер может проводить standup, разбирать нагрузку и давить на поставку, но у него может не быть ясного набора технических правил сверху. Без этого каждая команда решает одну и ту же проблему по-своему.

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

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

Почему это выглядит как проблема менеджмента

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

Поэтому команды часто воспринимают это как проблему людей. Engineering manager просят ужесточить planning, требовать больше апдейтов или сильнее контролировать команду.

Иногда это помогает. Часто — нет.

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

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

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

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

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

Вот в чем дорогая часть. Техническая путаница превращается в эмоциональную нагрузку.

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

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

Простой пример из растущей продуктовой команды

Представьте SaaS-стартап с одним engineering manager и восемью инженерами. Продукт быстро растет, клиенты каждую неделю хотят новые функции, и команда постоянно что-то выпускает. На бумаге все выглядит нормально.

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

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

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

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

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

И вот тогда напряжение становится личным. Backend-инженеры обвиняют product в том, что тот торопит работу. Frontend-инженеры жалуются, что API постоянно меняются. Senior-разработчики раздражаются, потому что снова и снова переписывают одни и те же части. Новым сотрудникам нужны недели, чтобы угадать, какой паттерн на этот раз «правильный».

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

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

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

Кто-то с более широкой властью должен принять небольшой набор решений и удерживать их стабильными. В стартапе это обычно CTO, технический фаундер или fractional CTO.

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

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

Нужен и простой ответ на вопрос ответственности. Кто владеет billing? Кто отвечает за auth? Кто чинит сбой деплоя ночью? Кто может менять общую инфраструктуру? Если ответственность остается размытой, работа встает, потому что все ждут кого-то другого.

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

• скорость или стабильность
• повторное использование или быстрые локальные исправления
• покупка инструментов или собственная разработка
• строгая единообразность или допустимые дубли
• поставка в краткосроке или время на приведение в порядок

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

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

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

Как может действовать engineering manager

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

Лучший ответ — простой и практичный.

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

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

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

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

5. Эскалируйте пробелы заранее. Если команде нужен продуктовый boundary, правило для data model или стандарт платформы, поднимайте это до того, как срыв поставки превратится в поиск виноватых. Такие решения должен принять или поддержать founder, CTO или внешний советник.

Менеджеру не нужны ответы на все вопросы. Но ему нужен видимый список незакрытых вопросов и спокойное давление на тех, кто должен на них ответить.

Ошибки, которые усугубляют разрыв

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

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

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

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

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

Растущая продуктовая команда может выдержать давление. Но она обычно не выдерживает хаотичное давление долго. Кто-то выше команды должен держать устойчивую техническую линию — будь то CTO, founder или fractional CTO, у которого достаточно контекста, чтобы принимать твердые решения.

Быстрая проверка команды

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

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

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

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

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

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

Ни одна здоровая команда не отвечает идеально на каждый вопрос. Это нормально. Важнее общая картина, чем любой отдельный ответ.

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

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

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

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

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

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

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

Для команд, которым нужен такой взгляд со стороны, Oleg Sotnikov на oleg.is работает как fractional CTO и startup advisor, с глубоким опытом в архитектуре продукта, инфраструктуре и AI-first software development. На практике такая поддержка часто означает ревизию codebase и привычек поставки, а затем настройку более компактного набора технических правил, которым команда действительно может следовать.

Сделайте это до того, как потеряется еще один квартал. Чем дольше дрейф остается без внимания, тем труднее и дороже его исправлять.