Teamlead Good Reads – тимлиды, архитектура, менеджмент людей и разработки
20K subscribers
302 photos
2 videos
1.39K links
Самые интересные статьи, видео и новости, связанные с управлением людьми, командами, разработкой и продуктами.

Размещение рекламы: @tanyasanovna

Папка лучших продуктовых каналов: https://t.me/addlist/YvmnHCHUp700Nzky
Download Telegram
Что выделяет топ-1% продактов

Отличного продакта от хорошего отличить еще сложнее, чем в случае тимлида. Ты вроде бы чувствуешь, что он реально крутой, но если тебя попросят объяснить, откуда это чувство берется, сделать это будет очень сложно. Мне понравился набор эвристик, которые выделяет автор поста по ссылке, они в основном соотносятся и с моей чуйкой. Вот некоторые из них:

👉Think big. Крутые продакты смотрят в будущее, не пытаясь ограничивать себя существующими сейчас рамками доступных ресурсов. Они целятся в большие возможности, и переводят их в конкретные планы по их достижению.
👉 Prioritize. Крутые продакты умеют держать баланс между проектами, которые приносят быструю выгоду, и долгосрочными инвестициями в платформу.
👉Execution. Крутые продакты делают все, что нужно, чтобы их проект дошел до результата. И почти всегда это значит выходить сильно за рамки их основной роли.
👉Forecast and measure. Крутые продакты умеют очень приблизительно, но при этом близко к реальности, оценивать потенциальную выгоду от инвестиций, используя свой предыдущий опыт и бенчмарки.
👉Trust. Крутые продакты умеют зарабатывать доверие своих стейкхолдеров, и затем пользоваться им, чтобы двигаться быстрее.
👉Push back effectively. Крутые продакты умеют не просто говорить "нет", но делать это так, чтобы не заводить себе врагов, а, наоборот, убеждать противников своих идей.
👉Driven by impact, not promotion. Крутые продакты думаю не о собственном промо внутри компании, а в первую очередь про импакт, который они могут принести. Промоушн – производная импакта.
Серия постов Шароватова про планирование

Виталий Шароватов начал серию клевых заметок про планирование, в которых с помощью цепочки рассуждений объясняет несколько важных идей:

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

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

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

👉Основной источник стресса большинства людей – работа, а не личная жизнь. При этом рабочий стресс негативно повлиял на физическое здоровье аж у 77% опрошенных, а 75% набрали лишний вес.
👉Работа влияет на жизнь людей и с положительной стороны. 53% опрошенных благодаря работе нашли компанию людей с похожими интересами, 48% стали увереннее в себе, а 44% стали менее остро чувствовать одиночество.
👉Топ примеров того, как менеджеры негативно влияют на эмоциональное состояние: отсутствие понимания жизни сотрудника за пределами работы, неравное отношение к разным членам команды, нарушение границ рабочего времени.
👉А вот топ положительных примеров: гибкое отношение к рабочему времени, менторство, поощрение карьерных амбиций.
👉93% опрошенных считают, что работодатель должен помогать с ментальным здоровьем.

Добавлю от себя, что партнерки с различными сервисами психотерапии – очень крутая составляющая соцпакета. Я и сам регулярно ей пользуюсь, и часто направлял туда ребят из своей команды. Если у вас такой нет, настоятельно рекомендую добиться ее появления от своих HR.
Разработка мобильных приложений на заказ от CleverPumpkin

Я очень давно и хорошо дружу с ребятами из CleverPumpkin, бутиковой студии, которая занимается разработкой мобильных приложений на заказ. С их СЕО мы как-то писали чудесный выпуск Подлодки про то, как вообще выстраивать аутсорс-компании, там работали много моих друзей, а сейчас в QA работает моя жена! Поэтому этот пост, хоть и рекламный, но в этот раз прям от чистого сердца!

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

👉Они работают с одними из самых классных компаний в России: Хабром, Авиасейлс, Kassir.ru, Интерфакс, Sports.ru, Комитет, Подари жизнь, Пикабу и многими другими.
👉Помимо приложений на заказ делают и свои продукты, которыми многие из вас даже пользуются – например, Moneon для учета личных финансов.
👉Они угорают и по продуктовому, и по техническому качеству того, что делают – поэтому куча клиентов к ним приходит по рекомендациям.

Чтобы пост был не только рекламным, но еще и полезным, держите ссылки на крутой контент, который ребята делают:

🔗Гайд по этапам разработки мобильного приложения
🔗Как организовать трансфер проекта от аутсорса к инхаус команде
🔗Сколько вообще стоит сделать мобильное приложение

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

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

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

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

Через неделю стартует новый сезон конференции Podlodka Soft Skills Crew про то, как правильно применять софты на собеседованиях. Вот несколько топовых сессий:

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

Среди спикеров такие классные ребята как Женя Антонов, Алексей Шаграев, Вероника Ильина и Валерий Бабушкин.

📆Дата: 13-17 мая, две сессии в день
👉Регистрация
Не бросайтесь сразу же исправлять все проблемы

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

Автор дает два, на мой взгляд, очень ценных совета для таких ситуаций.

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

2️⃣Фокусируйтесь на нескольких самых важных проблемах, отложив десятки остальных. Автор называет это правилом 63 – выбираете 3 проблемы для исправления, а остальные 60 осознанно отпускаете. Такой подход помогает не размазывать свой ресурс слишком тонким слоем, и добиваться видимого результата.
Про когнитивную нагрузку

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

Автор предлагает смотреть на когнитивную нагрузку с помощью следующей ментальной модели:

cognitive_capacity = individual_cognitive_strength - (environment_cognitive_friction + task_cognitive_weight

👉Cognitive strength – количество ментальной энергии, которое конкретный человек или команда могут выделить на работу в конкретный день.
👉Cognitive friction – влияние рабочего окружения на ментальную нагрузку. Коимат в команде, качество кода, комфорт рабочего места, автоматизация рутины.
👉Cognitive weight – сложность конкретной решаемой задачи, как неотъемлимая, так и порождаемая плохой декомпозицией.
Гайд по внутренним коммуникациям

37signals написали классный гайд про организацию коммуникаций внутри компании. Общая философия – уводить все общение в асинхронный режим, все важное фиксировать в долгоживущих документах, а митинги проводить, только когда нет другого выбора. А детали сформулированы в виде 30 принципов. Вот некоторые из них:

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

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

👉Автоматические сообщения вроде "Какую книгу вы сейчас читаете?" или "Встречали ли вы в последнее время примеры классного дизайна?". Такие опциональные вопросы дают людям дополнительную возможность завязать разговор и сблизиться, что особенно важно удаленным командам.
👉Heartbeats: 6-недельные статус репорты команды, департамента или конкретного человека. Они содержат обзор самых важных ачивок, подчеркивают важность работы и рассказывают про интересные мелочи. Цель – рефлексия о текущем прогрессе и предоставление сводки тем, кто в ней заинтересован.
В жизни любого руководителя и директора случаются черные полосы и ошибки, которые уж точно никто и никогда не собирался совершать. Эти ошибки сжигают кучу нервов, портят отношения с людьми, а иногда ставят на кон всю карьеру или бизнес. Про такие фэйлы не пишут в книгах, про них не предупреждают перед переходом на позицию или при прохождении интервью. На такие грабли нужно самому наступить или послушать, как на них наступали другие руководители

11 мая Школа «Стратоплан» проводит бесплатную однодневную конференцию Failconf: лучше учиться на чужих ошибках. Там мы хотим открыто и без стеснения поговорить про несколько реальных факапов наших тренеров-руководителей, которые в свое время стоили им кучи нервов, бессонных ночей, потерянных денег, проектов и сотрудников.

4 спикера, 4 истории плюс сессия вопросов и ответов для разбора ваших ситуаций в работе.

11 мая — день признания собственных фейлов. Регистрируйтесь и приходите послушать, какие проблемы могут возникать даже тогда, когда «все учтено и продумано»: Failconf: лучше учиться на чужих ошибках.
Как писать дизайн-доки

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

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

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

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

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

Пункты довольно очевидные, но в реализации довольно сложные. От себя добавлю, что есть еще один очень критичный совет – иметь внятные совместные цели, определяющие успех этой команды и объединяющие ее.
Как подойти к succession planning

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

1️⃣Проанализируйте, чем вы занимаетесь

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

2️⃣Распределите преемственность

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

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

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

В статье хорошо разобраны предпосылки и следствия каждого из законов.
Митап в Берлине про Quality Engineering

Один из самых активных членов нашего чата @tlbootcamp, и автор бесконечности полезного контента про менеджмент Виталий Шароватов организует в Берлине митап про качество в разработке. В программе три доклада:

👉Про то, как коммуникации влияют на качество итогового продукта
👉Про тестирование технических требований
👉Про роль человеческого фактора в обеспечении качества

📆Дата: 23 мая, 18:30
🔗Регистрация
Как уйти от перфекционизма в стратегии

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

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

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

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

👉67% участвовавших в исследовании разработчиков используют Copilot ежедневно.
👉Половина опрошенных говорит, что для них Copilot был супер полезен, еще 30% – просто полезен.
👉Среди группы, пользовавшейся Copilot, количество PR выросло на 9%, а рейт прохождения кодревью – на 15%.
👉Качество кода вроде как тоже поднялось. Процент успешных билдов у тестовой группы на 84% выше.
👉Что касается релевантности – 30% саджестов от Copilot принимались разработчиками, и в итоге 90% участников закоммитили сгенерированный код.
👉95% участников сказали, что благодаря Copilot они получают от программирования больше удовольствия.

Вы можете провести аналогичное исследование и у себя в компании, GitHub опубликовал целую методичку для этого.