Fable
The public works hall turns start-work procedures into a self-service counter
Every time an engineering team in the mountain city started a new project, they had to separately go to the warehouse for materials, the guard for permissions, the accountant for cost registration and the night watchman for monitoring.
The old team knew the ropes, but new teams often got stuck for half a month. Someone missed an alert, someone forgot to set a rollback, someone brought test keys onto the live site.
The city lord first set up a unified mailbox. All requests went to the mailbox and were then handled manually by the platform team. The teams no longer had to run around, but the platform team became the new bottleneck.
The platform team wrote many more scripts, scattered across different repositories. Those who knew how to use them were fast; those who didn't still had to ask the old team lead, and knowledge continued to pass by word of mouth.
Later, they built an engineering services hall. Engineering teams could create services, choose templates, request permissions, view dependencies, connect monitoring, and publish and roll back from a single entry point.
Behind the hall, many systems were still being called, but to the user it appeared as one standard path. Complex details were encapsulated, and key constraints became default options. The engineering team also gained clear boundaries for choice. Simple services could start on their own; special compliance projects could still go to the platform team for review. The hall's value wasn't in making decisions for everyone, but in turning most repetitive procedures into reliable defaults.
The platform team also maintained a service catalog. Who was responsible for which bridge, which dependencies were used, where costs were attributed, and current health could all be looked up. The platform team did not treat the hall as a one-time renovation. Every month they looked at which counters were slowest, which templates were most often modified, and which permission requests were always rejected, then continued to productize the common paths.
The new team's first project no longer depended on knowing some old captain. The self-service counter turned organizational experience into repeatable product capability. The city lord understood that an internal developer platform is not a portal page, but an internal product that connects creation, deployment, observability and governance. Later the steward wrote this experience into daily rules: first look at the scenario, then the boundaries, and finally who can take over when it fails. Only when all of these are clear will a beautiful demo become deliverable work.