Чеклист делегирования для CEO: для CEO

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

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

В конце — один вопрос, который я задаю CEO перед тем, как мы начинаем работать с делегированием. Большинство отвечают неправильно.

Делегирование ломается ещё до того, как задача уходит к исполнителю. Ломается в голове у CEO — в момент, когда он решает передать что-то, не ответив на три базовых вопроса.

Первый вопрос: готова ли задача к передаче?

Задача готова к передаче, если ты можешь описать результат в одном предложении. Не процесс — результат. «Провести переговоры с поставщиком» — это процесс. «Получить от поставщика письменное подтверждение скидки 8% на объём от 500 единиц до 1 июля» — это результат.

Если ты не можешь сформулировать результат сам — исполнитель точно не сможет его угадать.

Второй вопрос: готов ли человек?

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

Третий вопрос: готов ли ты отпустить?

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

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

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

Но подготовка — это не повод откладывать. Это повод сделать следующий шаг правильно.

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

Результат, а не процесс

Формулируй задачу через конечное состояние. Что именно должно существовать, когда задача выполнена? Какой документ, какое решение, какое изменение в системе? Если ты описываешь, как делать, — ты управляешь процессом. Если описываешь, что должно получиться, — ты управляешь результатом. Это разные роли.

Критерии приёмки

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

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

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

Здесь обычно возникает возражение: «Это займёт больше времени, чем сделать самому». Да, первый раз — займёт. Второй раз — уже нет, потому что у исполнителя будет шаблон. Третий раз — он сам напишет бриф и принесёт тебе на проверку. Инвестиция окупается не сразу, но она окупается.

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

Матрица компетенция × мотивация

Прежде чем передавать задачу, оцени исполнителя по двум осям:

• Высокая компетенция + высокая мотивация — передавай с минимальным контролем. Этот человек справится сам.
• Высокая компетенция + низкая мотивация — выясни, почему нет мотивации. Иногда достаточно объяснить, зачем задача важна. Иногда — нет, и тогда это сигнал о другой проблеме.
• Низкая компетенция + высокая мотивация — передавай с поддержкой. Человек хочет, но не умеет: твоя роль — обучить, а не контролировать каждый шаг.
• Низкая компетенция + низкая мотивация — не делегируй. Это не задача делегирования, это задача управления персоналом.

Типичная ошибка

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

Лучше услышать «я не уверен, что справлюсь» до начала, чем «я старался, но не получилось» после дедлайна.

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

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

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

Пять уровней полномочий

Есть простая шкала, которую я использую в работе с CEO:

1. Изучи и доложи — исполнитель собирает информацию, решение принимает CEO. 2. Предложи варианты — исполнитель готовит 2–3 варианта с оценкой, CEO выбирает. 3. Реши и сообщи — исполнитель принимает решение и информирует CEO постфактум. 4. Реши и действуй — исполнитель принимает решение и действует, CEO узнаёт при необходимости. 5. Полная автономия — исполнитель управляет функцией самостоятельно, CEO вне процесса.

Большинство CEO застревают на уровнях 1–2 и называют это делегированием. Это не делегирование — это консультирование снизу вверх.

Как зафиксировать договорённость

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

Из практики. Михаил — CEO производственной компании с выручкой около 400 миллионов — передавал коммерческому директору переговоры с ключевым дистрибьютором. Договорились устно: «Действуй по ситуации». Через три месяца дистрибьютор получил скидку, которую Михаил считал неприемлемой. Коммерческий директор был уверен, что действовал в рамках договорённостей. Михаил был уверен, что нет.

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

Переписали соглашение письменно: уровень 3 для скидок до 5%, уровень 2 для скидок выше. Конфликтов больше не было.

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

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

Частота контроля зависит от зрелости

Чем выше компетенция и опыт исполнителя в конкретной задаче — тем реже нужны check-in'ы. Для нового человека или новой задачи: контрольные точки чаще, горизонт короче. Для опытного исполнителя в знакомой функции: реже, горизонт длиннее.

Это не интуиция — это параметр, который можно обсудить явно: «Как часто тебе нужна обратная связь от меня, чтобы двигаться уверенно?»

Форматы check-in

Три рабочих формата:

• Статусное сообщение — исполнитель пишет раз в неделю: что сделано, что следующее, что нужно от тебя. Занимает пять минут, даёт полную картину.
• Короткий звонок — 15 минут, только по отклонениям от плана. Не отчёт, а разбор препятствий.
• Milestone review — встреча по завершении ключевого этапа. Подходит для проектов с чёткими фазами.

Что делать, если задача горит

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

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

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

Ретроспектива после передачи

Три вопроса, которые стоит задать после каждой переданной задачи — себе и исполнителю:

1. Что пошло так, как планировали? 2. Что пошло иначе — и почему? 3. Что изменим в следующий раз?

Это не разбор полётов и не поиск виноватых. Это накопление опыта в системе, а не только в голове у CEO.

Как не вернуть задачу обратно

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

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

Что делать, если исполнитель провалился

Разбери по шагам этого чеклиста: на каком именно шаге произошёл сбой? Задача была сформулирована нечётко? Исполнитель не подходил по матрице? Полномочий не хватило? Контрольные точки были слишком редкими?

Провал в делегировании — это почти всегда диагностическая информация. Используй её.

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

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

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

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

Убери один шаг — и система не работает.

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

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

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

Работаю с собственниками и CEO бизнесов от 80 миллионов выручки, у которых есть команда, но нет системы передачи. Если это про тебя — приходи на короткий разбор: 20 минут, без продажи, только про твою ситуацию. Я скажу, работаю я с такой задачей или нет.

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

P.S. Если не подхожу — скажу, к кому пойти.

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