Everything is important
Your team argues every architectural decision at the same intensity, and the expensive ones fall behind.
Where it goes wrong
Cheap and expensive decisions are not always easy to distinguish between. For example, both a language port and a change to the system's source of truth can turn up as tickets of the same size. The first is much cheaper to undo than the second.
A central factor in deciding the cost is how much of other people's work will sit on top of the decision once it is made. The amount of code produced predicts almost nothing about that.
How I'd handle it
My test for this: who has to adapt? A decision stays cheap while reversing it is yours alone to do. It turns expensive the moment reversing it means other people have to change what they built on it. Their schedule is not yours, and no tooling changes that.
I make sure we consider that test for the whole list of decisions before anyone digs in, and spend the time on the few that are expensive. The rest can be settled quickly and revisited when there is evidence.
Where I've done this
Two of Band's decisions looked quite important: one was a build target, which could be added later without touching the source. The other was a boundary both SDKs would build on, and it got more expensive every week it stayed open. Telling those two apart was worth more than settling either one fast.
SunbitAt Sunbit the argument sounded like it was about Kafka and Kotlin. Underneath it was a choice of which system holds the authoritative record, which was really about which team would own this crucial part of the system.
Recognize this on your team?
