Cross-Team Conflicts

Pattern

Surface and resolve conflicting decisions before they become blockers.

The Problem

Team A decides to standardize on GraphQL. Team B decides REST is fine for their microservices. Neither team knows about the other's decision until integration time.

By then, both teams have invested weeks of work. The conflict becomes a political battle instead of a technical discussion.

This pattern uses Arbtr to surface conflicts early—before code is written.

The Pattern

Shared Visibility

All stakeholders must be able to see the relevant decisions. This doesn't mean everyone owns every decision—just visibility into what affects integration points.

How to achieve this:

• Use domains to organize decisions by area (API, Infrastructure, etc.)
• Create a "Platform" or "Architecture" domain for cross-cutting decisions
• Ensure team members who work on integrations have access to relevant domains

Use conflicts_with Explicitly

When you create a decision that might conflict with another team's choice, add the conflicts_with relationship.

Conflict detected

"Use REST for Order Service" conflicts_with "Standardize on GraphQL"

Don't hide conflicts. Making them explicit is the whole point.

Surface in the Graph

Conflict edges appear as red lines in the graph. They're impossible to miss.

This visual makes conflicts a first-class concern. Leadership can see strategic tensions at a glance.

Resolution Decision

Create a new decision to resolve the conflict. This decision should:

Reference both conflicting decisions
Document the resolution (compromise, one wins, new approach)
Use supersedes to mark resolved decisions

Example resolution:

"API Strategy: GraphQL for external, REST for internal services"

supersedes both "Standardize on GraphQL" and "Use REST for Order Service"

Archive, Don't Delete

Keep the original conflicting decisions. They document the journey. Just mark them as superseded.

Six months from now, someone will ask "why didn't we just use GraphQL everywhere?" The history answers that question.

Warning Signs

Watch for these patterns that indicate potential cross-team conflicts:

Same domain, different choices

Two teams making decisions in the "API" or "Infrastructure" domain probably need to coordinate.

Contradictory tags

Decisions tagged "GraphQL" and "REST" in the same domain? Review for conflicts.

Integration boundaries

Any decision about how services communicate should be reviewed for conflicts with consuming teams.

Running a Resolution Meeting

When conflicts surface, here's how to resolve them productively:

1. Share the graph

Start by showing the conflict in the graph. Visual representation depersonalizes the issue—it's about decisions, not people.

2. Review the arguments

Each side explains their reasoning using the documented arguments. This prevents re-litigation and keeps discussion focused.

3. Document the resolution

Create the resolution decision in the meeting. The decision record becomes the meeting notes.

4. Update relationships

Add supersedes links to original decisions. The graph now shows the resolution, not the conflict.

Anti-Patterns to Avoid

Avoiding the conflicts_with tag

If you're tempted to not add a conflict relationship because it might cause friction—that's exactly why you need to add it.

Resolving in Slack

Don't resolve conflicts in chat. The resolution needs to be a decision record that future teams can reference.

Deleting the conflict history

Deleting conflicting decisions erases organizational learning. Archive them with clear supersedes relationships instead.

Tech Migration

RFC Process

Command Palette