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

Пару лет назад я написал шуточную статью «Как подсидеть тимлида». Но шутки-шутками, а кто-то подсиживает тимлидов на самом деле, и даже написал готовую инструкцию:
1️⃣Найти проблему в команде
2️⃣Начать ее исправлять, показав максимум инициативы и добившись результатов
3️⃣Пожаловаться вышестоящему руководству на то, что лямку самому тянуть приходится, а текущий руководитель не справляется
4️⃣Перейти решать проблемы в другой части компании и ждать, пока старый руководитель зафейлится
5️⃣Профит

Только после прочтения я понял, что, кажется, стал однажды жертвой примерно такой схемы. А вообще политику в компании и стандартные манипуляции мы разбирали в этом выпуске Подлодки.

Причина большинства проблем многих команд – это их тимлид. Знание частых антипаттернов может помочь вам не попасть в число таких команд. В статье разбираются три довольно часто встречающихся случая:
📌Слишком сильная декомпозиция и конвейерная работа над задачами
📌Переизбыток встреч по грумингу/планированию/ретроспективе
📌Чрезмерное увлечение диаграммами Ганта и проектными планами

Если вы чувствуете, что вас слишком сильно завалило различными пожарами, проектами и обещаниями, то вам может помочь один из самых простых и действенных инструментов тайм-менеджмента – мартица Эйзенхауэра. Ключевая идея проста – разбейте весь свой бэклог на четыре категории:
1️⃣Срочное и важное
2️⃣Не срочное и важное
3️⃣Срочное и не важное
4️⃣Не срочное и не важное

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

Если захотите узнать больше деталей, вот статья про то, как эту матрицу можно применять к задачам менеджера.

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

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

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

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

В рамках коллаба с каналом «Тимлид Очевидность» мы с Евгением Антоновым решили написать две заметки с советами про то, как тимлиду справляться с такими заказчиками, помогать им выявлять проблемы и придумывать решения. Обязательно подпишитесь и на него и прочитайте его пост на ту же тему.

Задавайте вопросы
Если вы видите, что вам приносят уже готовое решение, задайте заказчику несколько вопросов, которые помогут докопаться до исходной проблемы и контекста:
1. Какую проблему наших пользователей это решает?
2. Для кого конкретно мы решаем эту проблему?
3. Почему ты уверен, что эта проблема стоит решения?
4. Почему нужно решать ее именно сейчас?
5. Как решение проблемы повлияет на цели команды/продукта (если они есть)?
6. Что еще надо учесть при реализации задачи?

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

Если вы хотите глубоко погрузиться в теорию ограничений, то рекомендую такую последовательность:
1. Цель, Элияху Голдратт
2. Цель 2, Элияху Голдратт
3. Теория ограничений Голдратта, Уильям Детмер (именно здесь дается подробный обзор всей методологии и инструментов)

Если вы хотите вкатиться побыстрее, то вот короткий воркшоп от нас со Стасом Цыгановым про наш опыт применения ДТР для поиска корневых причин проблем.

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

Продвигать свои идеи в организации довольно сложно. Эта сложность имеет свойство нарастать с увеличением размера компании. Хотите сделать какой-то общий для всех сервис, чтобы не плодить костыли? Готовьтесь пробиваться через толпу людей, которых вам придется переубедить.

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

Есть два подхода к приоритизации:
1️⃣Собрать большой лист всего, что вы хотите сделать, отсортировать его, и стараться делать больше важных вещей и меньше не важных
2️⃣Отказаться от такого списка и делать только одну самую важную в настоящий момент вещь

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

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

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

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

Чтобы вдохновиться, почитайте этот исчерпывающий материал про то, как писать полезные эссе и делать это частью своей жизни.

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

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

В статье рассказывается про альтернативную систему ценностей: Люди->Бизнес->Деньги, в которой главной целью компании становится реализация и развитие ее сотрудников, а все остальное – просто производные от успеха людей.

Чтобы увольнение человека из команды не стало для вас сюрпризом, задайте ему на следующем one-on-one такие вопросы:
1️⃣Что в твоей работе за последний год было самым интересным?
2️⃣Какие возможности для роста у нас совпадают с твоими собственными целями?
3️⃣Какая поддержка от меня могла бы тебе помочь?
4️⃣Если бы у тебя была волшебная палочка, и ты мог бы изменить только один аспект своей работы, что бы это было?

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

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

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

Большая часть этих уроков выглядит банально и точно вас ничему не научит. Мне хочется, чтобы вы посмотрели на сам формат, и попробовали похожим образом проанализировать уроки, которые вы уже успели получить на текущем месте работы. А если получится – поделитесь ими в обсуждениях статьи!

Я когда-то уже писал пост про то, что система собственных принципов, описанных в явном виде, это прекрасный инструмент для того, чтобы принимать последовательные решения. Лучше всего про это рассказывается в книге Рэя Далио «Принципы». Если вы еще не читали ее, то добавляйте в вишлист.

Ваши принципы могут быть не только высокоуровневыми, описывающими принятие жизненных решений, но и частными. Например, принципы, которыми вы пользуетесь при написании кода или при работе с командой. Автор сегодняшней статьи использует четыре собственных принципа для того, чтобы отстраивать конкретные процессы в команде. Например, принцип «Humans behind lines of code» приводит его к тому, чтобы заниматься распределением знаний между членами команды с помощью дизайн сессий и парного программирования.

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

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

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

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

Туту подробно рассказали про то, чем занимался их СТО за 13 лет работы в компании. Помимо того, что в рассказе просто много интересных баек, это еще и очень крутой заход на найм нового СТО. Ребята детально рассказали про область ответственности, привели примеры старых челленджей, показали культуру компании, и все это завернули в отличную историю. Берите инструмент повышения интереса к вакансии себе на заметку!

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

А если у вас есть опыт управления командами дизайна – расскажите интересных историй в комментариях!

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

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

Кстати, если вам интересны продуктовые темы, рекомендую в целом подписаться на рассылку от Lenny – там много золотых материалов появляется.