Он написал мне в 23:47.
Не с вопросом — с констатацией: «Кажется, я только что потерял CTO».
Пауза. Потом: «И, возможно, компанию».
Я не стал отвечать сразу. Потому что знал: это не про CTO. Это про то, что происходит, когда ты передаёшь человеку ответственность — но не передаёшь право на ошибку. Когда говоришь «ты главный по продукту» — и в ту же неделю отменяешь его решение о найме. Когда строишь команду из сильных людей — и продолжаешь вести себя так, будто без тебя ничего не решится.
Это письмо про то, как именно это случается в IT. И почему это стоит дорого.
Это письмо не про тебя, если твоя команда меньше пяти человек и ты ещё не нанимал людей сильнее себя в отдельных областях. Оно про тебя, если ты уже нанимал — и что-то пошло не так. Или идёт не так прямо сейчас, но ты ещё не назвал это вслух.
Ты передал задачу. Но не передал право
Антон пришёл в компанию на позицию CTO. Продуктовая IT-компания, 40 человек в разработке, серия A за плечами, амбиции на международный рынок. Собственник — умный, быстрый, технически грамотный. Сам из разработки. Построил всё с нуля.
Антону дали «всё». Так и сказали: «Ты отвечаешь за технологическую стратегию, найм, архитектуру, процессы». Красивый оффер. Хороший пакет. Реальные полномочия — на бумаге.
Первые три месяца Антон разбирался. Потом начал принимать решения.
Первое решение — сменить подрядчика по DevOps. Собственник попросил «ещё раз обсудить». Обсудили. Решение отменили. Второе — нанять архитектора с опытом в highload. Собственник сказал: «Дорого, давай подождём». Подождали. Архитектор ушёл к конкурентам. Третье — перейти на другой стек для нового модуля. Собственник написал в общий чат: «Давайте сначала посоветуемся с командой».
Команда посоветовалась. Решение зависло на два месяца.
Антон продолжал работать. Но что-то изменилось. Он перестал предлагать. Начал спрашивать разрешения. Это не трусость — это адаптация. Умный человек быстро учится тому, как устроена реальная система принятия решений. И начинает работать в ней, а не против неё.
Делегирование без полномочий — это не делегирование. Это аутсорс тревоги. Ты передаёшь человеку ответственность за результат — но оставляешь себе контроль над каждым шагом. Он несёт вес. Ты держишь руль. И оба делаете вид, что это нормально.
Три ошибки, которые я видел чаще всего
За последние несколько лет я работал с IT-компаниями на разных стадиях — от 15 человек до 300. Ошибки делегирования везде разные по форме. Но по сути — одни и те же три.
Первая: делегирование результата без делегирования контекста.
Собственник говорит: «Сделай так, чтобы retention вырос на 20% за квартал». Передаёт задачу — и уходит. Команда начинает работать. Через месяц выясняется, что под «retention» собственник имел в виду одно, продакт — другое, а аналитик вообще считал по третьей методологии.
Это не проблема исполнения. Это проблема передачи смысла.
В IT это особенно болезненно, потому что разработчики — люди с высокой потребностью в логике. Они не просто хотят знать «что» делать. Они хотят понимать «зачем». Когда контекст не передан — они додумывают. И додумывают по-своему. Иногда правильно. Чаще — нет.
Я видел компанию, где команда из восьми разработчиков полгода строила интеграцию с платёжной системой — потому что так поняли задачу. Собственник имел в виду другую систему. Другую страну. Другой рынок. Никто не спросил. Никто не уточнил. Задача была «делегирована».
Вторая: делегирование задачи при сохранении права вето.
«Решай сам» — и через три дня: «Я тут подумал, и мне кажется, лучше сделать иначе».
Это самая распространённая ошибка среди собственников, которые выросли из технических специалистов. Они умные. Они видят детали. Они часто правы по существу. Но они не понимают, что каждое такое «я тут подумал» — это не корректировка курса. Это сигнал: твоё решение не окончательное. Жди.
Люди быстро перестают принимать решения, когда знают, что их могут отменить. Не потому что ленятся — потому что рационально. Зачем тратить энергию на то, что всё равно пересмотрят?
Один из моих клиентов — собственник продуктовой компании в сфере HR-tech — однажды сказал мне: «Я не понимаю, почему они не проявляют инициативу». Я спросил его: «Сколько решений твоей команды ты отменил за последний месяц?» Он задумался. Потом сказал: «Ну, несколько». Мы посчитали вместе. Оказалось — одиннадцать.
Третья: делегирование без договорённости о том, что считается успехом.
Это тихая ошибка. Она не взрывается сразу. Она накапливается.
Ты нанимаешь сильного человека. Говоришь: «Ты отвечаешь за направление». Он работает. Ты наблюдаешь. Через полгода у тебя ощущение, что «что-то не то». У него — что он всё делает правильно. Вы оба правы. Просто вы никогда не договорились, что именно считать «то».
В IT это особенно критично на стыке продукта и разработки. Продакт думает, что успех — это запущенные фичи. Разработка думает, что успех — это стабильность и отсутствие багов. Собственник думает, что успех — это рост метрик. Все трое работают. Все трое устают. И через год выясняется, что они строили разные здания на одном фундаменте.
Что происходит с людьми
Я хочу остановиться здесь. Потому что обычно разговор о делегировании — это разговор про процессы, про матрицы ответственности, про OKR и RACI. Это полезные инструменты. Но они не отвечают на главный вопрос.
Что происходит с человеком, которому не дают принимать решения?
Антон не уволился через месяц. Он проработал ещё полтора года. Хорошо проработал — по внешним признакам. Команда его уважала. Продукт двигался. Метрики росли.
Но он перестал предлагать смелые решения. Начал согласовывать то, что раньше просто делал. Стал осторожнее в найме — зачем брать сильных людей, если их всё равно не дадут нормально использовать. Его горизонт сузился с «куда мы идём через три года» до «что мы делаем в этом спринте».
Это называется адаптивным выгоранием. Человек не сгорает ярко — он медленно сужается. Продолжает функционировать. Перестаёт расти. И в какой-то момент понимает, что стал меньше, чем был, когда пришёл.
Лучшие люди не уходят с криком. Они уходят тихо. Сначала внутренне — перестают вкладывать больше необходимого. Потом физически — находят место, где их решения имеют вес.
Антон ушёл через полтора года. Не потому что не справился. Не потому что нашёл больше денег. Он ушёл потому что устал бороться за право делать свою работу.
Собственник написал мне тогда: «Я не понимаю. Я ему всё дал». Я не стал спорить. Потому что он действительно дал — на бумаге. Просто не дал самого главного: пространства, в котором решения Антона были бы настоящими.
Ошибки делегирования стоят дорого не только деньгами. Они стоят людьми. А в IT — где рынок узкий, где репутация работодателя распространяется быстро, где сильный архитектор или продакт стоит дороже любого инструмента — это цена, которую сложно посчитать заранее. И невозможно не заметить потом.
Есть хорошая статья про то, как делегирование превращается в тревогу — и почему умные предприниматели не могут отпустить даже когда очень хотят. Если узнаёшь себя в этом письме — там есть продолжение разговора.
Что я хочу сказать тебе
Ты читаешь это письмо. Значит, что-то в нём тебя зацепило.
Может быть, ты узнал Антона. Может быть, ты узнал собственника. Может быть, ты сейчас в середине этой истории — и ещё не знаешь, чем она закончится.
Я не собираюсь давать тебе чеклист. Не потому что его нет — он есть, и он работает. Просто сейчас не об этом.
Я хочу задать тебе один вопрос. Не риторический — настоящий.
Когда ты в последний раз позволил кому-то из своей команды принять решение, с которым ты был не согласен — и не вмешался?
Не «дал возможность». Не «обсудили и пришли к общему». Именно: не согласился — и не вмешался. Позволил человеку сделать по-своему. Посмотрел, что будет.
Если ответ «недавно» — хорошо. Если ответ «давно» или «не помню» — это и есть ответ.
Делегирование — это не техника управления. Это акт доверия, который требует от тебя чего-то неудобного: признать, что другой человек может знать лучше тебя. Не в целом — в конкретном вопросе, в конкретный момент. Это сложно для людей, которые построили бизнес своими руками. Я понимаю. Я видел это много раз.
Но вот что я знаю точно: компании, которые умеют делегировать по-настоящему, — не те, где собственник научился «отпускать». Это те, где собственник научился нанимать людей, которым можно доверять — и потом действительно доверять.
Это разные навыки. И оба требуют времени.
Антон сейчас CTO в другой компании. Я слышал, что там хорошо. Что его решения — его.
А тот собственник всё ещё ищет нового CTO. Третьего за два года.
Если ты узнал в этом письме кого-то — себя или Антона — напиши. Не с запросом, не с темой. Просто напиши: hi@vvetrov.com.
Иногда именно так начинается самый точный разговор.
Если хочешь поговорить о том, как это устроено в твоей компании — здесь можно оставить заявку на консультацию: /services/consulting/.
Короткие наблюдения о том, что происходит внутри бизнеса — в Telegram раньше, чем здесь: @vvetrovcom.
P.S. Эта история — не единственная такая. Похожие вещи происходят в B2B-услугах и в e-commerce. Там другие детали, другие люди — но та же механика. Если интересно — есть разбор для B2B и для e-commerce. А если хочется понять, как вообще выйти из операционного управления — начни с полного гайда.
Июль 2026. Автор — Виталий Ветров, стратегический советник.