Building a coordination system that survives the people who built it

Most teams do have a documented process. It is usually a folder of checklists written by whoever was most organized at the time, and it usually fails the only test that matters.

The test: can somebody who did not build it run a file with it, cold, without asking the author a question.

Why most documentation fails that test

Because it was written by an expert, for themselves, as a memory aid. Expert documentation has predictable holes:

• Steps whose order matters, presented as a list. The author knows the resale package goes first. The reader sees item seven of twelve.
• Conditional items presented as unconditional, or omitted because "obviously that only applies sometimes"
• Judgment encoded as a verb. "Follow up with the lender" contains the entire skill and communicates none of it
• No lead times. The single most valuable fact about any item is how long it takes, and it is almost never written down

The result reads as complete and is unusable by a newcomer, which is exactly the population it was written for.

Documentation written by an expert for themselves is a memory aid. Documentation that works is written for the person who has never seen this before and is slightly panicking.

The four properties

Ordered by dependency, not by category. Group by what has to happen before what, and put the long-lead items at the top regardless of how minor they look. An item that takes fourteen days outranks an item that takes an hour, even when the hour-long item feels more important.

Lead times stated. Every waiting item carries its expected duration. Resale certificate, ten to fourteen days. Association package request in Virginia, within three days of ratification. Closing Disclosure, three business days before signing. These are the numbers that let someone plan rather than react.

Conditions made explicit. "Lead paint disclosure, required if built before 1978" rather than "lead paint disclosure." The condition is the part that prevents the silent omission, and the silent omission is the failure mode conditional items have.

Jurisdiction-scoped. One process per county plus transaction type, not one process for "Maryland." Montgomery and Prince George's genuinely differ, and a merged checklist is wrong for both.

Owners, not roles

Every step names a person, and reassignment is an action taken in the system rather than a sentence said in a hallway.

"The team handles the resale certificate" is how certificates get ordered eleven days late. Two owners is zero owners. If two people genuinely need to act, it is two steps.

Keeping it alive

Documentation rots, and calendar reminders to review it produce reviews nobody acts on. Attach maintenance to the events that actually make it stale:

• A jurisdiction changes a requirement. Update that county's process the same week
• A form is revised. Update the step that references it
• A file slips. Run a short post-mortem and change the process, not the person. If the process did not cause it, say so and change nothing, which is also a valid outcome

That third trigger is the important one. Most teams respond to a slipped file with a conversation and no structural change, which means the same failure is available to the next person.

The handover test, run deliberately

Once a quarter, have someone run a file they did not open, using only the documented process. Not as an audit of the person, as an audit of the document.

Every question they have to ask is a defect. Write down the question, fix the document, move on. It takes an hour and it is the only reliable way to find out whether you have a system or a collection of one person's habits with a shared folder around them.