Simpleris Friday Fix blog tile: When Standards Slip illustrated as a team operating with an assumed standard producing variable quality, becoming a team following a written verified standard with consistent output.

When Standards Slip, Systems Were Never Clear

July 16, 20264 min read

Custom HTML/CSS/JavaScript

Output drops. The quality that used to come off the line at a consistent level is suddenly variable. Some batches are right. Others are not, and not in the same way. When you investigate, two operators are doing the same job differently, and neither version fully matches the written procedure. One says that is how they were trained. The other says the procedure changed at some point and nobody told them. Both are probably right. Standards slipped because they were never precise enough to hold their shape across the team and over time.

Pain: Quality dropped and the team cannot agree on what the standard actually is.

Quality problems rarely start with people choosing to work to a lower standard. They start with a standard that was never written with enough precision to produce the same result regardless of who follows it, or when. In a small manufacturing business, quality standards are often defined in broad terms: the product needs to meet the spec, the process needs to follow the procedure. But the gap between "follow the procedure" and "follow this exact sequence, checking these exact points, to these exact tolerances, in this order" is wide enough for significant variation to develop without anyone noticing. That variation accumulates across shifts, across weeks, and across the team until a customer flags it, a defect escapes the line, or an audit reveals a gap between what the procedure says and what people are actually doing.

The root cause is almost never non-compliance in the deliberate sense. It is ambiguity. When a standard is not written with enough specificity to constrain interpretation, different team members make different reasonable judgements. Those judgements drift over time as each person adapts the task to their own habits and experience. New starters learn the informal version from the person who shows them, not the written version, because the informal version is what the team actually uses day to day. The gap between the documented standard and the working standard widens gradually, without anyone setting out to widen it. This is process consistency risk at its most damaging: by the time it shows up in variable output or a customer complaint, the underlying drift has usually been building for months.

The hardest part to accept is the timing. By the time variable output becomes visible in customer complaints or a failed inspection, the drift has usually been building for six months or more. The informal version of the standard has already embedded itself into how the team works day to day. It is not the written procedure they are following. It is the version they were shown, adapted over time by their own judgement, that has become the actual operating standard on the floor. Closing that gap means closing two gaps simultaneously: updating the written procedure to reflect what it should say, and verifying that what the team does actually matches the updated version. If you only close one of the two, the drift continues on the dimension you did not address.

Fix: Write the standard down and verify the team is working to it.

The fix has two parts, and both need to happen. First, the standard needs to be written with enough specificity that two different operators following it independently produce the same result. Not a policy-level statement of intent, and not a procedure that describes the what without specifying the how. A step-by-step sequence with clear checkpoints, defined tolerances where relevant, and an explicit description of what acceptable output looks like versus what requires rework or rejection. If the current procedure does not meet this test, it needs to be updated before it is enforced. The update does not need to be formal or lengthy. It needs to be specific enough to remove interpretation from the critical steps. That is all. A procedure that closes the gap between the written standard and the working standard is the version that protects quality.

Second, once the updated standard exists, verify that the team is actually working to it. Not as a disciplinary exercise, but as a calibration check: you are testing whether the standard is fit for purpose and whether it has been communicated clearly enough to be followed consistently. Walk one operator through the updated procedure. Watch where they hesitate or adapt. Each hesitation point is a gap in the specification. Close the gap in the document before the next shift uses it. The combination of a specific written standard and a verification check stops the drift before it reaches the customer. Quality that depends on the right people being present on the right day is not a quality system. Quality that follows from a clear, verified, shared written standard is.

Where did standards slip for you this week?

Custom HTML/CSS/JavaScript

This post is part of the Friday Fix series, a weekly operational fix for UK manufacturing and engineering business owners.

Process ConsistencyQuality Standards
Martin Cable
I help founders of scaling tech and manufacturing SMEs identify and reduce the operational risk that quietly stalls growth. I specialise in turning individual heroics into resilient, predictable systems, so the business depends on how it works, not on who is in the room. My mission is to help leaders build businesses that run with precision, giving them the freedom to lead the future rather than managing the day-to-day.
Back to Blog