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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

👉Большая часть проблем с приоритизацией упираются в проблемы со стратегией: она может вообще отсутствовать, ее могут считать не очень важной, с ее ядром могут быть не согласны или ее просто могут не помнить. Поэтому в первую очередь разберитесь со своей стратегией. Как обычно, напоминаю про ключевую книгу, которую вам надо прочитать – 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 лет, а не о том, попала ли в спринт команды разработки фича, которая кажется ему важной. Но большой горизонт планирования влечет за собой отсутствие видимых краткосрочных результатов. Некоторых менеджеров это не устраивает и, чтобы почувствовать какой-то контроль, они начинают вмешиваться в операционку. В итоге страдают и команды, в работу которых они вмешались, и работа, которой на самом деле эти менеджеры должны были заниматься.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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