powstik
All outcomes
Skills

Author Architecture Decision Records for Systems You Own

8 weeks · 0 milestones

Author 3 Architecture Decision Records (ADRs) for real systems you built or are actively working on — not hypothetical or textbook systems. Each ADR must include: the problem context (what constraint or requirement forced a decision), at least 3 considered alternatives with documented trade-offs for each, the final decision with explicit rationale, and the consequences you have already observed or expect to observe (positive and negative). ADRs for systems you own are defensible because they include evidence of consequences — either already observed or verifiably testable. Proof: a principal engineer or senior architect asks 'what would make you revisit the decision in your second ADR?' — you must answer in terms of your actual system's constraints and what specific evidence would change the decision, not the general principle.

Milestone map

Milestone map

3 milestones

Author Three Architecture Decision Records for Real Decisions

4–8 weeks

Study the Architecture Decision Record format: context, decision, status, consequences, and alternatives considered. Read at least ten published real-world ADRs from open-source projects. Author three ADRs for real architectural decisions in a codebase you have worked on or for a personal project: one about a data store choice, one about a communication pattern, and one about a build or deployment choice.

Proof required

Submit: three ADRs in the standard format (context, decision, status, consequences, alternatives considered), each linked to a real codebase or project; and a 200-word reflection on the difference between documenting a decision and justifying it. A senior engineer or engineering manager must confirm the ADRs are genuine records of real decisions.

What gets checked

  • All three ADRs have an alternatives-considered section with at least two alternatives — not just the chosen option
  • The consequences section addresses both positive and negative consequences — not just benefits
  • A senior engineer or engineering manager has confirmed the ADRs are genuine records of real decisions

Common mistakes

  • ADRs with only the chosen option and no genuine alternatives — an ADR without alternatives is an announcement, not a record
  • Consequences section that only lists benefits — every engineering decision has tradeoffs and an ADR must name them

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

  • Does each ADR have at least two alternatives in the alternatives-considered section?
  • Does the consequences section name both positive and negative consequences?
  • Are these records of real decisions — or invented examples for the proof?

Lead an Architecture Review for a Real System Change

8–16 weeks (depends on system change scope)

Identify a real architectural change in a system you work on or contribute to. Write the ADR for the proposed change BEFORE implementing it. Present the ADR in a review meeting with at least two other engineers. Implement the change. Write a post-decision retrospective ADR documenting what changed from the original proposal.

Proof required

Submit: the pre-decision ADR (dated before the review); evidence the review was held (meeting notes or transcript with at least two engineers participating); the post-decision retrospective ADR documenting what changed and why; and a 200-word reflection on what the review process changed about your original proposal.

What gets checked

  • Pre-decision ADR was written and dated before the review — not after the implementation
  • Review evidence shows at least two engineers participated and raised specific questions
  • Post-decision retrospective documents what changed from the original proposal — not just confirms it was correct

Common mistakes

  • Pre-decision ADR written after implementation — the proof requires the ADR to have driven the review
  • Post-decision retrospective that only confirms the original proposal was correct — real reviews always change something

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

  • Was the pre-decision ADR written and dated before the review meeting?
  • Does the review evidence show at least two engineers with specific questions raised?
  • Does the retrospective document what changed from the original proposal?

Build an ADR Corpus and Present System Architecture

6–12 weeks (after milestone 2)

Author or collect at least ten ADRs for a real system you work on, covering decisions at multiple levels: data model, service boundaries, communication protocols, deployment, security boundaries, and observability. Present the full ADR corpus to a senior engineer or architect as a system-level architecture briefing.

Proof required

Submit: a repository containing at least ten ADRs covering decisions at multiple levels — with dates, status, and consequences; and a recording or transcript of a system-level architecture briefing to a senior engineer or architect where they asked at least three specific questions about the decisions.

What gets checked

  • At least ten ADRs covering decisions at multiple architectural levels — not ten ADRs about the same category
  • Each ADR has a current status (proposed, accepted, deprecated, superseded)
  • A senior engineer or architect asked at least three specific questions about the decisions in the briefing

Common mistakes

  • Ten ADRs that all cover the same category of decision — the corpus must span multiple architectural levels
  • Briefing that is a walkthrough without challenge — the reviewer must push back on at least some decisions

Resources

Foundationstart here

Depthgo deeper

What a verifier looks for

  • Do the ADRs cover decisions at multiple architectural levels — not all in one category?
  • Does each ADR have a current status reflecting actual state?
  • Were at least three specific questions asked in the briefing?

Part of

We use analytics to improve Powstik. No ads, ever.