Teamlead Good Reads – ежедневные советы про менеджмент людей и команд

Что произошло с зарплатами в 2023 за рубежом

Небольшой отчет про изменения зарплат по данным сервиса levels.fyi.

👉В сравнении с 2022 медианная зарплата менеджеров чуть-чуть подросла, на 2%. А вот у разработчиков упала на 0.5%.
👉Самые большие зарплаты в Европе – в Швейцарии. Второе место – Лондон, затем Дублин.

Architecture modernization enabling team

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

Конечно, в первую очередь надо задуматься, а точно ли вы понимаете, что и зачем делаете, или просто на очередной конференции услышали про распил монолита на микросервисы. Но допустим, что такое изменение оправдано. Держите статью про паттерн оргдизайна под названием AMET, Architecture Modernization Enabling Team.

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

Как DORA метрики помогли легаси проекту

Тимлид проекта с 25-летней историей развития, частично утерянными знаниями о его работе и повышенным количеством дефектов, делится тем, как фокус на улучшении характеристик, подсвечиваемых DORA метриками, помог за несколько лет существенно улучшить положение дел. Если вы не следили за хайпом вокруг DORA в среде DevOps, вот что это такое:

👉Deployment frequency: как часто команда релизит свою систему
👉Commit delivery lead time: время, за которое сделанный коммит доезжает до прода
👉Deployment failure rate: процент релизов, закончившихся поломкой
👉Mean time to recovery: среднее время на восстановление после поломки

Пример Manager's Readme

Я уже выкладывал в канале несколько материалов про то, что такое Manager's Readme. Если концепция заинтересует, посмотрите на них в поиске. Если кратко – это небольшой документ, в котором описываются ваши основные менеджерские принципы и ожидания от своей команды. Он особенно хорош, когда вы только вкатываетесь в новую команду, и не выстроены неявные модели ожиданий и рутина.

В статье по ссылке из заголовка тимлид небольшой команды показывает свой readme в сыром виде. Мне нравится там следующее:

👉Явно прописаны основные ожидания от роли самого менеджера.
👉Очень простыми словами объясняется, зачем нужны 1-1, и они не смешаны с проектными синками.

Что мне не очень нравится:

👉Документ получился сборной солянкой. Например, там зачем-то описывается в деталях роль "лидера фичи", или рабочее расписание. Кажется, этому место где-то в других артефактах.

Инцидент-менеджмент и recency bias

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

Чего ожидать от девелопер адвоката

Роль девелопер адвоката еще более загадочная, чем роль тимлида – мало кто может сформулировать, чем они должны заниматься. James Ward, довольно известный чувак в этой области, который сейчас работает в Google, попробовал сформулировать ожидания от роли в терминах набора артефактов, которые должны получаться на выходе любого проекта:

👉Семплы кода
👉Блог посты
👉Презентация или видео с лайвкодингом
👉Hands-on воркшоп
👉Сообщения в социальных сетях с широкими охватами
👉Фидбэк по продукту
👉Улучшение отношений с коммьюнити и партнерами

Выпуски Подлодки про управление командами

Мы недавно провели опрос слушателей нашего подкаста и помимо прочего выяснили, что тимлиды – один из самых крупных сегментов наших слушателей! По этому поводу держите подборку релевантных выпусков за последний год!

👉Онбординг с Евгением Антоновым про то, как построить простой и качественный процесс ввода в работу новых людей в вашей команде.
👉Организация стажировок со Стасом Цыгановым про то, как расширить воронку найма за счет кандидатов вообще без опыта работы, и как построить их отбор и обучение.
👉Письменная культура с Александром Ложечкиным про то, как развивать скилл написания полезных и понятных текстов и как эта кудьтура выстроена в Microsoft и Amazon.
👉Делегирование с Евгением Котом про самый важный навык любого руководителя.
👉Холакратия с Андреем Кузнецовым про то, как в Точке построена организация команд и процессы их работы.
👉Engineering Director с Евгением Котом про то, что меняется, когда от руководства командой вы переходите к руководству большим департаментом.

Если вам понравились эти или другие выпуски – напишите нам что-то хорошее в отзывах в Apple Podcasts, или прямо в чатике подкаста!

Анализ различных видов премий

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

Процессный долг

Начнем новый год с эссе про то, что организации страдают не только от технического долга, но и от процессного. Он бывает разных типов. Например, у стартапов процессный долг – следствие быстрого роста. К нему можно отнести отсутствие адекватного онбординга, работу, построенную только на неформальных коммуникациях, отсутствие стандартизации в процессах. У кровавого энтерпрайза тоже есть свой процессный долг, но выглядит он немного по-другому – переизбыток бюрократии, митинги на 50 человек, информационные колодцы.

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

Книги, которые вы прочитали в этом году

У меня выдался очень ненасыщенный год на менеджерскую литературу, всего несколько книг, которые готов порекомендовать:

👉Radical Candor – про то, как давать открытый и честный фидбэк в моменте, а не тянуть с ним вечность.
👉The Culture Map – про особенности работы с людьми разных культур.
👉Team Topologies (ее еще не дочитал, но пока нравится) – про осознанный подход к организационному дизайну.

Расскажите, а что в этом гожу прочитали вы? Что понравилось, а что – не очень?

🔥 Энтузиасты от комьюнити проектных менеджеров снова проводят исследование рынка, которое стало уже ежегодным!

Цель: выяснить зарплаты руководителей проектов и факторы, от которых они зависят, по выборке больше 1500 респондентов до 20 января 2024 года

Прошлогодний рекорд не побит - 564 чел 💪 Давайте поднажмем в этом году 🚀

Ссылка на опрос (~5 минут)

Как СТО развалить компанию

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

👉Внедрите сложный процесс приемки изменений, оправдывая его требованиями безопасности и комплаенса.
👉Требуйте вносить все задачи в трекер, а после этого проводить через ревью и приоритизацию группой не меньше 5 человек.
👉Чтобы избежать вендор-лока, настаивайте на том, чтобы реализовывать все самим вместо покупки готовых решений.
👉Поддерживайте коллективное владение кодом.
👉Наймите архитекторов и требуйте прохождения архитектурного ревью для всех изменений.
👉Привяжите зарплату к должности, а должность к размеру команды.
👉Отправляйте хай-перформеров на R&D проекты без четкой судьбы и целей.

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

Тестовая неделя как способ найма

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

Неделя оплачивается. Кандидату дают доступ ко всем необходимым инструментам и ставят четкую задачу. Например, реализовать фичу, которая поможет триажить входящие тикеты. Через эту систему проходят все нанятые люди, включая топ-менеджеров. Говорят, что ретеншн-рейт команды на протяжении 4 лет составил 96%.

Кому и зачем надо становиться менеджером

Очень классный мотивационный пост про то, почему стоит выбирать менеджерский карьерный трек помимо чуть большей в среднем по больнице зарплаты. Мне запали следующие мысли:

👉Задача менеджера – не принимать все решения, а делать так, чтобы они принимались.
👉Иерархия в компаниях существует для координации изменений в отдельных подсистемах и их постепенных улучшений. Менеджеры обеспечивают наличие в системе цикла обратной связи, благодаря которому эти улучшения и происходят, а систему получается выровнять вокруг общей цели.
👉Для некоторых людей потребность менторить других и передавать им свои знания – биологический императив. Это не обязательное требование, чтобы быть менеджером, но хорошая причина.
👉Другая хорошая причина – насмотреться на плохих менеджеров, понимать, как делать не надо, и хотеть помочь другим не страдать от тех же проблем.
👉Для хорошего инженера работа менеджером в течение пары лет – отличный опыт, чтобы вырасти в стаффа.
👉Опыт работы менеджером сильно помогает вам улучшить навыки взаимодействия с людьми, которые требуются и в личной жизни: вы учитесь управлять собой, понимать свои чувства и чувства других людей, устанавливать границы, говорить о неудобных вещах.

Выпуск Подлодки про то, кто такой engineering director

Руководить другими менеджерами – совсем не то же самое, чем линейными сотрудниками. Записали выпуск Подлодки с Евгением Котом про то, в чем заключаются основные особенности работы инжиниринг директором от обычной менеджерской роли, и поговорили, какие знания и навыки будут обязательными.

Гайд по переходу к асинхронным коммуникациям

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

Как в Google работает code review

Интересный разбор особенностей code review в Google – от гайдлайнов и до разбора Critique, внутреннего инструмента для ревью. Среди заметных фич:

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

Почему вы увольнялись с менеджерской работы

Я увольнялся с менеджерских позиций два раза. Первый раз был в 2016 году в Rambler&Co. У нас одним днем сменился весь менеджмент технического подразделения на каких-то очень эффективных ребят из Инновы. Первое, что они сделали – собрали всю нашу команду и начали рассказывать про Scrum и другие великие изменения, которые планируют внедрить. На любые разумные вопросы про эти изменения отвечали чем-то типа "Да я уже пять успешных бизнесов построил, когда сделаешь столько же, вопросы и задавай". После этой встречи мы завели встречи для всего iOS отдела, на которых совместно стали готовиться к интервью. Спустя пару месяцев уволился и я, и процентов 70 всей команды. Мораль, которую я для себя вынес – даже если вас нанимают ради внедрения изменений, не стоит врываться с ними с порога без внятной стратегии их исполнения.

Второй раз был уже из Авито. В какой-то момент количество скучных менеджерских задач на монй позиции стало перевешивать интересные. В частности, смешно получилось с перфоманс ревью. Еще в 2017 году я начал его внедрять в компании. Со временем он эволюционировал, превращаясь во все более сложную машину. Два года спустя, сидя поздно вечером на калибровке, на которой мы несколько часов до хрипоты спорили о том, кто из двух незнакомых мне инженеров заслуживает +0.05 к оценке, я понял, что это совсем не то, на что я хочу тратить свою жизнь.

А теперь ваша очередь! Расскажите в комментариях, почему вы увольнялись с менеджерской работы.

Как деливерить быстрее

Набор принципов, некоторые из которых показались мне интересными:

👉Protect momentum. Чем чаще вы что-то релизите, тем выше получается держать уровень мотивации и энергии в команде. Длинные циклы разработки приводят к выгоранию и потере контакта с пользователем.
👉Beware of prioritization. Бессмысленно тратить много времени на приоритизацию, когда все, что действительно важно – это какую задачу делать прямо сейчас, а какую – следующей.
👉Only doers can plan what you work on. Как только за планирование начинают отвечать оторванные от разработки люди, появляется искуственное раздувание сроков разработчиками, которые не хотят промахиваться в оценках. А работа занимает все выделенное на нее время.
👉There is no quality vs speed tradeoff. Плохое качество кода замедлит вам работу в будущем. Любой компромисс такого рода – в долгую вреден. При достаточном уровне культуры разработки и скиллов инженеров можно достичь обеих целей.

Навигаторы как замена архитектурным комитетам и командам

Про проблемы, вызываемые в компании наличием централизованной функции архитекторов, в канале мы обсуждали уже много раз (как минимум вот). При этом польза от них тоже есть, как минимум в том, чтобы любые технические вопросы не эскалировались до СТО. Один из вариантов замены – навигаторы.

👉На каждую большую бизнесовую область выделяется один человек навигатор. Им может быть только тот, кто активно контрибьютит в связанную кодовую базу.
👉Зоны ответственности навигаторов не пересекаются.
👉Навигатор целиком отвечает за принятие крупных технических решений в его области.
👉Если решение сталкивается с бизнесовыми или пипл-менеджерскими ограничениями, навигатор должен сам договориться с ответственными людьми.
👉Навигаторы отчитываются перед СТО за все принятые решения.
👉Если пара навигаторов не может договориться, вопрос эскалируется до СТО.