Почему CTO нужен CDO: инструкция по выживанию в мире, где технологии есть, а бизнес всё равно страдает

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

Сразу оговоримся: под CDO здесь имеется в виду Chief Digital Officer — директор по цифровой трансформации, а не Chief Data Officer. Это важно, потому что «директор по данным» и «директор по цифре» — родственники, но не близнецы.

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

CDO — это человек, который отвечает на вопросы: «Зачем мы это строим? Что это меняет для бизнеса? Как это поможет клиенту?» Цифровая стратегия, трансформация процессов, клиентский опыт, новые бизнес-модели. Если CDO приходит на встречу, от него обычно пахнет слайдами про NPS, воронку и «а давайте сделаем онбординг клиента за три минуты, а не за три недели».

Грубо говоря:

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

CTO уже построил систему. Она работает. За неё он отвечает. Его KPI — это uptime, безопасность, отсутствие инцидентов, предсказуемость релизов и чтобы в три часа ночи не звонил дежурный с криком «всё упало». А теперь приходит кто-то с презентацией «давайте внедрим новую технологию» — и для CTO это не «возможность», а миграция, новые зависимости, обучение команды, риск падения и ещё один тикет в три часа ночи.

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

Это не значит, что CTO всегда прав. Это значит, что CDO нужен не для того, чтобы «продавить инновации силой», а для того, чтобы добавить второй критерий: не только «не сломать», но и «изменить управляемо и с пользой для бизнеса».

По роду своей деятельности я очень часто общаюсь с директорами по ИТ. И должен сказать: в большинстве компаний этот человек — один. Он и CTO, и CDO, и немножко директор по кофе. Настоящий «царь и всея цифры». Про CDO многие из них раньше вообще не слышали. Типичная реакция: «У нас есть директор по ИТ — что ещё нужно?» И это не глупость. Это просто другая реальность, в которой человек десять лет тащит на себе всю технологическую инфраструктуру и привык отвечать за всё сразу.

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

За несколько десятков CTO, с которыми я сталкивался, только двое сочетали в себе и умение, и желание управлять стабильной экосистемой, и при этом понимали необходимость внедрения новых технологий, подходов и принципов. И знаете, что их объединяло? У обоих был опыт управления собственными ИТ-компаниями. То есть им не понаслышке была знакома важность экономической эффективности внедрения, запросов бизнес-пользователей, их удобства — так называемого юзабилити — и неотвратимость использования новых подходов и технологий.

Вот это и есть тот самый баланс, о котором мы говорим. Не «CTO против CDO», а «CTO, который умеет думать не только о стабильности, но и о бизнесе». Но таких — единицы. И именно поэтому в большинстве компаний нужен отдельный CDO, который привносит этот второй взгляд, не отбирая у CTO его зону ответственности.

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

Но клиенты почему-то не пользуются половиной функций. Потому что:

CDO приходит и говорит: «Ребята, технология отличная, но давайте перестроим клиентский путь, чтобы человек оформлял карту за две минуты».

CTO сначала упирается: «Не трогайте приложение, у нас стабильность, у нас релиз, у нас вообще всё работает». И это честная позиция: он отвечает за систему, которая уже живёт. Тут важно не воевать, а договориться. CDO приносит данные: «40% клиентов бросают оформление на третьем шаге». CTO видит не «хайп», а конкретную проблему. Дальше делают не «большую переделку всего», а пилот: новая кнопка на 5% трафика, feature flag, план отката. Стабильность не ломаем, бизнес-эффект проверяем.

Вот это и есть баланс: CTO отвечает за то, чтобы приложение работало. CDO — за то, чтобы оно приносило деньги и не отпугивало клиентов.

На заводе CTO внедрил систему мониторинга оборудования. Датчики есть, данные идут, дашборды светятся. Технически — вау.

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

CDO в этой истории — не «еще один начальник с презентацией». Он меняет процессы: договаривается с производством, упрощает интерфейс, обучает людей, считает эффект. CTO сделал систему. CDO сделал так, чтобы система реально использовалась, а не жила красивой картинкой в отчете.

И да, CTO здесь может сопротивляться: «Система работает, данные собираются, что вам ещё надо?» Но «данные собираются» и «завод экономит деньги» — это две разные новости. Вторая — как раз работа CDO.

В маленьком стартапе основатель часто совмещает роли: он и CTO, и CDO, и немного «директор по кофе». Это нормально, пока компания маленькая. Но когда продуктов становится больше, клиентов больше, а процессов — как в минном поле, начинается классическая проблема:

Если роли не разделены, получается либо «технология ради технологии», либо «фичи ради фич без фундамента». CDO нужен не для того, чтобы отобрать у CTO власть. Он нужен, чтобы у технологий был понятный бизнес-смысл.

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

Итог без CDO часто такой:

Тоже весело. CDO нарисует красивую цифровую стратегию: «мы станем клиентоцентричной платформой, у нас будет супер-онбординг и AI везде». А кто это строить будет? Кто отвечать за архитектуру, надежность и безопасность? Если нет сильного CTO, цифровая стратегия рискует остаться красивой презентацией, которую показывают инвесторам под грустную музыку.

Хороший тандем CTO + CDO — это не «технарь против бизнесмена». Это две стороны одной медали:

CTO смотрит внутрь технологии. CDO смотрит наружу — на рынок, клиента и бизнес-результат. Один обеспечивает технологическую состоятельность. Второй — бизнес-релевантность.

И ещё раз: сопротивление CTO изменениям — это часто не вредность, а защита того, за что он уже отвечает. Задача CDO — не снести эту защиту, а сделать изменения безопасными для стабильности и понятными для бизнеса. Пилоты, метрики, поэтапный rollout, план отката — вот язык, на котором такой разговор становится конструктивным.

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

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

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

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