Менеджеры-антипаттерны

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

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

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

Запугивающие вопросы

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

Менеджерам особенно важно уметь чувствовать эту грань. Некоторые вопросы могут довольно сильно подорвать моральный дух ваших сотрудников. Вот несколько таких примеров:

❌Я просил тебя это делать?
❌Кто дал тебе право принимать решение?
❌С чего ты взял, что это будет работать?

Вот более корректные варианты формулировок:

✅Из каких вариантов решения и как ты выбирал?
✅Какие факторы повлияли на то, как ты принимал решение?

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

Отличная статья от Дмитрия Болдырева, разбирающая каждый из этапов формирования команды – forming, storming, norming, performing, на примере монтажной бригады, прокладывающей ЛЭП где-то в тайге. Всю статью пересказывать не буду, поделюсь лишь одной частью – список вопросов, на который у группы должны быть ответы, чтобы она могла функционировать как нормальная команда:

👉Предмет деятельности (чем мы будем заниматься?)
👉Цели (зачем мы всё это делаем и каких именно результатов планируем достичь?)
👉Стратегия (каким образом, за счёт чего мы добьёмся поставленных целей?)
👉План (что, когда, в какой последовательности будем делать?)
👉Рабочие процессы (как что должно происходить?)
👉Роли (кто за что будет отвечать, кто конкретно, что именно будет делать?)
👉Регламенты взаимодействий (кто, что, кому передаёт, когда, в каком виде и т.д.?)
👉Стандарты качества (какое выполнение работы будет считаться хорошим, а какое плохим?)
👉Способы контроля качества (как мы будем проверять и оценивать выполненную работу?)
👉Система ответственности и вознаграждений (что получат участники, если добьются или не добьются ожидаемых результатов; как индивидуальных, так и групповых?)
👉Правила принятия решений (какие решения могут приниматься индивидуально, какие только группой и, если группой, то по какому принципу – единогласно, большинством или каким-то иным способом?)
👉Нормы поведения (какое поведение приветствуется, а какое нет?)
👉Система статусов, она же внутренняя иерархия (кто какой имеет вес и влияние?)
👉Лидерство (кто будет всем управлять, кого мы будем слушаться?)

Если предпочитаете смотреть, а не читать, вот тот же материал в видеоформате.

Как Leetcode влияет на прохождение интервью

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

👉В целом корреляция между решением задач на Leetcode и успешным прохождением интервью довольно сильная.
👉На силу корреляции влияет количество решенных задач и их сложность. При этом количество влияет только до определенного порога, после 500 задач эффект перестает расти так сильно.
👉Рейтинг на Leetcode не коррелирует с успешностью интервью.
👉Прорешивание сложных задач в два раза эффективнее, чем задач средней сложности. Каждые 50 сложных задач ведут к повышению успешности прохождения интервью на 7%.

Про зомби-процессы

Зомби-процесс – это какая-то практика, которая продолжает использоваться в компании только потому, что так принято, а не потому, что она продолжает приносить ту пользу, которая предполагалась изначально. Стандартный пример – OKR. Такой дрифт происходит постепенно:

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

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

Как давать субъективный фидбэк

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

Несколько правил, которые вам помогут:

👉Вообще забудьте о том, что фидбэк обязан быть объективным, это не так. Любая обратная связь от другого человека так или иначе субъективна. Главное, чтобы она была направлена на пользу общему делу.
👉Как обычно, по максимуму фокусируйте обратную связь на работе, а не на личности. Это касается как обсуждения нежелательного поведения, так и результатов – вам не надо просить человека меняться, вам надо объяснять ему, как его работа влияет на общий результат.
👉Чтобы дополнительно показать, что вы пришли поддержать, а не обвинять, подсветите роль окружения и внешних факторов в нежелательном поведении.
👉Расскажите, какой вы бы видели работу человека в идеальном мире, фокусируясь на конкретных изменениях.

База про компенсационную модель

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

👉Определяется иерархия ролей, состоящая из функции (маркетинг, разработка, дизайн), подфункции (разработчик, qa, sre), карьерного трека (менеджер или индивидуальный контрибьютор).
👉Для определения уровня оплаты каждой из клеточки получившейся матрицы проводится бенчмаркинг – либо через закупку отчетов у специализирующихся на этом компаний, либо с использованием рыночных данных с того же Glassdoor.
👉Расчитываются вилки – обычно от 80% до 120% от мидпойнта. Вилки соседних уровней чаще всего идут внахлест.
👉На все это накладываются региональные коэффициенты, если компания работает сразу в нескольких странах или районах.

Что делать, когда компания вам не подходит

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

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

Кент Бек про проектный треугольник

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

Как Scrum изматывает команды

Месяц не будет полным, если хотя бы раз не побухтеть на Scrum. В этот раз статья про то, как разные особенности фреймворка постепенно изматывают команды разработки.

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

Новые выпуски тимлидских подкастов

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

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

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

👉Кейс в канале

"Ставить под сомнение" как отдельный скилл

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

Я так и не смог найти более подходящий перевод на русский замечательного выражения "call bullshit", который не имел бы негативных коннотаций.

Podlodka Techlead Crew – это конференции для техлидов и опытных инженеров.

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

Спикеры этого сезона:

- Филипп Дельгядо расскажет, где искать надёжность при взаимодействии сервисов и стоит ли верить стандартным рекомендациям.
- Даниил Подольский обсудит Disaster Recovery и управление рисками.
- Вадим Мартынов расскажет о контроле перегрузок и защите сервисов от отказов.
- Александр Агейченко разберет принципы мобильной надежности на примере мобильного Т-Банка.

И это далеко не вся программа! Полная информация, а также билеты по сниженной цене ищите у нас на сайте: https://podlodka.io/techcrew 🏃‍♂️

Приоритизация

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

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

Аудит своей занятости

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

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

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

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

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

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

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

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

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

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

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

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

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

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