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

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

Папка лучших продуктовых каналов: https://t.me/addlist/YvmnHCHUp700Nzky
Download Telegram
Голосуем в исследовании тимлидов

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

👉Тимлиды постепенно уходят с полной удаленки, процент снизился с 44% до 35%. Основные причины возврата в офис – желание сменить обстановку, проведение встреч с командой и возможность быстрого решения вопросов.
👉Самым сложным в работе за последний год был слишком большой завал разными задачами и чересчур масштабные цели.
👉Треть тимлидов не получает поддержки от своих компаний в вопросах обучения – нет внутренних курсов, не оплачиваются внешние.

🔗Опрос можно пройти вот тут, результатами поделюсь в канале
Подкасты про переговоры

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

Держите два наших недавних подкаста, которые помогут вам узнать и попробовать новые тактики:

👉Выпуск Подлодки про зарплатные переговоры с Ильей Синельниковым
👉Выпуск Бреслава и Ложечкина про сложные переговоры со всякими топ-менеджерами
Pioneers – Settlers – Town Planners

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

👉Pioneers. Инноваторы, которые любят работать в условиях неопределенности, пилить кучу прототипов, исследовать новые идеи.
👉Settlers. Практики, которые умеют брать прототипы и продуктизировать их, доводя до пользователей в надежном виде.
👉Town Planners. Те, кто умеет оптимизировать уже существующие рабочие системы, делая их более надежными, стабильными и дешевыми.
Три важных софт-скилла при найме

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

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

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

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

Зачем нужны скип-левелы вверх:

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

Зачем нужны скип-левелы вниз:

👉Вы можете заметить начинающие таланты
👉Вы можете сравнить то, что говорит про климат в команде менеджер, и то, что считают сами члены команды

А самая главная ценность в таких встречах – возможность начать строить доверительные отношения не только с теми людьми, с кем вы постоянно работаете.
У Виталика в канале отличная подборка исследований про social loafing, эффект, при котором в больших группах люди прикладывают меньше усилий к своей работе. Берите себе на вооружение, это очень полезное знание, чтобы останавливать неразумных менеджеров, пытающихся сделать странное.
Forwarded from Sharovatov (Vitaly Sharovatov)
Кратко про social loafing (эффект, когда в группе люди прикладывают меньше сил к труду по сравнению с тем же трудом в одиночку):

основными причинами этого эффекта являются:
- излишне крупные группы
- ощущение несправедливости, возникающее от того, что люди видят, что кто-то “мало усилий прикладывает”
- “неинтересные задачи”

это что ж получается такое удивительное — людям внезапно становится скучно и неинтересно если увеличивать команды до дурных размеров а потом реальные проблемы по-барски эдак декомпозировать и раскидывать между людьми (продакт умнее пусть придумывает чо делать а тимлид умнее пусть и придумывает как делать)

кто бы мог подумать?

Рефы:
- https://journals.sagepub.com/doi/10.1177/0146167284101011
- https://psycnet.apa.org/doiLanding?doi=10.1037/0022-3514.37.6.822
- https://www.researchgate.net/publication/228608182_Social_Loafing_A_Field_Investigation
- https://journals.sagepub.com/doi/10.1177/0022002183014003009
- https://journals.sagepub.com/doi/10.1177/001872679504800603
Еще про перегрузку менеджеров

В продолжение вчерашнего поста даввйте поговорим о том, а откуда конкретно берется эта менеджерская загруженность:

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

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

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

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

По ссылке – хорошая подборка вопросов, которые стоит задавать при сборе рекомендаций. Вот некоторые из них:

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

Расскажите в комментариях, какие вопросы обычно задаете вы!
Инструкция по организации онбординга

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

Для затравки, некоторые тезисы:

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

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

👉Чтобы понять ваш совет, надо обладать вашим жизненным опытом, без него он неполный.
👉Люди могут просто не понимать ваш совет, особенно если он идет вразрез с их оценкой реальности.
👉В целом они согласны с вашим советом, но по какой-то причине в глубине души им кажется, что он не сработает. Например, потому что требует слишком много нестандартных усилий, а результат не гарантирован.
👉То, что сработало для вас, вообще не обязательно сработает и для других.
👉Людям может не хватать понимания контекста, чтобы оценить и принять совет.
👉У проблемы, на решение которой направлен ваш совет, и у того, почему ему не следуют, может быть один руткоз.
Как работать с кандидатами после того, как они приняли оффер

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

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

Я не очень сильно доверяю зарплатной статистике Хабра, но картина все равно интересная:

👉2024 год не стал хуже в сравнении с 2023. Конкуренция за вакансии стажеров и джунов осталась на том же уровне, где-то 80 откликов на каждую.
👉Больше всего джуновых вакансий среди бэкендеров. За ними идут, понятное дело, фронтендеры, и, удивительно, системные аналитики. Близких моему сердцу мобильных разработчиков нет даже в топ-10.
👉Зарплаты за год чуть-чуть подросли, примерно на 7%.
👉Джунов часто берут на удаленку, доля таких вакансий – 60%.
Как быть одновременно поддерживающим и требовательным

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

Лучше регулярных походов в спортзал только регулярные походы туда под хорошие подкасты. И я вам принес сразу пачку новых тимлидских выпусков:

👉Подлодка про корпоративное обучение: как строить внутренние и внешние программы обучения, оценивать пользу от них и откуда брать экспертов.
👉Бреслав и Ложечкин про переговоры с топами: как тимлидам защищать результаты своей работы, получать ресурсы и поддержку.
👉Три тимлида заходят в бар про оценку руководителей: как понять, хороший ли ты тиилид, или просто с командой повезло.
👉КОДА КОДА про конструктивные коммуникации и конфликты: про ошибки в общении, манипуляции и работу с эмоциями.
Тимлид не спит: команда двачеров

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

К чему все это – в нашем новом проекте "Тимлид не спит" мы запустили разбор первого кейса! Работает все так:

👉Сегодня собираем ответы подписчиков (не в этом канале, а вот тут)
👉Завтра публикуем разбор кейса несколькими экспертами
👉Подписчики выбирают самый лучший вариант разбора. Участвуют и эксперты, и ответы из комментариев!

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

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

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

Разберемся в этой классификации чуть-чуть подробнее.

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

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