One place I worked, the rule was "always have two pairs of eyes on code". Each team got to decide whether that rule was met with some mix of mob or pair programming, or just code reviews/pull requests. We could change depending on the needs of the project and team members. If management forces any of these options on teams it is a huge mistake. The point of pair programming is to share knowledge, reduce bugs, etc. and making it into a metric to measure teams by doesn't work.
It's a lot like setting a minimum code coverage rule like 80 or 90%, people end up cursing the rule as it makes them do stupid things to satisfy the rule. Code coverage is one great tool to explore where your code needs more tests, but it's not the only one, and it's not the point. The point is writing code that's easily maintained, safely changed, and can be delivered to meet customer needs.
You hired really smart people (hopefully) and you should let them decide how to work.
It's a lot like setting a minimum code coverage rule like 80 or 90%, people end up cursing the rule as it makes them do stupid things to satisfy the rule. Code coverage is one great tool to explore where your code needs more tests, but it's not the only one, and it's not the point. The point is writing code that's easily maintained, safely changed, and can be delivered to meet customer needs.
You hired really smart people (hopefully) and you should let them decide how to work.