Учебник по постройке технологических команд на масштабе Uber и Stripe

Учебник по постройке технологических команд на масштабе Uber и Stripe

Рецензия на книжку «An Elegant Puzzle» by Will Larson

3 min read

Учебник по постройке технологических команд на масштабе Uber и Stripe

10/10

Главное

  • 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% команд и процессов перешли на новую технологию. Своими руками мигрируем оставшихся. Выключаем старую технологию.