Concepts
The irreducible epistemic atoms underlying the curriculum. 4,828 atoms across 8 types
Start every standup with the constraint metric — before…
Begin every team standup with the current constraint metric before individual updates to keep collective attention focused on the binding bottleneck.
Ask 'what was the system state' not 'who caused this'…
In blameless postmortems, frame questions as 'what was the system state at [time]' and 'what information was available' rather than 'who caused this' to shift from evaluation to observation and enable information sharing.
Use 'how did this happen' not 'why did you do this'…
In technical postmortems, use 'how' questions ('how did the deployment occur') rather than 'why' questions ('why did you skip review') because 'how' elicits description while 'why' elicits defensive justification.
Enforce 5 minutes of data-only observation in incident…
During incident response, enforce a mandatory 5-minute observation period where team members only report dashboard data and log patterns before anyone proposes a causal theory.
Before recurring meetings, list five things that never get…
Before any recurring meeting or code review, spend 5 minutes writing down what topics never get discussed, what people never speak, and what failure modes are never mentioned—listing at least five absences.
Complete the incident timeline before writing any causal…
When drafting incident postmortems or failure analyses, complete the timeline of observable events (with timestamps and measurements) before writing any causal analysis, because mixing observation and explanation during collection produces defensive filtering.
Announce mode switches explicitly in team observation…
In team contexts where observation must be separated from evaluation, make the phase transition explicit through verbal announcement ('We are now switching from observation mode to evaluation mode'), because implicit transitions allow the two modes to collapse into each other despite individual intentions.
Ask 'what was your reasoning?' not 'why did…
In code reviews or technical evaluations, frame feedback requests as requests for reasoning rather than requests for justification—ask 'What was your reasoning?' instead of 'Why did you do it this way?'—because the first activates analytical explanation while the second activates defensive explanation.
Assign RACI roles explicitly — every task needs exactly…
For each agent-task pair in collaborative work, assign an explicit role type (Responsible, Accountable, Consulted, Informed) and verify that every task has exactly one Accountable party.
Shift team schemas through shared experiments…
When attempting to shift a shared team schema, create low-cost experiments where the team uses the new schema on one real decision, rather than presenting the new framework in slides or documents.
Before changing a team schema, map what it supports…
Before attempting to change a shared team schema, map what the current schema supports—which decisions it enables, what coordination it simplifies, and what would break if it disappeared—to understand its load-bearing function.
Schema change scales with group size
Scale your timeline expectations for schema change with group size—weeks for pairs, quarters for 50-person orgs, years for industries—and measure progress in behavioral change rather than stated agreement.