Why your team keeps re debating the same architectural decisions

There is a specific pattern that emerges in every software team between roughly 30 and 200 people. It looks like this.

A real architectural debate happens. Six engineers in a Slack thread, 47 messages, three pasted diagrams. Real tradeoffs get weighed. A decision lands. Someone writes a Notion page documenting the choice. The team moves on.

Three months later, a new engineer joins. They have a reasonable question about a piece of the system the original decision touched. They post it in #engineering. Within an hour, the original debate is restarting. The same tradeoffs, the same arguments, the same uncertainty about which direction is right.

Four months after that, a different new engineer joins. The cycle repeats.

By the one year mark, the team has had the same debate three to five times. Each rerun takes hours of senior engineering time. The team’s velocity slows because the same questions absorb the same cycles. And the engineers who were in the original debate get demoralized: they thought they had settled this question, and yet here they are settling it again.

This pattern is the central failure mode of growing software teams. It is worth understanding why it happens and what to do about it.

Why decision decay happens

Three forces interact to produce this pattern.

Documentation drifts from the decision.The Notion page someone wrote after the original debate captures the conclusion but not the reasoning. Six months later, the page reads as “we use Postgres” without the context of why. The “why” lived in the Slack thread, which is now buried under thousands of other messages.

Tribal knowledge is fragile. The original debate participants remember the reasoning. They can defend the decision when it comes up. But people leave, change roles, or simply forget over time. The institutional memory of why a decision was made decays faster than the decision itself becomes obsolete.

New employees do not trust documentation they did not help write. Even when documentation exists and is correct, new employees often question it because they were not part of the decision and the document does not preserve enough context to be self sufficient. They are not being unreasonable: documentation that captures “what” without “why” really is hard to trust.

The combination is structural. Without intervention, every growing team will have this pattern. The only question is how often and how expensively.

What the alternative looks like

The functional alternative is what you might call structured decision capture. Instead of relying on Slack threads (which decay) and Notion pages (which drift), the team captures decisions as structured entities with explicit fields: rationale, evidence, decision makers, outcome, follow up reviews.

When a new engineer asks “why do we use Postgres?”, they do not get a Slack search result or a stale Notion page. They get the Decision entity directly. The rationale is preserved structurally. The evidence considered is linked. The decision makers are named. They can see what was actually weighed and why this direction was chosen.

This is not just better documentation. It is a different data model. We covered this distinction in detail in the article on process graphs vs document graphs. The short version: when decisions exist as first class entities with their own properties, they do not decay the way documents do.

The compounding effect

The cost of decision decay is not just the time spent re debating. It is the compounding effect on team velocity and morale.

Velocity loss. A team running the same debate five times a year loses roughly 40 to 60 hours of senior engineering time per debate (the original plus the reruns), times however many decisions are in this pattern. For a 50 person engineering team with 20 such decisions, that is 800 to 1,200 hours per year. At loaded engineering cost, that is a meaningful slice of an FTE in pure waste.

Demoralization. Senior engineers who participated in the original debate become resentful when the same debate keeps restarting. They start checking out of new engineer conversations, leaving the burden of re litigation on others. This produces the worst kind of team dynamic: the people with the most context become the least willing to share it.

Newcomer friction. New engineers feel the team is in flux. They cannot trust documented decisions, so they question everything. They take longer to ship anything because they are unsure whether the conventions they are following will be respected. Onboarding stretches from 30 days to 90 days.

These costs are real and they compound. The team that solves decision decay has a permanent productivity advantage over the team that does not.

What you can do today

Three concrete patterns that help, in order of leverage.

1. Write structured summaries, not free form notes. After every meaningful decision, use a template: what was decided, what was considered, why this direction, who was involved, what would change our minds. The structure is the value; the prose is secondary.
2. Build a decision log your team can scan. Even a simple list of past decisions with their structured summaries beats a buried Notion page nobody reads.
3. When the same question keeps coming up, escalate the documentation, not the response. If a particular decision is being re litigated, that is a signal the documentation is not sufficient. Update it. Add context. Do not just keep re explaining in Slack.

These work, but they require discipline most teams do not have. The structural solution is a system that captures these patterns automatically. We are building Pulse around exactly this problem: every team decision becomes a structured entity in the process graph, with rationale, evidence, and outcome tracked over time. Live demo at pulsehq.tech.