Agreeing on technical decisions

Why these arguments drag

Because there's often no right answer. Both options work, each has its merits, and the argument becomes an exchange of preferences dressed as reasoning.

Second: technical arguments are enjoyable. Debating a library is more interesting than writing code. A team can spend a week choosing a tool for a three-week project.

The first question: how much does it matter

Split decisions into two kinds.

Reversible. Redoing it later takes an hour to a day. A variable name, a date library, an interface detail.

The rule: don't argue about these for more than fifteen minutes. Take either option and move on. The discussion costs more than the rework.

Hard to reverse. Redoing it takes weeks. Choice of storage, data structure, how permissions work, the core technology.

Here time is worth spending: half an hour to an hour of analysis, sometimes half a day of trying it.

The beginner's error is confusing the two. An hour arguing about a name and five minutes about the database structure.

Keeping the discussion substantive

Start from the problem, not the solution. Not "let's take this" but "we need fast text search and a comprehensible way to handle relationships". Half of arguments dissolve at this step: it turns out the sides are solving different problems.

State the constraints. How much time, who knows what, what's already in use. A wonderful technology nobody on the team knows is a poor choice for a one-month project.

Name the cost of each option. Not only the benefits. "This is faster, but it'll take a week to learn" is an honest argument.

Try it small. When an argument stalls, two hours on a trial slice often beats two days of discussion.

Arguments that mean nothing

"Everyone does it this way." Who exactly, and under what conditions? Large companies have different problems.

"It's more modern." A technology's age argues in neither direction.

"I don't like it." May be true, but must become a reason: what specifically is awkward.

"What if we grow?" The most expensive trap. Building for a million users something a hundred people will use is a reliable way not to finish at all.

Write it down

After the decision, a short note: what we decided, what the problem was, what we considered, why we chose this, what it costs.

Ten lines. It gives you three things:

• You don't argue twice. In a month someone will certainly ask "why not the other one?".
• A new contributor understands the context. Otherwise they see a strange decision with no visible reason.
• You can tell when a decision has expired. Conditions changed, the reasons no longer hold, and you can change it deliberately.

Who decides when you don't converge

Agree in advance. Workable rules: whoever owns that part decides; whoever will have to fix it decides; take what most people know.

Any rule beats none. Without one, an argument runs until somebody tires — the worst way to make decisions.