Cross-Team Dependencies Are a Contract Problem, Not a Scheduling Problem

When two teams depend on each other and the work slows down, the usual response is more coordination: another stand-up, a dependency tracker, a shared timeline. All of those describe the problem more accurately without necessarily solving it.

I saw this as Delivery Lead on the WooliesX insurance portals. We needed three portals live on a budget of $1M AUD: My Insurance Portal for motor policy purchase and management, and two Quotelines portals for Pet and Travel insurance quotes. Delivery was split between two organisations. The WooliesX product and delivery team built the portals, while Hollard, the insurance provider, was responsible for the backend insurance logic they depended on.

The biggest risk was never the build itself. It was the seam between two teams who did not report to the same person.

The first response only bought time

While waiting on Hollard, we had the WooliesX team build and test against mock data rather than sit idle. I would do that again. Idle engineers are expensive and bad for morale, and mock data lets you learn about the front end before the real services exist.

But mock data does not remove a dependency. It postpones the moment when both sides discover whether their assumptions match.

Say the problem out loud

The cadence was not good enough, and it was not going to fix itself. I called that out directly to both teams and to the leaders on both sides, setting out what speed we needed and what would get us there.

That can feel uncomfortable across an organisational boundary, where nobody wants to seem to be criticising a partner. In my experience, staying polite and vague is the costlier option. Once both sides had acknowledged the problem, we could run a joint brainstorming session aimed at the way we worked together, rather than at either team.

The fix: agree the API contract first

What we landed on was simple. The two teams would agree and lock the API contract upfront, so each could build independently with minimal touchpoints.

An agreed contract changes the nature of the dependency:

• Neither team needs to wait for the other's pace to keep working.
• Questions get answered once, in the contract, rather than repeatedly in meetings.
• Disagreements appear at the design stage, when they are cheap to resolve.
• Mock data becomes far more reliable, because it reflects an agreed interface.

What changed

On My Insurance Portal phase 2, delivery recovered from a dip in cadence and eventually reached full alignment between actual and targeted story points. Quotelines lagged its targets for the first four sprints, then exceeded projected cumulative progress by Sprint 9.

Both results came from the same fix. We did not add headcount and we did not extend the timeline.

Where else this applies

Think of a contract as any explicit agreement that lets two groups work without constant negotiation. For APIs it is a specification. The same idea applies elsewhere:

• Design and engineering: agreed components and states.
• Product and support: a clear definition of who handles what, and when it moves.
• Agencies and vendors: agreed data formats and responsibilities before work begins.

Before adding another coordination meeting, try asking what the two teams would need to agree once so they could stop meeting about it.

Goodwill matters, and I would not want to deliver without it. But it is a poor mechanism for closing a gap between two organisations. Naming the dependency early and making the agreement explicit is faster than hoping everyone will meet in the middle.