Loading
Every factual claim in this course traces to something here, grouped by the module it serves. If you find a source that contradicts a lesson, that is worth raising with your teaching agent — the lesson should change, or it should say why it disagrees.
Stating the problem, and finding out what the ask actually meant before you commit to anything.
WhyAmazon's working-backwards discipline: write the press release and FAQ before the code, so customer value is stated in plain language and disagreements surface while they are cheap. Primary source for the framing lesson.
WhyWritten for founders interviewing customers, and the questioning discipline transfers exactly to an internal ask: what people say they want is not data, and there is a specific way of asking that gets you facts instead. Primary source for the questions lesson.
Turning an agreed problem into a proposal, and getting it through other people without the thread eating the week.
WhyThe canonical description of the practice from someone who ran it at scale. Read it for the section list, and for how bluntly it treats alternatives-considered as one of the most important parts of the document. Primary source for the design-doc lesson.
WhyThe disagree-and-commit passage in the argument it belongs to: high-velocity decision making, and making most decisions at about seventy percent of the information you wish you had. The surrounding argument is what stops disagree-and-commit being a way to overrule people. Primary source for the review-thread lesson.
WhyCommonly cited as where disagree-and-commit originates, from Grove’s insistence at Intel that people argue hard and then leave the meeting committed. Attribution rather than documentation — the Bezos letter does not credit Grove, and this course states it as the received origin, not as a sourced fact.
WhyWhy proposals get circulated for review before commitment, and the RFC / design-doc / ADR distinctions this course’s glossary pins down.
Why estimates run low in a predictable direction, and what to do about the half of the problem that has a technique.
WhyReference class forecasting: the outside view turned into a working method, validated across a very large project dataset. Read it for the two-causes distinction — optimism bias and strategic misrepresentation are different problems and only the first has a fix. Primary source for the estimate lesson.
WhyHow much estimate accuracy depends on how well-defined the work is. At initial concept an estimate can be wrong by a factor of four in either direction; the cone narrows as definition improves, which is what earns you a tighter range later.
Standing behind a plan: finding what could break it, telling people when it does, and reversing it when the evidence turns.
WhyTeams able to test, deploy and change their systems without another team moving first deliver measurably better. Usually read as architecture advice; the dependencies lesson reads it as planning advice, which turns coupling from a design preference into a schedule risk. Primary source for the dependencies lesson.
WhyThe structural version of the same argument: how team boundaries create or remove the dependencies that decide delivery speed. Named in the dependencies lesson as the fuller treatment, for when the question stops being "how do I plan around this one dependency" and becomes "why do we keep having them".
WhyAssume the project already failed, then explain why. Built on prospective hindsight, which improves people’s ability to identify causes by around 30%. Possibly paywalled; Klein wrote the method up again for free in Psychology Today as “The Pre-Mortem Method”. Primary source for the pre-mortem lesson.
WhyAnchoring and adjustment: people start from whatever initial value is available and adjust away from it insufficiently. The wheel-of-fortune demonstration is the one to sit with — a visibly random number still moved estimates, which is why knowing a proposed date is arbitrary does not protect you from it. Primary source for the delivering-the-plan lesson.
WhyWhy the 2011 Scrum Guide replaced “commit” with “forecast” for the sprint backlog: teams were being held to estimates as promises. Cited in the delivering-the-plan lesson as evidence that the forecast/commitment confusion was expensive enough for a whole framework to rename a core concept over it.
WhyWestrum’s typology as it reached engineers, via Accelerate and the DORA research, where generative culture predicts delivery performance. The claim is not that pleasant cultures do better — it is that cultures which let bad news travel do better. Primary source for the delivering-the-plan lesson.
WhyThe origin of the pathological / bureaucratic / generative distinction, from safety research in aviation and healthcare rather than from software. Note the journal was renamed BMJ Quality & Safety in 2010, so it is cited under both names.
WhyBetter than its reputation: the argument is not “do not blame people” but the second story — why an action looked correct to the person taking it, with what they knew at the time. Applied to an estimate, that is what makes the recorded number safe enough to be honest. Google codified the same approach in chapter 15 of the SRE book. Primary source for the reference-class lesson.
WhyPeople commit the most resources to a failing course of action when they are personally responsible for the consequences — which makes the author of a decision the person least likely to notice it has gone wrong. Abstract free; full text usually findable via Semantic Scholar. Primary source for the decision-reversal lesson.
WhySource of “resulting” — judging a decision by how it turned out rather than by how it was made. The separation of decision quality from outcome quality is why the decision-reversal lesson tells you not to apologise for a call that was right on the information available.
For picking up a plan that is already running and is not yours.
WhyThe fence parable from G. K. Chesterton’s 1929 book The Thing, chapter “The Drift from Domesticity”: do not clear away what you cannot explain the purpose of. It is about reform in general rather than software, which is what makes it land — an inherited plan is full of fences, and some are the visible remainder of a constraint that is still true. Primary source for the inheriting lesson.
Facts about enterprise identity that the running project depends on. All three are published by companies selling identity software — the protocol facts are checkable and hold up, the recommendations are marketing. The design-doc lesson treats telling those apart as a skill in its own right.
WhyThe split the design-doc lesson turns on: SAML and OIDC authenticate, SCIM provisions. Separate protocols, asked about separately in enterprise security questionnaires.
WhyWhy just-in-time provisioning cannot deprovision: it fires on login, so by construction it has no path for a user who stops logging in. This is the fact that disqualifies the cheapest option in the design-doc lesson.
WhyThe published per-connection price used as the buy-side number in the design-doc lesson, and the figure the decision-reversal lesson’s revisit condition is measured against. Read the tiers rather than the headline — the figure changes with volume.
Every claim on these pages links to its source. If a source looks wrong or out of date, check the resource list and tell your teaching agent — the course is meant to be corrected.