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

Подборка свежих выпусков тимлидских подкастов

👉"Бреслав и Ложечкин" про то, как управлять изменениями в компаниях и в продуктах – как всегда, с кучей баек из опыта.
👉"КОДА КОДА" с Максимом Дорофеевым про логику и умение выстраивать причинно-следственные связи (а заодно и про его новую книгу).
👉"Едим слона целиком" про то, как руководителю искать для себя новые точки роста.
👉"Организованное программирование" про рынок найма в 2025 году – как на него повлияли все последние кризисы, в чем отличие от 2008 и как автоматизация и AI меняют сам процесс подбора.

Чек-лист по превращению рабочей группы в команду

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

1️⃣Этап предварительного анализа

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

2️⃣Этап постановки целей

👉Сформулируйте, зачем вам вообще нужен командный формат
👉Определите общую цель команды и стратегию достижения
👉Добейтесь buy in этой цели

3️⃣Этап реорганизации рабочих процессов

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

4️⃣Этап налаживания отношений в группе

👉Разрешите накопившиеся конфликты
👉Научите договариваться и аргументировать свою позицию
👉Научите людей принимать и ценить друг друга
👉Создайте атмосферу психологической безопасности и доверия
👉При необходимости обновите состав команды

5️⃣Этап отладки системы управления командой

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

Принципы СТО Amazon

👉Думайте о решении реальных проблем, а не о хайпе. Не нужно внедрять технологии только из-за FOMO.
👉Сбои и падения – часть плана, не нужно строить идеальные системы. На больших масштабах каждая дополнительная девятка в SLA стоит миллионы. Стремиться сделать отказоустойчивыми все элементы системы – дорого и бессмысленно. Вместо этого можно думать про три категории сервисов – Tier 1 (ни в коем случае не должно падать), Tier 2 (может немного деградировать), Tier 3 (может упасть, и никому не будет дела).
👉Разделяйте решения на обратимые и необратимые, они же – one-way/two-way doors. Обратимые решения принимайте как можно быстрее на неполных данных. Необратимые – замедлитесь и подумайте глубоко.
👉Security > Operations > Cost. Security – нельзя допускать никаких компромиссов в вопросах безопасности. Operations – софт дольше живет в продакшне, чем в разработке, так что удобство его поддержки должно быть заложено на самом старте. Cost – системы должны дизайниться с расчетом не только на масштабирование, но и наоборот, на возможность сжиматься в меньшие масштабы.
👉Кто сервис написал, тот за него дальше и отвечает – поддерживает, дежурит, чинит аварии по ночам. Благодаря этому у инженеров сохраняется плотный цикл обратной связи, и они видят последствия своих решений.

Про градиент власти

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

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

Вот некоторые из практик, которые помогают уменьшать такой разрыв:

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

Про хорошие публичные выступления

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

1️⃣Информировать аудиторию о том, что вы сделали, и почему это важно. Причем делать это, не вдаваясь слишком глубоко в детали, не интересные аудитории.

Стандартные паттерны:

👉Что-то раньше считалось невозможным, а вы показали, как это сделать
👉Что-то раньше было сложным или неэффективным, а вы показали путь получше
👉Что-то подвержено ошибкам, а вы показываете, как уменьшить их риск
👉Что-то очень сложное, или аудитория это плохо понимает, а вы можете это объяснить простым способом
👉Что-то кажется всем верным, а это на самом деле не так

2️⃣Образовывать аудиторию. То, о чем вы рассказываете, должно быть полезным, причем не только в вашем узком домене. Ключевые идеи должны быть сформулированы так, чтобы слушатели могли перенести их в свой контекст.

3️⃣Развлекать аудиторию. Это не значит, что нужно вставлять мемы на каждый слайд, или превращать доклад в стендап – вам надо нащупать комфортный вам способ зацепить аудиторию. Это может быть структура доклада, какие-то отсылки, искренность, открытость.

Я, кстати, когда-то давно писал статью со своими мыслями про подготовку хороших выступлений, куда добавил побольше прикладных советов и практик. Old but gold!

Как разговаривать про повышение зарплаты

1️⃣Занизьте свои изначальные ожидания, и не расчитывайте на то, что зарплату точно поднимут до того уровня, который вы хотите. Вместо этого сфокусируйтесь на том, что в зоне вашего контроля.
2️⃣Разберитесь в том, как работает пересмотр зарплат в вашей компании, и какие факторы на него влияют. Получить повышение проще, когда вы приходите за ним в нужный момент цикла бюджетирования. Еще лучше, если вы сможете получить критерии, на которые обычно смотрят при пересмотре.
3️⃣Подготовьтесь к разговору и покажите: план/факт по вашим целям и ожиданиям; что заметного вы сделали за рамками этих ожиданий; как ваша работа соответствует ценностям компании.

По итогу, на вероятность пересмотра больше всего влияет:

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

Google сократил треть руководителей маленьких команд

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

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

Лучшая архитектура – самая простая

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

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

Отрываем коммуникации от оргчарта

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

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

Правила хорошей коммуникации

Великолепный пост про то, как доносить важную информацию через каналы внутренней коммуникации.

👉Чем больше аудитория, тем больше в ней групп, заинтересованных в разном количестве деталей. Поэтому делайте вашу коммуникацию "слоеной" – начинайте с ключевой мысли, затем разбивайте ее на основные тезисы, а затем уже уходите вглубь каждого тезиса. Так люди смогут быстро понять, на какой уровень хотят погрузиться, и не отвалятся, совсем ничего не поняв.
👉Учитывайте не только тех, кому вы что-то рассказываете, но и аудиторию второго порядка – тех, до кого информация дойдем в пересказе. Поэтому информацию полезно давать в сжатом виде, который легко пересказать.
👉Учитывайте самый циничный способ интерпретировать свои слова. Такой человек обязательно найдется, он же перескажет ваши слова в таком виде другим людям, и эта версия разойдется по всей компании. Поэтому всегда перечитывайте свои мысли, оценивайте, можно ли их истолковать превратно, и докручивайте, чтобы уменьшить шансы на это.
👉Чтобы вашу ключевую мысль точно услышали, повторяйте ее несколько раз.
👉Используйте сразу несколько каналов, чтобы передать важную информацию – разные люди предпочитают разные источники. Плюс даже в маркетинге есть правило нескольких касаний.
👉Поддерживайте свои каналы донесения информации даже тогда, когда они вам не нужны – иначе потом, когда они понадобятся, будет поздно.
👉Доносите информацию как можно раньше, и как можно чаще. В большинстве случаев не нужно ждать 100% уверенности и вылизанности сообщения – шанс ошибиться не перевешивает появление слухов. Люди гораздо лучше справляются с неидеальной или неполной информацией, чем с информационным вакуумом.
👉Дебажьте проблемы в коммуникациях. Если вы что-то рассказали, а люди это не услышали, либо интерпретировали не так – в этом только ваша вина. Единственное, что вы можете сделать – попробовать понять, почему это произошло, и быть лучше в следующий раз.

Ментальные модели работы организации

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

👉Parkinson's Law of Triviality. Группам свойственно тратить слишком много времени на самые тривиальные вопросы. Это происходит потому, что обсуждать простые и понятные темы – безопасно.
👉Hick's Law. Чем больше вариантов решения есть, тем дольше оно будет приниматься.
👉Chesterston's Fence. Не отказывайтесь от каких-то правил, пока не поймете, зачем их вводили.

Про умение признавать ошибки

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

Главное, что с этим можно сделать – это научиться признавать свои ошибки, брать за них ответственность и восстанавливать доверие команды. Подписываюсь под этим на 200% – худшие менеджеры, с которыми я работал, ставили меня под удар, а потом просто продолжали общаться как ни в чем не бывало, даже не сделав попытку исправить ситуацию.

Вот что стоит сделать, если вы накосячили:

👉Будьте конкретными, когда говорите про свою ошибку. Вместо "можно было поступить лучше" говорите что-то вроде "Я перебил тебя на встрече, из-за чего тебе не дали высказать свою точку зрения".
👉Не оправдывайтесь. Не нужно объяснять, что именно вызвало ваш поступок – об этом вы сможете поговорить со своим терапевтом. Сосредоточьтесь на том, как ваша ошибка повлияла на других.
👉Чтобы слова не остались пустыми, вам надо изменить свое поведение и не повторять аналогичных косяков.
👉Готовьтесь к тому, что одного признания вины будет недостаточно, и на восстановление доверия уйдет время.

Джунов все-таки стали нанимать меньше

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

Держите свежее исследование рынка вакансий США, из которого видно следующее:

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

Про экзотические метрики

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

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

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

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

👉"Бреслав и Ложечкин" про то, как персональный бренд может иногда помочь прокачать карьеру, а иногда – быть уволенным
👉"Подлодка" про доверие к AI – откуда берутся галлюцинации и bias, и как с ними бороться
👉"Weekend Talks" с Виталием Шароватовым про его карьерный путь, помощь людям вокруг и важность тестирования
👉"КОДА КОДА" с Кириллом Мокевниным про A-players: кто это такие, надо ли их нанимать, и какую пользу бизнесу приносят
👉"Едим слона целиком" про способы управления командой и сохранения культуры в условиях очень быстрого роста

Как работать с социопатами

Если вы когда-то встречали людей, для которых:

👉Должность – способ самоидентификации
👉Люди вокруг – ресурсы или препятствия
👉Рабочие отношения воспринимаются как игра в статус
👉Положение в иерархии определяет отношение к другим и способы общения

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

1️⃣Не играйте с ним в иерархию. Ведите себя нейтрально – не реагируйте ни на лесть, ни на хамство.
2️⃣Фиксируйте все договоренности письменно, чтобы уменьшить возможности манипуляций фактами.
3️⃣Не оправдывайтесь перед ним, иначе он воспримет это как уязвимость и использует ее.
4️⃣Не вступайте в моральные дебаты. Сводите все общение к конкретной рабочей задаче.
5️⃣Не становитесь его другом, даже если он пытается подкатить. Дружба с социопатом всегда условная, и будет использована им как инструмент.
6️⃣Ищите союзников, с которыми можно поделиться своими наблюдениями, и которые смогут поддержать вас.

Заменять джунов на AI – тупейшая идея

На волне популистских заявлений всех компаний, делающих что-то вокруг AI, последнее интервью СЕО AWS выглядит прямо хорошо:

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

Как не превратиться в психотерапевта для своей команды

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

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

Так вот, поговорим о том, как построить эти здоровые границы:

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

Текущее состояние AI-assisted разработки

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

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

👉Адопшн AI очень большой и продолжает расти – разработчики всегда пытались сократить рутинную работу, и эти инструменты им помогают.
👉Трезвая оценка повышения продуктивности где-то в районе 20-30%, причем не во всех командах.
👉Все очень сильно варьируется от случая к случаю, например польза для новичков и для сеньоров будет очень разной.
👉С одной стороны, AI инструменты провоцируют over-confidence, а с другой – слепо доверять результатам их работы вообще нельзя.
👉Output != Outcome. Кода пишется больше, но скорость разработки может не измениться вообще, а то и упасть.

Как с этим вообще жить:

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

Слышу много похожих рассказов от друзей, которые сейчас плотно работают с джунами. Расскажите, а как у вас?