Когда я рос из инженера в управленца, мне казалось, что различия между CTO, CIO и COO во многом формальные. Всё же «про технологии», «про управление», «про процессы».

На практике оказалось, что это три разных способа смотреть на компанию. И путаница между ними начинает дорого стоить именно тогда, когда бизнес перестаёт быть маленьким.

Я прошёл путь от инженерных ролей до CTO и в том числе выполнял функции COO в компании до 500 человек (около 60 в IT департаменте), входящей в состав корпорации.
И именно на этом масштабе разница между этими ролями становится особенно заметной.

CTO: когда технология — это стратегия

CTO отвечает не за код и не за разработку как процесс, он отвечает за технологическое будущее компании.

Это роль про выбор направлений и ограничений:

• на каких технологиях строится продукт

• где мы готовы идти быстрее, а где закладываем надёжность

• какой технический долг допустим

• какие риски мы осознанно принимаем

Самое сложное в роли CTO для меня на первых этапах было перестать решать задачи руками. Инженерное прошлое постоянно тянет «пойти и сделать правильно», но на уровне CTO это уже ловушка.

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

А CTO нужен бизнесу не для того, чтобы чинить проблемы, а чтобы не создавать их в будущем. И именно здесь я осознал, что даже самая идеальная стратегия может не принести бизнесу ожидаемых бенефитов без надлежащей операционки.

CIO: IT как сервис, а не продукт

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

CIO отвечает за IT как инфраструктуру бизнеса:

• внутренние системы

• безопасность

• доступы

• стабильность

• соответствие требованиям корпорации и регуляторов

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

COO: где стратегия сталкивается с реальностью

COO — самая недооценённая и при этом самая сложная роль из трёх.

Если сильно упростить, COO отвечает за вопрос: как всё это будет работать каждый день.

Когда меня просят объяснить суть этой роли простым языком, я привожу следующую аналогию. Если представить, что компания — это солнечная система, то CEO это солнце, CPO/CTO/CIO это планеты, а COO это тёмная материя, которая пронизывает всё пространство.

Здесь заканчивается комфорт технологий и начинается реальность:

• люди

• сроки

• зависимости

• ограничения

• приоритеты

COO работает с последствиями решений, принятых раньше, в том числе технологических. Если CTO может сказать «так будет правильно», то COO должен ответить на вопрос «а как мы это реально сделаем». Самые острые конфликты между CTO и COO возникают не из-за ошибок, а из-за разных горизонтов ответственности: один смотрит на будущее, другой живёт в настоящем.

Почему эти роли путают

Есть несколько причин:

1. Масштаб
В компании из 20-30 человек один человек действительно может быть и CTO, и CIO, и наполовину COO.

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

3. Отсутствие зрелой структуры
Компания растёт, а модель управления остаётся старой.

Именно здесь начинаются проблемы ожиданий:

• от CTO ждут операционки

• от COO ждут технических решений

• от CIO ждут продуктовых инициатив

Итог

Главный инсайт для меня был простым и неприятным. Одна и та же задача может быть решена правильно с точки зрения CTO и при этом быть провальной с точки зрения COO.
И наоборот. Пока я не оказался по обе стороны, я этого не видел.

Если совсем упростить:

• CTO думает о будущем технологий

• CIO отвечает за стабильность IT сегодня

• COO превращает стратегию в ежедневную работу

Проблемы начинаются не из-за самих ролей, а из-за того, что от них ждут не того.

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

В моей практике были ситуации, когда архитектурно верное решение ломало сроки, а операционно правильный компромисс увеличивал технический долг. И оба варианта имели цену.

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

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