Fable
Break a bridge down into acceptance-testable wooden piles
A bridge was to be built across the river. In the past, when the old carpenter took on a job, he simply said the bridge would be delivered in three months, and everyone trusted him.
This time the bridge had to carry horse carts, pedestrians, and night patrols, and also avoid the flood season. A single order to "build a bridge" became too big, and no one could see where the risks were hidden.
The city lord first urged the carpenter to work harder. The carpenter called in more people, but some measured the river's width, some bought timber, and some had already driven piles—and the dimensions did not match each other.
He then divided the tasks evenly among ten groups. Every group was busy, but in the end the railing team couldn't get the bridge deck, the bridge deck team couldn't get the load-bearing drawings, and the warehouse bought the wrong timber.
After the flood washed away the half-finished work, the carpenter stopped work for three days and did only one thing: break the entire bridge into surveying, design, procurement, piling, decking, acceptance, and maintenance. Each segment clearly stated inputs, outputs, dependencies, owners, and failure conditions.
What could be parallelized was parallelized; what had to wait waited; high-risk nodes were first tested with small samples. The bridge was later completed on schedule, not because people suddenly worked harder, but because everyone knew how the pile they delivered supported the next plank.
After breaking down the tasks, the carpenter also drew dependency lines. Without measurement, the design could not be finalized; without timber, piling could not begin; without written acceptance criteria, the paving crew would not know how completion was counted.
When the city lord first saw it, he urged that urgency cannot replace structure. Breaking big work into small pieces is not slicing responsibility apart, but making each segment deliverable, checkable, and connectable to the next. The bridge's stability first comes from the stability of the tasks. Later, when newcomers started, the old masters no longer began with abstract labels, but had them review that failure: where intuition had originally been relied on, why the first repair was not enough, and how the new arrangement kept risk in a place that could be checked. Only when they could explain these details clearly, and also point out when to keep using the approach and when to upgrade it, were they considered to truly understand this method. Later they also used this method in drills for newcomers: first have the newcomers do it the old way and see how errors appear; then redo it under the new rules and see which step is blocked earlier and which step leaves evidence. If newcomers can only recite names, they will still misuse it in similar scenarios; only those who can state the applicable boundaries, costs, and remedies after failure are allowed to take on work independently. This checkpoint cannot be skipped. It must also be verified on site. Then handed to someone else for review. Only then can you feel at ease.