Your Data Shouldn't Change When Your People Do

How organizations can turn institutional knowledge into consistent business rules.

Every organization depends on people who know things.

Not things written in a policy manual. Things they simply know.

They know which customer belongs to which division. Which expense goes to which business unit. Which event should be classified which way. Which exception applies to which employee. Which code should be used for which transaction. Which spreadsheet needs to be updated before another process can run. Which strange-looking number is actually correct.

That knowledge is valuable. Sometimes enormously valuable.

But there is a problem when the accuracy of an organization's data depends on who happens to be sitting in the chair.

Two smart people can produce two different answers

Consider a financial process where an employee receives a description of an activity and determines how it should be classified.

The employee has experience. They understand the organization. They recognize the terminology. They know the history. So they make the correct determination.

Then that employee leaves.

Someone new takes over. They're perfectly capable. They follow the same instructions. But they don't have the same institutional knowledge.

A description means something slightly different to them. They classify it differently.

Nothing about the underlying business activity changed. But the data did.

That's dangerous—not because people are unreliable, but because interpretation is inherently variable.

When business rules live primarily in people's heads, a change in people can become a change in data.

The Harlem Globetrotters problem

In one sports and entertainment organization we worked with, payroll expenses associated with events needed to be charged to the appropriate business entity.

The process depended partly on an employee reviewing the event description and determining what kind of event it was.

Someone who knew the organization and the business could interpret those descriptions easily.

Then there was turnover.

A newer employee encountered an event involving the Harlem Globetrotters.

They saw basketball. They saw an arena. And reasonably enough, without the institutional context someone else had accumulated, classified it as one of the organization's professional basketball games.

It wasn't. It was a performance.

The person wasn't careless. Given the information available, the conclusion was understandable.

The process had simply asked a human being to make a determination based on knowledge the system already should have known.

The error wasn't really a people problem. It was a process-design problem.

Ask where the truth first becomes known

This is one of the most useful questions in data work: At what point does the organization first know what this is?

In the event example, someone knew what kind of event it was when the event was created.

It was a game. A concert. A performance. A private event. Another type of activity.

That information already existed at the beginning of the process. So why were we asking someone downstream to figure it out again?

Once the event was properly classified at creation, that classification could travel with it—into scheduling, labor, payroll, accounting, and financial reporting.

The organization didn't need five people to independently interpret the same information. It needed the right information captured once, by the people who understood it, and then carried consistently through the process.

If the organization already knows something, don't make someone downstream guess it again.

Capture knowledge where it belongs

This doesn't mean removing people from decision-making. Quite the opposite.

It means using people's expertise at the point where that expertise creates the most value.

Someone knowledgeable still needs to determine: What kind of event is this?

But once that determination has been made, the organization can encode the result. The system can then consistently apply the downstream rules associated with it.

People provide judgment where judgment is needed. Systems provide consistency where consistency is needed.

Both matter.

Turn institutional knowledge into organizational knowledge

Every organization has institutional knowledge. Some of it belongs in people's heads: relationships, experience, judgment, context, nuance.

But some institutional knowledge is actually a business rule waiting to be documented.

If Janet knows, “Whenever this happens, we always do that,” we should get curious.

Why? Is that a policy? A regulatory requirement? An accounting rule? A contractual obligation? A customer preference? An operational convention? And does someone else know it?

If the answer matters to the organization, perhaps that knowledge should become something more durable: a documented rule, a system configuration, a validation, a workflow, a reference table, an automated classification, a required field, or a decision tree.

Not because Janet isn't trustworthy. Because Janet should be allowed to take a vacation.

Turnover shouldn't rewrite history

There is another problem with subjective classification. It doesn't only affect today's transaction. It affects the organization's ability to understand itself over time.

Imagine looking at five years of data. Year 1 was classified by one person. Year 2 by another. Years 3 and 4 by someone with deep institutional knowledge. Year 5 by someone new.

If each interpreted the rules slightly differently, what appears to be a business trend may actually be a classification trend.

Revenue appears to shift. Costs move between categories. Performance changes. One business unit seems more expensive. Another appears more profitable. Leadership may begin asking why.

But perhaps the business didn't change nearly as much as the way the business was coded.

Consistent data allows us to compare the organization to itself.

Good data begins upstream

Organizations often discover data problems at the end.

Finance can't reconcile something. A dashboard looks wrong. Leadership questions a report. An analyst finds inconsistent categories. Then everyone starts cleaning the data.

Sometimes that's necessary. But the better question is: Where did the inconsistency enter the process?

If we're repeatedly correcting the same type of problem downstream, perhaps the solution isn't better cleanup. Perhaps we need to move upstream.

Capture the information differently. Validate it earlier. Eliminate duplicate interpretation. Change the source. Standardize the rule. Connect the systems.

The farther incorrect information travels, the more expensive it can become.

One wrong classification may appear in a schedule, then payroll, then accounting, then a financial report, then a leadership dashboard, then perhaps a decision. At that point, we're no longer correcting a field. We're unwinding a chain.

The cheapest place to fix bad data is often before it becomes bad data.

Standardization doesn't mean eliminating judgment

Not every business decision can—or should—be reduced to an automated rule.

Some situations genuinely require expertise. Context matters. Exceptions matter. Human judgment matters.

The objective isn't to automate every decision.

It's to know which decisions actually need to be made more than once.

If something is truly situational, let knowledgeable people evaluate it.

If the organization has already established a repeatable rule, perhaps the system should apply it.

That frees people to spend their judgment where judgment is actually valuable.

Consistency is also a scalability issue

Informal knowledge can work surprisingly well in small organizations.

Everyone knows everyone. Someone can walk down the hall and ask. The person who created the process is still there. There are only fifty transactions. Exceptions are memorable.

Then the organization grows.

Now there are 500 employees. Multiple locations. New managers. More transactions. More customers. New business units. More systems. More turnover. More complexity.

The informal knowledge network starts to strain.

That's not organizational failure. It's organizational evolution.

The practices that worked beautifully at one size may simply need to mature for the next.

Growth changes how much an organization can afford to leave unwritten, unstructured, or dependent on individual memory.

Don't automate the wrong rule

Automation creates consistency. But consistency isn't automatically correctness.

If we encode the wrong business rule, technology can now apply the wrong answer perfectly and thousands of times.

Before turning institutional knowledge into system logic, understand: Why does this rule exist? Who owns it? Is it still current? What are the exceptions? What happens downstream? Who should validate it? What changes it?

Then automate.

Technology should make good organizational thinking repeatable—not fossilize a decision nobody remembers making years ago.

Documentation is part of the solution

Not every rule belongs in software. Sometimes the right solution is simply to document it.

And importantly, document why.

A field named “Event Type” is useful.

A document explaining that Event Type determines downstream labor allocation, accounting treatment, and financial reporting is considerably more useful to the person inheriting the process three years from now.

Because someday someone will ask: “Why do we even capture this?”

And if nobody knows, there is a decent chance they'll stop.

Then five years later, someone else will wonder why the financial data isn't consistent anymore.

Organizational memory needs somewhere to live.

The goal isn't to make people interchangeable

Great employees are not interchangeable.

Experience matters. Institutional knowledge matters. Relationships matter. People develop judgment that can be extraordinarily difficult to replace.

The goal is not to engineer an organization where nobody matters.

The goal is to avoid making talented people spend their value remembering rules the organization could remember for them.

Let the organization preserve the repeatable knowledge. Let people bring the knowledge that grows with experience.

Systems should preserve what the organization knows so people can focus on what the organization still needs to figure out.

A question worth asking

Think about the information your organization relies on. Then ask:

Would this data look different if a different person were doing the work? 

If the answer is yes, don't immediately assume something is wrong. Ask why.

Does the work genuinely require judgment? Are the rules unclear? Is important context missing? Does institutional knowledge live with one person? Is someone downstream recreating information already known upstream? Could the rule be documented? Could the data be captured earlier? Could the system carry the information forward? Could automation apply a decision the organization has already made?

Sometimes variation is necessary. But sometimes it's simply a signal that important organizational knowledge hasn't yet been turned into organizational infrastructure.

Your data shouldn't have to start over every time your people do.