Enabling constraints

An enabling constraint is a limitation or rule that, rather than hindering creativity or progress, actually promotes innovation and problem-solving.
In software development, we've all experienced the positive effects of enabling constraints. Examples of enabling constraints in sw development are:
  1. trunk-based development
  2. continuous integration
  3. static code analysis/checks, i.e.: enforcing rules such as function or method length, number of parameters, naming conventions, etc
Recently, I've been thinking about the use of enabling constraints at the organizational level. One example I think I heard here was about strengthening the cooperation between engineering and marketing.
The solution can be remarkably simple:

have marketing prepare the material for a feature before its implementation.

What I was wondering is: how should we think about this change in terms of Team Topologies?
Before diving into the topologies and interactions I would observe that this change adheres to some of the key takeaways of Part 1 (Teams As the Means of Delivery), in particular:
change the team working environment to help teams succeed
The Team Topologies approach advocates for organization design that optimizes for flow of change and feedback from running systems.

Now, I find this a pretty tenuous connection as it can be applied to pretty much any change, so I stopping going down this path.

There is however one example that might fit this change, albeit it does so for a different reason and it is the hikers example from E. M. Goldratt's book The Goal.

In the hikers example, Alex Rogo the book protagonist tries to solve the problem of keeping a group of hikers (kids) together while still going as fast as possible. The metaphor is that of the factory line where one step goes slower than others and that causes inventory to build up (or deplete) requiring continuous intervention to keep the line from blocking entirely. All this maintenance then makes it impossible to work on the actual issue because the variability is too high and there is something urgent that cannot wait.
In other words: the constraint cannot be elevated (relieving Herbie of some his load) unless all work is subordinated to it.

TBH I'm still unsure if the above connection makes sense or is just incidental, but for now I'll let simmer.