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

Как работать в условиях неопределенности Самое полезное свойство сеньорности разработчика или менеджера, которое я встречал – это способность решать проблемы все с большим и большим уровнем неопределенности. А самые интересные проблемы случаются где-то на стыках разных функций. Например, разработки и legal. Какого-то универсального прикладного алгоритма решения таких проблем, к сожалению, нет – на то она и неопределенность. Но вот неплохая ментальная модель, с которой к такой неопределенности можно подходить. 1️⃣Разберитесь, кто и как заинтересован в решении проблемы. Поговорите со всеми причастными командами, соберите максимально подробные требования, найдите все проблемные места на стыке разных функций и определите ключевых стейкхолдеров. 2️⃣Выделите возможные варианты решения проблемы. Кластеризуйте все возможные подходы, дайте им четкие и понятные имена, выделите трейдоффы для каждого кластера. А еще пообщайтесь с людьми из других компаний, чтобы апеллировать к их опыту. 3️⃣Опишите процесс принятия решения и проверьте, что все стейкхолдеры с ним согласны. Проведите их через этот процесс, пока решение для проблемы не будет выбрано и утверждено. Договоритесь, в каких условиях вы готовы будете переоткрыть обсуждение. Мне понравился ценный совет из статьи – не беритесь за проблемы, лежащие на стыке разных функций, если среди топ-менеджмента нет понятного спонсора их решения. Без этого вытащить будет практически невозможно.

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

Автоматизация дежурств в команде на базе Grafana и Slack Автор рассказывает, как завести в команде следующую схему дежурств: 👉В календаре заполняется график дежурств с указанием имен дежурных. 👉В Slack заводится обезличенный тег, вида @team_duty. 👉Календарь линкуется с Grafana. 👉При упоминании обезличенного тега дежурного Grafana автоматически определяет, кого надо позвать, и тегает его.

The LinkedIn DPH Framework Команда Линкедина пошарила набор практик, которыми руководствуются в работе их платформенные и инфраструктурные команды. Вот что туда входит: 👉Советы по выбору целей и релевантных метрик, которые помогают оценивать прогресс. А еще – сигналы, по которым можно судить, насколько разработчики довольны и продуктивны. 👉Базовые продакт-менеджерские практики, адаптированные под нужды платформенных команд. Например, создание персон и сбор фидбэка с релевантных групп пользователей. 👉Хорошие гайдлайны по тому, как дизайнить систему сбора метрик, в каких случаях предпочитать качественные инсайты, и как не потерять за деревьями лес. Когда-то я составлял похожий гайд для платформенных команд Авито – Developer Experience Framework. В отличие от варианта Линкедина, я гораздо меньше уделял внимания выбора конкретным метрикам, и больший упор делал на процессы в команде, управление бэклогом и конкретные инструменты работы с пользователями. И вот с точки зрения автора похожей инициативы могу сказать, что таких подррбных гайдов по работе именно с метриками нам действительно не хватало.

Какие практики менеджеры могут перенять у инженеров Когда ты работаешь инженером, многие вещи воспринимаются как норма – тщательное ведение задач, над которыми ты работаешь, написание документации, обеспечение прозрачности для всех, заинтересованных в твоей работе. Но вот как только ты перестаешь заниматься инженерными задачами и перескакиваешь в менеджеры, все куда-то теряется. Ты работаешь над проектами с гораздо более невнятно описанными требованиями, а большая часть работы вообще является невидимой. Но это необязательно воспринимать как данность, и часть инженерных практик можно применять и менеджеру. 👉Делать свою работу видимой, как минимум, трекая ее в тикетах. 👉Документировать все, что вы делаете, особенно причины этого. Хорошее правило – у всего должен быть url. 👉Чем бы вы ни занимались, цельтесь в то, чтобы релизить как можно чаще. Процессы, решения, рабочая документация – применимо ко всему. 👉Автоматизируйте. Не делайте вручную то, что может сделать машина. 👉Ведите Management Decision Records, аналог ADR.

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

Бреслав и Ложечкин про то, заменит ли AI программистов Наш любимый менеджерский подкаст возвращается после зимних каникул. В этот раз разговор идет про то, как взрывная популярность LLM повлияет в перспективе нескольких лет на изменение работы программистов и используемый технический стек. Про перспективы различных языков особенно интересно слушать Андрея Бреслава, как создателя Kotlin.

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

Обязательные знания для тимлида Обязательные знания тимлида по версии подкаста Подлодка и Виталия Шароватова: 👉Физиология и психология труда 👉Оргпсихология 👉Андрагогика 👉Кибернетика 👉Теория систем 👉Теория исследования операций 👉Теория массового обслуживания 👉Теория принятия решений 👉Теория очередей Разбор того, зачем конкретно нужна каждая из этих тем, и откуда получить недостающие знания – в выпуске, так что приходите послушать! А затем – поспорить в комментарии к посту.

Что произошло с зарплатами в 2023 за рубежом Небольшой отчет про изменения зарплат по данным сервиса levels.fyi. 👉В сравнении с 2022 медианная зарплата менеджеров чуть-чуть подросла, на 2%. А вот у разработчиков упала на 0.5%. 👉Самые большие зарплаты в Европе – в Швейцарии. Второе место – Лондон, затем Дублин.

Architecture modernization enabling team Представьте, что в большой системе, над которой работает сразу много команд, надо провести какой-то очень большой сквозной архитектурный рефакторинг. Настолько большой, что помимо изменений в конкретных местах кодовой базы, требуется внедрить какой-то дополнительный тулинг и поменять культуру и практики разработки. Конечно, в первую очередь надо задуматься, а точно ли вы понимаете, что и зачем делаете, или просто на очередной конференции услышали про распил монолита на микросервисы. Но допустим, что такое изменение оправдано. Держите статью про паттерн оргдизайна под названием AMET, Architecture Modernization Enabling Team. Суть такая. Под конкретное изменение собирается команда, которая будет его координировать среди всех участвующих команд, обучать их, вовлекать требуемых стейкхолдеров и следить за тем, чтобы проект не бросили на полпути. Такая команда – строго временная, ближе к концу проекта ее польза постепенно уменьшается, и, как только он кончится, ее можно разобрать

Как DORA метрики помогли легаси проекту Тимлид проекта с 25-летней историей развития, частично утерянными знаниями о его работе и повышенным количеством дефектов, делится тем, как фокус на улучшении характеристик, подсвечиваемых DORA метриками, помог за несколько лет существенно улучшить положение дел. Если вы не следили за хайпом вокруг DORA в среде DevOps, вот что это такое: 👉Deployment frequency: как часто команда релизит свою систему 👉Commit delivery lead time: время, за которое сделанный коммит доезжает до прода 👉Deployment failure rate: процент релизов, закончившихся поломкой 👉Mean time to recovery: среднее время на восстановление после поломки