How do you resolve architecture disagreements on your team?

Question

Accepted Answer

Smart engineers will disagree on architecture, that's healthy. The TL's job is to turn disagreement into a **good decision and a committed team**, not to win the argument. Most disputes dissolve once everyone agrees on the criteria.

## A process for resolving it

```text
1. AGREE on the criteria first — what are we optimizing for?
   (scale, simplicity, time-to-ship, team familiarity)
2. Let each side make its STRONGEST case — steelman, don't strawman
3. Look for DATA — spike it, benchmark it, prototype it
4. If still tied — the TL decides, and explains why
5. DISAGREE AND COMMIT — once decided, everyone rows together
```

## A concrete example

Two engineers argue microservices vs. monolith. You reframe: "What are we optimizing for in the next year?" The answer, shipping fast with a small team, makes the monolith the obvious call. The argument was really about unstated goals.

## When to decide vs. defer

For reversible decisions, pick one quickly and move, the cost of deciding wrong is small. For one-way doors, slow down and gather data. Matching deliberation to reversibility avoids both bikeshedding and reckless calls.

## A pitfall

Don't let your seniority shut down debate, or let debate run forever. Both kill teams: one breeds resentment, the other breeds paralysis.

## Why it matters

Unresolved architecture fights fester and split teams into camps.

A TL who facilitates fairly, then decides, gets both a sound design and a team that owns it together, even those who argued the other side.