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

Звучит просто, но в статье каждый из этапов разобран прямо очень хорошо.
https://koolaidfactory.com/zines/the-planning-issue/

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

В статье рассматривается несколько различных подходов по измерению качества кодовой базы. Уверен, какие-то подойдут и вам!
https://thevaluable.dev/complexity-metrics-software

Я хочу активно развивать канал дальше, и для этого мне хочется узнать побольше про вас. Ситуацию усложняет то, что каждый тимлид, как известно, это снежинка. Поэтому мне никак не разобраться, если вы не пройдете небольшой опрос и не расскажете, чем вы занимаетесь, какими командами управляете и управляете ли вообще, какими темами интересуетесь. А чтобы мотивировать вас ответить на мои вопросы, между участниками я разыграю две проходки на ближайшую конференцию Podlodka Techlead Crew и сертификат в библиотеку МИФ, в которой очень-очень много крутых книг по тимлидству!
https://forms.gle/tif7oMQGQoVtuwQHA

The Influencer

Для кого:
Для тех, кто хоть раз пытался заставить группу людей изменить свое поведение

Рейтинг: 
Семь гвинейских червей из десяти

Уровень воды:
60%

В книге представлен фреймворк “Influencer”, применение которого позволяет кардинально менять поведение групп людей любого размера. Если прямо супер кратко, то выглядит он так:

Определяем итоговую цель изменений и чувствительные метрики
Выделяем несколько ключевых поведений (vital behaviors), следование которым позволяет достичь цели.
Используем шесть способов влияния в совокупности, чтобы целевая группа перешла к этим поведениям.
Работоспособность фреймворка иллюстрируется где-то десятком разных историй: начиная от спасения населения центральной Африки от заражения гвинейским червем или борьбы со СПИДом в Таиланде и заканчивая системными провалами крупных проектов по разработке софта. Здесь же кроется и существенный недостаток книги. Авторы утверждают, что выделили фреймворк, основываясь на изучении десятков историй успеха разных людей. Но ни слова не уделяется тем, кто следовал тем же путем и прогорел. Смахивает на систематическую ошибку выжившего.

В целом, читать рекомендую. Количество воды не превышает разумных пределов, а фреймворк выглядит достаточно рабочим.
https://www.amazon.com/Influencer-Science-Leading-Change-Second-ebook/dp/B00BPO7710

Родительство и тимлидство во многом очень схожи, несмотря на разницу в возрасте подопечных. В статье рассматриваются примеры того, чему работа с детьми может научить тимлида.
https://medium.com/wriketechclub/parenting-and-leadership-following-childrens-rights-in-teamwork-93dd0f43aaf0

Эссе про то, как связаны в стартапах роли СЕО и СТО, какие качества их отличают и к каким проблемам во взаимодействии это может привести.
https://www.forbes.com/sites/forbescoachescouncil/2020/02/21/when-startup-ctos-lose-clout

Во многих командах есть процесс performance review, либо его аналоги, на выходе из которых каждый сотрудник регулярно получает порцию обратной связи от коллег. Чтобы эта обратная связь не была бесполезной, стоит придерживаться нескольких важных правил:
- Ее содержание не должно стать сюрпризом
- Она должна быть честной и прямой
- Даже если она основана на показаниях других людей, вы должны отвечать за нее сами, без переведения стрелок на коллег
- Она должна быть привязана к ожиданиям от роли и результатам
- Она должна мотивировать на развитие
Детали про каждое правило и много других хороших мыслей про обратную связь можно почитать по ссылке.
https://larahogan.me/blog/performance-reviews-should-be-unsurprising-fair-and-motivating/

Держите два полезных инструмента для того, чтобы планировать рост хедкаунта в ваших командах. Первый поможет в том, чтобы обосновать необходимость роста и привязать ее к каким-то измеримым показателям. Второй поможет рассчитать, как найм новых людей повлияет на рост административных функций.
1: https://infraeng.dev/hiring-ratio/
2: https://infraeng.dev/organizational-design/

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

Мы как-то делали такое упражнение в Kotlin, чтобы договориться о том, как принимать решения связанные с дизайном новых фич. Вот такие примеры у нас получились:
- Readability over concision
- Producticity over runtime performance
- Safety over flexibility
- Evolution over 100% backward compatibility

Если подход показался интересным, почитайте статью – там дается больше примеров и деталей того, как завести у себ в команде.
https://academy.nobl.io/how-to-write-a-strategy-your-team-will-remember/

Результаты большого исследования причин увольнения людей из различных компаний. Самая сильная корреляция между увольнениями и влияющими на это факторами у токсичной корпоративной культуры. Для сравнения – фактор уровня компенсации раз в десять слабее. Если стало интересно, посмотрите на детальный разбор исследования в статье.
https://sloanreview.mit.edu/article/toxic-culture-is-driving-the-great-resignation/

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