Start from a question, not from the system

A real system — an engine, a supply chain, a government — contains thousands of parts. You cannot teach thousands of parts, and you do not need to. What you can teach is an answer to one question. "How does fuel become motion?" "Where does the money go?" "Why does the queue build up?"

The moment you have a question, simplification stops being lossy and starts being targeted. Every part that does not help answer your question is not being cut; it is simply not part of the answer. Write the question at the top of the page. It becomes the test every later decision has to pass.

Find the backbone

Inside any system there is one primary route that carries the thing you care about from start to finish — the fuel, the signal, the resource, the order. That route is the backbone, and it should be the only path in the first version of your model.

Secondary loops, backup routes and feedback paths are real and important, but they are the second lesson, not the first. Draw them later, once the reader can already trace the main flow without help. A model with one clear path teaches; a model with seven intertwining paths confuses.

From the real system to a teaching model Real system · many parts Teaching model · one backbone A B C D Five parts, one direction, nothing else competing for attention. Cut what does not answer the question; keep the route that does.
Figure 1 — The same system, twice. The left is faithful and unteachable; the right keeps only the backbone. The question decides what survives.

Give yourself a budget

The most effective constraint is a hard cap on parts. Pick a number — five is a good default, seven the absolute ceiling — and refuse to exceed it. A budget forces real choices: if a new part must go in, an old one has to come out, and you have to argue for it.

Keep

  • Parts on the primary route
  • The one driver that makes it move
  • Inputs the reader already knows
  • Anything named in your question

Cut (for now)

  • Backup and failsafe routes
  • Edge cases and rare inputs
  • Control systems and tuning loops
  • Parts whose role is "support"

Name what you left out

A teaching model is honest when it says so. A short "what this leaves out" line, or a single sentence in the caption, tells the reader the map is deliberately partial. It also protects you: nobody mistakes a five-box explainer for engineering guidance.

The cut parts are not wasted, either. They are the sequel — the natural subjects for a second diagram that zooms into a subsystem once the reader has the backbone in their head. Simplification is a plan for teaching in order, not a permanent reduction.

Test the model by teaching back

Hand the diagram to someone who does not know the system and ask them to explain the process from it. Every place they stall marks a missing part or an unclear flow; every question they cannot answer marks something you simplified away too aggressively. Fix the stalls, and note the rest as the next lesson.

Bottom line: simplify to a question, keep one backbone, cap the parts, and say what you cut. That is the whole method, and it works as well for a pump as it does for a payroll.