Nobody wrote down what the two teams owe each other

You ask the other team for something. They say yes. Three weeks later it has not happened, and when you follow up the answer is some version of "we've been slammed."

Nobody lied to you. The request landed in a queue you cannot see, ranked against work you do not know about, by a person whose manager measures them on something that has nothing to do with you. The support model between your two teams was never written down, so it defaults to goodwill, and goodwill is a budget that depletes.

This is the second of four failure modes behind most cross-team friction. The argument underneath all four is here.

Check the structure before you conclude it is trust

Almost everyone reads this pattern as a relationship problem. That is the wrong first read. Before you invest in building a better relationship, look at how both teams are measured and who they report to.

If helping you costs them, the goodwill will run out and nothing you do interpersonally will refill it. A team whose bonus depends on their own cycle time will deprioritize your request every time, and they will be right to. That is a finding about design rather than character. Check it first, because it determines whether anything else on this page is worth your time.

If the structure is neutral or supportive and the support still does not arrive, then the rest of this applies.

Make the queue visible and the answer honest

Rank the asks out loud. Use the shared priorities to say which of your requests comes first. A ranked queue is much easier for another team to accept than a refusal, and it gives them something to push back on specifically.

Be explicit about capacity in both directions. Tell them what you can do and by when. Ambiguity reads as unwillingness, and a vague yes does more damage than a clear no, because it stops the other team from finding another route.

Agree an escalation path before you need one. Decide in advance what happens when support does not arrive and who makes the call. Escalation designed during a crisis feels like an attack. Escalation agreed in advance feels like a process.

The trust version of this problem

Sometimes the structure is fine and there is still a wariness between the teams that predates everyone currently in the room.

Tell the stories where it worked, and name the people. Not your people. Theirs. Public credit for someone on the other team who made something happen is the cheapest trust mechanism available and it is almost never used deliberately.

Recognize people who do not report to you. Whatever recognition channel your organization has, point it across the boundary rather than down your own chain.

Make it safe to bring bad news early. Say it, then prove it the first time somebody tests you. Trust between teams is built almost entirely on what happens the first time someone tells you something you did not want to hear, and it is destroyed in the same moment.

Put people in the same room on real work. Shared work builds more trust than a team-building exercise. If you cannot arrange shared work, proximity of any kind still beats none.

When nobody knows how support is meant to flow

The third version is the simplest to fix and the most often skipped, because it requires admitting that the arrangement was never designed.

Get clear about your own team first. Define your charter. Then map which other teams you depend on, for what, and what good support from them actually looks like. Most leaders cannot answer that second question without writing it down. The other team is in the same position, and neither of you has said so.

Have the direct conversation. Talk through the support gaps and their causes with the other team rather than about them.

Draw the process. Visually map how the two teams are supposed to help each other, step by step, with named contacts for each kind of request.

Write a support charter and get it backed. One page: what each team will do for the other, who to contact, and what happens when it does not arrive. Then get a senior leader on each side to put their name on it. Without that last step it is a document. With it, it is an agreement.

How you know it worked

The measurable version is response time on cross-team requests, if you are willing to track it for a quarter. The observable version is easier: does anyone still need you personally to unblock a routine request between the two teams? If the answer is yes, the support model is still living in your head rather than on paper.

The exercise

Write down the last three things you needed from the other team. For each, note what you asked for, what you got, and how long it took.

Then answer one question honestly: in each case, did you know what their queue looked like when you asked?

If the answer is no three times, you do not have a trust problem yet. You have a visibility problem. Those cost less to fix.