When You Depend on Another Team: A Contract, Not a Favour

From the field: from “sure, we’ll do it” to number 23

We were building the IPO order screen. Before a customer could place an order, the screen had to read that customer’s IPO limit from the risk team’s service. The endpoint did not exist. The risk team had to build it. On 3 March I wrote to the risk team’s lead. The answer came in half an hour: “Sure, we’ll do it.” I felt relieved and closed the topic.

Our side was done in 11 days. The screen was ready, and the limit call was tested against a fake response. The release date was 13 April. For the next four weeks I did not ask the risk team a single time. They had said “we’ll do it”.

When I looked at their board on 9 April, the work was number 23. It was not bad intent. The risk team had an audit deadline on 30 April, and the whole team had turned to it. Their priority was right. So was ours. Two right priorities did not fit into the same team’s calendar.

On Friday morning I made my first mistake: I sent the CTO a message on my own. “The IPO screen is late because of the risk team.” The CTO forwarded it to the risk lead. The risk lead heard about the problem from the CTO, not from me. They read it, fairly, as being attacked from behind. Repairing that relationship took two weeks.

The result: the release moved from 13 April to 4 May, a 21-day delay. The first IPO was on 11 May. A pilot planned for four weeks was squeezed into one.

The real mistake was not on 9 April. It was on 3 March. I had taken a favour for a commitment.

Whose priority wins?

Most dependency crises get stuck on this question. Your team defends its roadmap, and the other team defends theirs. Both are right, and both are incomplete. Neither lead sees the whole company; each sees only their own slice.

The answer is this: the company’s priority wins. But the company is not a person. The common manager of the two teams sets that priority. And that person can only decide when they see both options side by side. Audit or IPO? The risk lead cannot choose that alone, and neither can I. What we can do is write the options down together.

If I had known this on 3 March, my question would not have been “can you do this?”. It would have been “where does this fit among your work this quarter?”. Everybody says yes to the first question. The second one gets you a real place in the queue.

Seeing dependencies early: the map

After the incident, the first thing we did was open every epic for the next quarter and ask: “Does this work need another team to do something?” The result was a one-page table:

EPIC                  DEPENDS ON TEAM       WHAT IS NEEDED      DOES THE OTHER TEAM KNOW?
---------------------------------------------------------------------------------------
IPO v2                Risk                  Limit update        YES  (no date)
Derivatives order     Market data           New price feed      NO
Customer alerts       Platform              Queue quota         YES  (date set)
Account closing       Accounting            Reconciliation rpt  NO
...

TOTAL: 17 epics, 11 dependencies, the other team does not know about 4.
RULE : A "NO" row is discussed with the other team that same week.
       A "no date" row counts as a risk until a date is written.

Those four “NO” rows scared me the most. If the other team did not know about the work, our plan was not in their plan. Halfway through the quarter we would have gone to them with “oh, we also need this”, and we would have seen number 23 again.

The map is not a complex tool. It is one table and one hour at the start of the quarter. The important question is: who finishes this work? If the answer is not “us”, the row goes into the table. Asking this during refinement, while you split epics, also helps. But without the round at the start of the quarter, dependencies still appear in the middle of a sprint.

A contract, not a favour: what, when, who

I know “contract” sounds heavy. I do not mean anything legal. I mean a record with three lines that both teams can read. And the record binds both teams, not only the other side.

After the incident we tied this record to four rules. They all fit on one page, and the page sits on both teams’ boards:

WHAT      : [endpoint + request/response example + acceptance criteria]
WHEN      : [a date - not "next sprint"]
WHO       : [a named owner on the other team]

RULE 1 - Plan B date   : A written day before the main date.
         If the work has not started by then, plan B starts by itself.
RULE 2 - Review time   : If we open a PR to the other team's code,
         the first review happens within 2 working days.
RULE 3 - 48 hours      : If the two leads cannot agree in 48 hours,
         it goes to a JOINT escalation. Never alone.
RULE 4 - Tuesday check : 5 minutes every Tuesday. One question:
         "Is the date still valid?" If not, go to rule 1.

Rule one matters most. In our incident there was a plan B, but it had no date. So nobody remembered it until 9 April. When plan B has a date, the decision is no longer an argument. It is a matter of the calendar.

Rule four is the cheapest. The Tuesday check is not a meeting. It is one message between two leads, or five minutes in the corridor. The question is always the same: “Is the date still valid?” Before 9 April, I could have asked it on four Tuesdays in a row. On one of them the answer would have been “the audit came up, it may slip”, and I would have had three more weeks.

If you are the other team

The same rules work in the other direction. When another team asks you for something, the easiest answer is “sure, we’ll do it”. You upset nobody in that moment. But with that sentence, the other team gets a date from you without you ever giving one. They build their plan on your sentence.

After the incident I set the same rule for my own team. Before we say yes to a request from another team, we check two things: where it fits among this quarter’s work, and which work it pushes back. Our answer is either “yes, on this date” or “not this quarter, and here is why”. The second one is hard to say. But it gives the other team five weeks to build a plan B.

Escalation: together, not alone

The message I sent the CTO on Friday was technically correct. The work really was late because of the risk team. But it read like this: “This team is slowing me down, fix them.” The risk lead reacted defensively. They were right to: I had not given them a chance to explain their situation. They had to explain their own audit deadline as an answer to the CTO’s question, not as part of my message.

On Tuesday 14 April I tried to fix it. The risk lead and I sat down and wrote three options on one page together. Then we went to the CTO together:

The meeting took 20 minutes. We chose B. Nobody asked “who was right?”, because that was not the question on the table. We could have reached the same result on Friday. If I had not written alone, we would also have skipped two cold weeks.

This gave us the 48-hour rule. If two leads cannot solve something in 48 hours, it goes up. But it goes up together: the options on one page, with both names on it. In the post on conflict I wrote about bringing a disagreement to the surface instead of pushing it down. The same is true between teams. The only difference is that two teams sit at the table.

“We will build it”: a PR to another team’s code

Option B looked easy on paper. The code is ours; only the repository is theirs. In practice it was not that easy. We opened the PR on 22 April, and it was merged on 28 April. Total cost: 4 days of code and 2 days of review fixes. The risk team had estimated the same work at 2 days.

The reason for three times the cost was clear. We did not know their test setup. We learned about two edge cases in the limit calculation only during review. Their logging rules were different from ours. These things were known to them and new to us.

It was still the right choice. With option A, we would have met the first IPO without a pilot; 6 days was cheap next to that. But before we say “we will build it” now, we ask four questions:

• Is there a promise to review? If the other team will not look at it within two days, you have moved the problem, not solved it.
• Who owns it afterwards? After the merge the code is theirs. If an alert fires at night, they get up. Do not start before this is written.
• Did you multiply the estimate by three? First work in someone else’s codebase always costs more than in your own.
• Once, or every time? If you open PRs to the same team every quarter, the problem is not the dependency. The boundary is drawn in the wrong place.

The last point matters. Where to draw boundaries is a separate topic, and I covered it in the squad model and reorg posts. If you always depend on the same team, that team may not be working like an internal product. That is the subject of the platform team post.

What to track

What did not work for me

• A weekly dependency meeting. Eight leads, 45 minutes, every week. By the third week half of them did not come. Most rows in the meeting had nothing to do with the people in the room that day. We replaced it with a 5-minute check every Tuesday for each dependency pair. Only two leads, one question.
• Tracking dependencies as Jira links. The “blocks / is blocked by” links were correct, but nobody looked at them. A link does not carry a date. A record without a date does not bind anyone to anything.
• Trusting “sure”. The problem was not the other team. I was the one who read a moment of politeness as a commitment.

Checklist

Conclusion

Number 23 on 9 April was not a surprise. It was the bill, five weeks later, for a date nobody wrote down on 3 March. The risk team had not made a promise. I had assumed I heard one.

What changed in the next quarter was not big. A one-page map, a three-line record, five minutes on Tuesdays. Epics slipping per quarter went from 5 to 1. And we learned about that one from the Tuesday check, not from the CTO.

If you depend on another team, the first thing to do is not to ask a favour. Write one sentence with a date, an owner and a plan B, in a place both teams read. Without that sentence, what you have is not a promise. It is a hope.