Making and recording decisions in the thread

A decision nobody can find has to be made again; write each one, its reason and its status where the team works.

Why the record matters

Software teams have a name for the fix: the architecture decision record. Its originator, Michael Nygard, described the problem: when people can't see why an earlier decision was made, they're left to accept it blindly or reverse it blindly. Neither is good.

A record in five lines

Nygard's format works for any team decision:

Chat is for talking, writing is for deciding

Basecamp's guide puts it sharply: "Writing solidifies, chat dissolves." Substantial decisions should start and end with "an exchange of complete thoughts, not one-line-at-a-time jousts." If something important was decided on a call, GitLab's handbook asks that the conclusion be written down.

One source of truth

Record the decision in one place and link to it. Restating it in five channels guarantees five slightly different versions.

Don't delete old decisions

When a decision changes, mark the old one superseded and link to the new one. The history of why you changed course is part of the record.

The short version

Without a record, people blindly accept or reverse past decisions.Context, decision, status, consequences: five lines is enough.Decide in complete written thoughts, not chat fragments.One source of truth; mark superseded decisions instead of deleting them.

Try it in Kanvo

When a Kanvo thread reaches a decision, post it in the five-line format and Pin to this conversation so it sits in the pinned bar. Months later, a message's ⋯ → Ask Kanvo → What was decided? finds it again.

Sources

Without the reasoning, later readers either blindly accept or blindly reverse a decision; proposes a short record of title, context, decision, status and consequences.