An Elegant Puzzle, часть 1: двигать домены, а не людей

Гость представляется: Евгений, senior engineering manager, пятнадцать с лишним лет в индустрии — начинал инженером, трогал инфраструктуру, поработал в небольшой компании и вернулся в engineering management. Выбрал он её потому, что при первом чтении было много «ага»-моментов: вот почему это работает, а вот это я уже видел в своей практике.

Ларсон начинал с блога — разбирал интересные задачки, писал о них посты, потом скомпилировал книгу. Евгений замечает, что это становится трендом, а Александр объясняет почему: сесть и написать книгу с нуля сложно, а статью пишешь, когда сам поймал момент, где пазл сложился; когда таких камешков набирается достаточно, они начинают переплетаться — и пора писать книгу. Главы в итоге независимые, книгу можно открывать как настольную и накладывать на совет автора свой контекст.

Евгений добавляет, что книга рассчитана не на first-time менеджеров: как проводить one-on-one, здесь не объясняют, зато разбирают проблемы состоявшегося мидл-менеджера и работают как трамплин на уровень организации, а не только своей команды.

Семь глав; участники перечисляют введение, устройство организаций, инструменты, подходы, культуру и построение карьеры, а затем обсуждают приложение с перечнем статей и QR-кодами, чтобы ссылки не перебивать руками; часть из них Евгений забрал себе почитать. Текста мало, схем много: страничка-полторы и картинка, на которой всё видно.

Разбор по главам начинается с формирования команд и «магических цифр». Ларсон советует не заводить пустых команд и не набирать их целиком из новичков: лучше дорастить одну до десяти человек и потом разделить. Евгений на эти грабли наступал сам — без костяка размывается и командная, и компанейская культура, а с костяком быстрее идут онбординг и сработанность. Чего книге не хватает, по его словам, так это объяснений «почему именно так»: это додумываешь с практикой.

Дальше правило про число прямых подчинённых: Ларсон предлагает не больше восьми, иначе менеджер превращается в коуча и перестаёт держать контекст, а группу меньше четырёх человек автор считает слишком маленькой для такой абстракции: менеджер в ней играет тимлида. Евгению понравилась аналогия, что команда — это абстракция над сложностью, а маленькая — абстракция протекающая. Александр вспоминает свой доклад трёхлетней давности про SOLID в менеджменте: инверсия зависимостей — это когда даёшь цели и правила, а не список задач.

Ещё Евгений отмечает, что взаимодействие команд Ларсон не покрывает, — здесь его дополняет Team Topologies, которую клуб разбирал раньше.

Александр напоминает об ограничении этих советов: Ларсон писал из опыта гиперроста. При более медленном росте нельзя под каждую задачу нанять новую команду; существующей приходится одновременно поддерживать старое и делать новое. Правила нужно соотносить с состоянием команды и ресурсами организации.

Онкол упирается в законодательство: Ларсон называет минимальный размер дежурной ротации, и Евгений сначала удивлялся, пока не сообразил, что в его контрактном контексте ограничено время дежурства в месяц. В его компании онкол закрыли бы и двое — сервис стабильный, — но, по словам Евгения, такая ротация могла бы нарушать действующие для них ограничения, и рецепт автора работает: поднять дежурство на уровень юнита с похожим контекстом, даже если соседи знают друг о друге только контракт API.

График зрелости даёт три рецепта: отстающей команде — нанимать, застрявшей — вводить WIP-лимиты и говорить «нет», дошедшей до инноваций — давать slack, время на безделье, ведь лучший код ненаписанный.

Главное же — переставлять не людей, а домены: Евгений признаётся, что сам разрушал сработавшуюся команду, переводя из неё людей в отстающую. Александр предлагает мягкий вариант: навесить на менеджера успешной команды соседний похожий домен и подтягивать отстающих общими целями.

Слайд про гиперрост показывает Uber, Google, Twitter и Facebook: по пересказу участников, в компании, где работал сам Ларсон, к четвёртому году было больше пяти тысяч человек, а за два года штат вырос с двухсот до двух тысяч — культуру передавать некому, каждые полгода оказываешься в новой компании, а новые люди добавляют энтропию и нагрузку на инфраструктуру и developer experience.

Александр застал похожее: пришёл в конце 2016 года менеджером на десять человек и постоянно перестраивался, формулируя это как «растёшь с болью»; позже он разделил большой юнит на четыре управления по бизнес-доменам, а с руководителем оставшегося сбоку отдела продуктовой аналитики будет интервью в следующем выпуске.

У Евгения штат вырос с тридцати инженеров до двухсот за год, и первой они дизайнили воронку найма: слоты, в каждом из которых доступны три-четыре инженера, потому что интервьюеры выгорают и на регулярных внутренних замерах такой инженер всегда в красном. Александр вспоминает, как в 2020-м найм централизовали и разбили на секции — тему поднял директор базовых технологий Игорь Маслов.

Вторая разобранная глава — про инструменты, их пятнадцать. Открывает её системное мышление: вход, выход, система и петля обратной связи. Александр говорит, что писал обзор этой книги-азбуки и видел людей, которым она бы сильно помогла, а Евгений соглашается: для инженеров системное мышление в какой-то момент становится частью ДНК. Через ту же оптику Ларсон раскладывает DORA-метрики из Accelerate.

В целеполагании стратегия — это диагноз, принципы и действия; здесь Ларсон отсылает к книге Good Strategy, Bad Strategy. Верно выбранные принципы обязаны быть некомфортными: придётся идти на компромиссы или чему-то говорить «нет».

Евгений выделяет совет завести два списка: работа, которая пока без тебя не делается, но её видно как делегировать, и задачи, которые можно отдать быстро. Если подготовка передачи займёт год, её важно начать заранее, а не терять время, не замечая зависимости от себя.

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

А заголовок про миграцию как единственный способ выплатить техдолг Евгению не откликается: техдолг должен быть гигиеной и частью ДНК команды, его выплачивают регулярно. Зато завершённой миграция считается не когда все переехали, а когда старая система выключена.