Прочитал отличную книгу “An Elegant Puzzle: Systems of Engineering Management”: https://www.amazon.com/Elegant-Puzzle-Systems-Engineering-Management-ebook/dp/B07QYCHJ7V/

Она про инженерный менеджмент, но затрагивает также развитие продукта, культуру компании и кучу разных других штук.

Когда я сделаю свой список лучших книг для менеджеров, эта книга туда точно попадет. В ней совсем нет воды, долгих историй и размазывания одной идеи на 300 страниц. Только конкретные четкие размышления, списки и шаги по самы разным областям (“делайте так”, “не делайте так — я сделал и было больно”). Видно, что автор прочувствовал все на своей шкуре и решил выразить весь свой опыт в одной книге. После каждой страницы хочется остановится и подумать. Это сильно отличает эту книгу от кучи других про “управление”, которые размазывают общие слова и видно, что автор в реальной жизни мало сталкивался с реальными проблемами команды.

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

Ниже записи интересных мне мыслей из книги.

Команды

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

Стратегии

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

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

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

Виденье

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

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

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

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

Продуктовый подход

Четыре стадии выбора над чем работать:

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

Цели и метрики

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

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

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

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

Изменение структуры организации

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

Как делать изменения в организации

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

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

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

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

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

Управление и вовлечение менеджера

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

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

Как говорить с журналистами

Три правила:

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

Правила в организации

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

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

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

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

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

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

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

Разное

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

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