Field Notes: How We Stopped Re-Litigating Every Decision

Skip: The Problem

The worst part of being CEO isn't making hard calls. It's making the same hard call four times because nobody wrote down what you actually decided.

I've spent years watching the same conversation happen across different meetings, different teams, different weeks. A decision gets made in a room (or on a Zoom, usually a Zoom). The team moves forward. Then someone asks, \"Wait, why did we go with this approach?\" And suddenly you're back in the room, re-litigating the exact same tradeoffs, the same constraints, the same dead ends you'd already thought through. Time melts. Trust frays. Scope creeps while people argue about whether the original constraint even existed.

We started tracking this a few years ago. Not to be depressing, but just to see where the bleeding was. Across a typical three-month product engagement, we were spending something like 15-20% of team meetings re-hashing decisions that had already been made. Sometimes explicitly. Sometimes just implied, and therefore forgotten.

That's not a meeting problem. That's a decision hygiene problem.

Skip: The Cost of Re-Litigation

Here's what re-litigation actually costs a product team.

First, there's the obvious: time. But it's not just meeting time — it's the worst kind of meeting time. People show up already frustrated because they feel like they're retreading ground. Energy is defensive, not creative. You spend the meeting explaining your reasoning instead of moving the work forward.

Second, there's the compound cost to decision-making itself.

Every time a decision gets relitigated, the team becomes more cautious about the next one.

Decisions start moving slower because nobody wants to have to re-defend them. I've watched teams get stuck inanalysis paralysisnot because the decision was hard, but because they knew they'd have to fight for it again later.

Third — and this is the one that kills client relationships — stakeholders start losing faith in the team's judgment. When a client hears the same options being debated in week three that were debated in week two, they wonder:Do these people actually know what they're doing?Even if the team knows exactly what they're doing, and the re-litigation is just a communication breakdown, the perception sticks.

I remember one engagement where we had decided early on to build a custom integration rather than use an off-the-shelf tool. The decision made sense: the client's workflow was specific enough that a generic tool would've required expensive, fragile workarounds. We made the call, documented why, and moved forward.

By week five, the decision was being relitigated in every steering committee meeting. New stakeholders kept asking, \"Are we sure about this?\" Different people had different half-memories of the constraints. Nobody had written anything down. So every week, the team had to re-sell the decision. By week eight, the relationship was actually tense — not because the decision was wrong, but because the team felt like they weren't being trusted. The client felt like the team kept dodging accountability.

It was a pure communication failure, but it felt like a judgment failure.

We needed to write things down. Not as documentation. Asdecision hygiene.

Chuck: What Decision Records Actually Look Like

Skip's describing a real problem, and the fix is simpler than you'd think: you write down what you decided, what you considered, and why.

That's it.Decision Records.Not a committee process. Not a formal gate. Just:we made this call, here's the reasoning, here's what we ruled out and why.

When we started doing this, I worried it would feel heavyweight. Like suddenly every architecture decision needs a three-page RFC. That's not it at all. A decision record is usually 200-400 words. Sometimes less.

Here's what one actually looks like, stripped of the client details:

Decision: Custom data pipeline vs. managed service (Redshift)

Decision date:Jan 22, 2025

Decided by:Product lead + tech lead

Status:Accepted

What we decided:

Build a lightweight custom ETL pipeline instead of using Redshift for initial data processing.

What we considered:

• Redshift (fully managed, battle-tested, expensive at this scale)
• Apache Kafka + custom Spark jobs (more control, higher operational overhead)
• Lightweight Python-based pipeline (simpler, fewer dependencies, easier to modify)

Why this decision:

1. Data volume at launch is ~500GB/month. Redshift's pricing curve doesn't make sense yet. We hit it later when volume justifies the cost.
2. The client's transformation logic is changing month-to-month as they understand their data better. A custom pipeline lets them iterate without needing engineering cycles.
3. Operational overhead is acceptable — we have two team members with Python/Airflow experience, and the failure modes are straightforward to debug.

What this locks:

• We're committing to owning operational support for the pipeline
• We're assuming data volume stays under 2TB/month (if it grows beyond that, we revisit)
• Team needs to document the pipeline thoroughly since it's non-standard

What could change our mind:

• Data volume grows faster than projected and Redshift economics shift
• Transformation logic stabilizes and we need guaranteed SLAs
• Team attrition makes operational overhead unsustainable

That's the format. Not fancy. But it does something interesting: it kills the re-litigation.

When someone in week seven asks, \"Why didn't we just use Redshift?\" you don't have to have the conversation again. You point them to the decision record. They read it. They see the constraint (cost/volume curve), they see what you considered, they see when you'd revisit it.

I'll add one caution: the worst decision records I've seen are the ones teams write after the fact to justify a call they already made. A decision record written three weeks after the decision misses the point entirely. The value is in thereasoning before the commit, not the documentation after. Speed requires up-front clarity.

Two things change immediately:

First, the team's decision-making gets faster.Once you know you're going to write it down, you're more intentional upfront. You don't waste cycles debating things that don't matter because you know you'll have to justify the time spent. You focus on the real tradeoffs. You make the call and move.

Second, people stop re-defending decisions and start understanding them.It sounds like a small difference, but it's not. When someone reads a decision record instead of hearing a re-explained defense in a meeting, they're reading reasoning, not negotiating. Totally different dynamic.

We also started a lightweight practice ofreviewing old decisionswhen something changed. If we hit that \"revisit if volume exceeds 2TB/month\" line, we don't just swap tools. We write a new decision record explaining what changed and what we're doing instead. That creates a chain of reasoning across time.

Skip: Why It Changes Everything

What I'm seeing across multiple teams now is that decision records solve three problems at once.

First, they eliminate the re-litigation tax.You stop having the same conversation twice. That 15-20% of meeting time freed up? That goes back into actual work.

Second, they build institutional knowledge.New team members don't have toreconstruct months of reasoningfrom Slack threads and half-remembered conversations. They read the records. They understand not just what was decided, butwhy— including the constraints and assumptions that were real at the time.

Third, they give you a trail of how constraints changed.You can look back and see: \"We decided X because of constraint Y. Constraint Y no longer applies. Here's what we decided instead.\" That's not re-litigation. That's learning.

This connects to the estimation piece we wrote a few weeks back — the idea that estimates are conversations, not numbers. Decision records are the same thing. They're not replacing your judgment. They're making your judgment visible, so the team doesn't have to re-discover it every seven days.

Chuck: The Deeper Layer

Skip's describing the cultural shift. I want to add the engineering layer.

We started measuring whether decisions wereproducing the intended outcomes. Not just whether they got made. Do we still need this decision? Is it still working? That's a conversation for a future article, but the pattern is the same — write down what you expect, then measure whether reality matches.

The framework is simple:

What did we decide?(The call itself)

What were we trying to optimize for?(The intent)

What did we rule out, and why?(The tradeoffs)

What would make us revisit this?(The change triggers)

That's decision hygiene. Not perfect. But it stops the bleeding.

A quick note: as with all our Field Notes, the details here are composited from multiple engagements and adjusted to protect the innocent — and a few of the guilty. The patterns are faithful. The specifics have been scrambled.

If this resonated, subscribe.

We’re writing about what’s actually changing in software delivery — no hype, no hand-waving, just what we’re seeing with real teams on real products.

What comes next:In the next piece, Chuck's going deep on how distributed teams actually make decisions at scale — when you don't have everyone in the same room, and silence in a Slack thread doesn't mean agreement.