Записки CTO про код и карьеру

Интервью о карьере, управлении командами и искусстве быть CTO

Летом на SouthHub я познакомился с Мишей Трифановым. Миша и команда Cloud.ru записывают подкаст, и недавно пригласили меня поговорить о том, как пройти путь от разработчика до CTO, управлять командами разных размеров и внедрять изменения, оставаясь при этом продуктивным и сохраняя баланс между работой и личной жизнью.

Мой топ интересных мыслей из интервью
    1. Брать на себя ответственность и делать результат — главный ключ к росту в любой компании.
    2. Роль CTO — это переводить язык технологий на язык бизнеса
    3. Хороший лидер должен уметь делегировать, иначе выгорание неизбежно.
    4. Если вы хотите расти в карьере, важно не только быть хорошим разработчиком, но и понимать, как работает бизнес.
    5. Тимлид — это не лучший программист в команде, а тот, кто делает команду эффективной.
    6. Важно строить такие процессы, которые помогают компании работать стабильно даже без вашего постоянного участия.
    7. Внедрение изменений — это постоянная работа, и сопротивление всегда будет, но оно преодолимо.
    8. Важная часть работы CTO — это долгосрочное планирование, чтобы компания оставалась на острие технологий.

Если вам интересно узнать больше о лидерстве в IT и моем пути, заходите по ссылке и смотрите интервью.
- YouTube
- VK Video

Как выстраивать работу в командах, чтобы она была не только эффективной, но и адаптивной к изменениям?

В последнее время я часто отвечаю на этот вопрос, рассказывая про фреймворк Team Topologies, описанный в книге Мэтью Скелтона и Мануэля Пайса. Он предлагает структурированный подход к организации команд и выстраиванию взаимодействия между ними.

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

Типы команд
- Stream-aligned team — это основной тип команды в организации. Такие команды сосредоточены на конкретном потоке ценности (продукте, услуге или функции) и полностью отвечают за разработку и поддержку своих продуктов. Они стремятся минимизировать внешние зависимости, чтобы сосредоточиться на быстрой поставке инкрементов, полезных для пользователей. Как правило, такие команды кросс-функциональные, то есть включают специалистов с различными компетенциями, необходимыми для самостоятельного выполнения задач.
- Platform team — создают платформенные решения, необходимые для работы других команд. Обычно это команды, которые превращают инфраструктуру в сервис для разработчиков. Они должны наладить сбор обратной связи от пользователей их платформы.
- Complicated subsystem team — работают над системами, требующими глубоких специализированных знаний. Примеры таких систем — поиск, рекомендации, финтех.
- Enabling team — помогают другим командам улучшать свои процессы, внедрять новые технологии или решать сложные задачи. Например, это может быть команда экспертизы по качеству, которая проводит аудит и помогает улучшить качество работы, или команда, которая помогает выделить функционал из монолита.

Виды взаимодействия
- Collaboration — команды работают вместе для достижения общей цели. Это самый «дорогой» вид коммуникации, поэтому его стоит использовать только тогда, когда это действительно необходимо.
- X-as-a-service — команды предоставляют сервисы или платформы другим командам с четкими SLA и документированными интерфейсами. Это снижает потребность в частых коммуникациях.
- Facilitating — основной тип взаимодействия для Enabling team. В его рамках они помогают другим командам улучшать процессы или решать технические вызовы.

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

Существует бенчмарк, согласно которому, для быстрой и эффективной работы поставки ценности, большинство команд в организации должно быть Stream-aligned team, а их взаимодействие преимущественно — по типу X-as-a-service.

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

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

Какой я руководитель. Мой Manager ReadMe

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

На просторах интернета я наткнулся на идею создать Manager ReadMe — такой же стартовый файл, который описывает, какой ты менеджер. Идея показалась мне интересной, поэтому я решил составить такой документ про себя.

— Я придерживаюсь принципов Radical Candor и даю открытый фидбек.
— Если я даю обратную связь, моя единственная мотивация  помочь стать лучше.
— Если ты не согласен с тем, что я говорю, выскажи это открыто.
— Мои решения могут быть не идеальными; если хочешь их улучшить, не стесняйся предлагать альтернативы.
— Если мы о чём-то договорились, это должно быть выполнено.
— У каждого руководителя, независимо от его роли, должно быть видение того, куда он ведёт и развивает свою команду.
— Я хочу, чтобы все менеджеры в моей команде были hands-on и deep dive. Не люблю менеджеров-администраторов, с которыми невозможно вести содержательную беседу.
— Мне нравятся гибкие подходы, и я стремлюсь строить автономные, зрелые, самостоятельные команды.

Чем отличается онбординг, когда я менял команду внутри Авито и когда перешёл в Яндекс?

Казалось бы, онбординг всегда одинаков: новые люди вокруг, новые задачи, новая команда.

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

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

Сейчас в Яндекс, мне приходится узнавать всё с нуля. Да, я принёс с собой багаж знаний, но прежде чем их применять, мне нужно понять, как всё работает в новой среде и почему именно так. Мне нужно разобраться, кто здесь ключевые люди и кто поможет мне внедрять изменения в команде.

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

Что объединяет команду: Личный опыт и проверенные практики

Сегодня прочитал классный пост у Вовы Коноплёва: https://t.center/konoplevthoughts/189. Вова рассказывает о практиках, которые он с командой попробовал в этом году, чтобы найти ответ на вопрос: "Команда мы или нет?"

Мне этот пост очень откликнулся, так как я с моей командой в Авито проходил очень похожий путь :) Тоже поделюсь своим списком.

🟢 Ретроспективы
Я люблю их проводить и делаю это часто. Если не использовать шаблонные форматы вроде "давайте обсудим, что было хорошо и что не очень", то ретроспективы всегда заходят на отлично в любые команды.

🟢 Кайфовать вместе
Это про бары, караоке, кальяны, совместные выезды и так далее. Всегда отлично работает для любых команд. :)

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

🟡 Тест Хогана
Это большой личностный тест. В результате каждый участник получал описание особенностей своей личности, разложенное по факторам. Дополнительно коуч собирал профиль всей команды.

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

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

🟢 Общие технические цели
Моя ставка была на то, что совместная работа и общие цели помогут сплотить команду. На роль такого общего проекта отлично подошла разработка технической стратегии для вертикали "Товары".

Ставка сработала. Проект позволил нам плотно поработать вместе, а получившиеся стратегические цели оказались клеем, которого нам не хватало.

Два года назад я выступил на Podlodka Teamlead Crew с докладом «Первые 90 дней на новой работе: онбординг тимлида». Сейчас я сам прохожу онбординг в Геосервисах, вспомнил свои советы и решил поделиться ими снова:

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

Также делюсь самим выступлением, слайдами и шаблонами, о которых рассказываю:
- Видео выступления
- Слайды
- Шаблон чек-листа онбординга
- Шаблон целей для себя или своей команды в формате OKR
- Шаблон инструмента Star Map

Привет, Яндекс!

На этой неделе я присоединился к команде Яндекса на позицию CTO Геосервисов.

За 6,5 лет в Авито удалось сделать многое. Запустить три вертикали, каждая из которых выросла с нуля до ста инженеров. Развить Авито Доставку и вертикаль Товары. Собрать сильную команду инженеров и менеджеров. Перестроить направление приёма платежей в полноценный финтех-сервис с кошельками, кредитами и сложными транзакционными сценариями. Разработать и внедрить множество HR-практик для инженерной команды Авито. И многое другое.

Многие коллеги спрашивали меня: "Толя, всё же было классно, ты на пике, зачем уходишь?". В Авито действительно крутая команда, по которой я буду скучать, но после всего сделанного душа просит новых вызовов :)

Пару лет назад я смотрел выступление Лёши Шаграева "Уйти красиво: как покинуть любимую компанию с пользой для всех".

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

Я благодарен за всё, что было в Авито, но пора двигаться дальше. Посмотрим, что получится в Яндексе.

Менеджеры с синдромом отличника и делегирование

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

Часто это происходит из-за того, что люди не могут начать делегировать. "Я же могу сделать это лучше, зачем кому-то за это платить? Потом еще и переделывать придется!"

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

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

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

Сегодня мы записывали подкаст с командой cloud.ru на тему масштабирования команд и того, как менеджеру расти вместе с командой, начиная с тимлида и дорастая до CTO.

Огромное спасибо Мише Трифонову за приглашение и интересный, душевный разговор. Мы записали два часа материала, из которых нужно оставить всего один. Посмотрим, что останется после монтажа :)

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

Нужны ли матрицы компетенций?

Существует два диаметрально противоположных мнения: — «Дичь какая-то, мы тут все снежинки, нам такое не подходит» и — «Это супер удобно, не понимаю, как люди живут без них».

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

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

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

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

В «Авито» нам удалось построить такую рабочую и живую систему на базе матриц компетенций, которая успешно зарекомендовала себя за последние пять лет, позволив нам вырасти с 300 до 2000 инженеров.

Сегодня участвовал в панельной дискуссии с коллегами из Сбера, Самолёта и УБРиР на тему "Проектное управление в ИТ: олдскул или вы просто не умеете его варить?".

Мысли, которые звучали на дискуссии и которые меня зацепили:
- Несмотря на гибкие подходы в разработке, проджекты и проекты никуда не исчезли.
- Проджекты подключаются к большим проектам, где участвует много команд и разных департаментов. Командам требуется много синхронизации сроков и усилий, или есть аутсорс, или аутстафф, или много сложных стейкхолдеров.
- Больших проектных офисов в компаниях спикеров не осталось, проджекты работают децентрализовано. В некоторых компаниях есть центры экспертизы, которые помогают поддерживать общие практики управления проектами.
- Роль проджекта размылась, и сейчас это больше роль, которую может выполнять кто-то из команды: продукт-менеджер, тимлид или отдельный человек — проджект.
- Точно так же со скрам-мастерами: в новых командах они есть, а потом это становится ролью кого-то из команды. Скрам-мастера начинают отдаляться от команд и делать более сложные и масштабные задачи.
- Какие навыки нужны проджекту? Главный — ему не должно быть всё равно. Кроме этого, понимание гибких методологий и немного технической экспертизы. Ну и управление проектами, конечно.
- Почему 50% проектов проваливается? Пожимают по срокам, на которые не согласна команда. Но тут ещё вопрос: а почему это плохо? Если была нормальная коммуникация со стейкхолдерами, проект в целом успешен и запущен, и всем ок, то не всё ли равно?
- Почему PMO часто оторваны от реальности и делают бесполезное? Им не хватает продуктового подхода в своей работе. Если думать о пользователях и решать их проблемы, то всё будет хорошо.

Дружочки, уже завтра в 18:30 ждем вас (а вас аж 300 зарегистрировавшихся, у нас тотальный солдаут) в БЦ Кунцево-плаза, ул Ярцевская 19.

Вам нужен вход в бизнес-центр и 5й этаж, там уже не потеряетесь ❤️

Трансляция будет здесь 😎

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

Нужны ли современному CTO навыки продуктового и бизнес-управления?

В разговорах с коллегами уже несколько раз всплывала тема о необходимости для CTO навыков продуктового и бизнес-управления. Нужны ли они современному CTO или нет?

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

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

Когда я только начал свой путь в Авито, я инвестировал много времени и усилий, чтобы получить продуктовые и бизнесовые знания. Что мне это дало?

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

Если вы сейчас думаете, что стоит изучить, чтобы быть конкурентным на рынке, то навыки продуктового и бизнес-управления определённо стоит включить в этот список.

Single Team Oriented Service Architecture

Долгое время я выстраивал архитектуру и команды вокруг неё, руководствуясь следующими принципами:
- Строить архитектуру на базе сервисов.
- У каждого сервиса должна быть команда, которая за него отвечает.
- Одна команда может отвечать за много сервисов, но много команд не могут отвечать за один и тот же сервис.
- Команда отвечает за разработку сервиса целиком и за его эксплуатацию во всех окружениях.
- Каждый сервис сам отвечает за хранение своих данных.
- Каждый сервис обеспечивает публичный контракт для своих потребителей с помощью удобного и хорошо документированного API и SLA для него.

И вот недавно я узнал, что кто-то придумал всему этому название — Single Team Oriented Service Architecture (STOSA).
Теперь можно всем рассказывать, что я пользуюсь известным фреймворком 🙂

Устали от Беспорядка в Заметках? Попробуйте Zettelkasten и метод PARA для их идеальной организации

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

В прошлом году один мой бывший коллега познакомил меня с программой Obsidian и методом ведения заметок Zettelkasten. Привет тебе, Никита, если вдруг ты это прочитаешь :). Мне стало интересно, и я начал читать разные статьи и книги по теме. Нашёл, что есть и другие похожие методы, например, Вечно зеленые заметки (Evergreen notes). Вся эта тема называется Личная Система Управления Знаниями или Personal Knowledge Management (PKM).

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

Вторым открытием для меня стал метод PARA из книги «Building a Second Brain» by Tiago Forte. Он смотрит на заметки немного под другим углом. Тиаго говорит, что вся наша взрослая жизнь — это обычно какие-то проекты или области интересов. Например, написать этот пост — это небольшой проект, или запланировать отпуск — тоже проект. Отличительная черта проекта — его конечность и ограниченность во времени. Писательство и путешествия могут быть областями моих интересов. Здесь уже нет конца, и пока мне эти темы интересны, я могу изучать материалы и улучшать себя довольно долгое время. В этой концепции заметки должны помогать нам заканчивать проекты и быть полезными в рамках наших областей интересов. Задача — сделать так, чтобы когда я сел писать статью или начал планировать новую поездку, вся нужная информация была у меня под рукой и мне не нужно было тратить много времени на её поиск.

Что изменилось после моего знакомства с этими методами ведения заметок? В моих заметках появилась понятная мне структура. Мой внутренний перфекционист уже только от этого радостно потирает ладошки 🙂

Но кроме этого, мне показалось отличной идеей объединить эти два подхода.

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

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

Меня часто спрашивают: "Зачем нам техническая стратегия в постоянно меняющемся мире?". Действительно, зачем планировать на 3-5 лет вперёд, если каждый год возникают кризисы, пандемии, конфликты, а в будущем и вовсе могут появиться неожиданные угрозы?

Техническая стратегия – это не жёсткий свод правил. Это направление, которое помогает нам адаптироваться и развиваться. Стратегия должна быть живой и поддаваться корректировке, чтобы соответствовать меняющимся условиям.

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

Что такое гибкая стратегия? Это как Scrum. Этот метод разработан для достижения целей в условиях хаоса. Мы движемся итеративно, постоянно проверяя, не сбились ли с пути. Стратегия в быстро меняющемся мире очень похожа на этот подход. Мы должны двигаться спринтами, отслеживать прогресс в каждом спринте, и если цель утратила актуальность из-за внешних факторов, это нормально – нужно остановиться и поставить новую цель, учитывая новые обстоятельства.

Кроме просто участия в South HUB, мне ещё посчастливилось открывать конференцию своим выступлением.

Я рассказал о том как росла команда разработки Авито, о том какие у нас были вызовы. Про наши менеджерские инструменты и практики, которые помогли нам на этом пути.

На слайдах было много QR-кодов со ссылками наш playbook на GitHub. Для читателей канала - бонус в виде удобных ссылок 🙂
- Матрица компетенций инженера
- Матрица компетенций технических менеджеров
- Technical Design Review (TDR)
- Team Maturity Model
- Avito Platform as a Service (PaaS)
- Общее описание процесса найма

Если после просмотра выступления у вас остались вопросы или хочется больше деталей про инструменты или подходы, то приходите в комментарии 🙂

Само выступление можно посмотреть здесь, а следующим постом выложу слайды.

В июне в Сочи прошла конференция для CTO "South HUB". Это мероприятие проводится уже в третий раз, но мне удалось поучаствовать только в этом году.

Я давно перестал посещать Team Lead Conf и менеджерские митапы, так как нового и интересного для меня контента там практически не появляется. Вы скажите "но кроме контента, есть ведь ещё и нетворк", и это бесспорно так! Но у ребят которые приезжают на подобные мероприятия вызовы и задачи сильно отличаются от моих. На этом фоне South HUB выгодно выделяется. Организаторам удалось собрать очень крутое комьюнити и программу. Столько контактов в записной книжке и идей я ещё ни с одного мероприятия не увозил.

Если вы тоже давно не были на классных менеджерских эвентах, рекомендую подумать про South HUB в следующем году 😃