No perfect runbook - map is not territory

KMS has many runbooks for routine procedures. We source control most the runbooks so they can be peer reviewed. We also use predefined templates that are source controlled and bar raised for change management in production. Overall I want to say we have a pretty high bar on runbooks. We’d like them to be precise and up to date. But a common complaint from team members is our runbooks are out of date, inaccurate or missing certain corner cases. It seems our efforts to have perfect runbooks are all in vain. Are they? I would like to argue that runbooks are never intended to, nor can they, capture the entirety of reality. Runbooks are like maps, they are our guide in reality to get somewhere by doing something, but a map is not the territory, it is just an abstraction. The definition of an abstraction is that it has to ignore certain details to be useful. With AWS’ velocity of innovation, a runbook could be stale before it is completed. So we encourage team members to be not frustrated with imperfect runbooks. We have weekly tech talks and adhoc knowledge sharing sessions to help team members understand the context of the runbooks and the whys behind the procedures. If a runbook is not consistent with the reality they are facing… well it is an opportunity to excercise their problem solving muscles. After that, they can update the runbook with their freshly acquired understanding. But why do we stop at runbooks? If these are recurring procedures, why not automate them? “A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness.” — Alfred Korzybski, Science and Sanity