Most coordination failures don't look like failures at first. They look like meetings that went well, until two weeks later, when both teams have built the same component differently, or neither has built it because each assumed the other would.
The fix isn't more meetings. It's making ownership explicit, in writing, before the work starts. Five questions, asked together, surface where the ambiguity actually sits, and an ownership matrix turns the answers into a reference everyone returns to when reality drifts.
The principle Two teams working the same problem need explicit interfaces. Without them, you get either duplication or political conflict, and you find out which one you have only after a sprint of wasted work. The job is to surface the questions before the work, not after.
1 · The five ownership questions
Before any cross-team work begins, get the involved teams in one room (or one document) and answer five questions out loud. The answers don't need to be elegant. They need to be unambiguous, and recorded somewhere both teams can find them next month.
1
Who owns shaping?
Who is accountable for taking a problem from "we should do something about this" to "here's what we're going to build, why, and what we're not building". One named person. If two teams answer this question with their own name, you have your first conflict to resolve.
2
Who approves requirements?
Once the shape is agreed, who has the authority to say "yes, build this"? This is rarely the same person who shapes, and getting these two roles confused is the most common source of late-stage rework. Approval lives with the person who carries the cost of being wrong.
3
Who defines adoption success?
What does "this worked" actually mean, and who decides? Adoption metrics rarely live with the team that builds, they live with the team that has to use the thing afterwards. If nobody owns this, success quietly defaults to "it shipped", which is not the same thing.
4
Who logs decisions and trade-offs?
Every cross-team initiative makes dozens of small decisions. Who writes them down, where, in what format. This sounds clerical until the third month, when both teams disagree about what was decided in week two. The log is what protects you from re-litigating settled questions.
5
Who resolves business-vs-platform conflicts?
When the business case wants something the platform constraints can't support, or when platform discipline says no to something the business genuinely needs, who has the final call? If the answer is "we'll figure it out when it comes up", that's the answer that produces the worst escalations. Decide upfront whose call it is, in which direction.
Victor's note
The first time I worked across two teams that genuinely overlapped, we spent six weeks producing parallel versions of the same data model before anyone noticed. It wasn't because either team was careless. It was because nobody had asked, in writing, who owned the shape. We assumed it would be obvious. It never is.
These five questions take twenty minutes to answer. They save weeks. The asymmetry is so consistent I now refuse to start cross-team work without them.
2 · The ownership matrix
The five questions produce one artefact: an ownership matrix. One row per workstream or initiative, one column per ownership question, named individuals (not teams) in each cell. It's the simplest possible coordination tool, and it works because it forces specificity.
Here's what one looks like, populated for a worked example, a multi-team data and AI initiative with a data team and a technology / infrastructure team.
Ownership matrix worked example A 4-row by 6-column matrix showing five ownership questions resolved across four initiatives in a multi-team data programme. INITIATIVE Shapes Question 1 Approves Question 2 Adoption Question 3 Logs Question 4 Resolves Question 5 AI triage PoC Data team initiative Lead PM Data lead Steering Committee Ops lead Analyst team Lead PM Sol doc Sponsor Data dept Data lake migration Joint workstream Lead PM + tech lead Tech head Final sign-off Lead PM Quality metrics Both Shared log CTO Escalation Infra provisioning Tech team initiative Tech lead Owns shape Tech head + security Lead PM Fit for purpose Tech lead Tech log CTO Escalation Reports phase 2 Data team initiative Lead PM Sign-off req Biz lead Business owner Biz lead Usage metrics Lead PM Sol doc Sponsor Data dept
Notice what the matrix forces: every cell has a name, not a team. "Data team" doesn't approve anything, a person does. The matrix surfaces the moments when nobody can name the person, which is exactly when you need to find one.
3 · How RACI fits, and where it doesn't
If you've worked in larger organisations, this will look adjacent to RACI. Responsible, Accountable, Consulted, Informed. RACI is a useful frame, and the ownership matrix above is essentially a slimmed-down RACI focused on the questions that matter most for cross-team work.
The reason to use the five questions instead of full RACI most of the time:
- RACI gets unwieldy fast. Once you list every task and tag four roles per row, the matrix overwhelms the conversation it was meant to enable. Most teams maintain it for one sprint, then quietly stop.
- The five questions are the high-leverage subset. Shaping, approval, adoption, decision logging, conflict resolution. These are the ownership questions that actually cause failures when ambiguous. Granular task-by-task RACI doesn't.
- The five questions are conversation-shaped. You can answer them in twenty minutes with two teams in a room. A full RACI takes a planning workshop.
If your organisation already runs on RACI, fold the five questions into it. If you're starting fresh, start with the five, and only formalise into RACI if scale demands it.
4 · Shared documentation is the operating system
The matrix only works if both teams can see it, edit it, and refer to it. Coordination across teams fails most often not because the model is wrong, but because the model lives in one team's tool and the other team forgot it existed.
The minimum coordination stack:
- One shared solution doc per initiative. Both teams contribute. Both teams read. The matrix lives at the top of it. (See the Solution Doc page for the structure.)
- One shared decision log. Every cross-team decision goes here, with date, decision, rationale, owner, and a one-line note on what was considered and rejected. The log makes future arguments shorter: when someone asks "why did we choose X?", the answer is two clicks away.
- Regular alignment cadence. Weekly when the work is active. The agenda is fixed: status against the matrix, new decisions to log, escalations needed. Not a status update meeting. A coordination check.
- Naming teams instead of people. "The tech team approves" is not an answer. Approval lives with humans, not org units. If you can't name the person, you haven't resolved the ambiguity.
- Putting the matrix on one team's wiki. If the other team has to log into a different tool to see it, they won't. Pick a shared space, even if it's the less convenient one for either team.
- Treating the matrix as a one-off. Roles change. People leave. Initiatives evolve. Review the matrix every month, even if you think nothing's changed. The act of reviewing surfaces the changes you didn't notice.
- Avoiding question 5. The business-vs-platform conflict question is the one teams skip because answering it feels political. Skipping it means the conflict happens later, with worse blast radius. Better to bruise an ego upfront than escalate a sprint later.
5 · Take-aways
- The five questions are the lever. Shapes, approves, adoption, logs, resolves. If you can't answer all five with named people, you don't have a coordination model. You have an unspoken assumption.
- The matrix is the artefact. One row per initiative, one column per question, named individuals in each cell. Lives in shared documentation, reviewed monthly.
- Shared docs and a decision log are the supporting infrastructure. Without them, the matrix becomes a snapshot that quickly goes stale.
- RACI is a richer version of the same idea. Use it if your org already runs on it. Otherwise, the five questions are the high-leverage subset.
- The cost of ambiguity compounds. Every week you delay answering the five questions, the cost of resolving them later goes up. Twenty minutes early beats two weeks late, every time.