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

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

Когда организация выросла до сотен человек, стало очевидно: CTO не должен быть главным инженером компании. Его задача – построить систему, в которой сильные команды и руководители самостоятельно принимают качественные решения. Поэтому фокус смещается с конкретных технологий на архитектуру организации: ответственность, скорость принятия решений, time-to-market, надежность и способность платформы масштабироваться.

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

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

— Где заканчивается роль CTO как руководителя технологической функции и начинается роль стратегического партнера CEO? В каких ключевых бизнес-решениях участие CTO сегодня становится необходимым?

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

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

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

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

Поэтому сильный CTO это не руководитель IT рядом с бизнесом, а один из участников формирования самой бизнес-стратегии.

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

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

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

Параллельно мы существенно меняли архитектуру платформ и инженерные инструменты: уменьшали связанность систем, развивали API, автоматизировали разработку и поставку изменений. Это позволило запускать продукты быстрее и масштабировать их без пропорционального роста сложности.

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

— В вашем опыте есть кейс, где применение машинного обучения в кредитовании позволило одновременно сильно снизить NPL (долю проблемных кредитов) и повысить ROI (рентабельность инвестиций) на 40%. Что должно произойти внутри бизнеса, чтобы ИИ и машинное обучение перестали быть технологическим экспериментом и начали давать измеримый финансовый результат?

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

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

Это был достаточно длинный и поэтапный процесс. Мы тестировали несколько подходов, на каждом этапе собирали обратную связь, смотрели метрики, анализировали результат и только после этого масштабировали решение. Именно такой цикл: гипотеза, внедрение, измерение, корректировка, и привел в итоге к существенному снижению NPL и росту ROI примерно на 40%.

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

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

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

Поэтому сначала мы определяем бизнес-задачу и показатели результата: хотим ли мы увеличить конверсию, сократить время выхода на рынок, снизить стоимость обслуживания, уменьшить количество ошибок, повысить удержание или надежность сервиса. Затем смотрим, способна ли технология существенно повлиять на эти показатели.

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

При этом важно смотреть не только на технические метрики, но и на продуктовые: активные пользователи, конверсия, удержание, стоимость привлечения и обслуживания, выручка или маржинальность продукта.

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

— Сегодня ИИ становится обязательной частью повестки практически любой компании. Как отличить инициативу, которая действительно может изменить экономику бизнеса, от проекта «нам тоже нужен ИИ»? И какие вопросы CTO должен задать бизнесу до того, как инвестировать в такую инициативу?

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

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

Хороший пример – внедрение ИИ в жизненный цикл разработки программного обеспечения. Недостаточно ускорить написание кода на 30–40%, если дальше остаются bottleneck в тестировании, согласованиях или релизах. Нужно смотреть на весь процесс и понимать, что еще необходимо изменить, чтобы реально выросла скорость поставки продукта.

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

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

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

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

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

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

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

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

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

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

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

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

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

Отдельный вопрос инфраструктура и вычислительные мощности. Нужно заранее понимать, как масштабировать нагрузку, автоматизировать развертывание и оптимизировать стоимость ресурсов.

Но полностью предусмотреть локальную специфику невозможно. Поэтому сильная платформа не та, где заранее реализовано все, а та, которую можно быстро и безопасно адаптировать под потребности нового рынка.

— Вы прошли путь от управления командами в 50+ человек до 600+ специалистов. Что принципиально меняется в роли CTO по мере роста организации? В какой момент уже невозможно управлять технологиями напрямую и главной задачей становится построение системы, которая способна эффективно работать без вашего постоянного участия?

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

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

При таком масштабе на новый уровень должны выйти базовые процессы: найм и развитие людей, запуск новых сервисов, работа с архитектурой, управление надежностью и разбор инцидентов. Все это должно быть воспроизводимо и масштабироваться вместе с организацией.

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

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

— Вы много занимались развитием руководителей внутри технологических команд. По каким признакам вы понимаете, что перед вами не просто сильный инженер, а будущий технологический лидер? И можно ли вообще научить человека быть таким лидером?

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

Для меня лидер это человек, который способен повести за собой людей, взять ответственность и прийти не только с проблемой, но и с вариантами ее решения, а еще лучше уже решить При этом он не боится ошибаться, умеет делать выводы и постоянно развивается.

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

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

Научить лидерству полностью, наверное, нельзя. Это приходит через свой собственный опыт. Но можно создать условия, в которых ответственность, самостоятельность и способность работать с людьми будут развиваться. И именно в такой среде будущие лидеры становятся заметны.

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

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

В одном из банковских кейсов бизнесу нужно было быстро запускать большое количество новых кредитных продуктов. Формально можно было продолжать дорабатывать существующую платформу, но это давало бы все меньше эффекта и все больше ограничений. Умение показать, что изменение архитектурного подхода даст не только более быстрый запуск следующих продуктов, но и позволит подключать дополнительные данные, гибче настраивать кредитные сценарии и масштабировать решение дальше.

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

Иногда правильное решение – принять долг. Иногда – остановить инициативу. Главное, чтобы это было осознанное бизнес-решение, а не следствие накопившихся технологических ограничений.

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

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

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

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

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

• Интервью: Операционная система бизнеса как драйвер роста – взгляд операционного директора на трансформацию, эффективность и управляемость бизнеса.

• Интервью: Портфель как стратегия – как управлять активами, стоимостью и ростом в новой реальности

• Интервью: «Идеальный второй»: как Chief of Staff превращает видение CEO в работающую систему.