"бизнесу вроде как тоже да" вот это ключевое. все остальное не важно

можно почитать чонить вкратце по теме?

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

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

ну есть такая ситуация: бизнес валит кучу задач в высоком приоритете. соответственно, чем раньше они выйдут в прод, тем лучше. "бизнес ждет". по факту это все может тянуться месяц и более (хотя так то можно при здоровой системе запилить за пару часов и выкатить), ну по моим прикидкам

тут смешано, я вижу что понимания нет.
условно бизнесу лучше 10 фич через 3 месяца. или 5 фич через 2 ?

тут проблема больше в том что у вас есть ботлнек в виде одного человека который принимает решение. То есть либо проблема с уровнем доверия (ну вот серьезно протоспеки между сервисами должен архитектор апрувить? это ж микроменеджмент) - мол вы там все джуны а архитектор все разрулит.

Так же мне видится проблема в том что у вас есть вот эти "стадии" - дизайн базы, дизайн микросервисов (как это вообще? микросервисы с общей базой?), протобуфики и т.д.

Для решения описанной проблемы нужно больше полномочий и автономии спускать внизы. Что бы архитект только направление задавал, мол какая команда чем заниматься должна. А такие мелкие вещи как "че как кого дернуть" - должен быть свод правил и ограничений какие данные куда передавать можно (по умолчанию никакие и никуда) а какие нельзя ни при каких обстоятельствах (PHI/PII какие).

Тут как с код ревью. Нужно определить что ревью требует а что можно и без него. Начните с того что бы из всего спектра выбрать те вещи которые "не то что бы сильно требуют апрува архитектора" - это и дизайн базы (у вас же микросервисы вы че)  и протобуфы. Уменьшите скоуп только до "вот мой сервис ходит в тот сервис за такими-то данными и потом на основе этого решение делает - это ок?". Дальше уже можно идти в сторону формализации таких правил. Мол что ревью у архитектора нужно только если вам надо стучать в другой сервис. или еще чего делать что не описано в зависимостях вашей команды. Так постепенно можно уменьшать скоуп зависимостей.