Надеюсь я сам ничего не перепутал :)

Пойду сверюсь с коллегами по цеху - вернусь с вердиктом

Честно говоря, у меня есть ощущение, что ты перепутал))

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

Для обмена опытом и знаниями есть и иные возможности

пока нет желания у людей изучать код и что-то с ним делать, не замотивируешь никак

а желание изучать код и что-то с ним делать появляется, кгда есть задачи, в рамках которых надо этот код изучать и менять

а не просто запросы  "ой поглядите вон наш код, авось вам это когда-то пригодится"

"бас фактор" — а проблема есть?

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

Код ревью - плозая идея делиться опытом между командами. Это скорее должно быть какое-то место, где можно было бы посмотреть с какими глобальными проблемами команда сталкивалась и как решала, чтобы в случае чего у ним можно было прийти и уточнить как они решали ту или иную проблему. Рассказы об этом на всю компанию будут иметь, как мне кажется, малый эффект, так как бысро забудутся. Нужно именно какое-то пространоство чтобы понимать с кем можно пообщаться, но не пытаться насильно транслировать это на всю компанию.

+

время от времени участники команды переходят в другие команды, как минимум приходится вводить в курс дела, хоть это и не новый сотрудник

принято. но а как быть с тем, что нужна экспертиза коллег из других команд?

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

Что Вы под этим подразумеваете? Кто из других команд будет контрибьютить в продукт другой команды?

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

то, что обычно проверяются какие либо мелочи, то что и линтеры умеют, а хотелось бы чуть более глубокой аналитики..

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

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

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