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

Что замедляется после прихода нового сотрудника

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

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

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

Чаще всего замедление возникает из-за трех вещей: неясных полномочий, скрытого контекста и поздних изменений.

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

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

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

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

Где полномочия становятся размытыми

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

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

Сначала замедление кажется небольшим. Один пункт дорожной карты лежит еще один день. Просмотр дизайна откладывается до встречи с основателем. Инженер спрашивает решение у менеджера, а потом еще раз у основателя — «на всякий случай». Такие паузы складываются.

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

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

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

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

Контекст, который никто не записал

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

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

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

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

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

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

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

Как изменения в последний момент ломают импульс

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

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

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

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

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

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

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

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

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

Представьте небольшую SaaS-команду из шести человек. Основатель по-прежнему утверждает большинство продуктовых решений, недавно пришел новый вице-президент, а работу делают четыре исполнителя: два инженера, дизайнер и QA.

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

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

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

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

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

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

Пятница кажется насыщенной, но почти ничего не уходит в релиз чисто. Биллинг исправлен наполовину. Онбординг отполирован наполовину. Журнал аудита существует, но в нем нет экспорта, который просил вице-президент. QA находит ошибки в двух местах, потому что все спешили, а у команды не было одного четкого ответа на вопрос, что значит «готово».

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

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

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

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

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

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

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

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

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

В конце недели проверьте несколько пробелов:

• Какое решение все еще металось между двумя людьми?
• У какого проекта все еще была неясная ответственность?
• Какое позднее изменение нарушило новое правило?

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

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

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

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

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

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

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

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

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

Быстрые проверки на следующие два спринта

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

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

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

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

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

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

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

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

Что делать дальше, если команда все еще буксует

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

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

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

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

Часто помогает короткий перезапуск:

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

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

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

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