When there's a boundary there's an automatic "us vs them".

"Us" is the side of the boundary I'm on, and "them" is the other side.

An API between teams creates a boundary.

In ambiguity it's tempting as an engineer to put up an API as a kind of defensive wall to keep the ambiguity at bay, to make the ambiguity the other side's problem.

"They didn't set the requirements right" vs "we didn't set the requirements right".

A shared obligation vs one to put on the other and then blame them for if it doesn't work.

But the overall system will succeed or fail based on whether the API is the right one; whether it's simplifying but also adaptable.

A good pattern to counteract this is to take the API boundary internal to a team.

So one person, or one team, is responsible for both sides of the API boundary.

This helps ensure that the API is well designed.

Kind of similar logic to getting a fair split of something: have one person split the item, and the other person pick. Aligning the incentives for maximum fairness.