Skip to main content

Ownership and Judgment Exercises

Why this chapter matters

Architectural judgment is not only technical. It includes ownership, sequencing, communication, and knowing how much process a decision deserves.

These exercises train that judgment.

Exercise 1: Ownership map

Pick one product area and map:

SurfaceOwnerQuality gatesEscalation pathExpiry/debt notes
Route
Feature module
Shared component
API contract
Experiment
Third-party script

Judgment question: Which item would fail in production because no one truly owns it?

Exercise 2: Reversibility ranking

Rank these decisions from easiest to hardest to reverse:

  • component prop naming
  • route rendering model
  • state management library
  • design token taxonomy
  • auth/session architecture
  • microfrontend split
  • GenUI component registry schema
  • CDN cache key strategy

Then write the review depth each decision deserves.

Exercise 3: The exception register

Create an exception register:

ExceptionReasonRiskOwnerExpiryReview signal

Examples:

  • temporary bundle budget exception
  • legacy component without accessibility contract
  • third-party script without full observability
  • CSP report-only period
  • GenUI component allowed only for internal users

Judgment question: Which exceptions are actually unowned permanent debt?

Exercise 4: Tradeoff translation

Translate this technical statement:

We need to move this route from CSR to a hybrid static shell with a hydrated form island.

Into language for:

  • product manager
  • designer
  • backend engineer
  • engineering manager
  • security reviewer

Good architecture communication changes vocabulary without changing truth.

Exercise 5: Decision pressure

You have two weeks before launch. The team finds:

  • p75 mobile LCP is 3.4s
  • keyboard focus is broken in a modal
  • analytics attribution is incomplete
  • a new dependency has a known moderate vulnerability
  • the product owner wants one more experiment variant

Write:

  • what blocks launch
  • what can ship behind a flag
  • what needs an exception
  • what needs executive/product visibility
  • what must be fixed after launch with an owner and date

Review standard

A strong answer names:

  • user harm
  • business risk
  • reversibility
  • owner
  • evidence
  • follow-up mechanism