The Hidden Cost of Working With People and Systems That Lack Integrity
A small failure can create a surprisingly large operating cost.
A supplier misses a delivery. A spreadsheet contains one wrong assumption. A manager gives a date that nobody has checked. A software service fails intermittently. A colleague routinely arrives late to a handoff.
The visible problem is usually easy to name.
The harder part is everything that happens around it.
Someone has to check again. Another team adds a buffer. A customer asks for confirmation. A meeting gets moved. A second system is built to monitor the first one. People keep private notes because the shared record is not trusted. Decisions slow down because nobody is sure which information can be relied on.
The 2010 seminar materials collected under A New Model of Integrity: The Missing Factor of Production use the language of integrity to describe this loss of wholeness and workability. The source applies the idea not only to people but also to objects and systems. A wheel with missing spokes does not merely have a moral problem. It becomes less workable.
That distinction is useful in organizations because it shifts attention away from blame and toward propagation.
The operational question is not simply:
Who failed?
It is:
What extra work did this unreliability create everywhere else?
Reliability is part of other people's infrastructure
When a commitment, process, or system is dependable, other people build around it.
A team schedules the next step because a handoff is expected on Tuesday.
Finance closes a forecast because a data feed is assumed to be accurate.
A customer stops looking for alternatives because a delivery date has been confirmed.
An employee submits information once because the system is expected to retain it.
Reliability therefore becomes part of the surrounding infrastructure.
When it fails, the cost is not confined to the original task. Everyone who organized around it must absorb the disruption.
That can produce:
- waiting;
- duplicated checking;
- rescheduling;
- contingency work;
- additional communication;
- re-entry of information;
- defensive documentation;
- lost decision time;
- reduced willingness to delegate.
None of these may appear in the original incident report.
The supplier was one day late.
The file contained one wrong number.
The API was unavailable for twenty minutes.
But the real cost includes the behavior the failure forced into the rest of the system.
Unreliability creates coordination tax
Consider two teams that exchange work every week.
In the first case, the handoff arrives when promised, in the agreed format, with known exceptions clearly marked.
The receiving team can begin.
In the second case, the handoff is usually close to the agreed time, but not always. Fields are sometimes missing. A message occasionally arrives later explaining that one section should be ignored.
The second team adapts.
Someone checks whether the file is final.
Another person keeps the previous version in case the new one is incomplete.
A manager waits before assigning downstream work.
People start sending confirmation messages that would be unnecessary in the first system.
This is a coordination tax.
No one decided to create it.
It emerged because the original handoff could not safely be treated as complete.
Over time, the tax can become so familiar that it stops being recognized as a consequence of unreliability. It becomes simply the way work is done.
The cost appears as caution elsewhere
People learn from systems.
If a shared calendar is inaccurate, people stop trusting it.
If status updates repeatedly hide risk until the deadline, managers begin asking for more frequent updates.
If a vendor's dates are unreliable, purchasing begins ordering earlier than necessary.
If a colleague regularly forgets requests, others start copying more people into messages.
Each response may be rational.
Yet every response consumes attention, time, or flexibility.
This is why a lack of integrity can spread without anyone copying the original behavior. One unreliable element causes otherwise careful people to become more defensive.
A team may look bureaucratic when the deeper problem is that its environment taught people not to rely on the simple path.
Buffers can hide the original problem
Redundancy is often good engineering.
Critical systems need backups. Important processes need checks. High-risk decisions should not depend on one unverified input.
The problem is different when buffers accumulate only because a basic commitment has become unreliable.
A five-minute task gets a two-day deadline because nobody trusts the handoff.
Three people approve something because one approval was historically inconsistent.
Teams maintain parallel spreadsheets because the authoritative system cannot be trusted.
Customers call to confirm information that should already be clear.
These adaptations can keep work moving, but they also conceal the source of the extra cost.
The organization begins optimizing the workaround instead of repairing the failure that made the workaround necessary.
A useful diagnostic question is:
If the underlying component were completely reliable, which of these surrounding activities would no longer be needed?
That identifies the cost of unworkability more clearly than the original failure alone.
Association transfers risk
The source makes a broader point: dealing with an out-of-integrity object, person, or organization can impose costs on those around it.
That is not a reason to label people as bad or permanently untrustworthy.
It is a reason to understand dependency.
If one team's promise becomes an input to another team's promise, the second team inherits some of the first team's reliability risk.
If a business represents a partner's information to customers, it may inherit the consequences of inaccurate partner data.
If a manager repeatedly accepts unsupported forecasts, the manager's own commitments may become unreliable even when the original numbers were produced elsewhere.
Association creates operational exposure.
That exposure can be managed without moralising it.
The relevant questions are practical:
- What are we relying on?
- How reliable has it actually been?
- What happens downstream when it fails?
- Which commitments of our own depend on it?
- What boundary or verification is proportionate to the risk?
Not every failure requires distrust
A reliable system can still fail.
Machines break. People get sick. New information appears. A good process can encounter an unusual condition.
The distinction is not between perfection and failure.
It is between a failure that is surfaced and repaired, and a pattern that requires everyone else to compensate without clarity.
A one-off breakdown that is communicated quickly may produce less long-term cost than a small recurring defect that nobody owns.
The same principle appears in [When a Broken Promise Is Not the Same as Broken Integrity](/post/when-a-broken-promise-is-not-the-same-as-broken-integrity/): a missed result and the integrity surrounding that result are not identical.
For systems, the question becomes whether the breakdown is made visible enough for the surrounding network to respond intelligently.
Trace the propagation, not only the incident
When something unreliable causes a problem, an incident review can stop too early.
The immediate event matters, but four additional questions reveal the wider cost.
What relied on this?
List the people, systems, customers, decisions, and deadlines that treated the failed element as dependable.
What compensating work appeared?
Look for rechecking, waiting, duplicate records, additional approvals, buffers, escalations, and manual follow-up.
What commitments became harder to keep?
A failure often moves outward. The receiving team may now miss its own date. A customer-facing promise may become uncertain. A manager may lose confidence in a forecast.
What would restore simple reliance?
Sometimes the answer is a technical repair.
Sometimes it is a clearer commitment.
Sometimes the dependency needs redundancy.
Sometimes the right action is to stop promising what the system cannot reliably deliver.
The goal is not to eliminate every safeguard. It is to distinguish safeguards required by genuine risk from safeguards created by avoidable unreliability.
Workability is an economic resource
Organizations often measure direct costs well.
They can count refunds, downtime, overtime, replacement parts, or penalties.
They are less likely to measure the value of a process that simply works.
A dependable process lets people move without repeatedly checking whether the ground is still there.
That frees attention for judgment, creation, service, and improvement.
The benefit of integrity in this operational sense is therefore not abstract virtue.
It is reduced friction.
It is fewer hidden loops around ordinary work.
It is the ability to treat a commitment, system, or handoff as a usable input rather than as a question that must be reopened every time.
The next time an unreliable component creates trouble, look beyond the defect itself.
Trace the caution, delay, duplication, and defensive work that spread around it.
The largest cost may not be where the failure began.
It may be everywhere else that had to stop trusting the simple path.