Потеря людей в команде это вообще очень сложная тема. При оценке последствий ухода сотрудника нужно оценивать количество разрушенных социальных связей внутри вашей команды, взаимосвязи с другими командами, потерю знаний доменных знаний. Нельзя считать, что если вы быстро наняли замену, то все потери восстановлены – это не так.
https://benjiweber.co.uk/blog/2022/01/12/cost-of-attrition/

Ребята из Corporate Rebels собрали пошаговый план, как сделать любую команду самоуправляемой. Короче говоря, отменить тимлида. В целом все сводится к тому, чтобы договориться о правилах совместной игры и в понятном виде записать их. Читайте, вдохновляйтесь, пробуйте!
https://corporate-rebels.com/how-to-become-a-self-managing-team

Доклад Виталия Шароватова про то, почему вам на самом деле не нужны оценки сроков от инженеров в команде, и чем можно пользоваться вместо этого.
https://youtu.be/tqoJOEjeAEw

Разбор фреймворка от Shopify по найму VP of Engineering (ну или любого другого технического топ-менеджера). Включает в себя разбор самой роли, обязательных компетенций и вопросов, по которым их можно оценить. Список компетенций, кстати, такой:
1. Эксперименты с процессами разработки
2. Умение постепенно избавлятьс команду от административки и рутины
3. Фокус на постоянную доставку ценности
4. Привлечение кандидатов и построение процесса найма
5. Умение растить привлекательность компании для потенциальных кандидатов
6. Фокус на том, чтобы помогать другим добиваться успеха
7. Умение задавать сложные и глубокие вопросы
8. Непредвзятость даже к собственным техническим предпочтениям
9. Доверие к команде одновременно с готовностью взять на себя принятие сложного решения
https://review.firstround.com/hiring-a-vp-of-engineering-use-this-framework-from-shopify's-vpe-to-get-it-right

Очень здравая подборка принципов по тому как тимлиду приоритизировать задачи в команде и распределять их между инженерами. Мне больше всего понравилась идея введения абстракции «стрима» – потока задач примерно одной направленности, стоимость переключения контекста между которыми для инженера не очень велика. И вот оперировать стримами гораздо удобнее, чем конкретными задачами:
- В идеале команда работает над одним стримом, край – двумя, один из которых будет менее важен
- Переключать инженера между стримами можно только один раз и только в одну сторону, чтобы он мог полностью выгрузить первый из головыг
- Если стримы долгосрочны, перевод между ними может рассматриваться как инструмент роста
- Поток задач на поддержку или багов может быть оформлен как отдельный вид стрима со своими правилами
https://leeorengel.medium.com/prioritization-multiple-work-streams-unplanned-work-oh-my-b0adf59404a4

Я наконец-то подбил итоги недавнего опроса. Спасибо всем, кто принял участие – вы оставили шикарную обратную связь, которая, во-первых, очень мотивирует вести канал, а во-вторых, подкинула несколько хороших идей для будущего развития. Как и обещал, разыгрываю призы:
- Проходки на Podlodka Techlead Crew получают @koilas и @hyhyen
- Сертификат в МИФ улетает @mawhi7

Ну и несколько интересных фактов, чтобы вам было интереснее читать этот пост:
🤩 66% подписчиков – линейные руководители, а 12% руководят другими менеджерами
👴🏻 62% работает в IT больше семи лет
🔥 Три топовые темы по запросам: управление людьми, софт-скиллы и процессы разработки

Метрики разработки – одновременно очень мощный и очень опасный инструмент. Часто их используют бесполезно и вредно. Например, для попытки оценить эффективность разработчиков или для установки KPI тимлиду (да-да, бывает и такое!). Но не стоит полностью от них отказываться, потому что бывают ситуации, когда они могут быть полезны. Например, для оценки прогресса какой-то инженерной инициативы, или для отслеживания динамики какого-нибудь процесса. Сегодня я вам принес сразу две ссылки на эту тему.

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

Обычно у тимлидов нет проблем с развитием хард-скиллов в своей команде. Все мы были инженерами, умеем отличать хороший код от плохого и в общем виде представляем себе дерево навыков в любой программистской специальности. А вот развитие софт-скиллов – задача посложнее. В неплохом кейсе от МКБ разбирается их фреймворк обучения софтам. Отдельно респектую за то, что поделились своими ошибками:
- Если ничего не делать, со временем люди сами не обучатся
- Перекидывание из команды в команду не помогает
- Чтение книг само по себе не работает
- Теоретические тренинги бесполезны
https://habr.com/ru/company/mkb/blog/647005/

Сейчас читаю «The Hard Thing About Hard Things» и наткнулся там на очень-очень классную концепцию – Managerial Debt, менеджерский долг. Это примерно то же самое, что технический долг, но для менеджерских решений. Каждый раз, когда вы принимаете какое-то простое решение, которое снимает текущий пожар, но создает долгосрочный дисбаланс, вы берете в менеджерский долг. Несколько примеров:
1. Закрывая срочную нехватку ресурсов, вы нанимаете разработчика на зарплату сильно более высокую, чем у остальной части команды. Это решение закрыло текущую проблему, но в будущем эта информация, скорее всего, утечет всей команде.
2. Вы закрываете глаза на конфликт в команде, так как сильно перегружены другой работой. В моменте вы освободили свой ресурс, но в долгосроке это тоже аукнется.
https://a16z.com/2012/01/19/management-debt/

Сталкивались с тем, что когда-то принятые командой решения со временем забываются? Или, еще хуже, само решение люди помнят, а вот причины его появления – нет, из-за чего оно постепенно превращается в карго-культ? Держите простой шаблон и описание практики логирования ключевых решений, который может это исправить.
https://infraeng.dev/decision-log/

Интересный взгляд на то, в чем заключается роль техлида проекта – управление технической достижимостью планов. И для этого есть три основных области влияния – время, навыки команды и используемые технологии. Подход, на мой взгляд, не без недостатков, но вполне работоспособный в описанном автором сетапе команды с отдельными продуктовым и дизайн лидом.
https://www.biodigitaljazz.tech/p/technical-feasibility

На прошлой неделе вам хорошо зашла статья про самоуправляемые команды. Судя по опросу, на такой подход готовы не все. Вот вам очень хороший материал про промежуточный вариант – полностью от лидерства отказываться не нужно, но постепенно количество лидеров в команде растет, с чем повышается и ее антихрупкость.
https://blog.pragmaticengineer.com/a-team-where-everyone-is-a-leader/

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

✍️Менеджерские практики
Менеджерский долг
Доклад про то, что оценка сроков и дедлайны не нужны

🐞Работа над качеством
Коллекция статей про организацию процессов QA в крупных компаниях
Как в Ozon организован инцидент-менеджмент

🛠Инструменты, гайды, чек-листы
Шаблоны для того, чтобы сказать “нет”
Гайд по организации планирования
Decision log для решений в команде

👨‍👨‍👦‍👦Найм и увольнения
Почему некоторые разработчики никогда не пройдут собеседование
Влияние токсичности на увольнения
Как оценить последствия ухода сотрудника из команды

📚Рекомендации по книгам
The Hard Thing About Hard Things
Influencer: The New Science of Leading Change
Powerful: Building a Culture of Freedom and Responsibility

Если дайджест вам понравился – ставьте ❤️, 👍 и 🔥. Благодаря этому я пойму, что собирал его не зря! А если у вас будут конкретные предложения по его улучшению – смело пишите в комментарии!

#digest

Большая часть организационных структур следуют одной из трех устоявшихся на рынке моделей:
- Функциональная: отделы, сформированные вокруг общих компетенций;
- Матричная: из функций набираются люди в кроссфункциональные проектные команды, у каждого два руководителя;
- Agile/Продуктовая: автономные кроссфункциональные команды формируются вокруг общего компонента/потока ценности;

Иногда получается так, что ни один из стандартных подходов не ложится на культуру команды или особенности ее продукта. Это и произошло у ребят из статьи, которые построили всю организационную структуру вокруг центрального для них процесса – цикла обработки пользовательского фидбэка и сигналов рынка.
https://corporate-rebels.com/a-new-way-of-organizing

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

Короче, забирайте в копилку статей, повышающих насмотренность.
https://adhoc.team/2022/01/04/crafting-leadership-teams-for-fast-effective-information-flow

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

Ключевая идея – люди всегда узнают, кто сколько в команде зарабатывает, поэтому правила должны быть едины и прозрачны для всех.
https://review.firstround.com/A-Counterintuitive-System-for-Startup-Compensation