LEARN. PRACTICE. GROW.Concept and mechanism
A manager should create conditions for informed technical decisions, involving people who understand the system and will bear the consequences. Examine disagreement through requirements, evidence, alternatives, and trade-offs rather than personal preference or hierarchy alone. In code review, distinguish issues affecting quality from optional presentation suggestions. Google’s guidance favors improving code health without demanding perfection in every detail; it does not authorize reducing quality merely to finish faster. When written discussion stops progressing, a short conversation can clarify criteria, followed by a decision record for people who were not present.
Guided application
A team debates replacing middleware during a cloud migration. Compare support, skills, compatibility, recovery, operating cost, and reversibility. A bounded experiment can resolve the most important technical uncertainty before a larger commitment. For an architecturally significant choice, record context, rejected options, the decision, consequences, and confidence. If the choice changes, create a new ADR superseding the earlier one and link both, preserving historical reasoning. Do not rewrite the old decision as if new information had always existed. Also define who decides and when reconsideration will occur. The intended result is an understood, sustainable decision rather than the technology preferred by the highest-ranking participant.
An ADR preserves why a decision was made, including consequences and alternatives.
Common pitfalls
Preference treated as evidence; perfectionism; ownerless decisions; erasing architectural history.
Related topics: Mandate, autonomy, and delegation · Feedback and skill development · Capacity, operational load, and toil
Use explicit criteria and preserve decision reasoning.
Reference: Maintain an architecture decision record · GitLab Handbook 2026; DORA current five-metric model; SRE and engineering guidance reviewed 2026-09-30