Как CEO избавился от перфекционизма: история: кейс

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

Антон руководит компанией в сфере профессиональных услуг. Средний бизнес, оборот в диапазоне, который принято называть «крепкий средний». Команда — несколько десятков человек, часть из которых работает с ним больше пяти лет. Люди опытные, лояльные, в целом компетентные.

Внешне всё выглядело как история успеха. Компания росла. Клиенты возвращались. Репутация держалась. Но сам Антон к моменту нашего знакомства был в состоянии, которое я бы описал как «функциональное истощение»: работает, справляется, но уже на морально-волевых.

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

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

Это была его версия. Честная, искренняя — и при этом не совсем точная. Но об этом чуть позже.

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

Первые две встречи я потратил на то, чтобы понять, с чем именно мы работаем. Не с тем, что Антон назвал проблемой, — а с тем, что за этим стоит.

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

Когда человек знает, как делать, но не делает — обычно дело не в знании.

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

Я спросил: «Зачем переделывал?»

Он задумался. Потом сказал что-то вроде: «Потому что я не мог отправить это так».

Вот здесь и была точка входа. Не «команда не дотягивает». А «я не мог». Это разные вещи.

Перфекционизм у CEO редко выглядит как погоня за качеством. Чаще он выглядит как тревога, замаскированная под стандарты. Антон не переделывал работу потому, что она была плохой. Он переделывал, потому что иначе ему было некомфортно. Некомфортно — это мягко сказано. Точнее: иначе у него возникало что-то похожее на физическое беспокойство.

Когда я это назвал — он не согласился. Сказал, что это не тревога, а просто высокие стандарты. Что он отвечает за репутацию компании. Что клиенты платят за качество.

Всё это было правдой. И всё это было защитой.

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

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

Первая развилка: признать паттерн.

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

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

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

Вторая развилка: договориться с командой.

После того как паттерн был признан, встал практический вопрос: что менять в операционке. Мы разработали простую систему — Антон определяет, какие задачи требуют его финального взгляда, а какие нет. Не всё, а конкретный список. Остальное — команда выпускает самостоятельно.

Первые две недели это работало. Потом начались исключения. «Это важный клиент». «Это нестандартная ситуация». «Здесь я всё-таки посмотрю». Список «обязательных проверок» незаметно расширился обратно до прежнего объёма.

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

Третья развилка: выбор в реальном времени.

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

Антон узнал об этом постфактум. И его первая реакция была — злость. Не на клиента, не на команду. На себя: «Надо было проверить».

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

Он это увидел. Это был важный момент.

Но вот что он сделал дальше — это и есть компромиссный исход этой истории.

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

Что изменилось — реально и измеримо. Он перестал переделывать работу команды в тех случаях, где это не влияло на результат для клиента. Это примерно 60–70% от прежнего объёма вмешательств. Команда начала выпускать продукт самостоятельно — и, что важно, начала нести за него ответственность. Это изменило динамику: люди стали принимать решения, не дожидаясь его.

Вечера стали свободнее. Не полностью — но заметно.

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

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

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

Компания при этом выросла. Не потому что он «исправился», а потому что команда получила пространство. Это тоже результат — и немаловажный.

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

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

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

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

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

Ответ на этот вопрос обычно многое проясняет.

Это единичный случай или типичная история для CEO?

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

А если у меня не перфекционизм, а действительно слабая команда?

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

Что делать, если узнал себя в этом кейсе?

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

Антон пришёл с запросом на делегирование. Ушёл с пониманием, что вопрос был в другом. Это не всегда приятный разворот — но обычно полезный.

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

Работаю с CEO и собственниками бизнесов от 80 миллионов выручки. Беру не больше двух advisory-клиентов в квартал — это ограничение реальное, не маркетинговое. Заявка через форму на странице /services/coaching/: кто вы, что за бизнес, с чем пришли.

Если кажется, что у вас другое — возможно, так и есть. Но обычно это не другое. Обычно это та же структура, другие детали.

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

Апрель 2026. Автор — Виталий Ветров, практикующий юрист и стратегический советник.

Смежные материалы по теме:

• Как CEO поймал себя на confirmation bias — о другом когнитивном паттерне с похожей структурой
• Как фаундер избавился от перфекционизма: практика — практическая сторона той же темы
• Когнитивные ловушки предпринимателя: 10 искажений — обзорный материал кластера