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

Что такое запутанная техническая власть

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

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

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

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

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

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

Почему хорошие senior‑сотрудники сдаются быстро

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

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

Хорошие люди быстро замечают несоответствие. Им говорят: «Вы отвечаете за инженерию», но каждое решение требует ещё три разрешения. Им ставят в вину задержки, но они не могут убрать блоки. Название должности говорит одно, а ежедневная работа — другое.

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

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

Разделённая собственность создаёт тупики

Стартап может нанять head of engineering, VP или внештатного CTO и при этом сохранить ту же самую путаницу. Основатель всё ещё утверждает архитектуру. Советник по‑прежнему вмешивается в продуктовые звонки. Продакт обещает даты до того, как инженерия согласовала работу. Новый старший получает титул, но не контроль.

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

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

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

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

Побочные сделки разрушают доверие

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

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

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

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

Через два–три таких раунда хорошие сотрудники перестают спорить. Они знают, что не контролируют приоритеты, и что им всё равно будут ставить в вину доставку.

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

Люди могут справляться с тяжёлой работой и с хаосом некоторое время. Но они не будут долго терпеть фиктивную власть.

Нечитаемые приоритеты превращают работу в политику

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

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

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

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

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

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

Простой пример из стартапа

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

Первая неделя кажется обычной. Новый VP встречается с инженерами, просматривает роадмап и набрасывает план на квартал. Затем проявляется реальная структура.

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

Простой найм превращается в хаос. VP хочет нанять бэкенд‑лида, потому что команда слаба в одной области. CEO говорит «да», но только после бюджетного обзора на следующей неделе. CTO предлагает подождать, потому что возможно появится знакомый подрядчик. Рекрутинг тормозится. Кандидат принимает другое предложение.

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

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

Потом VP уходит.

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

Как по‑шагам привести это в порядок

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

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

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

Короткий «рестарт» обычно работает лучше, чем большая реорганизация:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Ищите простые сигналы тревоги:

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

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

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

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

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

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

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

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

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

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

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

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