Tech Lead Handbook
  • 👋Introduction
  • People
    • Space for Growth
    • One on Ones
    • Manage Conflicts
    • Deal with Passive Aggressive
    • Give Feedback
    • Performance Management
    • Manage Up
    • Talent Matrix
  • Engineering
    • Pair Programming
    • DCI Framework
    • Code Ownership
    • ADR
  • Leadership
    • Leadership Competencies
    • The Communication Pyramid
    • Anti Patterns
  • Prioritisation
    • Types of Decisions
    • Pros and Cons
    • Decision Matrix
  • Hiring
    • Hiring Process
    • Prepare a Hiring
    • Position Description
    • Shortlisting
    • Case Study
  • Product
    • Working with Product Managers
    • Assumptions Mapping
    • Decision Making
    • Practice vs Process
    • Nemawashi
    • OKRs
    • Consensus vs Consent
  • Project
    • The Triple Constraint
  • Strategy
    • Tech Strategy
  • Communication
    • Use Positive Language
  • Shortlist
  • ...
Powered by GitBook
On this page
  1. Engineering

ADR

PreviousCode OwnershipNextLeadership

Last updated 1 year ago

Each template element appears on one line in the above example:

  1. context: functional requirement (user story or use case) or an architecture component,

  2. facing: non-functional requirement, for instance a desired quality,

  3. we decided for: decision outcome, arguably the most important part,

  4. and neglected: alternatives not chosen (not to be forgotten!),

  5. to achieve: benefits, the full or partial satisfaction of the requirement,

  6. accepting that: drawbacks, impact on other properties/context and effort/cost.

https://medium.com/olzzio/y-statements-10eb07b5a177
5