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

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

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

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

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

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

— На мой взгляд, ключ к ускорению delivery и time-to-market — это инженерная культура, а не отдельные процессы или инструменты.

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

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

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

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

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

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

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

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

Еще одна типовая ошибка — менять архитектуру, но не менять процессы и организационную модель. Микросервисы требуют другого уровня ownership, ответственности и взаимодействия команд. Без этого они не ускоряют delivery, а лишь усиливают хаос.

И, наконец, многие компании недооценивают финансовую сторону трансформации. Микросервисы — это не только код, но и инфраструктура, процессы, поддержка, on-call, observability. Без оценки стоимости владения и сопоставления ее с ожидаемой выгодой такие трансформации часто оказываются неоправданно дорогими.

— Что сегодня является фундаментом зрелой инженерной культуры? И как ее выстроить, когда команда быстро растет?

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

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

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

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

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

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

Поэтому важно не бояться расставаться с людьми, которые последовательно подрывают культуру — даже если они кажутся «незаменимыми». Как показывает практика, незаменимых людей не бывает. В противном случае возникает эффект «clubhouse cancer», когда токсичное поведение становится нормой.

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

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

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

Второй важный сценарий — усиление инженеров и продуктовых команд. AI не заменяет специалистов, а снижает когнитивную нагрузку и ускоряет цикл: помощь в разработке кода, генерация тестов, code review, анализ логов и инцидентов, быстрое прототипирование. Это напрямую влияет на скорость delivery и качество.

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

При этом эффект AI часто переоценивают:

• В первую очередь — в попытках построить универсальных AI-агентов «на все» без четких границ, ответственности и контроля.
• Вторая распространенная ошибка — стремление заменить людей, а не усилить их.
• Третья — ожидание быстрого ROI «из коробки». AI не бесплатен: он требует данных, интеграции, изменений процессов и культуры работы. Без этого можно получить нулевой результат за очень большие деньги.

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

И, наконец, стоит критически относиться к самому термину «AI»: сегодня его часто используют как маркетинговую упаковку, за которой не всегда стоит реальная генеративность или измеримая бизнес-ценность.

— Технологическая интеграция при M&A — сложный процесс. На какие риски чаще всего не обращают внимания, и как подготовиться к такой трансформации?

— На мой взгляд, ключевые риски технологической интеграции при M&A лежат не столько в технологиях, сколько в отсутствии целостной стратегии после сделки.

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

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

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

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

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

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

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

CTO, который говорит только «нам нужно», почти всегда проигрывает.

CTO, который говорит языком бизнеса, — выигрывает доверие.

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

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

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

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

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

— Переход из роли senior-инженера в управление большой технической организацией — это другая профессия. Что критично развивать в первые 12–18 месяцев, чтобы стать сильным лидером?

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

На практике этот переход почти никогда не происходит резко. Между senior-инженером и лидером есть несколько промежуточных этапов: рост ответственности, неформальное лидерство, влияние на решения и людей, управление командой, затем — несколькими командами и дальше — вширь организационной структуры. Со временем появляется необходимость управлять не только инженерами, но и другими менеджерами и функциями, например, product или project management.

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

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

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

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

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

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

Если вы CTO или технический лидер и хотите системно развивать свою роль и влияние — свяжитесь с командой Benchmark.

Читайте наши полезные материалы

• Как вывести бизнес на новый уровень в эпоху цифровых технологий.

• О будущем финтеха, искусственном интеллекте и командах.

• От DevOps к техническому директору: интервью с Ольгой Русаковой, ex-техническим директором в Leroy Merlin, ex-Aliexpress, ex-Luxoft.