Сейчас читаю «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

В крупных инженерных компаниях менеджерский карьерный трек – это только одна из веток развития. Вторая, равная по количеству уровней и компенсации – техническая. В статье Principal Engineer из Амазона делится тем, как устроен процесс повышения до принципала и какие ответственность и влияние на компанию появляется с этой лычкой.

Чтобы зацепить ваше внимание, краткое описание условий для повышения:
- Наличие подробного документа от твоего менеджера, описывающего твои достижения
- 5-7 людей выше по уровню, подписавшихся под этим документом и оставивших свой фидбэк
- Два ассессора, которые детально изучили все, что ты делал на работе: дизайн документы, код, комментарии на кодревью и доклады
- Аппрув от специального комитета
- Аппрув от еще более специального комитета самых мощных инженеров
https://medium.com/geekculture/belonging-to-amazons-principal-engineering-community-aa8059152fbf

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

В статье рассматривается несколько конкретных кейсов «тройничков»:
1. Смена руководителя у сотрудника
2. Временный перевод человека из проекта в проект
3. Ввод в кроссфункциональную команду новой роли, ожидания от которой не понятны
4. Пропушивание решений с помощью третьего человека
https://davidxiang.com/2021/12/30/use-more-1-1-1s/

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

В статье хорошо разложены причины такого поведения и конкретные способы борьбы с ним.
https://www.thezbook.com/the-biggest-mistake-i-see-engineers-make/

RACI-матрица – супер простой и дико полезный инструмент для того, чтобы достичь прозрачных договоренностей о ролях и ответственности в проекте. Работает он следующим образом – вы выделяете конечный набор обязанностей в проекте, а затем каждому вовлеченному в него человеку назначаете одну из ролей:
- Responsible – тот, кто физически выполняет работу
- Accountable – тот, кто отвечает за результат и аппрувит его
- Consulted – тот, с кем надо обсудить решение и принять мнение во внимание
- Informed – тот, кому надо сообщить по факту принятия решения

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

В общем, советую, это один из инструментов, которыми должен уметь пользоваться любой тимлид.
https://habr.com/ru/company/timeweb/blog/597281/

На прошлой неделе у нас разгорелся хороший такой холивар в комментариях к материалу про систему определения зарплат в Facebook. Вдогонку к этому, ребята из стартапа ConvertKit поделились своим подходом к определению финансовой компенсации для своих сотрудников.

Тезисно:
- Все получают одинаковые зарплаты в зависимости от грейда, основанные на данных от Radford;
- Зарплаты одинаковы вне зависимости от локации;
- Компенсируется 5% от зарплаты, если сотрудник откладывает их на пенсионный счет;
- 52% от профита компании выплачивается всей команде в виде performance бонуса. Топы получают 8%, владельцы – 40%;
- Грейд не влияет на бонус. 75% разделяется поровну между всеми, 25% зависит от времени работы в компании;
- Сотрудники получают доли в компании;
- Все финансовые данные абсолютно открыты для команды.

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

Когда я впервые стал тимлидом, я попросил руководителя посоветовать мне каких-нибудь книг по теме. Одной из них было «Руководство фасилитатора» Сэма Кейнера. Это очень крутая книга для всех, кто хочет построить себе системную картинку про принципы работы групповой дискуссии и набрать десятки инструментов по управлению ей. Максимально рекомендую!

А пока присматриваетесь к книге, можете начать с прочтения статьи с набором советов разного уровня по тому, как сделать ваши встречи чуть более ценными. Фреймворк 5Р, про который тут идет речь, сам использую на постоянной основе.

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

Шесть признаков перфекциониста:
- Страх провала
- Подход «все или ничего»
- Не умеет делегировать
- Часто прокрастинирует
- Слишком сильно сфокусирован на результате
- Тяжело принимает конструктивную критику

Подробный рассказ про эти шесть признаков и подходы к управлению такими людьми

В продолжение вчерашней темы держите классную методичку от Pluralsight. В ней разбирается 20 паттернов поведения команд и отдельных людей в них. Эти паттерны можно заметить как наблюдая за поведением людей, так и при детальном анализе метрик из системы контроля версий и трекера задач. В отличие от других статей про использование инженерных метрик в этой мне нравится, что авторы не пытаются делать каких-то выводов про успешность работы команды, а смотрят на них просто как на желтые флажки.

В команде Kotlin, где я сейчас работаю, я довольно сильно заморочился с настройкой процесса онбординга новых сотрудников. Для меня этот процесс критически важен – я нанимаю непрограммистов в команду разработки языка программирования. Если их плавно не погрузить в детали рабочих процессов, не объяснить базовое устройство всех компонентов системы простыми словами и не поставить четкие и ясные цели, то вкатывание в команду очень усложнится.

Сейчас онбординг у меня состоит из следующих больших кусков:
📹 Видеокурс, где простым языком объясняется устройство различных компонентов: компилятора, IDE, билд тудтнга и других штук
🎛 Trello-доска с задачами на погружение в компанию, разными материалами для изучения и ключевыми людьми, с которыми нужно познакомиться
🎯 Цели на период онбординга, которые составляются вместе с новичком спустя пару недель работы
🤝 Наличие ментора, который сопровождает новичка в процессе онбординга

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