A pull request has been waiting two days. The reviewer's comment says "this contradicts how we agreed to handle retries". The author replies that nobody told them. Neither of them can find where it was agreed, because it was agreed in a meeting in March and the only record is a chat thread that has long since scrolled away.
That is the problem an architecture decision record exists to solve, and it is why we think managers should know the format well even though they will rarely write one. The format takes an afternoon to learn. What takes judgment is knowing what a good record looks like, what a thin one is hiding, and what to do with a record once the decision it describes has stopped being true.
The four sections Nygard proposed
Michael Nygard's 2011 post on documenting architecture decisions set out the original shape. A title that is a short noun phrase. A context section describing the forces at play in neutral language, without arguing for an outcome. A decision stated in the active voice as "We will...". A status. And consequences, which he defines as the resulting situation after the decision is applied, listing good, bad and neutral results.
Nygard's constraints matter as much as his sections. The whole document should be one or two pages. It should read like a conversation, and he warns against bullet points as "an excuse for writing sentence fragments". A record three lines long has skipped the context. A record ten pages long has turned back into the architecture document he was trying to replace.
What the later templates added
The ADR community site collects the templates that followed Nygard, and two additions deserve a manager's attention.
The first is options. The MADR template, which stands for Markdown Architectural Decision Records, adds a section for considered options and another for the pros and cons of each, and states the outcome as the chosen option "because" of a stated justification. That one word, because, is the difference between a record and an announcement. If you can afford to ask for only one thing in every ADR, ask for the options that were rejected and why. A decision with a single option was a notification.
The second is confirmation. MADR's optional confirmation section describes how the team will verify that the implementation complies with the decision. AWS's guidance on the ADR process puts the same idea into code review. A reviewer who spots a change that violates an accepted ADR asks for an update and links the record. That is how the retries pull request above should have gone. The reviewer links the record, the author reads it, and a two-day wait becomes a ten-minute one.
Reading each section as a manager
You are not checking the architecture. You are checking whether the decision was made well.
In the context, look for the forces that are not technical. Nygard listed "technological, political, social, and project local" forces on purpose. A context that mentions only latency and cost, when you know the real pressure was a launch date, is incomplete. Ask for the date to be written down.
In the decision drivers, look for the one that would change the answer. MADR's decision drivers are the concerns that pushed the choice. If none of them is strong enough that removing it would flip the decision, they are decoration.
In the consequences, look for the negative ones. Nygard asks for every consequence, and a record whose consequences are entirely good was written by an advocate rather than a team. Ask who carries the bad ones. It is usually the on-call rota, the team that owns the downstream service, or whoever has to migrate the data in six months.
In the status, look at the date it last changed, and at who changed it.
The lifecycle of a decision
Nygard's statuses were proposed, accepted, deprecated and superseded. MADR adds rejected. The AWS guidance describes the transitions. An owner proposes, the team reads the record in a fixed slot, and the record is accepted, sent back with named actions, or rejected with a written reason "to prevent future discussions on the same topic".
The rule that makes the lifecycle work is immutability. The AWS guidance states that once the team accepts an ADR it becomes immutable, and new insight means a new ADR that supersedes the old one. Joel Parker Henderson's collection on GitHub gives the same advice, "Don't alter existing information in an ADR. Instead, amend the ADR by adding new information, or supersede the ADR by creating a new ADR", while noting that some teams prefer dated updates that keep the record alive. Nygard's own rule was that numbers are never reused and that a reversed decision stays in the log, marked superseded.
We side with immutability, for a management reason rather than a technical one. An accepted record that gets edited loses the thing that made it valuable, which is a trustworthy account of what the team knew at the time. A superseding record has to say what changed. Over a few years that is a history of your team's learning, and you cannot reconstruct it later.
When to skip one
The fastest way to kill the practice is to require a record for everything. Henderson's advice is to "skip an ADR when a decision is limited in scope and time and risk and cost". The AWS guidance scopes the process to decisions about structure, non-functional requirements, dependencies, interfaces and construction techniques, a classification it attributes to Richards and Ford.
The manager's version of that rule is shorter. Ask for a record when more than one team will live with the consequence, when reversing the decision would take longer than a sprint, or when the same argument has now happened twice. The retries decision qualifies on the third count alone.
One small, practical point from Henderson's collection. Teams that named the directory "decisions" rather than "adr" found that people wrote more of them. The word architecture scares off the people whose decisions most need recording.
Where this sits in the standard
Evaluating architectural decisions is competency TJ-1 in the EMA Competency Framework, in the Technical Judgment domain. The TJ-1 unit of the Body of Knowledge covers how a manager weighs trade-offs and reversibility without owning the design, and the TJ-2 unit covers what deliberate shortcuts cost when nobody tracks them.