Fable
The city's bridge repair crews finally no longer each had to build their own carpenter's shop
The mountain city had more than a dozen bridge repair crews. Each crew had to build its own scaffolding, buy ropes, write acceptance books and find night watchmen, so actually repairing the bridge took only half their effort.
At first, everyone called this professional freedom. But as there were more and more bridges, accidents also became more alike: permissions were opened carelessly, releases relied on verbal instructions, no one knew how to roll back, and incident records were scattered in personal notebooks.
The city lord first issued a thick manual. The manual was very comprehensive, but at kickoff they still had to build the environment from scratch, and the team was merely repeating old mistakes more slowly.
He also established an approval office. Every bridge queued up for experts to review it. Quality improved a little, but speed was blocked. Engineers began to take detours, and safety rules moved even farther from the site.
Later the city built a public works platform. Common bridge types had templates, scaffolding could be claimed with one click, and permissions, monitoring, release, rollback and post-incident records all came with default configurations.
The bridge repair teams could still do their own designs, but no longer had to repeatedly solve the basic problems common to every bridge. The works desk also looked at which step was slowest and which types of accidents recurred, then built good practices into the default path. The mountain city finally turned reliable delivery into a foundation that teams could use on their own.
At first some complained that the public works platform would turn every team into the same bridge-building method. The platform team did not force all bridges to look alike; it only built the repetitive foundations—scaffolding, acceptance, rollback, and night watch.
The best changes happened after accidents. When a certain bridge had a problem, the platform team turned the lesson into a default configuration, and the next team naturally inherited it when starting work. The mountain city's experience no longer spread through meetings, but sank into the tools. Later, when newcomers were onboarding, the veteran masters no longer first talked about abstract categories, but had them review that failure: where intuition had originally been relied on, why the first patch 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 continue using it and when to upgrade it, were they considered to truly understand this approach. Later they also had newcomers practice this approach: first let the newcomers do it the old way and see how errors appeared; then redo it under the new rules and see which step was blocked in advance and which step left evidence. If newcomers could only recite names, they would still misuse it in similar scenarios; only those who could state the applicable boundaries, the costs, and the remedies after failure were allowed to take on work independently.