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

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