Ну, премия, повышение з/п и увольнение

Просто "наказания и поощрения" наводит на мысли, будто должно быть что-то более изощренное

Типа, Иванов хорошо рерайтнул деплой-скрипты — он ест пончик, пока все остальные делают 50 отжиманий

Можно назвать это системой мотивации.

Но может быть и что то "изощрённое", не только премия.

Тут уж кто на что горазд.

Айтипанк.

2086 год. Неизвестные взломали сервера крупнейшей галеры, и получили доступ к личным контактам сотрудников. Им на почты посыпался спам от эйчаров, и они этим крайне недовольны. В процессе разбирательства выяснилось, что автора взломанного модуля сбил управляемый перетренированной нейросетью автобус ещё в 57-м, а дыру его попросил написать его менеджер, ныне директор отдела безопасности индийского филиала компании, чтобы было можно работать с картотекой сотрудников без впн. Как предотвратить отток недовольных разработчиков, понесёт ли виновник наказание, при чём тут тридцатилетний контейнер, запущенный на холодильнике в головном офисе?

Вполне логичный подход)
Тут важно чтобы в компании у PO не было возможности получить премию “за запуск” и сразу свалить на другой проект, оставив все проблемы другим.
Видимо условием успеха будет принцип dogfooding

Согласен.

А что важно с вашей точки зрения?

Если зоны ответственности команд ограничиваются отдельными продуктами, таким опорным программистом может быть тимлид или ведущий разработчик, отвечающий за архитектуру внутри продукта. В таком случае, главный архитектор согласует решения, затрагивающие более одного продукта, либо сам их прорабатывает в сложных ситуациях. Это согласование должно быть явно включено в жизненный цикл каждой фичи.
Надзор за архитектурой внутри каждого конкретного продукта в ландшафте выполняется силами этих самых тимлидов по единым архитектурным принципам, сформулированным главным архитектором. Инструменты: выше уже писали про встраивание проверок в пайплайн сборки, ну и старые добрые design / code review.
Несмотря на отсутствие непосредственной власти над людьми у главного архитектора, все его решения должны быть обязательны для исполнения тимлидами в силу явной поддержки руководства, которая должна быть четко обозначена командам.

На тему встраивания в пайплайн Neal Ford говорит в контексте fitness functions

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

Я только позавчера вспоминал методики достижения баланса между бизнес-интересами и техническими интересами, XP 1st edition глава 14. Это не то решение, которое находится в 100%-й власти бизнеса.

Определиться, что ценно.

Ценно "скотный двор" устроить - вот под него и типы организаций, и типы мотиваций, и типы отношений.
Ценно "мы-такие-разные-разнообразные" - другие типы организаций и отношений
Ценно создать культуру вызова, культуру совместного достижения целей - третьи.

https://www.youtube.com/watch?v=mIlWgF8SVR8
Вот скетч про "мы-такие-разные-разнообразные" ))

Не должно быть там методик и достижения баланса. Если это не стартап или новый продукт. Кто платит, те интересы и должны быть. А вот проблемы тех. Части, если не справляются, нужно подтягивать, с отведенными ресурсами. И никаких балансов и в ущерб интересам платящего. Только "догонять" отведенными ресрсами.

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

Задача архитектора ему это показать.