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

Про причины отмены удаленки

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

Статья довольно категорично заявляет, что за возвращением людей в офисы стоят очень конкретные задачи:

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

Я со своей стороны не очень верю в то, что все так однозначно. Из того, что я вижу, в большинстве кейсов за таким решением стоит обычное самодурство – кто-то в топ-менеджменте безосновательно верит, что личное взаимодействие усиливает творчество/креативность/whatever. При этом компания находится в кризисе, нужно показать видимость действий, и такой менеджер своей сильной волей продает проект возврата в офисы всем остальным, получает свою заслуженную премию и засыпает счастливым.

Про обезьян на вашей шее

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

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

Если вы узнали в этой ситуации себя, то вот несколько вещей, которые можно подебажить:

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

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

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

При столкновении с такой ситуацией, место того, чтобы вставать в защитную позицию или эскалировать конфликт, попробуйте несколько более конструктивных реакций:

👉Рефрейминг. Переведите фокус конкретно с этого аргумента на большую картину, сказав что-то вроде "Давай сделаем шаг назад и посмотрим на цели, которых мы хотим достичь".
👉Задавайте вопросы вместо того, чтобы спорить. Вопросы реже воспринимаются как оборонительная тактика, вы вытаскиваете больше информации и получаете возможности для рефрейминга.
👉Подвесьте разговор, сказав что-то вроде "Мне нужно это переварить, поговорим позже".

Вопросы, которые стоит задать компании на собеседовании

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

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

Про кривые вашего роста

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

Про удержание сотрудников

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

👉Человек должен оставаться в компании только до тех пор, пока это соответствует его личным приоритетам. Никакие другие аргументы, помимо личной заинтересованности, не должны на это решение влиять – чувство локтя, страх, боязнь подвести других и прочий буллшит.
👉Компания должна работать с сотрудником только до тех пор, пока их интересы выровнены, и сотрудник приносит пользу. Удерживать людей, которые плохо вписываются в компанию – плохая идея не только с точки зрения бизнеса, но и с точки зрения заботы об этих людях. Работать там, где твое развитие и карьерный рост невозможны – довольно бессмысленно.
👉Задача менеджера – сделать так, чтобы вот эти два перечисленных выше фактора оставались актуальными настолько долго, насколько возможно. У сотрудника была бы личная заинтересованность в компании, и он продолжал бы приносить явную пользу.
👉Хороший менеджер не должен бояться подсвечивать сотрудникам возможности для роста за пределами компании, если он правда верит, что это будет в их личных интересах.
👉В целом какой-то уровень естественного оттока – норм. Компания со временем меняется, и люди, которые справлялись хорошо в старом контексте, в новом могут начать справляться хуже. Нужна свежая кровь.
👉Есть два типа людей, потеря которых может быть критичной – суперзвезды и single point of failure. Ваши усилия по удержанию должны быть направлены именно на суперзвезд, которые двигают вашу команду и компанию вперед. С single point of failure стратегия другая – в краткосроке удержание важно, но в долгосроке вам надо работать на снижение зависимости от них.
👉Когда кто-то решил уйти, в большинстве случаев что-то делать уже поздно. Идти на какие-то исключительные меры ради удержания в таких экстренных случаях почти никогда не оправданно, потому что любое исключение неявно ломает ваши договоренности с другими людьми.

Строим модель влияния LLM на продуктивность разработки

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

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

Можно ли улучшить тулинг для кодревью

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

Ребята из GitClear реализовали другой алгоритм, который различает аж шесть видов операций: Added, Deleted, Updated, Moved, Find/Replaced, и Copy/Pasted. Этот алгоритм прогнали на 12 тысячах пулл реквестов, и получилось, что с его помощью ревьюить надо на 30% меньше строк кода, а понимание кода ревьюерами при этом не ухудшилось.

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

Как сообщать плохие новости

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

👉Избегайте дополнительной драмы и не сгущайте краски. На это влияет даже выбор используемых слов. Даже такое невинное выражение как "к сожалению" только подкрепляет негативные эмоции, и ведет к тому, что рационализирующая часть мозга теряет контроль.
👉Не углубляйтесь в лишние детали. Когда люди чувствуют вину, они склонны к слишком подробным объяснениям. Пользы от них мало – исходное сообщение усложняется, и получателю сообщения проще не становится.
👉Не берите на себя вину, даже если вам кажется, что так новость будет проще донести, или это успокоит ее получателя. Прогоните свою речь заранее и задайте себе вопрос: "Есть ли шанс, что получатель новости решит, что я принимаю часть вины на себя?".
👉Напомните получателю новости про его агентность. Она может выражаться в том, что он заранее принимал на себя риски, и тогда стоит об этом напомнить, или в том, что он может предпринять какие-то следующие шаги, которые помогут выбраться из ситуации.

Про фаворитизм

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

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

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

Как группа становится командой: фаза шторминга

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

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

👉Разбор кейса

Нейронетипичность

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

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

Эскалации как признак некомпетентных менеджеров

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

Чем выше уровень менеджера, тем на более далеком горизонте он должен работать. СЕО компании должен думать о том, как привести ее к успеху через 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. В этот раз статья про то, как разные особенности фреймворка постепенно изматывают команды разработки.

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