KPI для операционного директора в IT-компании: из опыта советника

Операционный директор работает третий месяц. CEO доволен: человек активен, на встречах присутствует, задачи закрывает. Потом CEO идёт в отпуск — и через три дня начинает отвечать на звонки.

Это не история про плохого директора. Это история про неправильно поставленные KPI.

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

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

IT-компания устроена иначе. Основной продукт — это решения людей. Разработчик, который принял неверное архитектурное решение в среду, создаёт проблему, которая обнаружится в следующем квартале. Менеджер, который не поговорил с ключевым клиентом в нужный момент, теряет контракт через полгода. Операционный директор в IT управляет не потоком, а средой — и это принципиально меняет логику KPI.

По данным Harvard Business Review, роль COO — одна из наименее стандартизированных позиций в C-suite. Исследователи HBR выделяют семь различных архетипов операционного директора, и ни один из них не является универсальным. В IT эта вариативность ещё выше: операционный директор в продуктовой компании и операционный директор в аутсорсинговом агентстве — это почти разные профессии.

Типичный CEO, который нанимает COO в IT, — это технический фаундер или продуктовый человек, который вырос в операционку случайно. Он хорошо понимает продукт, плохо понимает процессы, и нанимает операционного директора именно потому, что устал от операционки. Это важный контекст: он нанимает не для оптимизации, а для освобождения. И KPI должны отражать именно это — но почти никогда не отражают.

Что происходит дальше — предсказуемо.

По данным First Round Review, более 60% стартапов, нанявших операционного директора, меняют его в течение 18 месяцев. Это не значит, что все эти директора были плохими специалистами. Это значит, что ожидания и реальность расходились — и чаще всего расходились именно в зоне KPI.

Типичная последовательность выглядит так.

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

Второй-третий месяц — первые результаты. Директор начинает что-то менять. Часть изменений работает, часть вызывает сопротивление команды. CEO начинает замечать, что по-прежнему принимает те же решения, что и до найма директора. Но списывает это на период адаптации.

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

Это классический паттерн. И в его основе — конкретная ошибка в конструкции KPI.

Вопрос в том, какая именно. И здесь начинается самое интересное.

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

Большинство KPI для операционных директоров в IT строятся вокруг активности. Количество проведённых встреч с командой. Процент задач, закрытых в срок. Скорость реакции на запросы. NPS внутри команды. Иногда добавляют финансовые метрики — выручка, маржа, burn rate.

Всё это измеримо. Всё это понятно. И почти всё это — не то.

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

Рабочие KPI для операционного директора в IT строятся вокруг другого вопроса: какие решения CEO больше не принимает?

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

Вот несколько конкретных примеров того, как это выглядит в IT-специфике.

Нерабочие KPI:

• «Провести аудит процессов разработки» — это задача, не KPI
• «Снизить time-to-market на 20%» — это хорошая метрика, но она не про делегирование
• «Еженедельный отчёт CEO о состоянии команды» — это создаёт зависимость, не автономию

Рабочие KPI:

• «Решения по найму до уровня тимлида принимаются без участия CEO» — измеримо, конкретно
• «Конфликты внутри команды разрешаются на уровне директора, не эскалируются» — фиксируется по факту обращений
• «Квартальные цели команд формулируются директором, CEO только утверждает» — меняет направление потока

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

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

Но почему CEO интуитивно выбирает первый список? Ответ неприятный.

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

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

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

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

Что работает в IT-специфике — это трёхуровневая конструкция KPI.

Уровень 1 — операционная стабильность. Базовые метрики, которые показывают, что директор держит процессы. Delivery в срок, retention команды, отсутствие критических инцидентов без реакции. Это гигиена, не цель.

Уровень 2 — передача ответственности. Конкретный список решений, которые переходят от CEO к директору каждый квартал. Фиксируется в начале, проверяется в конце. Это основной KPI.

Уровень 3 — стратегическое плечо. Насколько директор освобождает CEO для работы над тем, что CEO делает лучше всего — продукт, клиенты, инвесторы. Это измеряется через структуру времени CEO, а не через метрики директора.

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

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

Но есть один момент, который разрушает даже хорошо построенную систему.

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

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

Рабочая система KPI для операционного директора в IT включает не только метрики, но и протокол: что происходит, когда CEO хочет вмешаться. Не запрет — это нереалистично. А осознанный выбор: «Я вмешиваюсь сейчас — и фиксирую это как исключение, а не норму».

Три наблюдения из практики, которые стоит держать в голове.

Первое. KPI операционного директора в IT должны измерять изменение в поведении CEO, а не только в поведении директора. Если CEO не изменил своё расписание — система не работает.

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

Третье. В IT особенно важно разделить KPI на «операционную стабильность» и «стратегическое делегирование». Первое — необходимое условие. Второе — цель.

Параллельный случай для иллюстрации. По данным Forbes Russia, один из наиболее часто описываемых сценариев в российских IT-компаниях — найм сильного операционного директора из корпоративной среды, который привыкает к чёткой иерархии и ждёт задач сверху. В стартапе или быстрорастущей IT-компании это создаёт паузу: директор ждёт, CEO ждёт инициативы. Через полгода оба разочарованы. Решение — не в замене человека, а в явном контракте на старте: «Ты не ждёшь задач. Ты определяешь зону и берёшь её».

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

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

Это работает только для крупных IT-компаний или для небольших тоже?

Трёхуровневая конструкция KPI масштабируется. В компании с командой 15–20 человек уровень 1 будет проще, уровень 2 — конкретнее. Принцип тот же: измеряем не активность директора, а изменение в поведении CEO. Размер компании меняет конкретные метрики, не логику.

А если операционный директор уже работает год и система не работает — поздно перестраивать?

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

Что делать прямо сейчас, если я узнал свою ситуацию?

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

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

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

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

hi@vvetrov.com — кто ты, что за компания, где сейчас застряло.

P.S. Если директор уже есть и уже не работает — это тоже разбираемо. Иногда дело не в человеке.

Смотри также: Нанял директора за 400 тысяч — и всё равно всё решаю сам: разбор ошибки · Выход из операционки за 6 месяцев: кейс производственной компании · KPI для операционного директора в B2B-услугах: практика · Полный гайд: как выйти из операционного управления

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