Will Larson—Head of Foundation Engineering at Stripe, ex Digg, SocialCode и Uber
книжка тактильно очень приятная. Вёрстка текста—шик. Общая эстетика—космос. Иллюстрации очень плохие :)
чувствуется, что каждый тезис написан кровью и потом разработчиков и их руководителей. Чистая практика, без воды.
Книжка шикарно структурирована. Видно, что писал инженер, который не приемлет долгих расшаркиваний и этого вашего сторителлинга.
на какие вопросы вы найдёте ответы в этой книге:
- Как обеспечивать быстрый рост команды, поддерживая уровень техдолога [энтропии] на приемлемом уровне?
- Как нанимать? Как строить воронку найма, как интервьюировать, как онбордить, на какие метрики смотреть?
- Как определять и коммуницировать стратегию и вижн для каждой команды?
- Какие процессы и инструменты коммуникации использовать руководителю для коммуникации с командами и 1on1?
- Как строить культуру?
- На чём фокусироваться руководителю?
- Как строить карьеру руководителя инженеров?
- Как помогать строить карьеру своим сотрудникам?
- Как строить систему оценки сотрудников

Тезисы

[это примерно 10% от всех тезисов. Я выбрал только те, которые релевантны мне прямо сейчас. Читайте книгу!]

оптимальное количество инженеров на одного менеджера—от шести до восьми
оптимальное количество менеджеров на руководителя менеджеров—от четырёх до шести
четыре стадии команды и что делать на каждой из стадий:
1. Команда явно не справляется: каждую неделю беклог длиннее, чем в предыдущую, инженеры вкалывают, прогресса почти нет → нанять людей, пока команда не начнёт топтаться на месте
2. Команда топчется на месте: команда выполняет основную задачу, но не может приступить к починке техдолга или начинать новые большие проекты → урезаем Work In Progress, чтобы команда могла быстрее закончить приоритетные задачи и приступить к техдолгу; помогаем инженерам мыслить в терминах продуктивности команды
3. Платит техдолг: когда начинаешь платить техдолг, попадаешь в снежный ком: чем больше техдолга чинишь, тем больше техдолга вылезает :) → терпим и увеличиваем время
4. Фигачит инновации: Всё классно: энтропия на низком уровне, мораль высокая, команда на всех парах фигачит ценность для клиентов → не перегружать команду, чтобы новые проекты делались с достаточным уровнем качества и можно было оттянуть момент оплаты техдолга
нанимайте в один момент времени в одну команду! Добавление нового члена команды запускает процесс regelling [притирку, склейку, буду использовать оригинальный термин] членов команды, поэтому нанимайте последовательно в команду за командой, не параллельно в несколько команд!
если нужно переключить фокус команды на другой проект—меняйте скоуп [набор задач] команды и старайтесь не переводить людей в другие команды, так как это запускает процес regelling'а
если ваш бизнес удваивается каждые шесть месяцев и вы хотите удваивать количество инженеров раз в шесть месяцев, тогда важно помнить, что производительность инженера будет значительно меньше 1 (обученного инженера):
- допустим, опытный инженер обучает двух неопытных. На обучение уходит 10 часов в неделю на одного обучаемого ⇒ эти три инженера вместе выдают 1,16 обученных инженеров: 20,33+10,5
- около 4х часов в неделю уходит у опытных инженеров на найм ⇒ производительность опытного падает 0,5 > 0,4
- на каждый новый порядок количества инженеров вам нужно добавлять +1 слой менеджмента
- на 10 инженеров нужна новая команда ⇒ больше коммуникации
- выше нагрузка на девопсов
- больше разработчиков—больше отказов, разборов, постмортемов
- ⇒ на выходе, производительность опытного инженера падает до 0,275
как проводить миграции на новую технологию/переписанную в процессе уплаты техдолга:
1. Снижаем риски: итеративно пишем документацию переезда, затем переводим две самые требовательные команды на новую технологию. Плотно работаем с ними, чтобы полечить все корнер-кейсы
2. Переводим основную массу: пишем документацию и self-service инструменты, чтобы программно мигрировать 90% процессов и команд на новую технологию. Сидим с каждой командой и помогаем им мигрировать. Переходим к следующей команде.
3. Заканчиваем миграцию: останавливаем кровь: убеждаемся, что 100% команд и процессов перешли на новую технологию. Своими руками мигрируем оставшихся. Выключаем старую технологию.