Идеи из книги “An Elegant Puzzle: Systems of Engineering Management”

Привет, меня зовут Евгений, я VP of Product в Ecwid. Иногда я пишу заметки про прочитанные книги и статьи. Ниже интересные мысли из новой книги “An Elegant Puzzle: Systems of Engineering Management” про инженерный менеджмент, развитие продукта, культуру компании и много других штук.

Книгу “An Elegant Puzzle: Systems of Engineering Management” написал Will Larson. Он работал в Uber, Digg, Stripe. Ведёт интересный блог про инженерный менеджмент, управление командами, сложные системы, культуру компаний, изменения и другие штуки. Недавно он собрал все свои мысли вместе и написал книгу.

Если я сделаю свой список лучших книг для менеджеров, эта книга туда точно попадёт. В ней совсем нет воды, долгих историй и размазывания одной идеи на 300 страниц. Только конкретные чёткие размышления, списки и шаги про самые разные области («делайте так», «не делайте так — я сделал, и было больно»). Видно, что автор прочувствовал всё на своей шкуре и решил выразить весь свой опыт в одной книге.

Это сильно отличает эту книгу от множества других про «управление», которые размазывают общие слова, и видно, что их автор в жизни мало сталкивался с реальными проблемами команды.

Важно отметить, что некоторые штуки в книге важны только для крупных организаций, некоторые актуальны только для US-компаний. Также автор не пытается сильно убедить в своей точке зрения. Он описывает, почему он считает, что что-то правильно, но не пытается долго убеждать всех в своей точке зрения. Ниже — краткие записи интересных мне мыслей из книги.

• Менеджеру должно репортать от шести до восьми человек. Если менеджеру репортает больше девяти человек — он больше тренер, а не менеджер: просто даёт советы и подстраховывает, но не управляет.
• Команды меньше четырёх человек — не команды. Команды из одного-двух человек — всегда плохо. Смысл в том, что команда абстрагирует сложность людей, из которых она состоит. Команды из одного-двух человек — это «дырявые абстракции», управление ими не отличается от работы с конкретными людьми. Также они хрупкие, уход одного человека сильно нарушает равновесие.
• Если нужно создать новую команду, лучше вырастить текущую до восьми-десяти человек и разделить её на две. Создавать пустые команды — нехорошо.
• У инженерной команды может быть четыре состояния: отставание (с каждой неделей бэклог больше, чем был, критические штуки не делаются), топтание на месте (критические штуки делаются, но нет времени отдать технический долг), возврат технического долга (есть время его возвращать) и этап инноваций (технический долг низкий, есть время делать новые штуки). Команды хотят идти от первой стадии к последней. В больших компаниях разные команды могут быть на разных стадиях, лучше фокусироваться на одной команде сначала, а не вкладывать все усилия понемногу во всё.
• Хорошая сработанная команда — залог высокой продуктивности. Если разобрать команду, даже сохранив частично её членов, то это всегда потеря продуктивности. Командам надо много времени, чтобы сработаться. Это надо учитывать при росте команды или изменении её состава.

Стратегия — это список конкретных действий, которые решают конкретную проблему в условиях определённых ограничений. Хорошая стратегия состоит из диагноза, принципов и действий.

• Диагноз описывает саму проблему, вызов, который перед нами стоит. Текущую ситуацию и её ограничения.
• Принципы: набор правил, которыми мы следуем, чтобы решить проблему. Хорошие принципы — некомфортные, заставляют чему-то сказать «нет», часто являются компромиссами между противоречащими целями.
• Действия: появляются после применения принципов к диагнозу. Часто тяжёлые абстрактные решения принимаются легко, но никогда не вытекают в конкретные действия. Поэтому действия должны быть конкретные. Такие, чтобы тоже было достаточно некомфортно им следовать (если проблема сложная).

Абсолютно нормально иметь несколько стратегий — по одной на каждую проблему.

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

Хорошее виденье состоит из следующих частей.

• Главное утверждение. Одно-два вдохновляющих предложений, которые описывают всю суть документа. Это главная мысль, которую нужно повторять везде снова и снова.
• Ценность для пользователя. В чём будет наша ценность для пользователя? В чём будет его успех, который мы поможем ему достичь?
• Наши возможности. Что продукту нужно уметь делать, чтобы пользователи смогли получить эту ценность и достичь этого успеха?
• Ограничения. Какие у нас сейчас есть ограничения, но от которых мы избавимся в будущем? Какие у нас возникнут ограничения в будущем?
• Ссылки на остальные документы: метрики, таблицы, планы и так далее. Это всё в дополнение, чтобы не усложнять основной документ.
• История: когда все предыдущие штуки написаны, надо связать их суть в короткую историю. Вставить эту историю после главного утверждения.

Хорошее виденье требует нескольких итераций и тестирования на людях. Один-два раза в год виденье надо обновлять.

Есть четыре стадии в работе над каким-то изменением.

• Обнаружение проблем. Боли пользователей (опросы и интервью), цели пользователей (куда они хотят прийти?), сравнение с конкурентами и индустрией (чтобы понимать свои слабости и сильные стороны), сравнение поведения своих же когорт (чтобы посмотреть, нет ли новых пользователей с другими нуждами), обнаружение своих competitive moats (какие есть и что это даёт, какие можно построить, какие есть у конкурентов), что можно построить, что даст пользу сейчас, но также будет фундаментом больших хороших штук в будущем
• Выбор проблемы. Что надо сделать прямо сейчас, чтобы выжить сегодня? Что надо сделать, чтобы выжить в ближайшем будущем? Что надо сделать, чтобы победить? Посмотреть на различные временные рамки: что если у компании кончатся деньги через полгода, над чём тогда работать? А что, если совершенно нет никакого внешнего давления — и результат можно было бы показать через два года? Или через пять? Посмотреть, куда двигаются тренды индустрии. Посмотреть, есть ли быстрые штуки с большим возвратом. Подумать, что можно сделать сейчас, чтобы выбор проблемы в будущем был проще.
• Валидация решения проблемы. Попробовать убрать риски и проверить решение перед его реализацией. Например: написать анонс запуска перед реализацией и посмотреть — полезно и круто ли звучит? Показать его некоторым реальным пользователям. Посмотреть, как решают проблему другие и решают ли. Найти первых пользователей, показать им прототип. Найти способ провести быстрый эксперимент или валидацию идеи.
• Реализация.

Просто метрика-число — плохая цель. У хороших целей есть четыре числа.

• Сама цель: чего хотим достичь.
• Исходные данные: где мы сейчас.
• Тренд: текущий рост этой метрики (например, за прошлый период).
• Ограничение по времени — на какой период цель.

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

Метрика — отличный способ внедрения новых заметных изменений во всей организации. Для этого сначала определяешь нужную метрику, смотришь, как каждый отдел на неё влияет, делаешь её публичной (в том числе сравнивая отделы между собой), добавляешь побуждений (дэшборды, письма, если метрика сильно изменилась) и — если есть возможность — задаёшь некий уровень, ниже которого нельзя опускать её. Раз в какой-то период делать ревью по ситуации.

• Лучшая реорганизация — та, которая решает структурную или системную проблему (для улучшения коммуникации, более быстрых решений, лучшего фокуса и так далее), и та, которая не состоялась.
• Не надо делать реорганизацию, чтобы просто избежать решения проблемы с менеджментом конкретных людей или из-за плохих отношений с конкретными людьми.
• Не надо делать реорганизацию, чтобы решить будущие проблемы, которые ещё не настали. Мы не знаем, какие именно у нас будут проблемы.

Как сообщить об изменениях:

• Описать, зачем мы их делаем.
• Описать, как затронет каждого.
• Будут недовольные: проявить эмпатию и дать им возможность высказать свои волнения.

Также в сложных ситуациях стоит:

• Поговорить сначала лично с теми, кого затрагивает сильно.
• Подготовить менеджеров и ключевых ребят к тому, чтобы они могли объяснить, зачем эти изменения, и рассказать детали.
• После этого выслать письмо с деталями и быть готовым отвечать на вопросы.
• Иногда общий личный сбор стоит провести, но не всегда — люди плохо обрабатывают сложные новости в больших группах. Увеличить количество skip level 1-1 после изменения.

Лучше внедрять изменения по одному, измеряя результат после каждого.

Есть разные уровни вовлечения менеджера в зависимости от задачи.

• Я это делаю. Я делаю эту штуку и отвечаю за неё целиком — ты смотришь и вовлекаешься по необходимости.
• Предпросмотр. Ты делаешь, но я хочу быть вовлечён часто и много. Мы, скорее всего, не согласны в чём-то, частая синхронизация поможет избежать выкидывания ненужной работы.
• Ревью. Покажите мне перед публикацией или запуском. Я хочу убедится, что всё будет нормально перед запуском, но в целом у нас нет расхождений во мнениях.
• Давайте апдейты. Сообщайте время от времени, как дела, чтобы я знал, что к чему и как всё движется. Не ждите никакого фидбэка от меня, чтобы продолжать работу.
• Без сюрпризов. Сообщайте, только если что-то сильно изменилось в проекте (задаче) или есть серьёзные проблемы. Главная цель: не должно быть сюрпризов в моём понимании того, как движется проект или задача.
• Дайте мне знать, если нужна помощь. Если от меня требуется помощь в решении проблемы — скажите. В остальном нам не надо тратить время на обсуждение этой штуки.

Три правила:

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

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

Хорошие правила ограничивают. Если правило не ограничивает или очень мало ограничивает, не нужно эту штуку делать правилом. Достаточно описать рекомендацию «у нас принято делать так». Это позволит избежать траты времени на требование их выполнения, разбор нарушений и решение корневых случаев.

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

Исключения в правилах подрывают их силу и создают ощущение несправедливости. Вместо исключений надо делать так:

• Собирать запросы на исключения.
• Время от времени (раз в какой-то период или когда много накопилось) ревьювить правила и ограничения, принимая во внимание эти новые обстоятельства.
• Или изменить правило (или ограничения), или оставить их без изменений (подтвердив, что они были правильные).

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

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

• Надо уметь говорить «нет» своему руководству и объяснить, почему предложенный путь ведёт к проблеме или нежелателен. Два самых частых кейса: скорость («почему эта штука делается так долго?», «а давайте ещё сделаем и вот это?») и приоритеты («а почему мы делаем это, а не то?»). Эти вещи надо уметь объяснять.
• Для продуктивности хорошо работает ограничение случайных отвлечений «мне просто спросить» в Slack или лично, нотификации и так далее: автоматизировать их, сделать бота, просить делать тикеты, направлять вопросы дежурному и так далее. Ещё хорошо работает общий список, кто за что отвечает, и хорошая внутренняя документация (но это очень сложно).
• Системы, как правило, имеют какие-то свойства, помогающие им самоисцеляться. Например, перегруженная база данных замедлит работу сервиса, это заметит дежурный инженер и починит. Хорошие системы (необязательно именно технические даже) имеют эффективные и явные системы самолечения.
• Хорошие правило менеджмента: у каждого должна быть зона ответственности, за которую он отвечает. Награда и статус должны выдаваться за завершение качественной работы. Не проси делать то, что бы не сделал сам. Менеджмент он во многом про этику.
• Корень почти каждой внутренней проблемы: плохие или отсутствующие отношения.
• Люди важней процессов. С правильными людьми любой процесс подойдёт. С неправильными людьми никакой процесс не заработает. Если процесс не работает, иногда дело не в процессе.
• Делать сложные вещи надо, не откладывая: плохие отношения с кем-то, конфликт в команде и так далее. Если их откладывать — они выстрелят сильно позднее и с ними всё равно надо будет разбираться.
• Правильный фрейм принятия решения: что хорошо для компании? Что хорошо для моей команды? Что хорошо для меня? Именно в таком порядке.
• Есть два состояния: сильный рост и недостаток роста. Когда рост сильный, новые идеи не так важны — и так понятно, что делать, важно делать. Если роста сильного нет — наоборот, важны новые идеи.
• Правила хорошего спринта.
  Команда знает:
  1. Над чем работать.
  2. Почему это важно.
  3. Может определить, когда работа закончена.
  4. Знает, над чем работать дальше.
  Стейкхолдеры знают:
  5. Над чем работает команда.
  6. Над чем будет работать команда.
  7. Как повлиять на планы.

Отличная книга. Советую всем, кто имеет отношение к работе с инженерными командами.