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

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

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

Пятый раз за квартал вижу одну и ту же картину в IT-компаниях с выручкой от 100 до 500 миллионов: фаундер жалуется, что команда «не берёт ответственность». Команда жалуется, что фаундер «лезет во всё». Обе стороны правы. И обе описывают симптом, а не причину.

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

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

Отдельная история — фаундеры с техническим бэкграундом. Парадокс: они делегируют хуже, чем те, кто никогда не писал код. Потому что у них есть мнение о том, как надо. И это мнение они транслируют — иногда прямо, иногда через вопросы на ревью, иногда через правки в задачах. Команда считывает сигнал и перестаёт думать самостоятельно. Зачем, если фаундер всё равно переделает?

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

Прежде чем читать дальше — вспомни последние три вещи, которые ты делегировал. Как именно ты их формулировал? Задача или результат?

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

Один из клиентов — собственник IT-компании, разрабатывающей b2b-продукты, выручка около 200 миллионов — пришёл с классической историей. Он делегировал команде «переделать онбординг». Команда работала три месяца. Результат был технически безупречен. Пользователи по-прежнему отваливались на третьем шаге. Потому что фаундер имел в виду «снизить отвал при онбординге», а команда поняла «переписать онбординг с нуля на новом стеке». Три месяца. Ноль влияния на метрику, которая имела значение.

Цена этой ошибки — не только три месяца работы. Это три месяца, в течение которых конкурент улучшал именно ту метрику, которую нужно было улучшать.

Смежная, но отдельная проблема. Фаундер знает, почему эта задача важна. Команда — нет. И это не мелочь.

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

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

Я слышал от CTO одной из компаний, с которой работал как адвайзер, примерно следующее: «Мы перестали спрашивать зачем. Фаундер всё равно не объясняет. Просто делаем, что сказали». Это не жалоба. Это адаптация. Команда научилась работать в условиях информационного вакуума. И это — один из самых дорогих режимов работы, которые я знаю.

Если тебе близка эта тема — в моём телеграм-канале я разбираю операционные ловушки фаундеров: конкретные ситуации, без мотивационной упаковки. [t.me/vvetrov]

Фаундер говорит «я доверяю команде». И проверяет каждый пул-реквест. Это не делегирование. Это аутсорсинг исполнения при сохранении всех решений за собой.

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

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

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

Подробнее о том, как не потерять контроль при реальном делегировании — в материале «Делегирование фаундер: как не терять контроль».

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

Фаундер хочет делегировать важное. Важное нужно доверить лучшим. Лучший разработчик становится тимлидом. Потом — руководителем отдела. Потом — CTO.

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

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

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

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

Это не проблема команды. Это проблема системы делегирования, в которой приоритизация не передана явно.

Результат предсказуем: команда делает всё одновременно и не делает ничего хорошо. Скорость падает. Качество падает. Фаундер видит это и начинает контролировать сильнее. Круг замыкается.

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

CTO не должен решать, что строить. Только как.

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

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

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

Граница, которую нельзя делегировать: что мы строим и для кого. Как мы строим — можно и нужно.

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

Это не отдельная ошибка — это мета-ошибка, которая порождает все предыдущие.

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

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

Большинство фаундеров застревают на первом уровне и называют это делегированием. Это не делегирование. Это постановка задач.

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

Признаки, что делегирование работает: команда приходит с решениями, а не с вопросами. Фаундер узнаёт о проблемах до того, как они стали кризисом. Люди остаются.

Простой тест: если в формулировке есть глагол действия («сделай», «напиши», «настрой») — это задача. Если есть измеримое состояние через определённое время («через месяц конверсия из триала в оплату должна вырасти с 8% до 12%») — это результат. Большинство фаундеров смешивают оба формата в одной постановке — и получают ни то ни другое.

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

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

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

И тот вопрос, который я обещал в начале. Я спрашиваю собственника IT-компании: «Когда ты последний раз узнал о серьёзной проблеме от команды — до того, как она стала кризисом?» Если человек задумывается надолго — ответ понятен без слов.

Если хоть три из семи ошибок — про тебя, есть смысл разобраться с системой, а не с симптомами.

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

Работаю с собственниками IT-бизнесов от 80 миллионов выручки. Гайд бесплатный — скачай на странице консультирования или напиши на hi@vvetrov.com, пришлю напрямую.

Если нужен разбор живой ситуации — там же можно договориться о 20-минутной встрече. Без продажи: короткий разбор, и я скажу, работаю я с такой задачей или нет.

P.S. Если гайд не подойдёт — скажу, что смотреть вместо него.

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