Honest Take — Module 10: Workshops, Courses & Curriculum-Scale Architecture #

Curriculum design is harder than engineers think it is, and the evidence is the same everywhere: the first workshop every engineer builds is "ten blog posts in a row." Nobody retains anything, the feedback survey says "great content!", and the engineer concludes workshops are intrinsically lossy. They aren't. The workshop was just designed forward — "here are the things I know about X, sequenced" — and the sum of covered topics almost never equals competence.

M3 gave you the fix at artifact scale; this module applies it at session and system scale, and the most unpopular mechanical rule is the one that does the most work: design the workshop so the participants are doing something for at least half the time. Hands on keyboards, pen on paper, voices in small groups. Engineers fall into watch-me-do-the-thing constantly, pace the front of the room for three hours about a topic they love, feel great afterward, and the participants retain ten percent. A workshop where you talk for half the time you wanted to is not a compromised workshop. It is the first real one you've run.

The second contrarian point: most workshops are too long. The default tech-conference duration — three hours, or a full day — is wrong for almost every topic. Three hours is enough to teach one substantial thing well, with practice; a full day is enough for two or three. The instinct is to fill the slot; the result is four things taught badly instead of one taught durably. Cut, then keep the leftover time as breathing room and let people leave early or stay and ask questions. And steal the minute paper from Lang without modification: sixty seconds at the end of each segment for every participant to write the most important thing they learned and the question they still have. It costs nothing, forces retrieval, and tells you immediately which concept you only think you taught.

Then the architecture layer, which is where this module earns its "hard" rating. A workshop is an interactive system; a course is a stateful one — a concept referenced in week 4 must have been written in week 1 and retrieved in weeks 2-3 to still be live, or by week 8 the course is a leaky bucket and the learner blames themselves. And if you operate anything at multi-course scale — a course platform you built, a curriculum collection, even a long-running internal training path — the architecture document will surface something specific and uncomfortable: the thing grew, it was not designed. Courses accumulated organically across sprints of "let's add one on X next." That is not a moral failing; it is the default growth pattern of any content system shipped under product pressure. The honest move is to draw the dependency graph and ask the system-design questions you would ask of any production architecture: which units depend on which prerequisites, where does near-duplicate content exist because there was no shared layer, does the graph have cycles or orphans, what entry ramp and exit capability does the path actually imply?

My prediction about your reaction to that diagnosis: the full-redesign fantasy. Every course re-architected, the graph cleaned, all assessments rebuilt per M3. That fantasy is months-to-years of work, it would freeze the catalog while losing the momentum the existing content generates, and you will not do it — nor should you. The operational move is backwards-compatible architecture: leave the existing catalog in place, retrofit the few units with the highest traffic or commercial weight, and architect everything new against the document from day one. The consolation is real: curriculum architecture is just system design applied to learning paths — modules are services, prerequisites are call graphs, checkpoints are SLOs, time estimates are capacity planning — and you already have years of that skill. You simply hadn't seen your teaching as a system.

One more thing, because it hides in the estimates row: a curriculum that says "10 hours" and takes 30 doesn't get completed, it gets abandoned, and the learner concludes they failed. Sandbagged estimates are an ethics problem wearing a planning costume.

Conclusion #

A workshop teaches a sequence; a course teaches a system; and the discipline that makes either work was worked out by educators decades ago and can be learned at the 90% level in weeks. Backward-design the session, make participants do things half the time, keep retrieval flowing across weeks, draw the dependency graph honestly, and refuse the full-redesign fantasy in favor of architecting what comes next. The test for the architecture document is the same as for any good runbook: could a stranger navigate the system using only the document?

Predictions #

Your first outcome sentence for the workshop will be too vague — "understand X" instead of a verb a stranger could observe. The sharpening will take several passes; it is the practice, not a prelude to it.
On delivery you will discover you still budgeted too much content despite cutting. Have a section you can drop without harm, and drop it without apology.
The minute paper will reveal that one concept you were sure you taught well was missed by half the room. Re-teaching it will sting and work.
If you operate a multi-course catalog, the dependency graph will surface at least one orphan unit that connects to no path and at least one near-duplicate. Flag them as content-debt; don't start deleting in the same sitting.
The full-redesign fantasy will visit you within an hour of finishing the graph. Refuse it; architect the next few units instead, and let the contrast become the argument.
One participant per workshop will ask a question you cannot answer. "I don't know — let me check and get back to you," followed by actually doing so, will build more credibility than a confident wrong answer ever could.
Within six months, one thing you build from scratch against the architecture document will produce measurably better learner outcomes than your organically-grown material, and that comparison will convert you more thoroughly than this file can.