Продвижение в AI-командах: как определять рост не только по выполнению задач

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

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

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

Именно поэтому решения о повышении в AI-командах становятся размытыми. Многие менеджеры по-прежнему награждают то, что легко посчитать: закрытые задачи, слитые pull request'ы, исправленные баги, написанные страницы. Эти метрики никогда не были идеальными. А когда AI берет на себя большую часть черновой работы, они становятся еще менее полезными.

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

Лучшие вопросы для повышения теперь звучат иначе:

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

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

Что меняется, когда AI берет на себя большую часть исполнения

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

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

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

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

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

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

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

Широта решений показывает, насколько большую зону человек закрывает

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

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

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

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

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

Небольшая продуктовая команда легко показывает эту разницу. Один инженер спрашивает: «Какой вариант вы хотите?» Другой говорит: «Вариант B выйдет на этой неделе, дешевле в поддержке и создаст для нас приемлемую проблему с поддержкой». Оба могут пользоваться одними и теми же AI-инструментами. Но только один закрывает более широкую зону решений.

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

Ответственность за риски показывает, кто несет более тяжелую нагрузку

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

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

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

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

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

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

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

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

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

Ясность между командами помогает работе двигаться

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

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

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

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

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

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

Простой пример помогает это увидеть. Команда хочет добавить подсказки для онбординга. Один человек говорит: «Мы хотим, чтобы пользователи быстрее начинали работать». Это слишком расплывчато. Более сильный коллега переформулирует: «Новые пользователи должны прийти к своему первому завершенному действию меньше чем за пять минут», — и сразу назначает product ответственным за метрику успеха, design — за поток подсказок, engineering — за отслеживание событий. Теперь работа может двигаться.

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

Как оценивать повышение шаг за шагом

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

Сначала определите роль, а уже потом оценивайте человека. Роль более высокого уровня должна отвечать за более широкий набор решений. Запишите эти решения простыми словами. Должен ли человек выбирать между скоростью и надежностью? Решать, когда сокращать объем? Урегулировать конфликт между product и engineering? Если вы не можете назвать сами решения, роль, скорее всего, все еще размыта.

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

Хорошо работает простой процесс ревью:

1. Определите решения, за которые отвечает более высокий уровень роли.
2. Назовите риски, связанные с этими решениями.
3. Попросите два недавних примера, где человек столкнулся с реальными компромиссами.
4. Посмотрите, как он удерживал согласованность между product, design, engineering, support или sales.
5. Сравните доказательства за полный цикл поставки — от планирования до запуска и последующей доработки.

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

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

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

Простой пример из небольшой продуктовой команды

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

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

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

Оба инженера создали результат. Только один взял на себя больший бизнес-риск.

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

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

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

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

Ошибки, из-за которых решения о повышении становятся слабыми

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

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

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

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

Навык работы с инструментами создает еще один неверный вывод. Человек может знать все быстрые приемы в Claude, GPT или кодовых ассистентах и при этом быть не готовым к большей зоне ответственности. Навык работы с инструментами помогает. Но сам по себе он не означает старшинство. Старший человек использует AI, чтобы принимать более качественные решения, уменьшать предотвратимые риски и оставлять более понятный путь для других.

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

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

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

Сырой объем работы теперь слабый сигнал. Человек может выпускать очень много с хорошими инструментами и при этом нуждаться в плотном сопровождении. Более сильный сигнал — суждение под давлением.

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

Потом посмотрите на ясность между командами. Если после встречи product, design, support или sales уносят разные представления о том, кто делает следующий шаг, значит, человек еще не работает на более широком уровне. Люди, готовые к большей ответственности, уменьшают путаницу. Они называют владельцев, ставят границы и замечают пробелы до того, как работа встанет.

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

Короткая проверка может уместиться на одной странице:

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

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

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

Следующие шаги для команды, которая хочет более ясный рост

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

Начните с описания уровней. Если в уровне все еще написано, что человек пишет больше кода или закрывает больше задач, перепишите это. Более сильное описание говорит, какие решения он принимает, какие сбои предотвращает и как помогает product, design, engineering и support оставаться согласованными, когда работа становится хаотичной.

Один практичный шаг — короткий аудит перед следующим циклом ревью:

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

Общие примеры важнее, чем отполированные формулировки. «Вел поставку» — слишком размыто, чтобы помочь. «Выбрал план выката, заранее заметил риск сбоя и согласовал engineering и support до запуска» — дает менеджерам конкретную опору для оценки.

Небольшим стартапам здесь часто нужен взгляд со стороны. Основатели обычно знают, кто работает усердно, но им бывает трудно отделить усилия, лояльность и уровень. Fractional CTO может развести эти вещи и сделать лестницу точнее. Oleg Sotnikov на oleg.is делает такую работу со стартапами и небольшими компаниями, опираясь на опыт в software engineering, CTO leadership, startup advising и AI-first operations.

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