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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В последнее время я часто отвечаю на этот вопрос, рассказывая про фреймворк 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.

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

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

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

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

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

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

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

Меня волновал один вопрос: будет ли этот опыт отличаться? Ответ оказался очевидным — да, и очень сильно

В чем оказались основные отличия?

1. Большой масштаб: нельзя быстро погрузиться во все детали
Мне помогло справиться с этим постепенное погружение методом "progressive jpeg". Не нужно пытаться сразу получить в голове идеальную и точную картинку — важно начинать с крупных "пикселей", постепенно добавляя детализацию в тех местах, где это нужно.

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

2. Когда ты CTO, никто не поставит тебе цели на испытательный срок
Ты главный эксперт, и CEO ждёт от тебя план изменений и первые шаги. Важно это понимать и начинать готовить свою стратегию уже с первого дня. Весь онбординг на самом деле должен быть посвящён формированию стратегии и целей.

Мне помогает два подхода
- Визионерство. Что нужно исправить, чтобы стало идеально? Какие практики и бенчмарки из индустрии подойдут новой команде?
- Слушать команду. У команды часто есть идеи, которые обсуждались раньше, но так и не были реализованы. В рамках онбординга нужно успеть понять, что из этого важно и возможно реализовать.

3. Сложно показать быстрый результат
Когда ты CTO, горизонт планирования и реализации изменений составляет 9+ месяцев. А если добавить сюда онбординг, то получается уже 12+.

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

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

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

Коллеги попросили меня поделиться списком материалов для тим лидов, которые лично мне запомнились и зацепили чем-то.

Задача оказалась довольно трудная, но я справился! :) Решил запостить в канал топ-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

Сначала команды, потом код: как оргдизайн меняет архитектуру

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

Возьмём классический пример. Есть команды клиентской разработки (фронтенд и мобильная) и бэкенд. В такой оргструктуре зона ответственности между ними делится по границе бэкенд-API и клиентских SDK. Клиентские команды, стремясь минимизировать свои зависимости и ускорить TTM, делают себе собственные прокси и «лёгкие» бэкенды. А бэкенд-команды, не имея контроля над клиентским кодом, стараются управлять всем со своего слоя. В результате возникает дублирование логики и размытие зон ответственности: каждая команда «делает своё», а итоговая система становится «слоистой» и перегруженной.

Про связь оргдизайна и архитектуры говорит «закон Конвея»: организации проектируют системы, которые копируют структуру их коммуникаций. Из него вытекает «обратный манёвр Конвея»: чтобы достичь желаемой архитектуры, нужно сначала организовать команды и их взаимодействия так, чтобы они отражали целевую структуру системы.

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

Как объяснить топам, что у нас всё хорошо с качеством?

Качество можно описать кучей разных метрик. В Яндекс Картах мы смотрим на такие:
- соблюдение 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

ChatGPT vs performance review
На CTO Conf, который прошёл неделю назад, я вёл круглый стол про performance review. У многих компаний сейчас «сезон ревью» — и один из самых частых вопросов: можно ли использовать LLM в этом процессе?

Мы сошлись во мнении, что ничего страшного в их использовании нет, причём почти все участники уже сталкивались с результатами их работы или сами пользовались ими.

Чаще всего LLM используют в двух случаях:
1. При написании самоотзыва. Здесь человек сам заинтересован получить хороший результат, поэтому AI обычно выступает как партнёр-копирайтер.
2. При написании фидбеков другим людям. 1,5–2 года назад было легко понять, где текст написал человек, а где — модель. Сейчас отличить одно от другого всё сложнее. Модели поумнели, их качество растёт.

Как не потерять ценность ревью, если в него вовлечены LLM?
- Делать AI помощником, а не автором. Он отлично помогает собрать мысли в связный текст или сократить лишнее. Я сам так его использую.
- Меньше фокусироваться на пустой похвале. Позитивный фидбек важен, но когда он формален и пуст — он теряет смысл. Именно такие случаи чаще всего отдают на аутсорс LLM.
- Ценить развивающую обратную связь. Мы обсудили, что если менеджеры перестают реагировать на дежурные «молодец», команда тоже меняет подход. И LLM включают реже.
- Добавлять к фидбеку технические детали: какой промт и какая модель использовались. Это не обязательно, но добавляет честности и помогает распространять лучшие практики 🙂

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

Представьте, у вас есть набор агентов:
— один собирает проекты из таск-трекера
— второй вытаскивает инженерные детали из коммитов
— третий анализирует A/B-тесты и метрики релизов
— четвёртый сводит всё в внятный отчёт
Часть из этого уже можно автоматизировать. Остальное — вопрос времени.

Единственное, где AI пока не пророс, — это калибровка. И, пожалуй, хорошо, что именно здесь решение всё ещё принимает человек. Хотя, кто знает, может и это кто-то уже пробует аутсорсить GPT...

В июле я выступил с докладом «Быть заметным и расти: как руководителю взять развитие в свои руки» на первой конференции Яндекса для тимлидов — 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
• Слайды

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