How should Product and Engineering manage dependencies between teams?

A Feature may be small inside one team and still depend on a platform change, data permission, another customer journey or an external provider. When those needs appear late, teams wait, duplicate work or compromise the intended experience. The issue is coordination around an outcome, not merely maintaining a dependency list.

Identify dependencies in the outcome and the system

During shaping, trace the user journey and the systems needed to support it. Ask which team must decide, build, approve, supply data or operate each part. Distinguish a genuine prerequisite from a convenient assumption about sequencing. Product should show why the work matters to each affected product and resolve competing priorities with the appropriate leaders. Engineering should explain the interface, constraints and integration risks. An ownerless dependency is a forecast risk, even if every team has a ticket.

Use shared plans and explicit agreements

Roadmaps, planning sessions and dependency boards can help, provided they lead to conversations. GOV.UK guidance recommends planning together and making cross-team work visible. For each material dependency, agree the expected output, receiving team, responsible decision maker, target decision point, test approach and an escalation trigger. A technical contract may specify data formats, availability, versioning and failure behaviour. Keep a bounded record so teams can see changes, but do not use a document in place of direct collaboration.

Reduce the number of waits where possible

Product and Engineering should first ask whether the Feature can be sliced to deliver a useful result with fewer teams. An existing capability, a temporary manual process or a different interface may remove a wait, subject to cost and risk. Engineering may propose a stable platform contract or shared component when recurring integration work justifies it. Product checks whether the altered route still serves the user outcome. Teams can work in parallel with mocks or contract tests, but the result needs end-to-end integration before it is treated as delivered.

Escalate changes and fix recurring patterns

A dependency is healthy when its owners can explain the decision, timing and status. Review waiting time and failed integration as well as completed tasks. If another team cannot meet the agreed date, Product should revisit value, sequence and scope; Engineering should assess technical alternatives and risks. Where the same hand-off recurs, examine ownership boundaries, architecture and shared specialist capacity. AI may help summarise dependency records, but it cannot confirm another team’s commitment or make an interface safe. Those require accountable people and evidence.

Example

In a hypothetical subscription business, a customer cancellation change needs billing data from a platform team. Product teams agree the customer outcome and an initial segment. Engineers from both teams define the data contract, failure behaviour and a contract test. They plan a joint integration checkpoint before promising a release. When the platform work slips, Product narrows the first journey to accounts already supported by an existing interface, while Engineering records the longer-term dependency for a later decision.

FAQs

• Should every dependency have a central owner?

  Each material dependency needs named owners in the contributing and receiving teams. A programme or delivery lead may coordinate, but cannot replace those decisions.

• Can teams deliver independently with mocks?

  Mocks can enable parallel work, but real integration and failure behaviour must be verified before the dependent Feature is considered complete.

• When is a dependency a structural problem?

  When the same wait repeatedly delays outcomes or creates fragile integration, review team responsibilities and system boundaries rather than only escalating tickets.