Кейс: Делегирование и потеря контроля. Cto финтех-стартапа. Итог: возврат к регулярному сну

Автор: Алексей Туманов, коуч руководителей ritlid, MCC ICF. Специализация — executive coaching, развитие ЛПР, карьерные переходы. Дата публикации: 26 июня 2026.

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

CTO финтех-стартапа, 41 год. Компания — платёжная инфраструктура для малого бизнеса, около 90 человек в команде, из них 35 — в инженерном блоке. Стартап прошёл раунд серии A за восемь месяцев до обращения, после чего основатели приняли решение масштабировать команду: за полгода инженерный блок вырос с 18 до 35 человек.

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

К моменту первой встречи он не спал полноценно около четырёх месяцев. Засыпал в районе часа ночи, просыпался в три-четыре, проверял Slack и Jira, снова засыпал к шести, вставал в восемь. Субъективно — «функционирую, но на холостом ходу».

На первой встрече клиент описал три конкретных эпизода за последние два месяца.

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

Второй: на ретроспективе один из тимлидов предложил изменить процесс code review. Клиент согласился, делегировал внедрение. Следующие три недели он мысленно возвращался к этому решению каждый день — «а вдруг это замедлит релизы», «а вдруг я не учёл что-то важное».

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

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

В ходе диагностической сессии «Точка опоры» (№01) и первых двух встреч программы стала проявляться более глубокая структура.

Клиент вырос в роли CTO органично — из сильного инженера. Его авторитет в компании держался на экспертизе: он знал систему лучше всех, принимал технические решения быстро и точно, команда шла к нему за ответами. Это была рабочая модель при команде до 20 человек.

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

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

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

Работа велась в формате программы «Ясность» (№02) — пять сессий за пять недель — с последующим переходом в «Лидер в балансе» (№04). Итого 12 сессий за три месяца.

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

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

Это наблюдение стало первой точкой опоры: тревога была не про качество команды и не про собственную некомпетентность. Она была про информационный вакуум. Это управляемо.

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

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

• Еженедельный асинхронный апдейт от каждого тимлида — короткий, структурированный, в пятницу до 17:00
• Явный договор с командой: «я не пишу в личку с вопросом «как дела» — если нужна информация, она приходит по расписанию»
• Личный ритуал «закрытия дня» в 21:00: просмотр апдейтов, фиксация трёх вещей, которые идут по плану, выключение рабочих каналов до утра

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

К девятой неделе сон стал более устойчивым — клиент засыпал в 23:30–00:00, просыпался один раз вместо трёх-четырёх, возвращался ко сну без проверки телефона. Субъективно: «первый раз за полгода чувствую, что высыпаюсь».

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

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

К завершению программы клиент описал изменения по трём направлениям.

Сон. Регулярный режим восстановился: засыпание до полуночи, одно пробуждение или ни одного, подъём в 7:30 без ощущения, что «не добрал». Телефон с рабочими каналами — в режиме «не беспокоить» с 21:00 до 8:00.

Делегирование. Изменился не сам факт делегирования, а то, что происходит после. Тревога при передаче задачи снизилась с 7–8 баллов до 3–4 по субъективной шкале. Желание проверить «как дела» в обход договорённостей возникает реже и проще поддаётся откладыванию до пятничного апдейта.

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

Три месяца — достаточный срок для стабилизации и первых устойчивых изменений. Не достаточный для полной перестройки идентичности.

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

Это нормальная динамика: первый запрос («не могу спать») закрыт. Следующий слой стал виден именно потому, что первый перестал занимать всё внимание.

Работа велась в формате коучинга по стандартам ICF с элементами КПТ-техник для работы с тревогой. Коучинг работает с настоящим и будущим: ролью, решениями, поведенческими паттернами. Психотерапия — с историей, клиническими состояниями, глубинными структурами. В данном случае запрос не требовал клинического вмешательства: бессонница была функциональной, не органической, и была связана с конкретным рабочим контекстом. Если бы в ходе работы появились признаки клинической тревоги или депрессии — клиент был бы направлен к психотерапевту или психиатру.

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

Структурные изменения (апдейты по расписанию, ритуал закрытия дня) были необходимы, но недостаточны. Клиент пробовал вводить похожие правила самостоятельно до обращения — они не держались, потому что тревога была сильнее договорённостей с самим собой. Работа с механизмом тревоги и с идентичностью создала внутреннюю опору, на которой структурные изменения смогли удержаться.

В данном кейсе — 12 недель до устойчивого результата по основному запросу. Это близко к среднему для запросов, связанных с тревогой при смене роли: по практике ritlid, большинство клиентов с похожей динамикой выходят на стабилизацию за 8–14 недель. Более глубокие изменения — в идентичности, в отношениях с командой — требуют более длительной работы, что и объясняет переход в формат долгосрочного сопровождения.

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

Если в этом кейсе вы узнали свою ситуацию — полезно начать с одного разговора. Диагностическая сессия «Точка опоры» (№01) — 90 минут с экспертом команды ritlid: разбор ситуации, карта того, что происходит, рекомендация формата работы или честный отказ, если запрос не в нашей зоне. Бесплатно при первом обращении с сайта. Записаться можно через кнопку «Записаться на консультацию» в футере — опишите в форме контекст в двух предложениях. Альтернативный путь: info@rittlid.ru.