Writing policies people actually follow
Most shop documentation fails the same way: it is written to satisfy an auditor, filed, and never opened again. A document only earns its place if someone uses it to do the job right. Here is how to write the three kinds that matter so they get used, not shelved.
Policy, procedure, instruction
People use these three words interchangeably and then wonder why their documents are a mess. They are three different altitudes, and each answers a different question:
| Level | Answers | Glass example |
|---|---|---|
| Policy | What we intend, and why. Short, rarely changes. | "Every tempered lite is verified against ASTM C1048 before it leaves the shop." |
| Procedure | Who does what, in what order, across a process. | How a tempering order flows: who sets the recipe, who runs QC, who signs off, what happens on a fail. |
| Work instruction | How to do one specific task at one station. | The exact steps to run the fragmentation test: sample, break, count, weigh, record. |
The policy is the promise, the procedure is the flow, the work instruction is the hands-on detail. A common mistake is to cram all three into one giant document, which then serves none of them: too vague to work from at the bench, too detailed for anyone to read as intent. Keep them separate and let each be the right length for its job. A policy can be three sentences. A work instruction might be a single laminated card at the station.
Writing one people follow
The work instruction is where the rubber meets the glass, and it is the one most worth getting right. The difference between one that gets used and one that gets ignored is not formality, it is usability:
- Write it at the station, with the person who does the job. Not at a desk from memory. The operator knows the real steps, including the ones that never made it into the old version.
- Use the words the shop uses. If everyone calls it the zebra board, do not write "roller-wave distortion reflection template." You are writing for the person at the bench, not for a dictionary.
- Show, do not just tell. One clear photo of the correct setup beats a paragraph describing it. A photo of the reject beside the accept is worth more again.
- One task, short steps, in order. If it runs past a page for a single task, it is probably really a procedure, or it is padded. Cut it to what someone genuinely needs to do the job right.
- Make the pass or fail unambiguous. "Check the edges" invites a shrug. "No chip deeper than X, measured with the gauge" can be followed and checked. Vague acceptance is where quality quietly drifts.
A worked example
Take the tempering setup sheet, the document that captures how a given order was run. A weak version is a blank box labelled "settings" that gets filled in differently by everyone, or left blank when the shift is busy. A strong one is built so the right thing is the easy thing:
- It names the fields that matter and leaves space for the operator to enter the real values, glass type, thickness, and the actual settings used, rather than assuming a number. The person running the job knows the variables; the sheet just makes sure none get skipped.
- It ties to the check. The setup sheet and the QC record reference the same order, so months later you can connect how a batch was run to how it performed. That link is what makes a fragmentation failure investigable instead of a mystery.
- It records who and when. Not to assign blame, but because a record with no name and no timestamp cannot be trusted or traced, and traceability is the entire point of keeping it.
This is exactly why the LiteSpec tools are built the way they are: the operator enters the real values, the tool does the checking against the standard, and the output is a stamped, dated record tied to the job. A good document and a good tool are the same idea, one on paper and one on a screen.
Tempering QC LogA worked example of a setup-and-check record: you enter the real values, it verifies against the standard and stamps who, when, and the result.Version, owner, and review
A document with no owner rots. Three small disciplines keep the whole set trustworthy, and they are the difference between documentation that helps and documentation that actively misleads:
- One named owner per document. Someone whose job is to keep it current. "The team owns it" means nobody does, and it will be wrong within a year.
- A version and a date on every page. So anyone can tell at a glance whether the sheet in their hand is the current one. An out-of-date instruction being followed faithfully is worse than none, because it manufactures defects with confidence.
- A review trigger. Review on a schedule, and also whenever the process changes or a root cause analysis exposes a gap. The moment a document stops matching the floor, it needs updating or retiring, not quietly ignoring, because every ignored document teaches people that the paperwork is optional.
The goal is not a fat manual. It is a small set of living documents that genuinely describe how good work gets done here, kept current by people who use them. Everything else is filing.