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

Публикуем новый кейс + разбор от экспертов канала! 👉 Кейс #9 Политический конфликт Директор отдела смежников имеет личный конфликт с директором вашего отдела из-за неразделенных амбиций(ваш отобрал область задач и влияния у другого пару лет назад). Это сильно мешает работе твоей команды, когда вам нужно иметь дело с зоной ответственности смежников. Тяжелые кодревью, невозможность синхронизировать планы или получить апрув на изменения в пересекающихся доменах стали вашей реальностью последние пару лет. Все потому, что у соседей когда-то забрали кусок предметки и то не вы. Топы уровнем выше признают проблему, но не могут ничего с этим сделать. Оба директора компетентны и решают задачи бизнеса хорошо. Проблема усугубляется тем, что уже ваша команда накопила вагон обидок и претензий, и начинает предвзято относится к соседям во всех вопросах. Найти общие вектора и договориться тоже не получается, потому что договариваться никто не хочет. Что делать не понятно. С уровня руководителя команды помирить директоров сложно, да и вроде не твоя задача. Команда, домен и работа нравится, но воевать за каждый шаг в предметке надоело и мне и команде. Очевидное решение для топов вернуть домен назад вместе с командой, но к смежникам в отдел идти уже никто не захочет в силу накопленного негативного опыта. Да и странно из-за обидок и амбиций двух людей дамажить работу нескольких команд. ❔Поделитесь, решали ли что-то подобное. Может кто-то медиацию пробовал или что-то похожее? 💬Разбор от экспертов Кейс разбирали: 👉 Александр Орлов @eagleson77, автор книги "Джедайские техники конструктивного обшения", управляющий партнер Школы менеджмента Стратоплан 👉 Миша Шляхов @tehaleph - техлид из Tutu.ru

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

Результаты большого исследования тимлидов Я проводил исследования мобильных разработчиков, продактов и тимлидов довольно долго, еще с 2017 года. И вот этот рисерч – первый, который проводился вообще без меня, так как я решил полностью выйти из проекта. Поэтому я вдвойне рад, что у ребят все получилось, и несу вам разные интересные инсайты из него: 👉Основные обязанности руководителя: собеседования, развитие людей и оценка перфоманса. 👉Напрямую зарплатами своей команды управляет только половина линейных тимлидов. 👉Большинство руководителей тратит на написание кода не больше 30% своего времени. 👉Самыми важными навыками считают умение работать с людьми и командами. А вот, например, обеспечение качества болтается где-то в самом низу списка, что заставляет где-то грустить одного Виталия Шароватова. 👉Самая разочаровавшая всех книга – "Как пасти котов" 😅 👉Основной критерий выбора компании для работы – зарплата.

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

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

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

Исправляем недостаток стратегического фреймворка Румельта Продолжаю топить за то, что лучшая книга, которая может вас научить тому, что такое стратегия – "Good Strategy, Bad Strategy". Ключевая идея автора книги, Ричарда Румельта, в том, что хорошая стратегия должна строиться вокруг челленджей, которые компании требуется преодолеть, чтобы достичь своих целей. Вокруг этих челленджей выстраивается ядро стратегии – набор "направляющих политик" – принципов, по которым вы работаете, и конкретных усиляющих друг друга действий. Так вот, мне всегда казалось, что во фреймворке не хватает одного важного компонента – ставок на то, как будет развиваться будущее. Вера компании в какой-то конкретный сценарий должна сильно влиять на принимаемые решения. Поэтому я всегда в разделе с диагнозом старался в явном виде описать, каким мы видим будущее, и почему верим, что оно будет именно таким. Точка зрения автора статьи полностью совпадает с моей, но он преисполнился настолько, что даже обсудил ее в переписке с самим Румельтом. В общем, если вы уже читали книгу, статью точно рекомендую. Если не читали – ну вы поняли, что делать на выходных. Кстати, благодаря этой статье я узнал, что сравнительно недавно Румельт выпустил продолжение – The Crux. Как прочитаю, обязательно поделюсь впечатлениями!

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

Опасность и вред метрик в менеджменте Самая важная цитата Питера Друкера, которую вам надо помнить: What gets measured gets managed—even when it's pointless to measure and manage it, and even if it harms the purpose of the organization to do so. Вторая самая важная цитата: It is the relationship with people, the development of mutual confidence, the identification of people, the creation of a community. This is something only you can do… It cannot be measured or easily defined. Откуда берется вред измерений: 👉Без глубокого понимания оптимизируемого процесса и системы, в которой он работает, из метрик очень легко сделать ложные выводы, или пропустить какие-то сайд-эффекты. 👉Проще всего поддаются измерению метрики, определяющие успех на коротком горизонте. Если сфокусироваться на них, получите много локальных оптимизаций, которые легко могут испортить общую картину. 👉Фокусируясь на измеримом, например, на скорости разработки, вы теряете фокус с других важных компонентов, которые измерить сложно, вроде климата в команде или качества принятия решений. 👉Метрики вселяют ложное чувство безопасности и контроля, которого на самом деле у вас нет.

Как менеджерам не попасть под сокращения Регулярные массовые сокращения стали уже привычной новостью. Только за прошедший месяц сходу вспоминается два громких лэйоффа в ABBYY и в Miro. Логика выбора того, кого сократить, в каждом конкретном случае отличается, но можно выделить общие паттерны, которые увеличивают или уменьшают ваши риски. Какие категории сотрудников обычно попадают под сокращения: 👉Accodentally Invisible. Работа, которую они делают, не видна топ-менеджменту, даже если она важная 👉Faded Glory. Когда-то сделали важный проект, но в последнее время он перестал быть кому-ьо интересен. 👉Needs Auxiliary Management. Есть заметные со стороны проблемы с качеством работы, коммитментами, софт-скиллами, так что для работы с ними требуется прилагать больше усилий. 👉Kingdom of None. Если всю или значимую часть команды сокращают, то менеджер попадает туда же под раздачу. Это касается не только прямого менеджера, но и любых технических лидов. Вот несколько советов, как тимлиду и его команде уменьшить свои шансы попасть под лэйофф: 👉Активно помогать людям в своей команде находить возможности достичь заметных всем результатов. Верно и обратное – как только вы понимаете, что проекты, над которыми вы работаете, не важны топ-менеджменту, надо либо найти возможность вернуть им актуальность, либо перевести команду куда-то еще. 👉Помогать своей команде достигать этих результатов, в том числе быстро и явно рассказывая им про проблемы с их перфомансом. 👉Делать так, чтобы работа вашей команды была заметна топ-менеджменту, и ее важность была понятна. Это особенно важно для всяких около-инфраструктурных штук, которые влияют вообще на все, но абсолютно невидимы со стороны.

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

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