Relying on knowledge of external teams

In our last Retro, I had each team member choose at random a pain point identified by the team to help solve as their action item for the Sprint.

Mine was "relying on external teams' knowledge."

What this looks like in practice is we're building technology that is used by other teams, or we are building upon technology previously built by other teams. So our team often has questions for other teams about the history of a build, or they might need to consult with other teams when something goes wrong, or they give another team a heads up that what we're working on may affect the other teams' work.

This can slow our work down, especially when the external teams are in other time zones. And I also suspect feelings are creeping into this - our tech lead is very sensitive to the team going outside for information, takes it as something lacking in himself, and wants to be the main source of knowledge.

But, for the overall team, I'm stuck on how to help solve this. I had some ideas:

- invite the other teams to our standups and reviews (time zones don't overlap, though we do record our reviews)

- attend other teams standups or reviews (time zones)

- invite an external team member to share at a standing bi-weekly knowledge share the team has (I was told the external team member we rely on the most wouldn't be comfortable sharing)

- pair programming with other team members (would be similar to above - time zones and discomfort)

- document what we learn from other teams so we can refer back to it (team is already doing this in Confluence and Jira)

- work on coaching the team lead and his feelings

I think the idea I'm most interested in at this point is:

- be OK with it. This is a natural part of work.

Have you had any success minimizing reliance on other teams' knowledge? Or coaching a team to accept this as part of work and optimize their work and comfort around it?