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

3X Framework – Explore/Expand/Extract Все вы знаете Кента Бека как автора XP, одного из подписавших Agile манифест и громкого сторонника TDD. Но помимо всего этого, у него много других классных статей и мыслей. Одна из моих любимых – про фреймворк 3Х, который очень простым способом объясняет основные стадии жизни продукта и то, как они влияют на подходы к разработке: 1️⃣Explore. Этап прототипирования, когда вы только пытаетесь нащупать рабочую идею, которая получит отклик у пользователей. Правильная стратегия разработки на этом этапе – максимально снижать стоимость экспериментов, и запускать их как можно больше. 2️⃣Expand. Product/market fit нашелся, пошла фаза быстрого роста. В этот момент основной фокус разработки должен быть на поиске бутылочных горлышек в технологиях, процессах и команде, потому что именно они могут остановить рост. 3️⃣Extract. Проблемы роста решены, формула продукта в целом понятна. Теперь вы превращаете создаваемую им ценность в деньги. И тут фокус смещается на устойчивость, снижение костов разработки и поддержки, и вот все то, чем мы любим заниматься в бигтехе. Какие ключевые мысли дает эта модель: 👉Каждая фаза требует очень разных майндсетов, процессов и технологий. 👉Фазы нельзя смешивать, а слишком ранний или поздний переход могут убить весь бизнес. 👉Менять людей и команды при переводе продукта между фазами, в целом, нормально. Какие-то люди отлично работают на этапе Explore, но вот решать проблемы роста им вообще не интересно.

PR/FAQ про AWS Lambda В Amazon очень сильно развита культура письменных коммуникаций. В частности, обсуждение любой идеи нового продукта или фичи начинается с детально описанного документа, известного под названием PR/FAQ. В чем суть – вы пишете пресс-релиз так, как будто продукт уже вышел, включая туда понятное читателям описание сценариев его использования, преимуществ перед конкурентами, и даже цитаты счастливых пользователей. Помимо пресс-релиза, туда же вы включаете ответы на самые частые вопросы, которые раскрывают уже более глубокие темы как с точки зрения пользователей, так и с точки зрения бизнеса. Отличный пример такого PR/FAQ – по ссылке в заголовке. К десятилетию запуска AWS Lambda ребята из команды решили выложить свой документ с дополнительными комментариями. Очень рекомендую почитать, можно забрать хорошие идеи, если вы тоже придерживаетесь культуры письменных коммуникаций.

Что делать, когда вас окружают идиоты Мой рецепт – сразу же вспомнить про фундаментальную ошибку атрибуции: Это склонность человека объяснять поведение других их индивидуальными особенностями, а своё поведение — ситуацией, внешними обстоятельствами. В статье заходят немного с другой стороны, но с тем же самым результатом: 👉Поймите, что проблема, скорее всего. в вашем собственном восприятии реальности. Мысли вида "все тупые, а я молодец" – детская эгоистическая позиция, в которой вы не берете на себя ответственность за происходящее вокруг. Плюс это работает как бессознательная попытка самоутвердиться за счет других людей. 👉Чтобы понять мотивацию других людей, недостаточно просто наблюдать за их поведением. Если вам кажется, что кто-то делает дичь – попробуйте сначала поговорить с ним и с его коллегами, чтобы составить более взвешенное мнение. 👉Если идиотами кажутся решительно все, то еще один довольно очевидный вариант – надо вырвать себя из обыденности, отвлечься от работы и отдохнуть. Стресс только усиливает негативные эмоции.

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

Что вы думаете про открытые зарплаты Я к идее открытых зарплат отношусь скорее негативно: 👉Я не вижу каких-то явных преимуществ от того, что я или кто-то еще будет знать точную зарплату своего коллеги. В лучшем случае, если она совпадает с твоей оценкой человека, ты просто проигнорируешь эту информацию. В худшем – почувствуешь ощущение тотальной несправедливости. 👉Это ощущение несправедливости может быть абсолютно необъективным. Ты можешь не видеть всех сторон деятельности своего коллеги, и не обладать полной картиной мира для оценки объективности оплаты его труда. При этом демотивация остается. 👉Эта политика довольно сильно связывает руки менеджеру – бывают ситуации, когда взять на себя "менеджерский долг" в виде слишком большой зарплаты нового сотрудника имеет смысл. Я бы точно не хотел терять такой инструмент. Так вот, где-то в начале следующего года мы хотим записать выпуск Подлодки про открытые зарплаты. Хороший план выпуска всегда строится на разборе существующих мнений и острых вопросов – поэтому накидайте их в комментарии! А если у вас был собственный опыт жизни с открытыми зарплатами, то еще интереснее – расскажите, что сработало, а что нет.

Лучшие посты за 2024 Конечно же я расчитываю, что весь год каждое утро вы начинали с того, что читали новый пост в канале (а днем еще и обязательно тыкали на рекламную ссылку). Но если вдруг так случилось, что какие-то дни вы пропустили, я подбил дайджест самых популярных постов за этот год! 👭Команда Как проводить оффбординг Эффект IKEA Как выражать признание другим людям Экономия на зарплате вредит бизнесу Осмысленные карьерные разговоры Запугивающие вопросы Про удержание сотрудников ↔️Процессы Советы по управлению долгими проектами Как писать статус-репорты Гайд по внутренним коммуникациям Очередь задач вместо сторипойнтов 20% на техдолг не работают Парадокс Тога 🥰Культура Эффект Мертвого моря Критика современной культуры менеджмента Как не терять контакт с реальностью Культурный контракт с сотрудником Опасность метрик в менеджменте 🤝Найм Гайд по поиску работы engineering manager Рекрутеров можно заменить броском монеты ✨Личная эффективность Практики таймменеджмента, которые работают Аудит своей занятости А вообще, с наступающими праздниками всех! Держим пальцы крестиком, чтобы LLM в следующем году не заменили всех менеджеров и инженеров, не появилось бы новых черных лебедей, а постов про скрам писалось бы меньше 🎄

Одна из самых классных моих покупок за этот год – планшет Remarkable Pro. Я его использую и для конспектов всяких лекций, и для индивидуальных брейнштормов, и для кучи других задач. Помимо ощущения настоящей бумаги, его главный плюс перед айпадом – это устройство, заточенное ровно под одну задачу, без этих ваших тиктоков и других социальных сетей. Так вот, мы прямо сейчас стартуем новогодний стрим Подлодки, где не только будем делиться разными полезными штуками, но и разыграем этот самый планшет, так что подключайтесь! 🎄Стрим на YouTube

Дорофеев про прогнозирование сроков Очень старый, но все еще бесконечно актуальный доклад Максима Дорофеева про то, как заниматься оценкой сроков в Scrum и Kanban: статистические методы, карты Шухарта и люди-снежинки с руками из жопы.

Как определять SLO Если вы не знакомы с термином, то SLO расшифровывается как Service-Level Objectives. Это набор целей, которые вы ставите перед надежность вашего продукта. Так вот, держите по ссылке хороший подробный гайд, как с ними работать. Если кратко, то алгоритм такой: 1️⃣Определите самые важные пользовательские сценарии 2️⃣Определите SLI, service-level indicators, которые описывают надежность этих сценариев 3️⃣Выберите целевые показатели, в которых эти SLI должны находиться. Помните, что они должны быть реалистичными. 4️⃣Заложите бюджет на ошибки – проседание этих индикаторов, которое может быть более-менее нормально воспринято пользователями. Его можно расчитать, как процент измерений ваших SLI за какой-то промежуток времени, в который они не попадают в SLO.

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

Простая памятка про managing up Ваш менеджер не должен переживать о чем-то в вашей зоне ответственности сильнее, чем вы. Основных идей за этим правилом две: 👉Приоритеты у вас и у вашего менеджера должны быть одинаковыми, иначе вы довольно быстро столкнетесь с микроменеджментом и недоверием. 👉Чтобы эта схема не превратилась в безоговорочное принятие любых, даже бредовых приоритетов, важно управлять ожиданиями проактивно – пытаться понять истинные причины за хотелками менеджера, и приносить свои собственные решения, которые в них бьют.