In system design, a common paradigm is to declare an API or abstraction boundary -- users/clients utilize the abstractions without consideration for the systems underlying implementation. When an abstraction is not logically complete or the implementation is flawed, details about the implementation are leaked to the user. This isn't good, as the system now demands the user to understand more details that should not have been necessary in the first place.

Have you considered that cross-functional communication can be visualized similarly?

Imagine this common scenario where a product manager asks an engineer, "How much work is it to build this feature and how long would it take?" To the product manager it is a simple question, their goal is to scope out the expense and timeline for the feature.

Because the engineer's job is different, this question brings up different thoughts for them. Analyzing it on the spot, they respond "Well, to build that, we would need to run a database migration, write a job to periodically scan the whole database, and get James from IT to provision new application servers. Samantha from security would need to approve it, so we would also have to file a specification for security review."

The engineer feels helpful and thorough. Unfortunately, the product manager has not received an answer to their question, and so more analysis and discussion is needed.

The issue is that the Engineer leaked the abstraction! In communication terms -- they changed the granularity of the vocabulary. The Product Manager wanted to discuss ‘this feature' and ‘how long and how much work it would take'. The engineer leaked the abstraction by discussing "what steps it would take", which is an underlying implementation detail to the product manager's question.

Those implementation details are certainly relevant to the Engineer's daily job. However, the Product Manager is the Engineer's client! A client doesn't want to know about implementation details, they just want to know the minimum necessary details to collaborate appropriately. Anything more is distracting, or worse overwhelming.

A solution? Speak in similar abstractions, using similar vocabulary. Leak abstractions only when necessary, doing so as concisely as possible.

"This feature would take 5-8 days, some of them stemming from interactions with other teams. It possibly would get shot down in security review".