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

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

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

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

3. Набор специалистов.

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

Это происходит по нескольким причинам:
- почти нигде нет нормального автоматического тестирования и, в целом, длинные циклы обратной связи = накладные расходы;
- избыточно сложная архитектура = накладные расходы (см. п. 1);
- избыточные процессы = накладные расходы (см. п. 2);
- эффект ёмкости задачи (9 женщин не могут родить одного человека за месяц);
- недостаточное внимание к приоритизации часто приводит к тому, что огромную часть времени команды тратят на второстепенные задачи, пока киллер-фичи простаивают. Например, из трех команд одна загружена киллер-фичами на полгода вперёд, а две другие пилят всякую малозначительную ерунду из своего бэклога. То же можно сказать и про специалистов: один загибается над ключевыми задачами, второй подметает всякую второстепенную мелочёвку из бэклога. В итоге, команда работает вполсилы.
- Избыточно узкая специализация сотрудников, когда бэки в мыле пилят фичи, фронты от безделья фреймворк меняют и кнопки красят, а девопсы все настроили и вообще бамбук курят или на второй работе фигачат.

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

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

Вывод

Короче, если вы CTO, то базовые рекомендации:
- сосредоточиться на результате, а не на процессе;
- слепить микросервисы обратно;
- упростить процессы обратно;
- не налегать на найм.