Earlier in my career, I spent time working in manufacturing and distribution environments, including Sara Lee and Chock full o’Nuts.
Technology looked very different then. We were working with platforms such as Sybase and JD Edwards World and OneWorld, and I was involved with organizations working through ISO 9000, ISO 9001, and many other quality standards.
But one of the most important lessons I took from that period had very little to do with the technology itself.
Quality had to be verified.
It wasn’t enough to say something had been built, configured, packaged, entered, processed, or shipped correctly. There were processes designed to make sure it actually was correct.
Later, when I worked in the pharmaceutical industry, that principle became even more apparent.
There were controls around temperature, storage, handling, controlled substances, regulatory requirements, documentation, access, and countless other areas. The consequences of getting something wrong could extend far beyond an unhappy customer.
Different industry. Different risks. Same fundamental principle:
Don’t simply assume the process worked. Verify it.
The Value of the Second Set of Eyes
I’ve carried that lesson with me throughout my career.
Whether we’re manufacturing a product, handling pharmaceuticals, configuring a firewall, deploying software, changing a security policy, building an application, processing an order, or implementing a new business system, there should be some mechanism for asking…
Did we actually do what we intended to do?
Sometimes that’s another person.
Sometimes it’s an automated test, checklist, reconciliation, approval workflow, peer review, audit, monitoring system, or validation process.
The mechanism can change. The principle shouldn’t.
A second set of eyes isn’t there because the first person isn’t competent.
It’s there because people miss things. Processes fail. Assumptions can be wrong.
One overlooked setting can matter.
One incorrect digit can matter.
One forgotten step can matter.
One configuration checkbox can matter.
Quality Control Isn’t Just for Factories
When people hear “quality control,” they often picture a manufacturing line where someone inspects a finished product.
But QC exists, or should exist, throughout a business.
In cybersecurity, it can mean peer-reviewing a firewall rule before implementation.
In IT, it can mean validating a system after a change rather than simply confirming that the change completed successfully.
In software development, it’s code review and testing.
In finance, it’s reconciliation and approval controls.
In HR, it can be validating employee information and access during onboarding and offboarding.
In project management, it’s confirming that the delivered result actually matches the requirement.
The terminology may change… QA, QC, peer review, change control, validation, testing, governance, audit… but the underlying idea is remarkably similar.
Someone or something needs to verify the result.
“Done” and “Done Correctly” Are Not the Same Thing!
This may be the most important distinction.
We naturally measure completion.
- Was the ticket closed?
- Was the server built?
- Was the order shipped?
- Was the application deployed?
- Was the firewall changed?
- Was the customer provisioned?
- Was the project completed?
Of course, those are useful questions.
But there’s another question that matters just as much:
Was it done correctly?
There is a significant difference between completing a task and delivering the intended outcome.
Responsible organizations build that distinction into their processes.
Speed Makes Quality Control More Important, Not Less
This principle may actually matter more today than it did when I first encountered it.
Our systems are faster. Automation is everywhere. Cloud platforms allow enormous changes to be made in seconds. Infrastructure can be deployed through code. Workflows can automatically perform hundreds or thousands of actions.
And now we have AI.
AI can help write code, create configurations, analyze information, produce documentation, recommend actions, and automate work at a speed that would have been difficult to imagine earlier in my career.
That’s an incredible productivity advantage.
But there’s another side to it.
Speed also allows mistakes to travel faster.
An incorrect manual process might affect one transaction. Automate that same process incorrectly and it could affect thousands.
A developer can make a mistake in a few lines of code. AI can help generate hundreds of lines in seconds, but those lines still need to be reviewed and tested.
An AI-generated answer can sound extremely confident and professional while still containing an incorrect assumption.
The lesson isn’t that automation or AI should be avoided. Quite the opposite.
It’s that the more we accelerate the work, the more important validation becomes.
AI doesn’t eliminate quality control.
In many ways, it makes good quality control even more valuable.
The Cost of Skipping QC
Quality control sometimes gets viewed as additional overhead.
Another approval. Another person involved. Another test. Another delay before something can be considered complete.
But what’s the cost of not catching the mistake?
- It might be rework.
- It might be downtime.
- It might be a security incident.
- It might be a compliance finding.
- It might be a defective product.
- It might be a lost customer.
- It might even lead to litigation.
And sometimes the biggest cost is simply the customer’s impression of your organization.
Customers generally don’t see all the processes behind what we do.
They see the result.
If something arrives incorrectly, doesn’t work, exposes their information, causes an outage, or forces them to call multiple times to get something corrected, that’s their experience with your company.
And ultimately, quality control is part of customer experience.
An Old Principle That Still Works
Technology has changed tremendously since my days working with Sybase and JD Edwards.
The tools will continue to change.
AI will get better. Automation will increase. Systems will become faster. We’ll find new ways to accomplish more with fewer manual steps.
But I don’t think the fundamental principle changes.
Build it. Configure it. Implement it. Automate it. Improve it.
But verify it.
Because the goal shouldn’t simply be to get something done.
The goal should be to get it done correctly, consistently, safely, and in a way that ultimately delivers the best possible experience for the customer.
Sometimes all it takes to make that difference is one process, one validation step, or one additional set of eyes.
