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

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

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

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

Эскалации как признак некомпетентных менеджеров В контексте статьи под эскалацией подразумевается ручное вмешательство менеджеров в планы работы нижестоящих уровней организации и внесение в них каких-то важных и срочных изменений. В чем вообще проблема – если такие эскалации происходят достаточно часто, работа в командах становится непредсказуемой, люди не чувствуют смысла в своей деятельности, выгорают и увольняются. Чем выше уровень менеджера, тем на более далеком горизонте он должен работать. СЕО компании должен думать о том, как привести ее к успеху через 5-10 лет, а не о том, попала ли в спринт команды разработки фича, которая кажется ему важной. Но большой горизонт планирования влечет за собой отсутствие видимых краткосрочных результатов. Некоторых менеджеров это не устраивает и, чтобы почувствовать какой-то контроль, они начинают вмешиваться в операционку. В итоге страдают и команды, в работу которых они вмешались, и работа, которой на самом деле эти менеджеры должны были заниматься. Хороший инструмент борьбы с такими эскалациями – постмортемы. К каждой эскалации можно относиться как к инциденту, анализировать его корневую причину, и менять что-то в организации, чтобы подобное не повторялось. Помимо обычного эффекта в виде постепенного улучшения процессов, у такого решения есть и важный политический эффект – мало какому менеджеру захочется из раза в раз выглядеть некомпетентным самодуром, который эскалировал конкретную проблему вместо системного решения того, что ее вызывает.

Аудит своей занятости На мой взгляд ключевое качество, отличающее довольных своей жизнью менеджеров от выгоревших в хлам – умение управлять своими ресурсом. Каким бы прошаренным специалистом по личной эффективности вы ни были, периодически разумно сверять часы и перепроверять, а точно ли вы свой ресурс тратите так, как вам бы того хотелось. Есть несколько разных техник такого аудита, в статье как раз одна из них. 1️⃣В течение нескольких недель записывайте, сколько времени и на какие конкретно активности вы тратите. 2️⃣Агрегируйте все активности в не слишком общие категории или проекты. 3️⃣Пройдитесь по каждому из проектов, и проставьте ему один из пяти статусов: - Stop, если от того, что вы не занимались бы этой активностью, ничего бы не поменялось. - Delegate, если эту активность можно передать кому-то, кто справится с ней не хуже. - Reassign, если ваша вовлеченность могла бы сократиться, если бы кто-то еще перед вами поработал над этой задачей. - Modify, если вы можете каким-то образом переработать этот проект, чтобы либо тратить на него меньше времени, либо с большей пользой. - Keep, если менять ничего не надо. Я регулярно использую аналогичную практику для себя, и периодически помогаю провести ее же менеджерам, которыми руковожу. Пользы обычно довольно много, так что рекомендую.

Приоритизация Прекрасный тред про то, как выстраивать систему приоритизации. Конкретные мысли, под которыми я тоже готов подписаться: 👉Большая часть проблем с приоритизацией упираются в проблемы со стратегией: она может вообще отсутствовать, ее могут считать не очень важной, с ее ядром могут быть не согласны или ее просто могут не помнить. Поэтому в первую очередь разберитесь со своей стратегией. Как обычно, напоминаю про ключевую книгу, которую вам надо прочитать – Good Strategy Bad Strategy. 👉После того, как проблемы стратегии решены, разберитесь с приоритизацией ключевых направлений работы. В чем суть – надо раскидать все, чем можно заниматься в вашем продукте, на несколько бакетов, выбрать самые важные из них на определенный горизонт времени, и договориться о проценте выделяемых ресурсов. Пример такой системы областей – Differentiators, Tablestakes, Incrementals, Embarrassments, Large customer requests, Speculative bets, Tech foundation. Не факт, что вам подойдет именно такая разбивка, но как база – норм. 👉Не нужно пытаться набрать задач в каждой из областей. На 3/6-месячном горизонте разумно ограничиться всего несколькими областями, а остальные вообще не трогать. 👉Максимально вовлекайте команду в то, чтобы определить, а над какими конкретно фичами работать. У них есть вводные – стратегия, ключевые области работы, распределение инвестиций между ними.

"Ставить под сомнение" как отдельный скилл В чем суть скилла – вы должны достаточно разбираться в различных предметных областях, чтобы челленджить представление людей об ограничениях. Например, когда разработчик говорит, что что-то сделать невозможно, то это может происходить из-за того, что он переживает об эдж кейсах, которые вообще не важны для пользователя. Так вот, вам не нужно обладать глубокими знаниями в каждой области, чтобы ставить такие утверждения под сомнение. Достаточно уметь задавать вопросы, и закапываться дальше первого слоя ответов на них. Я так и не смог найти более подходящий перевод на русский замечательного выражения "call bullshit", который не имел бы негативных коннотаций.

В нашем канале "Тимлид не спит" новый кейс – про то, как поднимать мотивацию команды после череды запусков ненашедших свою аудиторию продуктов. Приходите обсуждать в комментарии и рассказывать, как бы вы решали эту проблему! 👉Кейс в канале

Новые выпуски тимлидских подкастов За последние пару недель вышло еще несколько полезных выпусков менеджерских подкастов, которыми хочу с вами поделиться: 👉Подлодка про джунов: про то, что в 2024 году происходит с обучением начинающих разработчиков и вообще входом в IT 👉Бреслав и Ложечкин про менторство: как найти ментора и получить от него максимальную пользу для своей карьеры 👉Три тимлида заходят в бар про микроменеджмент: когда погружение в детали является нормой, а когда – излишней тягой к контролю 👉КОДА КОДА про внутренний пиар: как сделать так, чтобы про успехи вашей команды знала вся компания

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

Кент Бек про проектный треугольник 👉Зависимости в проектном треугольнике сложнее, чем кажется на первый взгляд. Самая контринтуитивная вещь – чтобы ускорить выполнение проекта или удешевить его, часто нужно не жертвовать качеством, а, наоборот, повышать его. 👉Треугольник имеет смысл только для фиксированного объема работы. Скоуп большинства проектов в IT заранее неизвестен, команды выясняют его постепенно. И то, какие в итоге фичи войдут в продукт – самая важная составляющая того, приносит он пользу конечным пользователям или нет. Из этого следует простой, но важный вывод – инкременталтные планирование и разработка в долгоживущих проектах принесут гораздо больше ценности, чем попытки срезать углы на других составляющих треугольника.

Что делать, когда компания вам не подходит Очевидный ответ – уволиться, чтобы не тратить свое время на компанию, которая не бьется с вашими ценностями. Но важно помнить, что у вас есть и другие опции: 👉Абстрагироваться от того, с чем вы не согласны, и продолжить работать. Так себе вариант. Краткосрочно он может иметь смысл, но на длинном горизонте вы не получаете удовольствия от работы, эффективность падает, карьерное движение точно становится далеким от оптимального. 👉Изменить компанию. Если у вас достаточно энергии, настойчивости и авторитета, вы можете попробовать изменить то, что считаете не правильным. В случае успеха это еще и кучу потенциальных плюшек принесет, как и отличную историю для будущих собеседований. Опасность такого варианта в том, что долгая безрезультатная борьба с ветряными мельницами вряд ли хорошо на вас скажется. 👉Создать свой пузырь. Если в компании – бардак, вы можете попробовать построить все так, как считаете нужным, в вашей области контроля. Если все сделать правильно и постепенно привлекать сторонников, то этот пузырь может постепенно начать расти, захватывая все большую часть компании. В конце концов, если вы смогли выстроить работу лучше, чем остальные, у вас захотят научиться. 👉Измениться самому. Вполне может быть, что в компании все не плохо, а просто отличается от того, как вы привыкли работать, и в итоге это вам надо будет научиться новому.