Команда в девелопменте которая работает без CEO: как строить

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

В третьем разделе — один вопрос, который я задаю каждому девелоперу на первой встрече. По ответу сразу понятно: есть у него команда или только сотрудники.

1. Почему девелопмент — особый случай 2. Что значит «работает без CEO» — операционное определение 3. Архитектура команды — кто нужен и зачем 4. Как передавать решения — не делегирование, а архитектура полномочий 5. Как не сломать то, что построил — удержание и культура 6. Типичные ошибки и как их избежать

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

Девелопмент — не ритейл и не IT. Здесь три принципиальных особенности, которые делают зависимость от CEO системной проблемой, а не личной слабостью собственника.

Первое: цикл сделки. Жилой комплекс — это 3–5 лет от земли до ключей. Коммерческий объект — иногда дольше. Ошибка в решении, принятом в первый год, обнаруживается на третий. К тому моменту контекст забыт, люди сменились, а цена исправления — десятки миллионов. Это означает, что решения в девелопменте должны приниматься людьми, которые понимают не только текущую задачу, но и её место в трёхлетней логике проекта. CEO, который держит весь контекст в голове, — это не сила. Это риск.

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

Третье: регуляторная среда. Девелопмент — одна из самых зарегулированных отраслей. Разрешения, согласования, проектная документация, взаимодействие с банками по 214-ФЗ. Каждый из этих треков требует специализированного человека, который не просто исполняет, но и принимает тактические решения в своей зоне. Если все эти решения идут через CEO — он превращается в узкое горлышко, которое стоит дороже, чем кажется.

Автономная команда в девелопменте — это не роскошь и не признак зрелости. Это операционная необходимость для компании, которая хочет расти или хотя бы не деградировать.

Но прежде чем говорить о том, как строить такую команду, — нужно договориться о том, что именно мы строим.

Здесь обычно возникает первое возражение: «Подождите, я же не собираюсь уходить из компании. Зачем мне команда, которая работает 'без меня'?»

Это обоснованное возражение. Но оно основано на неточном прочтении задачи. «Работает без CEO» не означает «CEO не нужен». Это означает: CEO не является узким горлышком в ежедневной операционке.

Прежде чем читать дальше — вспомни последние две недели. Сколько раз к тебе приходили за решением, которое мог бы принять кто-то другой, если бы у него был нужный контекст и полномочия? Не «не хотел» принимать — а именно «не мог», потому что не было ни того, ни другого.

Я выделяю три уровня автономии команды в девелопменте.

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

Уровень 2: операционная автономия. Команда принимает решения, выходящие за рамки утверждённых параметров, — но в пределах согласованного протокола эскалации. Например: коммерческий директор может дать скидку до 5% без согласования, до 10% — с уведомлением CEO, свыше 10% — с его одобрением. CEO включается в исключения, а не в правило.

Уровень 3: стратегическая автономия. Команда способна вести компанию в отсутствие CEO в течение 3–6 месяцев без потери качества. Это уровень, к которому большинство девелоперов не приходят — и не обязаны. Но он нужен тем, кто строит несколько проектов параллельно или планирует выход.

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

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

Вот тот вопрос, который я задаю каждому девелоперу на первой встрече: «Если ты уедешь на три месяца — кто в компании знает, что делать, когда что-то пойдёт не так?»

Не «кто будет исполнять». А кто будет принимать решения в нештатных ситуациях.

Если ответ — «ну, Сергей позвонит мне» — это не команда. Это набор исполнителей с одним центром принятия решений.

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

Роль 1: операционный якорь. Человек, который держит целостность проекта — видит стройку, финансы и продажи как единую систему. Это не обязательно COO с таким титулом. Это человек, который понимает, как решение в одном треке влияет на два других. В небольших компаниях это часто сам CEO — и это проблема.

Роль 2: технический арбитр. Человек, которому доверяют технические решения на стройке — и который несёт за них ответственность. Главный инженер, технический директор — название не важно. Важно, что он не ходит к CEO за подтверждением каждого отступления от проекта.

Роль 3: коммерческий переговорщик. Человек, который ведёт отношения с банками, крупными покупателями и ключевыми подрядчиками. Не исполняет инструкции CEO — а самостоятельно ведёт переговоры в согласованных рамках.

Роль 4: финансовый контролёр. Человек, который видит кассу, эскроу и проектное финансирование в реальном времени — и имеет полномочия принимать тактические решения по ликвидности без ежедневного согласования.

Теперь — важное разграничение, которое многие путают.

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

Мини-история — компромисс

Михаил, девелопер из регионального рынка, строил компанию 11 лет. Выручка — около 400 миллионов в год, три объекта в работе одновременно. Пришёл с запросом: «Хочу нанять человека, который возьмёт операционку». Нашёл — опытный управленец из федерального застройщика, с хорошим резюме и правильными словами на интервью.

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

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

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

Но даже правильные люди на правильных ролях не дают автономии, если нет одной вещи. О ней — дальше.

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

В девелопменте я использую простую матрицу решений. Четыре квадранта по двум осям: цена ошибки (высокая / низкая) и частота (регулярная / нерегулярная).

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

Здесь обычно возникает второе возражение: «У меня специфика — в девелопменте нельзя делегировать стройку. Там каждый день что-то нештатное».

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

Протокол эскалации — это документ, который отвечает на вопрос: «Когда команда всё-таки идёт к CEO?» Он должен быть написан — не устно договорён. Устные договорённости в девелопменте живут ровно до первого кризиса.

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

Контекст передаётся не на одной встрече. Это процесс — минимум 2–3 месяца совместной работы, где CEO сначала принимает решения вместе с человеком, потом наблюдает, потом отпускает.

Смотри также: Построение топ-команды: полный гайд для фаундера — там подробнее о том, как структурировать этот переходный период.

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

Третье возражение, которое я слышу регулярно: «Хороший операционный директор стоит как отдел. Это не окупится».

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

Но допустим, ты нашёл правильных людей, передал контекст и полномочия, команда работает. Теперь — самый неочевидный риск.

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

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

Культура в девелопменте — это не корпоративные ценности на стене. Это операционный инструмент, который отвечает на вопрос: «Как у нас принято принимать решения в условиях неопределённости?» Если ответ — «звоним CEO» — это не культура автономии. Это культура зависимости, которую ты сам и создал.

Смотри также: Удержание ключевых людей в девелопменте: практика — там конкретные механики удержания топ-менеджеров в строительных компаниях.

Мини-история — потеря

Николай строил производственно-складской девелопмент. Небольшая компания — 5–6 объектов в год, выручка около 200 миллионов. Три года назад нанял операционного директора — Ирину, с опытом в крупном федеральном застройщике. Год ушёл на передачу контекста, второй — на то, чтобы она реально взяла операционку. На третий год Николай впервые за долгое время уехал в отпуск на две недели и не открывал почту.

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

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

Корпоративная культура в строительстве при масштабировании — отдельная тема, которую я разбираю в этом материале.

Шесть лет работы с девелоперами дали мне устойчивый список ошибок. Они повторяются с такой регулярностью, что я перестал удивляться — начал просто фиксировать.

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

Ошибка 2: построить команду под себя, а не под задачу. Собственник нанимает людей, которые думают так же, как он. Это комфортно — и смертельно для автономии. Команда, которая думает так же, как CEO, будет принимать те же решения, что и CEO. Зачем тогда команда?

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

Ошибка 4: передать полномочия без ответственности. «Ты теперь отвечаешь за стройку» — но бонус по-прежнему зависит от решений CEO. Человек получил полномочия, но не получил мотивацию ими пользоваться. Он будет перестраховываться и эскалировать — потому что так безопаснее.

Ошибка 5: ждать, пока команда «дозреет». Автономия не возникает сама. Её нужно строить — с конкретными шагами, сроками и точками проверки. «Постепенно отпустить» без структуры означает не отпустить никогда.

Начни с диагностики: возьми последние 30 решений, которые прошли через тебя, и раздели их по матрице (цена ошибки × частота). Скорее всего, обнаружишь, что 60–70% из них могли быть приняты без тебя — если бы у людей был контекст и полномочия. Это и есть первый шаг: не нанимать нового человека, а передать контекст тем, кто уже есть.

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

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

В начале я написал, что большинство девелоперов убеждены: без CEO компания встанет. Теперь ты видишь, почему это убеждение — ловушка. Компания держится на CEO не потому что так правильно. А потому что CEO никогда не строил систему, которая работает без него.

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

Это строится. Не быстро — но строится.

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

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

Беру не более 3 новых заявок в неделю.

Напиши на hi@vvetrov.com: кто ты, что за компания, в чём вопрос — одним абзацем.

P.S. Если задача не моя — скажу честно и, скорее всего, подскажу, к кому.

Апрель 2026. Автор — Виталий Ветров, стратегический советник для предпринимателей.