An Elegant Puzzle, часть 2: реорганизация — крайняя мера

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

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

Александр подчёркивает важность ясной, понятной всем цели и предостерегает от построения структуры вокруг конкретных людей. Он не уверен, в какой именно главе Ларсон даёт последний совет.

Евгений добавляет практику своей компании: как для архитектуры ведут architecture decision record, так для организационных изменений завели organization decision record — с контекстом, рассмотренными вариантами и следующими шагами. Документ шарят на всю организацию, и потом можно ретроспективно оценить, хорошо ли принималось решение; он вспоминает подход «вести через контекст» из книги про Netflix.

У Александра то же самое выглядит как большие документы по крупным реорганизациям с комментариями и подведением итогов: он возвращается к ним, когда готовит доклады на конференции, а внутри компании такие тексты работают почти как прецедентное право.

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

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

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

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

В разговоре о времени участники замечают: даже опытным коллегам трудно дать совет, если они сами перегружены. Правило простое — чего нет в календаре, то не запланировано, и работа расплывётся на всё доступное время; Ларсон советует посмотреть, куда уходит месяц и квартал, выделить блоки фокуса и посчитать математику встреч: сколько прямых и скип-репортов, с кем один на один обязателен, что можно делегировать.

Евгений вспоминает эксперимент: два часа утром оставили под встречи, остальное время — под сосредоточенную работу. Другие приглашения отклоняли, но инициатор мог вернуться и объяснить, почему участие необходимо. Оказалось, что примерно 70% приглашений были просто для информирования; их заменили заметками, и, по наблюдению Евгения, результативность команды выросла.

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

Про сообщества обучения Евгений вспоминает внутренний Reading Club, начатый с Team Topologies Workbook и упражнения с описанием Team API, а Александр — про фасилитатора, которого звал, когда делил свой юнит на четыре части.

Политики должны работать на основном сценарии, а исключения надо собирать и замыкать ими обратную связь, иначе правила отрываются от реальности, как ковидные регламенты про офис, когда все уже работают удалённо.

Отдельный навык — говорить нет: в английской культуре отказ звучит как «yes, but», но опираться он должен на данные, потому что приоритеты и велосити — это то, чем менеджер действительно управляет. Александр добавляет: менеджер, который всему говорит да, становится прозрачной абстракцией над командой, работа влетает внутрь, ничего не доводится до конца, и дальше приходится как хирургу отсекать лишнее.

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

Культ героев участники считают сигналом дисбаланса: постоянные переработки могут означать, что команда не ограничивает входящую работу. Задача руководителя — сделать результат предсказуемым, а работу устойчивой; бесконечно компенсировать проблемы личным героизмом невозможно.

Уровень компенсации на схеме Ларсона привязан к уровню опыта и упирается в потолок вилки, а вилка есть в любой компании, даже если в вакансии её не указывают; участники уточняют, что платят скорее за ожидание того, насколько ты будешь перформить.

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

Дальше воронка: органический поток, рефералы и сорсинг, который Ларсон считает работой менеджера и снабжает шаблоном письма; участники замечают, что письмо от CTO или VP открывают охотнее, чем письмо рекрутера.

Метрики Ларсон продолжает за оффер — онбординг, время до импакта, промоушены и уходы: только так, по словам Александра, можно сравнить наймы с рынка с выпускниками внутренних образовательных программ, а не верить на слово.

Матрицу компетенций участники советуют включать в критерии интервью, чтобы при найме и последующем росте человека оценивали по одним ожиданиям. Подробные матрицы в первую очередь нужны для ролей с массовым наймом; для редких позиций может хватить простой шкалы без множества уровней.

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