Привет! Это ИнженеркаТех и наш проект «Три Крюка». Здесь мы не просто берем интервью, а лезем «под капот» к тем, кто задает вектор развития современных технологий в компании - к CTO.
Сегодня у нас в гостях Дамир Афлятунов (СТО «Штрафы ГИБДД»). Тяжеловес в мире IT с 18-летним бэкграундом. Он прошел путь от рядового разработчика до CTO, успев поработать в таких гигантах, как Газпромбанк и Магнит. В его портфолио лежит запуск масштабных digital-продуктов: от e-commerce до сложных финтех-сервисов по оплате штрафов и онлайн-страхованию.
Дамир мастерски превращает хаос в порядок: выстраивает архитектуру, внедряет прозрачные delivery-процессы, настраивает CI/CD и Agile так, чтобы команды до 30 человек поставляли фичи в прод предсказуемо и без багов.
Сейчас его фокус - архитектурное переосмысление для масштаба:
как построить системы, которые растут без конфликтов между командами;
как внедрять паттерны для автономии команд;
как использовать ИИ для ускорения инженерной культуры, а не только для писания кода.
И сегодня поговорим о том, как вырасти из техлида в директора, как нанимать лучших на сложном рынке и где в работе CTO заканчивается код и начинается чистый бизнес...
Фаря:
Как именно произошел переход из техлида в CTO? Тебя назначили или это был твой запрос?
Дамир:
Я изначально пришел на позицию техлида. Переход произошел органично, когда предыдущий CTO покинул пост. Руководство увидело мою активность, вовлеченность в бизнес-задачи: я переделал архитектуру деплоя, внедрил принципы модульной разработки для растущих команд и показал, как синхронизировать несколько продуктов через единую платформу. Это позволило трём командам работать параллельно без блокировок. Руководство увидело, что я не просто вовлечен, а систематически улучшаю способность компании масштабироваться.
Это не был четкий план мол «стану директором к 30 годам». Скорее, я всегда плыл по течению своего интереса: мне хотелось влиять на продукт целиком, а не только на его части. Желание наводить порядок в процессах само вытолкнуло меня из чистого кодинга в управление.
Какие задачи занимают 80% твоего времени как CTO?
Большая часть времени - это архитектурные решения и дизайн систем:
как организовать команды так, чтобы их структура отражала структуру нашей архитектуры,
как спроектировать систему, чтобы разные продукты не мешали друг другу,
как выстроить ясные границы ответственности и контракты между сервисами.
Когда ко мне приходят продакт-менеджеры и техлиды с задачей, я вижу её через призму архитектуры. Это требует синхронной или асинхронной работы? Нужен ли новый микросервис или интеграция через message queue? Как это повлияет на другие системы и на скорость их команд?
Есть и квартальное планирование вместе с CPO и CEO: мы смотрим, где мы сейчас, какие есть продукты, техдолг, проблемы и как развиваться дальше.
Вообще, на позиции CTO 80% времени - это всегда менеджмент, управление и бизнес, и только 20% (или даже меньше) - техника. Главная задача здесь — не писать код самому, а обеспечивать надежность системы, скорость поставки фич и понимать, как технологии помогают компании зарабатывать деньги.
Но, честно говоря, иногда я могу залезть в код, чтобы провести архитектурное ревью, помочь разобраться со сложным багом или написать небольшой скрипт для автоматизации внутренних процессов.
Как ты балансируешь между инженерными хотелками и бизнес-целями?
Техдолг не абстрактен - это финансовая модель. Если рефакторинг архитектуры задерживается на месяц - это значит, что три команды на неделю теряют скорость, потому что не могут работать параллельно без конфликтов.
Три команды × потерянная продуктивность × зарплаты = реальная стоимость.
Когда техдолг считается в деньгах, а не в "хотелках", решения принимаются быстрее. Мы моделируем финансовый импакт каждого архитектурного решения: сколько оно дает в скорости доставки, сколько снижает количество инцидентов, сколько экономит на пропускной способности команды.
Есть ли у тебя личные лайфхаки, которые помогают держать этот баланс между инженерами и бизнесом?
Главный лайфхак - быть ближе к разработчикам и понимать их текущие боли. Самые простые управленческие вещи, которые помогают держать контакт - это смолтолки, ван-ту-ван, вопросы вроде: «почему ты сделал задачу именно так?” и “какие у тебя проблемы?».
С бизнесом мне проще, чем с разработчиками. Опыт позволяет объяснить, почему стоит менять флоу продукта или отложить что-то ради скорости. Поэтому основное внимание я уделяю именно разработчикам, потому что сам из разработки и хорошо понимаю их контекст.
То есть сложнее всего договориться именно с разработкой?
Да. С бизнесом можно объяснить на языке выгоды. С разработкой труднее: они могут не учитывать бизнес-цель. Я стараюсь работать так, чтобы у команды был фокус и понимание, зачем мы делаем задачу. Так проще оценивать и измерять эффективность команды разработки. Можно смотреть Jira-статистику, например, стабильность выполнения задач. Но я оцениваю и по-человечески. Если разработчик понимает контекст и стабильно приносит результат, хочет пробовать новые задачи, то это показатель эффективности.
Также я стараюсь выделять проактивных. Это всегда первый признак хорошего Тимлида. Если человек видит проблему и сразу предлагает решение, а не просто констатирует, что что-то сломалось, то это всегда хороший сигнал для меня.
Какие самые частые провалы у инженеров?
Главный провал - это локальная оптимизация. Инженер пишет идеальный код по SOLID, добавляет расширяемость для "будущих кейсов", но не видит общей картины. Например:
Какова вероятность, что эта расширяемость понадобится?
Сколько когнитивной нагрузки это добавляет новичку?
Сколько времени занимает codereview из-за лишней сложности?
В FAANG рост инженера измеряется способностью влиять на широкие компоненты архитектуры и системы целиком, а не красотой отдельного модуля. Нужно уметь отказываться от красивого решения в пользу решения, которое позволяет другим командам двигаться быстрее.
Точно. Немного меньше перфекционизма, чуть больше понимания бизнеса и коммуникации - и вот уже идеальные инженеры.
Очень тяжело найти таких. Часто цели бизнеса и разработчика не совпадают. Разработчик хочет делать платформу и рефакторинг, а бизнесу нужен продукт. Найм занимает много времени и дорого стоит, плюс онбординг требует усилий тимлида или старшего разработчика.
А кого сейчас особенно не хватает?
Back-end разработчиков. Когда мы были на PHP, то было сложно нанять сильных middle+ разработчиков. Но в этой ситуации можно переосмыслить архитектуру - выделить критичные пути (обработка платежей, обработка штрафов) в отдельные сервисы. Теперь можно поговорить с senior-архитектором, который понимает trade-offs между языками и поможет принять решения на уровне сервиса: когда стоит Go, когда Python, когда остаться на PHP. Это совсем другой уровень найма и интервью.
Чем отличается техлид от тимлида?
Тимлид отвечает за людей, трек, доставку. По сути, это менеджер. Техлид отвечает за качество архитектурных решений, за консистентность стека и за то, чтобы решения масштабировались за границы одной команды. В компаниях, которые масштабируются, появляется промежуточный уровень - TechLead Manager. Он отвечает за технический вектор нескольких тимлидов, за синхронизацию между командами и за то, чтобы архитектурные решения не создавали узких мест. Это уровень, где вы думаете не о том, как одна команда пишет код, а как система команд создает консистентную платформу. Вот это и есть реальный шаг к CTO.
Техлид может подчиняться тимлиду, особенно в продуктовой разработке. Тимлид - это «мини-CTO»: он рулит ресурсами и приоритетами, а в его команде может быть техлид как эксперт по технологиям.
А что нужно подтянуть тимлиду, чтобы стать CTO?
Понимать, чего хочет его руководитель и почему. Собирать картину из задач разных команд и видеть, как они складываются в общую стратегию.
Веришь в обучение?
Да. Курсы бывают разными. «Стань разработчиком за 3 недели» — это моветон. Но если человек с опытом понимает, что ему нужно подтянуть, курс может сильно ускорить. У нас был пример с QA: сотрудник выбрал курс по автоматизации, и это реально помогло. Я сам недавно брал консультации у ментора - лидера направления из Сбертеха, о том, как синхронизировать 3-4 команды так, чтобы они не блокировали друг друга. Мы переиграли весь процесс. Вместо еженедельных синхронов по каждому проекту, ввели архитектурные рамки - явные API контракты, SLA между сервисами, ответственных за каждый сервис. Скорость delivery выросла на 40%, потому что команды перестали ждать друг друга на уровне интеграции.
Еще хочу изучить глубже архитектуру и системный дизайн. Ещё, как использовать AI для задач высокого уровня: анализ данных, прогнозирование.
Совет будущим CTO от Дамира
Перестаньте думать только категориями «красивого кода» и начните думать категориями денег и пользы для клиента. Учитесь разговаривать с бизнесом на их языке. И главное - не бойтесь брать на себя ответственность за ошибки всей команды, а не только за свои.
Вот те самые «Три крюка» - три главных вывода из разговора с Дамиром Афлятуновым, которые помогут вам по-новому взглянуть на управление разработкой:
CTO - это про архитектуру систем и организационные структуры. Переход из техлида происходит, когда вы начинаете думать не о том, как пишется код, а о том, как структура команд определяет структуру архитектуры. CTO не валидирует пул-реквесты. CTO проектирует системы, которые позволяют параллельной работе.
Лидеру нужно отказываться от красивого решения в пользу решения, которое позволяет другим командам двигаться быстрее. Инженер может написать идеальный код по SOLID, но если он не видит импакта на масштабируемость всей платформы, то это локальная оптимизация.
Техдолг - это финансовая модель, не бэклог. Задержка в рефакторинге архитектуры считается как замороженный ресурс: 3 команды × 3 недели × зарплата = конкретная стоимость. Когда техдолг считается в деньгах, а не в "хотелках", приоритизация становится объективной и скорость принятия решений растет.
Спасибо, что дочитали до конца. Подписывайтесь на наш Telegram-канал ИнженеркаТех. Там мы публикуем полезные подборки от инженеров, делимся инсайтами и обсуждаем, как инженеру middle+ уровня вырасти в лидера индустрии.
