Доклады

- Сколько зарабатывают технические директора, структура дохода
- От чего может зависеть уровень дохода, на который может претендовать СТО: рынки (страны), отрасли, размер компании, размер команды, масштаб проектов, софт-скиллз и тд
- Какие хард и софт скиллз ждут от СТО работодатели
- Есть ли разница оценки СТО на российском рынке и на международном

Вы трудились днями и ночами, не покладая рук, прогрызая путь по карьерной лестнице.
И вот свершилось - вы стали CTO!
У вас большой штат, вы руководите другими руководителями. Каждый из них лучше и сильнее вас в своей компетенции.
Но возникает вопрос: «А зачем же нужны вы в этой системе?»

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

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

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

В 2009 году я стал ИТ-менеджером. Стать крупным ИТ руководителем было моей мечтой, мне было интересно, как и за счет чего люди становятся ИТ-директорами и Вице-президентами и я нащупывал собственный путь в этой ипостаси. Сегодня я руковожу крупным ИТ-кластером, мне по-прежнему интересно расти, и я готов поделиться собственным накопленным опытом и исследованием пути моих коллег - C-level СТО компании МТС.
В нашей компании собрана сильная и многогранная команда ИТ-лидеров, каждый из которых прошел уникальный путь к высокой позиции. В своем докладе я собрал обобщенные данные своей и их истории становления, которые смогут вдохновить и помочь тем, кто только начинает свой управленческий путь и уже наметил амбициозную цель. Мы разберем, какими базовыми навыками обладают все СТО в МТС, что считают важным и необходимым в своей профессии и на своем уровне. Отдельно обратим внимание на препятствия, которые им пришлось преодолеть, и советы, которые они могут и хотят дать тем, кто стремится в C-level ИТ.
Бонус – некий форсайт о роли и навыках C-level CTO в ближайшие 10 лет.

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

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

В своем докладе попробую ответить на эти вопросы на примере внедрения инициатив в Яндекс Еде

На конференциях мы постоянно слышим про использование Kubernetes. Создается впечатление, что сейчас кубы — это такой же гигиенический стандарт как git или Jira. Как технический директор компании, занимающейся outstaff я постоянно консультирую наших клиентов и вижу совсем другую картину: мало у кого на самом деле есть кубы. Более того, несмотря на то, что я помогаю организовывать DevOpsConf и продвигаю Kubernetes в России, я не считаю, что кубы нужны любой компании. В этом докладе через призмы своего опыта я расскажу, какие ключевые признаки важны для CTO при выборе инфраструктурного решения. В каких случаях кубы действительно необходимы, а в каких это будет слив бюджета в никуда и Docker Swarm / Nomad будет более чем достаточно.

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

Вы СТО? Ок, а теперь представьте себя в роли стажера.
Скорее всего вам не понравится эта необычная мысль - большинство СТО скажут "Зачем? я же СТО!"
А я считаю эту идею крайне удачной и полезной, и в этом докладе я расскажу:
* Как я, будучи СТО, прошел стажировку в команде обеспечения надежности
* Как это помогло команде увидеть новые проблемы и исправить их
* Как это помогло мне вырасти как СТО
* Какую огромную ценность я вижу в такого рода стажировках для СТО и их команд

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

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

Кейс как рос проект АДЕНЬГИ в 8 раз по объему бизнеса. В 20 раз по людям и какие стадии роста команды проходили на пути с 5 до 120 ИТ сотрудников.
* История роста бизнеса МФО АДЕНЬГИ
* График роста ИТ команды
* Переломные точки в росте роли СТО
* Что помогло перестроить мышление
* Роль физической нагрузки в успехах СТО
* Язык каких цифр понимает бизнес
* "Ты - это не твоя работа"
* Как договориться о сроках релизов
* Почему бизнес не принимает твоих доводов
* Как и кого нанимать в быстрорастущей компании
* Тимлиды -это помощники?
* Проблема бюджетирования и планирования команд/расходов
* Процессы строить или забить?
* Когда и что будем мерить?
* Технический и менеджерский долг когда отдавать?
* Бизнес просит "сократить издержки"
* Как и что показывать бизнесу, говоря о успехах ИТ
* Когда наступает плато и что с ним делать?

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

Как связать IT-затраты с бизнес-результатами? Мы столкнулись с проблемой: IT воспринималось как неизбежная статья расходов, а не инструмент роста. Нужно было найти способ показать влияние IT на ключевые бизнес-показатели.

PL UNIT: внутренняя модель заказов IT-услуг. Мы внедрили систему, в которой каждое бизнес-подразделение (юнит) или проект становится самостоятельным заказчиком IT-услуг, управляет своим бюджетом и отвечает за собственные метрики эффективности.

Прозрачность IT-расходов через юнит-метрики. Каждый юнит теперь оценивает IT-разработку через понятные бизнес-метрики:
1С – скорость закрытия заявок и автоматизация процессов.
ECOM – влияние на онлайн-продажи и конверсию
Продукт - Скорость поставки и увеличения кол-во предложений и так далее

Что мы получили в реальности?
Плюсы:
Прозрачность затрат. Бизнес начал видеть, сколько стоит разработка, тестирование и поддержка.
Фокус на метриках. IT больше не абстрактная “черная дыра”, а инструмент для достижения бизнес-результатов.
Приоритизация задач. Заказчики сами решают, что для них важнее: ускорение процессов, рост продаж или автоматизация.

Но вместе с этим появились серьезные вызовы:
“Почему так дорого?” Юниты начали задавать вопросы о стоимости разработки, тестирования, поддержки.
“Давайте сделаем без смока и регресса.” Когда бизнес увидел расценки на тестирование, попытки “оптимизации” не заставили себя ждать.
Техдолг? Зачем мне за него платить?” Бизнес не хотел тратить деньги на технические улучшения, требуя только новых фич.
Что делать с людьми при отсутствии бюджета?” Проекты откладываются, финансирование урезается — куда девать специалистов, когда нет работы?

В докладе раccкажу: Как мы решили эти проблемы и сделали модель жизнеспособной