Decision Engine для founder-а: как контекст ломает стратегические решения

Я наблюдаю одно и то же в десятках компаний. Стратегия, которую founder выбрал в январе после длинных праздников, через три месяца оказывается не в тех руках. Согласие на проект, которое он дал в пятницу вечером в усталости, через два месяца становится зоной выгорания команды. Разворот, объявленный после вирусного поста или громкого выступления, через 90 дней оказывается не самым устойчивым направлением.

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

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

Почему состояние founder-а определяет качество стратегии

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

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

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

Шесть контекстов, которые систематически искажают решения

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

Контекст 1. Конец зимы — начало года: синдром раздутых амбиций

Между концом декабря и началом февраля у большинства founder-ов наступает резкий рост уверенности и амбиций. Это сочетание факторов: сезонная биология, новогодний рефрейм («новый год — новая жизнь»), психологическая компенсация декабрьской усталости. На бумаге появляются 25–30 целей, грандиозные планы, новые направления.

К концу года из этих 25–30 целей в живом виде доживает примерно 12%. Это не «founder ленивый» — это переоценённый стартовый объём.

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

Контекст 2. Усталость: запрет на короткие дедлайны

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

В Neutral-состоянии та же задача оценивается реалистично — на 5–7 рабочих дней. В усталости — «один вечер». Команда получает невыполнимое обязательство, проваливает срок, founder обвиняет команду, доверие падает, цикл повторяется.

Что делать. В фазе усталости — никаких deadline короче 3 рабочих дней на серьёзных задачах. Либо переносить решение до восстановления, либо дробить на микрошаги без жёсткой даты. Это не слабость, это калибровка.

Контекст 3. Перед длинными выходными: защита базы важнее проектов

Перед майскими, новогодними, длинной командировкой founder и команда часто ставят tight deadline «давайте успеем до». Параллельно с этим — режим питания и сна расползается, физиология идёт наперекосяк, способность к концентрации падает.

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

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

Контекст 4. Угроза якорям: критическое перевешивание финансовых соображений

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

Пример: контракт на 500 000 ₽ в месяц, но требует 3 недели в чужом часовом поясе без режима. На бумаге деньги нужны. На практике — за 3 месяца такой работы founder теряет здоровье, отношения и рабочую форму. Стоимость восстановления потом — в разы дороже заработанного.

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

Контекст 5. После провала: ловушка тотального отказа

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

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

Контекст 6. После пика внимания: 72-часовой карантин

Зеркальный пятому. После вирусного поста, успешного выступления, продуктового запуска с большим откликом — у founder-а возникает желание брать новые обязательства, входить в новые проекты, расширяться. Это recognition как топливо мотивации, и оно искажает оценку реальности так же сильно, как боль провала.

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

Что делать. После любого пика внимания — задержка решений на 72 часа. Каждое новое обязательство, которое появляется в этот период, проходит вопрос «я бы согласился на это через 10 дней в нейтральном состоянии?». Если ответ слабый — отложить.

Базовая цепочка: четыре вопроса до любого решения

Decision Engine не ограничивается контекстными проверками. После них любое значимое решение проходит четыре вопроса, в этом порядке.

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

Второй вопрос — конструкция. Я здесь буду конструировать или обслуживать? Здесь работает моя сильная функция (стратегия, упаковка, смысл) или я затычка для чужих процессов? Если я затычка — мой настоящий потенциал вне этого проекта, и согласие на него — упущенная возможность.

Третий вопрос — люди. Эти люди усиливают или отравляют? Быстро схватывают суть или тонут в деталях? Держат слово или словоблудят? Дают свободу или лезут под руку? Если хоть на один из этих пунктов «отравляют» или «не держат слово» — за деньги это никогда не компенсируется.

Четвёртый вопрос — свобода. Это оставляет мне свободу или запирает в рутину? Через 6 недель я буду рад, что согласился, или буду жалеть, что не отказался? Эта проверка через будущее «я» часто даёт правильный ответ быстрее, чем рациональный анализ.

Если на любой из четырёх вопросов получается твёрдое «нет» — это red flag для всей сделки, независимо от того, что говорят критерии в финансовой таблице.

Готовые choice-фреймворки для типовых развилок

Decision Engine — это не «думайте каждый раз с нуля». Для типовых развилок есть готовые фреймворки.

Брать клиента или проект

1. Нужна ли тут моя сильная функция? Если нет — пропускаем независимо от денег.
2. Эти люди усиливают или отравляют? Если отравляют — пропускаем.
3. Что меня убьёт через 6 недель — скука, рутина, фальшь или контроль? Если ответ конкретный и уверенный — пропускаем.
4. Это даёт свободу или запирает? Проверка через календарь следующих 2 недель — что я буду делать с этим в моменте.
5. Какой минимум я вынесу из этого проекта, если всё пойдёт плохо — опыт, связи, деньги? Если «ничего» — пропускаем.

В январе-феврале — добавить «я бы согласился на это через 10 дней?» В усталости — отложить решение на 3 дня. После пика внимания — задержать на 72 часа.

Какой фронт сейчас главный

В любой момент у компании есть несколько слоёв: money engine (то, что приносит деньги сегодня), authority layer (то, что строит репутацию на 12–24 месяца вперёд), legacy (то, что создаёт долгосрочную ценность вне финансовой логики). Приоритет в большинстве периодов: money > authority > legacy.

Но legacy нельзя схлопывать до нуля. Если это происходит — компания превращается в чистый money-machine без души, и через 3–5 лет founder выгорает, потому что работает только на цифры. Минимум 2 часа в неделю на legacy — это инвестиция в собственную устойчивость.

Прокрастинация: диагноз вместо дисциплины

Если задача не двигается 2+ недели — это не «надо больше дисциплины». Это диагноз. Возможные причины:

1. Задача требует Neutral-состояния, а вы её решаете в усталости. Перенос на восстановленное состояние.
2. Здесь нет вашей сильной функции. Делегировать или отказаться.
3. Не хватает ресурса (человек, деньги, информация). Найти ресурс, не пытаться через волю.
4. Это вообще не нужно делать. Применить kill-criteria.

В 70% случаев правильный ответ — третий или четвёртый. Дисциплина без ресурса — это самонасилие, которое в B2B не работает.

Risk Patterns: теневые искажения, которые нужно замечать

Это паттерны, в которые попадают почти все founder-ы. Знание паттерна не делает иммунитет автоматическим — но позволяет узнать его, когда он включился.

Признание переутяжеляет. Сигнал: меня тянет туда, где видимость и сцена, но реальные деньги — размытые. Counter: «Где конструкция? Где деньги? Видимость — бонус, не причина решения».

Новый фронт обгоняет дожим старого. Сигнал: готов заходить в новый проект, когда старые не закрыты. Counter: «Какой процент старых проектов доведён до закрытия? До закрытия — нет новых».

Масштаб как топливо. Сигнал: маленький проект кажется недостойным. Counter: «Мне сейчас нужен масштаб или устойчивость? В фазе подъёма усилить этот вопрос».

Деньги сжимают горизонт. Сигнал: «надо срочно денег». Решение принимается через страх, не через выбор. Counter: «Что минимум денег нужно на 3 месяца? Это решение закрывает этот минимум, или это ещё один спринт?».

Спасательский порыв. Сигнал: «я должен этот проект вытащить». Counter: «Это из чувства красоты или из чувства долга? Кому реально причитается этот долг?».

Фальшь в упаковке. Сигнал: клиенту обещаю то, во что сам не верю или не буду делать сам. Counter: стоп. Переформулировать или отказаться. Цена фальши слишком высокая на горизонте 12 месяцев.

Green Flags и Red Flags: с кем работать

Decision Engine применяется не только к проектам, но и к людям.

Green Flags. Быстро схватывают суть, не требуют долгих объяснений. Держат слово, возвращаются с ответами в обещанные сроки. Не контролируют процесс, верят в результат. Говорят прямо, когда не согласны. Признают свои ошибки. Платят без напоминаний.

Red Flags. Самоуверенная посредственность — знают всё, делают никак. Бесконечные созвоны без решений. Меняют задачу после согласования. «Потом обсудим» вместо ясных условий. Эмоциональные качели — сегодня супер, завтра «вы нас разочаровали». Задерживают оплату «потому что». Требуют быть в их инструментах, в их часовом поясе, в их правилах.

Один Red Flag в первой встрече — звонок. Два — пропускаем, какие бы деньги ни предлагались. Три — отказ обязательный.

Quick heuristics: 30-секундный фильтр

Когда нет времени на полный Decision Engine, есть короткая версия из шести шагов.

1. В каком состоянии я сейчас — нейтральном, возбуждённом, усталом, после провала, после пика? Если не нейтральном — отложить.
2. На каком фронте это решение — money, authority, legacy? Если не на приоритетном — отложить.
3. Контекстные проверки: январь-февраль? Перед длинными выходными? Угроза якорю? Если хоть один «да» — отложить или применить мультипликатор.
4. Базовая цепочка из четырёх вопросов: энергия, конструкция, люди, свобода. Если хоть один «нет» — отказ.
5. Топ-3 risk patterns — какой из них сейчас может включиться? Признание? Спешка? Спасение?
6. Если решение необратимое и я не уверен на 90% — отложить минимум на 48 часов.

Шесть шагов проходятся за 30–60 секунд, если они стали привычкой. Без них любое серьёзное решение — это лотерея.

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

Кейс 1. После успешного выступления. Founder B2B-технологической компании выступил на крупной отраслевой конференции, получил 80+ обращений в LinkedIn, четыре новых лида от enterprise-клиентов. На следующий день совет директоров обсудил «давайте запустим три новых направления, чтобы поймать момент». Это классический контекст 6 — пик внимания. Через 72 часа задержки и проверку через четыре базовых вопроса осталась одна инициатива из трёх — та, которая совпадала с реальной сильной функцией команды. Две другие были «эйфория от внимания», и через неделю стало видно, что ресурса на них нет. Если бы решения принимались в день после конференции, через 6 месяцев компания тушила бы три параллельных пожара вместо одного управляемого проекта.

Кейс 2. После провала ключевой сделки. Технологический B2B-стартап потерял enterprise-клиента, на которого делались главные ставки квартала. Через 24 часа founder написал команде «закрываем enterprise-направление целиком, возвращаемся к mid-market». Это контекст 5 — переоценка масштаба провала через свежую боль. Применили правило 72-часовой задержки + разбор с теми, кто не был эмоционально вовлечён в сделку. Через три дня в спокойном состоянии стало видно: enterprise-канал работает, проиграли одну сделку из десяти, остальные девять движутся нормально. Закрытие направления стоило бы шести месяцев работы команды. Не закрыли — через два квартала канал стал давать стабильный pipeline.

Decision Engine защищает компанию от своего же founder-а

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

Без Decision Engine компания страдает от обоих. С ним — получает в основном первое и системно отсекает второе.

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

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