Ошибки делегирования которые стоят дорого: IT-компании: для фаундера

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

Это не история о плохом директоре. Это история о том, как ошибки делегирования в IT-компании устроены архитектурно — и почему фаундер, который их совершает, как правило, искренне убеждён, что делегирует.

IT-сервис Антона существовал восьмой год. Выручка — под двести миллионов. Несколько десятков сотрудников. Продукт — живой, с платящими клиентами, с роадмапом. По всем внешним признакам — зрелая компания, которая давно должна была перестать зависеть от одного человека.

По внутренним признакам — Антон по-прежнему был в каждом найме, каждом крупном баге, каждом разговоре с ключевым клиентом. Не потому что хотел. Потому что иначе не умел.

Фаундеры IT-компаний — особая категория. Большинство из них начинали как технари: писали код, проектировали архитектуру, лично отвечали за качество. Это формирует специфическую уверенность — «я понимаю продукт лучше всех». Уверенность обоснованная. Проблема в том, что она не исчезает, когда компания вырастает. Она просто начинает стоить дороже.

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

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

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

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

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

Три структурные ошибки делегирования вскрылись быстро.

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

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

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

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

Антон слушал это без удовольствия. В какой-то момент сказал: «Получается, я сам создал проблему, с которой пришёл». Да. Именно так.

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

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

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

Мы выбрали переформатирование. Это потребовало прямого разговора с директором — честного, без дипломатии. Антон объяснил, что менял правила игры на ходу, что это было несправедливо, что теперь будет иначе. Директор, по словам Антона, смотрел на него с лёгким недоверием. Это нормально — доверие восстанавливается делами, не словами.

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

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

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

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

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

Через шесть месяцев картина была следующей.

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

Бюджетирование инфраструктуры перешло в зону директора полностью. Антон видел итоговые цифры раз в месяц. Не детали — итог.

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

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

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

Итог — win с оговорками. Система заработала. Антон освободил примерно треть своего времени — не половину, как хотел изначально, но треть — это уже другая жизнь. Директор восстановил способность принимать решения. Компания перестала тормозить на каждом найме и каждом бюджетном вопросе.

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

Три признака, что делегирование сломано — не в людях, а в системе.

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

Второй. Фаундер знает детали процессов, которые формально ему не принадлежат. Знает, кто что делает, в каком статусе задача, почему задержка. Это не осведомлённость — это симптом того, что он не вышел из операционки, просто переименовал своё участие.

Третий. Решения принимаются медленно — не потому что сложные, а потому что ждут фаундера. Компания работает в ритме его доступности.

Если три из трёх — архитектура сломана. Нанять нового директора не поможет. Он адаптируется к той же системе за полгода.

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

Структурная ошибка делегирования не отраслевая. Она архитектурная. IT просто создаёт для неё особенно благодатную почву — потому что фаундер-технарь привык к точности и контролю, и эти качества, которые сделали продукт, начинают разрушать компанию.

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

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

Это специфика IT — или такое бывает в любом бизнесе?

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

А если директор действительно слабый — не просто адаптировавшийся к системе?

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

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

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

Тот же человек. Просто теперь он действительно был директором — не посредником.

Антон получил то, за чем пришёл. Не сразу, не без потерь, не в полном объёме. Но получил. Треть времени — это не мало, если раньше не было ничего.

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

Работаю с фаундерами и собственниками бизнесов от 80 миллионов выручки. Беру до 3 заявок в неделю.

hi@vvetrov.com — кто ты, что за компания, в чём вопрос.

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

P.S. Антон написал через год. Сказал, что жалеет об одном — что не пришёл раньше.

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