Sorry, I was more aggressive than I should have been.
I misunderstood your comment, I thought you were suggesting the home team build the guard rails in response to another team's request. I don't disagree that the pattern you're describing can be effective if the home team was always expecting other teams to work in their codebase.
But that's not what the away team model is, the away team model is for unexpected cross team work. E.g. if the guard rails are too restrictive and the home team doesn't have time to expose the new functionality to "userland" code so the other team needs to work with "kernel" code to do so.
What I suggest I think is different than away team (which feels a bit like swoop in and crap on host teams codebase). Just saying I prefer it to away team.
Fundamentally it’s just a hard problem most large orgs don’t do that well
I misunderstood your comment, I thought you were suggesting the home team build the guard rails in response to another team's request. I don't disagree that the pattern you're describing can be effective if the home team was always expecting other teams to work in their codebase.
But that's not what the away team model is, the away team model is for unexpected cross team work. E.g. if the guard rails are too restrictive and the home team doesn't have time to expose the new functionality to "userland" code so the other team needs to work with "kernel" code to do so.