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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример Manager's Readme

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

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

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

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

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

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

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

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

Architecture modernization enabling team

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

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

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

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

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

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

Обязательные знания для тимлида

Обязательные знания тимлида по версии подкаста Подлодка и Виталия Шароватова:

👉Физиология и психология труда
👉Оргпсихология
👉Андрагогика
👉Кибернетика
👉Теория систем
👉Теория исследования операций
👉Теория массового обслуживания
👉Теория принятия решений
👉Теория очередей

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

Пропускайте митинги, с любым исходом которых вы готовы смириться

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

Бреслав и Ложечкин про то, заменит ли AI программистов

Наш любимый менеджерский подкаст возвращается после зимних каникул. В этот раз разговор идет про то, как взрывная популярность LLM повлияет в перспективе нескольких лет на изменение работы программистов и используемый технический стек. Про перспективы различных языков особенно интересно слушать Андрея Бреслава, как создателя Kotlin.

Как проводить оффбординг

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

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

Статья фокусируется на советах по проведению exit интервью, но дает советы и по другим этапам.

Какие практики менеджеры могут перенять у инженеров

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

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

👉Делать свою работу видимой, как минимум, трекая ее в тикетах.
👉Документировать все, что вы делаете, особенно причины этого. Хорошее правило – у всего должен быть url.
👉Чем бы вы ни занимались, цельтесь в то, чтобы релизить как можно чаще. Процессы, решения, рабочая документация – применимо ко всему.
👉Автоматизируйте. Не делайте вручную то, что может сделать машина.
👉Ведите Management Decision Records, аналог ADR.

The LinkedIn DPH Framework

Команда Линкедина пошарила набор практик, которыми руководствуются в работе их платформенные и инфраструктурные команды. Вот что туда входит:

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

Когда-то я составлял похожий гайд для платформенных команд Авито – Developer Experience Framework. В отличие от варианта Линкедина, я гораздо меньше уделял внимания выбора конкретным метрикам, и больший упор делал на процессы в команде, управление бэклогом и конкретные инструменты работы с пользователями. И вот с точки зрения автора похожей инициативы могу сказать, что таких подррбных гайдов по работе именно с метриками нам действительно не хватало.