Онбординг CTO: как выжить в большом масштабе
Как опытный CTO, я не раз наблюдал и организовывал онбординг для других. Но в этом году впервые онбордился сам — как CTO большой команды.
Меня волновал один вопрос: будет ли этот опыт отличаться? Ответ оказался очевидным — да, и очень сильно
В чем оказались основные отличия?
1. Большой масштаб: нельзя быстро погрузиться во все детали
Мне помогло справиться с этим постепенное погружение методом "progressive jpeg". Не нужно пытаться сразу получить в голове идеальную и точную картинку — важно начинать с крупных "пикселей", постепенно добавляя детализацию в тех местах, где это нужно.
Широкая картина помогает понимать, что происходит в целом. А для уточнения деталей и более глубокого погружения я выбираю области, где вижу потенциал для улучшения в среднесрочной перспективе, или направления, которые особенно важны для бизнеса в данный момент.
2. Когда ты CTO, никто не поставит тебе цели на испытательный срок
Ты главный эксперт, и CEO ждёт от тебя план изменений и первые шаги. Важно это понимать и начинать готовить свою стратегию уже с первого дня. Весь онбординг на самом деле должен быть посвящён формированию стратегии и целей.
Мне помогает два подхода
- Визионерство. Что нужно исправить, чтобы стало идеально? Какие практики и бенчмарки из индустрии подойдут новой команде?
- Слушать команду. У команды часто есть идеи, которые обсуждались раньше, но так и не были реализованы. В рамках онбординга нужно успеть понять, что из этого важно и возможно реализовать.
3. Сложно показать быстрый результат
Когда ты CTO, горизонт планирования и реализации изменений составляет 9+ месяцев. А если добавить сюда онбординг, то получается уже 12+.
Важно, работая над стратегией, не забывать про быстрые изменения в тех направлениях и проектах, которые больше всего болят у бизнеса.
Есть хорошая практика для онбординга любого руководителя: чтобы завоевать авторитет у команды и нового руководителя, нужно добиваться серии быстрых побед. В дальнейшем этот авторитет поможет продвигать более масштабные изменения.
Что в итоге?
Онбординг в новой компании оказался для меня гораздо глубже и сложнее, чем я ожидал. Это похоже на жонглирование тремя гранатами: ты одновременно узнаёшь что-то новое, анализируешь ситуацию и начинаешь действовать. И уронить ни одну из них нельзя :)
Как опытный CTO, я не раз наблюдал и организовывал онбординг для других. Но в этом году впервые онбордился сам — как CTO большой команды.
Меня волновал один вопрос: будет ли этот опыт отличаться? Ответ оказался очевидным — да, и очень сильно
В чем оказались основные отличия?
1. Большой масштаб: нельзя быстро погрузиться во все детали
Мне помогло справиться с этим постепенное погружение методом "progressive jpeg". Не нужно пытаться сразу получить в голове идеальную и точную картинку — важно начинать с крупных "пикселей", постепенно добавляя детализацию в тех местах, где это нужно.
Широкая картина помогает понимать, что происходит в целом. А для уточнения деталей и более глубокого погружения я выбираю области, где вижу потенциал для улучшения в среднесрочной перспективе, или направления, которые особенно важны для бизнеса в данный момент.
2. Когда ты CTO, никто не поставит тебе цели на испытательный срок
Ты главный эксперт, и CEO ждёт от тебя план изменений и первые шаги. Важно это понимать и начинать готовить свою стратегию уже с первого дня. Весь онбординг на самом деле должен быть посвящён формированию стратегии и целей.
Мне помогает два подхода
- Визионерство. Что нужно исправить, чтобы стало идеально? Какие практики и бенчмарки из индустрии подойдут новой команде?
- Слушать команду. У команды часто есть идеи, которые обсуждались раньше, но так и не были реализованы. В рамках онбординга нужно успеть понять, что из этого важно и возможно реализовать.
3. Сложно показать быстрый результат
Когда ты CTO, горизонт планирования и реализации изменений составляет 9+ месяцев. А если добавить сюда онбординг, то получается уже 12+.
Важно, работая над стратегией, не забывать про быстрые изменения в тех направлениях и проектах, которые больше всего болят у бизнеса.
Есть хорошая практика для онбординга любого руководителя: чтобы завоевать авторитет у команды и нового руководителя, нужно добиваться серии быстрых побед. В дальнейшем этот авторитет поможет продвигать более масштабные изменения.
Что в итоге?
Онбординг в новой компании оказался для меня гораздо глубже и сложнее, чем я ожидал. Это похоже на жонглирование тремя гранатами: ты одновременно узнаёшь что-то новое, анализируешь ситуацию и начинаешь действовать. И уронить ни одну из них нельзя :)
🔥27👍18❤5🤓4🆒1
Коллеги попросили меня поделиться списком материалов для тим лидов, которые лично мне запомнились и зацепили чем-то.
Задача оказалась довольно трудная, но я справился! :) Решил запостить в канал топ-3 из тех, что пришли в голову.
1. “Agile менеджмент” - Юрген Аппело
https://alpinabook.ru/catalog/book-agile-menedzhment/
В оригинале называется “Management 3.0”.
Эта книга мне очень зашла, когда мы внедряли Scrum и думали с командой над вопросом: “А зачем нужен менеджер в самоорганизующихся командах?”
Автор рассказывает про стиль управления servant leadership (лидер-слуга) и подкрепляет всё понятными примерами из своего опыта.
Потом оказалось, что на позиции CTO это вообще must have, так как ты уже работаешь только с опытными, самостоятельными и организованными менеджерами. И управление в концепции лидер-слуга позволяет лучше понять свою добавленную стоимость и приносить пользу команде.
2. “Джедайские техники” (обе части) - Максим Дорофеев
https://www.mann-ivanov-ferber.ru/catalog/product/dzhedajskie-texniki/
https://www.mann-ivanov-ferber.ru/catalog/product/put-dzedaia-dopolnennoe-izdanie/
На мой взгляд, это лучшие книги по тайм-менеджменту на русском. Максим собрал и агрегировал много разных советов, идей и подходов в стройную систему.
Книжки очень практичные, я до сих пор пользуюсь советами оттуда :)
3. Подходы к системному ведению заметок: Zettelkasten, Метод PARA, Вечнозеленые заметки (Evergreen notes) и программа Obsidian
Удивительно, но я только недавно узнал, что такое вообще существует. Хотя практики не новые, в айтишных кругах почему-то редко про них говорят.
Практики очень полезные, когда изучаешь много нового контента. Помогают хорошо систематизировать знания и не забывать важные мысли. Каких-то конкретных материалов хороших не могу посоветовать, собирал свое представление из кусочков. Свои мысли об этих подходах писал тут: https://t.iss.one/cto_notes_panov/11
Задача оказалась довольно трудная, но я справился! :) Решил запостить в канал топ-3 из тех, что пришли в голову.
1. “Agile менеджмент” - Юрген Аппело
https://alpinabook.ru/catalog/book-agile-menedzhment/
В оригинале называется “Management 3.0”.
Эта книга мне очень зашла, когда мы внедряли Scrum и думали с командой над вопросом: “А зачем нужен менеджер в самоорганизующихся командах?”
Автор рассказывает про стиль управления servant leadership (лидер-слуга) и подкрепляет всё понятными примерами из своего опыта.
Потом оказалось, что на позиции CTO это вообще must have, так как ты уже работаешь только с опытными, самостоятельными и организованными менеджерами. И управление в концепции лидер-слуга позволяет лучше понять свою добавленную стоимость и приносить пользу команде.
2. “Джедайские техники” (обе части) - Максим Дорофеев
https://www.mann-ivanov-ferber.ru/catalog/product/dzhedajskie-texniki/
https://www.mann-ivanov-ferber.ru/catalog/product/put-dzedaia-dopolnennoe-izdanie/
На мой взгляд, это лучшие книги по тайм-менеджменту на русском. Максим собрал и агрегировал много разных советов, идей и подходов в стройную систему.
Книжки очень практичные, я до сих пор пользуюсь советами оттуда :)
3. Подходы к системному ведению заметок: Zettelkasten, Метод PARA, Вечнозеленые заметки (Evergreen notes) и программа Obsidian
Удивительно, но я только недавно узнал, что такое вообще существует. Хотя практики не новые, в айтишных кругах почему-то редко про них говорят.
Практики очень полезные, когда изучаешь много нового контента. Помогают хорошо систематизировать знания и не забывать важные мысли. Каких-то конкретных материалов хороших не могу посоветовать, собирал свое представление из кусочков. Свои мысли об этих подходах писал тут: https://t.iss.one/cto_notes_panov/11
alpinabook.ru
Agile-менеджмент: Лидерство и управление командами — купить книгу Аппело Юргена на сайте alpinabook.ru
Agile-менеджмент: Лидерство и управление командами, Автор Аппело Юрген Онлайн заказ на сайте. Доставка по всей России. Гарантируем низкие цены, доставка курьером и в пункты выдачи от 99 руб. Онлайн заказ на сайте. Издательство Альпина Паблишер
🔥26👍8❤4✍1
Сначала команды, потом код: как оргдизайн меняет архитектуру
Последние месяцы я много обсуждаю с командой оргдизайн. Кому-то даже может показаться, что я чересчур много времени трачу на это. Ведь CTO должен фокусироваться на технологиях, а не на «вот этом вот всём». Но, на мой взгляд, умение выстроить правильную структуру и коммуникации в команде — это чуть ли не более важный навык, чем выбор технологий и фреймворков.
Возьмём классический пример. Есть команды клиентской разработки (фронтенд и мобильная) и бэкенд. В такой оргструктуре зона ответственности между ними делится по границе бэкенд-API и клиентских SDK. Клиентские команды, стремясь минимизировать свои зависимости и ускорить TTM, делают себе собственные прокси и «лёгкие» бэкенды. А бэкенд-команды, не имея контроля над клиентским кодом, стараются управлять всем со своего слоя. В результате возникает дублирование логики и размытие зон ответственности: каждая команда «делает своё», а итоговая система становится «слоистой» и перегруженной.
Про связь оргдизайна и архитектуры говорит «закон Конвея»: организации проектируют системы, которые копируют структуру их коммуникаций. Из него вытекает «обратный манёвр Конвея»: чтобы достичь желаемой архитектуры, нужно сначала организовать команды и их взаимодействия так, чтобы они отражали целевую структуру системы.
В итоге, если мы хотим сделать действительно крутую архитектуру, важно посмотреть на то, как устроены наши команды. И начать стоит не с нового стека технологий, а с «обратного манёвра Конвея».
Последние месяцы я много обсуждаю с командой оргдизайн. Кому-то даже может показаться, что я чересчур много времени трачу на это. Ведь CTO должен фокусироваться на технологиях, а не на «вот этом вот всём». Но, на мой взгляд, умение выстроить правильную структуру и коммуникации в команде — это чуть ли не более важный навык, чем выбор технологий и фреймворков.
Возьмём классический пример. Есть команды клиентской разработки (фронтенд и мобильная) и бэкенд. В такой оргструктуре зона ответственности между ними делится по границе бэкенд-API и клиентских SDK. Клиентские команды, стремясь минимизировать свои зависимости и ускорить TTM, делают себе собственные прокси и «лёгкие» бэкенды. А бэкенд-команды, не имея контроля над клиентским кодом, стараются управлять всем со своего слоя. В результате возникает дублирование логики и размытие зон ответственности: каждая команда «делает своё», а итоговая система становится «слоистой» и перегруженной.
Про связь оргдизайна и архитектуры говорит «закон Конвея»: организации проектируют системы, которые копируют структуру их коммуникаций. Из него вытекает «обратный манёвр Конвея»: чтобы достичь желаемой архитектуры, нужно сначала организовать команды и их взаимодействия так, чтобы они отражали целевую структуру системы.
В итоге, если мы хотим сделать действительно крутую архитектуру, важно посмотреть на то, как устроены наши команды. И начать стоит не с нового стека технологий, а с «обратного манёвра Конвея».
👍28🔥23❤4💯3
Как объяснить топам, что у нас всё хорошо с качеством?
Качество можно описать кучей разных метрик. В Яндекс Картах мы смотрим на такие:
- соблюдение SLA на исправление багов (aka zero bug policy);
- надёжность ключевых пользовательских сценариев (aka «девятки», 99.99);
- среднее время восстановления после сбоя (Mean Time to Recovery)
- скорость работы интерфейса (например, Time to Interactive, Freeze Time);
- и поскольку карты — это в первую очередь продукт, завязанный на данные, мы отдельно следим за качеством данных. Пока у нас есть только одна метрика — SLA по доставке данных от пользовательской правки до продакшна, но мы ещё работаем над полной моделью.
Но, глядя на него, сложно ответить на вопрос: «А что у нас с качеством?» Непонятно, почему мы смотрим именно на эти метрики, и как по ним показать общий прогресс и приближение к идеальному состоянию.
Здесь помогает подход с фитнес-функцией — объединяем метрики формулой и общей логикой.
Для общей логики хорошо заходит идея: смотрим на то, насколько продукт кажется пользователю качественным. Её легко объяснить бизнесу.
А чтобы получить составную метрику — я называю её quality score — используем взвешенную формулу. Берём каждую метрику, переводим её значение в шкалу от 0 до 1. Например, надёжность 99.95% при цели 99.99% может дать 0.5 балла. Если баги закрываются в срок — это 1, если нет — меньше. Всё зависит от приоритетов.
Задаём каждой метрике вес в общем скоре, по умолчанию можно просто 1, и считаем итог:
Quality Score = Σ (вес метрики × значение метрики в шкале)
На выходе получаем один показатель, который отражает общую картину с качеством — и выглядит вполне понятным для бизнеса.
Если хочется углубиться в детали, то можно прочитать статью про Quality Score от Саши Матвеева из Авито. Где мы с ним и командой качества внедряли аналогичную метрику https://habr.com/ru/companies/avito/articles/767728
Качество можно описать кучей разных метрик. В Яндекс Картах мы смотрим на такие:
- соблюдение SLA на исправление багов (aka zero bug policy);
- надёжность ключевых пользовательских сценариев (aka «девятки», 99.99);
- среднее время восстановления после сбоя (Mean Time to Recovery)
- скорость работы интерфейса (например, Time to Interactive, Freeze Time);
- и поскольку карты — это в первую очередь продукт, завязанный на данные, мы отдельно следим за качеством данных. Пока у нас есть только одна метрика — SLA по доставке данных от пользовательской правки до продакшна, но мы ещё работаем над полной моделью.
Но, глядя на него, сложно ответить на вопрос: «А что у нас с качеством?» Непонятно, почему мы смотрим именно на эти метрики, и как по ним показать общий прогресс и приближение к идеальному состоянию.
Здесь помогает подход с фитнес-функцией — объединяем метрики формулой и общей логикой.
Для общей логики хорошо заходит идея: смотрим на то, насколько продукт кажется пользователю качественным. Её легко объяснить бизнесу.
А чтобы получить составную метрику — я называю её quality score — используем взвешенную формулу. Берём каждую метрику, переводим её значение в шкалу от 0 до 1. Например, надёжность 99.95% при цели 99.99% может дать 0.5 балла. Если баги закрываются в срок — это 1, если нет — меньше. Всё зависит от приоритетов.
Задаём каждой метрике вес в общем скоре, по умолчанию можно просто 1, и считаем итог:
Quality Score = Σ (вес метрики × значение метрики в шкале)
На выходе получаем один показатель, который отражает общую картину с качеством — и выглядит вполне понятным для бизнеса.
Если хочется углубиться в детали, то можно прочитать статью про Quality Score от Саши Матвеева из Авито. Где мы с ним и командой качества внедряли аналогичную метрику https://habr.com/ru/companies/avito/articles/767728
👍22🔥9❤7👏2
ChatGPT vs performance review
На CTO Conf, который прошёл неделю назад, я вёл круглый стол про performance review. У многих компаний сейчас «сезон ревью» — и один из самых частых вопросов: можно ли использовать LLM в этом процессе?
Мы сошлись во мнении, что ничего страшного в их использовании нет, причём почти все участники уже сталкивались с результатами их работы или сами пользовались ими.
Чаще всего LLM используют в двух случаях:
1. При написании самоотзыва. Здесь человек сам заинтересован получить хороший результат, поэтому AI обычно выступает как партнёр-копирайтер.
2. При написании фидбеков другим людям. 1,5–2 года назад было легко понять, где текст написал человек, а где — модель. Сейчас отличить одно от другого всё сложнее. Модели поумнели, их качество растёт.
Как не потерять ценность ревью, если в него вовлечены LLM?
- Делать AI помощником, а не автором. Он отлично помогает собрать мысли в связный текст или сократить лишнее. Я сам так его использую.
- Меньше фокусироваться на пустой похвале. Позитивный фидбек важен, но когда он формален и пуст — он теряет смысл. Именно такие случаи чаще всего отдают на аутсорс LLM.
- Ценить развивающую обратную связь. Мы обсудили, что если менеджеры перестают реагировать на дежурные «молодец», команда тоже меняет подход. И LLM включают реже.
- Добавлять к фидбеку технические детали: какой промт и какая модель использовались. Это не обязательно, но добавляет честности и помогает распространять лучшие практики 🙂
А что нас ждёт дальше — с учётом того, как быстро развиваются модели?
С развитием агентности в моделях, я думаю, мы придём к полностью автоматической генерации самоотзыва.
Представьте, у вас есть набор агентов:
— один собирает проекты из таск-трекера
— второй вытаскивает инженерные детали из коммитов
— третий анализирует A/B-тесты и метрики релизов
— четвёртый сводит всё в внятный отчёт
Часть из этого уже можно автоматизировать. Остальное — вопрос времени.
Единственное, где AI пока не пророс, — это калибровка. И, пожалуй, хорошо, что именно здесь решение всё ещё принимает человек. Хотя, кто знает, может и это кто-то уже пробует аутсорсить GPT...
На CTO Conf, который прошёл неделю назад, я вёл круглый стол про performance review. У многих компаний сейчас «сезон ревью» — и один из самых частых вопросов: можно ли использовать LLM в этом процессе?
Мы сошлись во мнении, что ничего страшного в их использовании нет, причём почти все участники уже сталкивались с результатами их работы или сами пользовались ими.
Чаще всего LLM используют в двух случаях:
1. При написании самоотзыва. Здесь человек сам заинтересован получить хороший результат, поэтому AI обычно выступает как партнёр-копирайтер.
2. При написании фидбеков другим людям. 1,5–2 года назад было легко понять, где текст написал человек, а где — модель. Сейчас отличить одно от другого всё сложнее. Модели поумнели, их качество растёт.
Как не потерять ценность ревью, если в него вовлечены LLM?
- Делать AI помощником, а не автором. Он отлично помогает собрать мысли в связный текст или сократить лишнее. Я сам так его использую.
- Меньше фокусироваться на пустой похвале. Позитивный фидбек важен, но когда он формален и пуст — он теряет смысл. Именно такие случаи чаще всего отдают на аутсорс LLM.
- Ценить развивающую обратную связь. Мы обсудили, что если менеджеры перестают реагировать на дежурные «молодец», команда тоже меняет подход. И LLM включают реже.
- Добавлять к фидбеку технические детали: какой промт и какая модель использовались. Это не обязательно, но добавляет честности и помогает распространять лучшие практики 🙂
А что нас ждёт дальше — с учётом того, как быстро развиваются модели?
С развитием агентности в моделях, я думаю, мы придём к полностью автоматической генерации самоотзыва.
Представьте, у вас есть набор агентов:
— один собирает проекты из таск-трекера
— второй вытаскивает инженерные детали из коммитов
— третий анализирует A/B-тесты и метрики релизов
— четвёртый сводит всё в внятный отчёт
Часть из этого уже можно автоматизировать. Остальное — вопрос времени.
Единственное, где AI пока не пророс, — это калибровка. И, пожалуй, хорошо, что именно здесь решение всё ещё принимает человек. Хотя, кто знает, может и это кто-то уже пробует аутсорсить GPT...
👍18🔥5
В июле я выступил с докладом «Быть заметным и расти: как руководителю взять развитие в свои руки» на первой конференции Яндекса для тимлидов — Dream Team Lead. Делюсь ключевыми идеями и полезными материалами.
«Стеклянный тупик»
Многие руководители рано или поздно сталкиваются с этим ощущением: работаешь, стараешься, задачи усложняются, а роста — нет. Кто-то в такой момент ждёт, что его «заметят» или подскажут путь. Но, на мой взгляд, развитие — это зона личной ответственности.
Не обязательно идти на дорогое обучение — можно собрать кастомный план развития под себя. DIY-подход, который я сам использую и рекомендую другим.
Что помогает расти:
— Диагностика через матрицы компетенций
Оценить, где ты сейчас и какие зоны требуют прокачки. Полезные фреймворки:
• TL roadmap
• Avito Tech Lead Profile
• Dropbox Career Framework
— Развитие скиллов
Классическое развитие hard и soft skills тут работает, но с нюансом: для менеджера софты становятся «новыми хардами».
— Работа с майндсетом
Применять знания часто мешают внутренние барьеры — страх, самозванец, установки и т.п. Тесты вроде Hogan и Gallup помогают понять себя и дают инструменты для изменения.
— Окружение
Нетворк, мастермайнд-группы, неформальные «советы директоров для себя» — мощный рычаг. Где искать:
• GetMentor
• Solvery
• No Flame No Game (бот в Telegram)
• IT-мастермайнды
Где посмотреть доклад:
• VK Video
• YouTube
• Слайды
Если тема отозвалась — посмотрите доклад, делитесь ссылкой и пишите, если хочется обсудить.
«Стеклянный тупик»
Многие руководители рано или поздно сталкиваются с этим ощущением: работаешь, стараешься, задачи усложняются, а роста — нет. Кто-то в такой момент ждёт, что его «заметят» или подскажут путь. Но, на мой взгляд, развитие — это зона личной ответственности.
Не обязательно идти на дорогое обучение — можно собрать кастомный план развития под себя. DIY-подход, который я сам использую и рекомендую другим.
Что помогает расти:
— Диагностика через матрицы компетенций
Оценить, где ты сейчас и какие зоны требуют прокачки. Полезные фреймворки:
• TL roadmap
• Avito Tech Lead Profile
• Dropbox Career Framework
— Развитие скиллов
Классическое развитие hard и soft skills тут работает, но с нюансом: для менеджера софты становятся «новыми хардами».
— Работа с майндсетом
Применять знания часто мешают внутренние барьеры — страх, самозванец, установки и т.п. Тесты вроде Hogan и Gallup помогают понять себя и дают инструменты для изменения.
— Окружение
Нетворк, мастермайнд-группы, неформальные «советы директоров для себя» — мощный рычаг. Где искать:
• GetMentor
• Solvery
• No Flame No Game (бот в Telegram)
• IT-мастермайнды
Где посмотреть доклад:
• VK Video
• YouTube
• Слайды
Если тема отозвалась — посмотрите доклад, делитесь ссылкой и пишите, если хочется обсудить.
👍33🔥17❤6