Как меняется соотношение инженерных менеджеров и разработчиков после внедрения ИИ

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

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

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

ИИ сначала сокращает реализацию, а не работу руководителя

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

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

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

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

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

Соотношение не заменяет операционную модель

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

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

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

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

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

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

Отделите управление людьми от управления потоком поставки

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

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

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

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

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

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

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

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

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

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

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

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

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

Менеджмент снижает координацию, когда отвечает за сложные границы

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

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

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

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

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

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

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

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

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

Decision: Add approval routing for account administrators
Owner: Product lead
Problem: Larger customers need a second review before a workflow goes live
In scope: One configurable approver stage in existing workflows
Out of scope: Role redesign, multi-stage chains, external identity sync
Success condition: An administrator can require one approval and see who approved
Engineering owner: Staff engineer
Decision deadline: Thursday, 3:00 PM
Open risk: Existing audit records do not store reviewer identity

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

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

Недавний инцидент показывает, работает ли структура

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

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

Рекомендации Google по SRE разделяют командование инцидентом, операционную работу, коммуникацию и планирование. Incident commander удерживает общую картину, а операционная роль меняет систему. Это разделение важно, потому что человек, который ищет ошибку, не должен одновременно отвечать на все вопросы заинтересованных сторон. Небольшим компаниям не нужна большая бюрократия инцидентов, но при высоких ставках разделение необходимо.

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

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

Составьте журнал работы до изменения подчиненности

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

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

Небольшой журнал может выглядеть так:

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

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

Здоровый охват зависит от зрелости и изменчивости

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

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

Перед расширением охвата менеджера задайте четыре практических вопроса:

1. Может ли каждый инженер объяснить текущий приоритет и отказаться от работы за его пределами?
2. Может ли команда развернуть, откатить и обработать обычную производственную проблему без указаний менеджера на каждом шаге?
3. Принимает ли технический владелец решения по дизайну в согласованных границах?
4. Дает ли кто-то своевременную обратную связь, если взаимодействие или результативность ухудшаются?

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

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

Меняйте структуру по одной ответственности

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

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

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

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

Если нужен внешний взгляд, Team & AI Audit должен сопоставить эти обязанности с потоком поставки до рекомендаций по сокращению штата. Ценный результат, это перестроенный набор прав на решения и ролей, а не модное соотношение, скопированное у другой компании.

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

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

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

А потом посмотрите на соотношение. Оно станет следствием работы, и именно там ему место.