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

Как выглядит раздражение основателя в реальной работе

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

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

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

Обычно этот шаблон видно по нескольким ежедневным привычкам:

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

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

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

Почему это не просто проблема людей

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

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

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

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

Кто-то должен сказать:

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

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

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

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

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

Как начинается постоянная переделка

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

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

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

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

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

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

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

Что меняющийся объём работ делает с командой

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

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

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

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

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

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

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

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

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

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

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

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

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

Хорошие технические лидеры заранее принимают четыре решения и потом регулярно их повторяют:

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

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

Как исправить пробел в лидерстве

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

Начните с 30-дневной цели, которую люди смогут проверить в конце месяца. «Улучшить онбординг» — слишком размыто. «Снизить отвал при регистрации на 15%» даёт команде ориентир и упрощает компромиссы.

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

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

Фиксируйте компромиссы простым языком, пока принимаете решения. Длинные документы не нужны. Достаточно нескольких строк:

• На этот релиз мы выбрали скорость вместо аккуратности.
• Сейчас поддерживаем один платёжный сценарий, а не три.
• Мы готовы две недели вручную помогать клиентам, чтобы сначала проверить спрос.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обычно fractional CTO для стартапов исправляет это одним скучным, но очень важным решением: выбрать цель релиза и защитить её. В этом случае целью релиза стало простое self-service онбординг-решение для одного типа пользователей. Приглашения в команду, расширенные роли и мастер настройки перешли на более поздний этап.

Правила быстро стали понятными:

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

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

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

Быстрая проверка на ближайшие две недели

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

Используйте простой чек-лист.

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

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

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

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

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

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

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

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

Сначала проверьте четыре области:

• ответственность: кто может принять решение без согласования с основателем
• roadmap: кто превращает цели в порядок разработки
• архитектура: кто решает, что должно оставаться простым, а что требует больше работы
• управление изменениями: кто говорит «нет», когда объём работ меняется в середине разработки

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

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

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