The Safe Way Has to Become the Easy Way

When I first started working in my father's medical practice, we were a small team.

There were maybe five to eight people working closely together. At that size, an enormous amount of information could live between people rather than inside a system.

Someone knew the patient had called.

Someone remembered that the schedule had changed.

Someone could walk across the office and ask a question.

If something unusual happened, there was a good chance the person who knew the story was sitting twenty feet away.

Then we built a larger building and grew quickly. Eight employees became thirty and eventually around fifty. People were spread across different parts of the practice. Roles became more specialized. Employees turned over. The person receiving information was increasingly unlikely to be the person who ultimately needed to act on it.

The work hadn't fundamentally changed.

But the way the organization had to remember had.

What a small group could hold together through proximity, conversation and experience no longer worked at scale.

That was when I began to understand something that has followed me through almost everything I've done since:

If doing something correctly requires a person to remember to do it correctly, the system is unfinished.

Someone Knows

Consider something as ordinary as a patient changing her mind.

A patient is scheduled for surgery the next morning and calls the office to say she no longer wants an additional procedure that had been included in the plan.

The front desk answers the phone.

Now the front desk knows.

But that isn't enough.

The information needs to reach the patient coordinator. The coordinator is responsible for the quote and scheduled appointment and needs to make sure the physician's H&P reflects the revised surgical plan.

The operating room needs to know.

And when the surgeon walks into the OR the next morning and looks at the board, what is written there needs to reflect what the patient actually decided.

There can be competent people at every point in that chain and still be multiple opportunities for yesterday's reality to survive after reality has changed.

In a small organization, "someone knows" can function surprisingly well as infrastructure.

Eventually it can't.

The same problem can appear in ways that are less frightening but much more common.

A new employee allows a patient to receive thousands of dollars of injectable product before collecting payment. The treatment is completed. The patient reaches checkout. The credit card declines.

An experienced employee knows not to let that happen.

So the obvious response is to teach the new employee the rule.

And that works.

Until the next new employee.

When Training Becomes the System

As we grew, training consumed an extraordinary amount of time.

An experienced employee might accumulate hundreds of small pieces of operating knowledge: what to check, who needs to know, which situations are unusual, what has to happen before something else can happen.

Then that employee leaves.

A replacement arrives and the process begins again.

We document more. We create procedures. We train harder.

Eventually the new person becomes experienced enough to carry the same collection of rules in her head.

Then perhaps she leaves too.

And the organization discovers that although an employee learned a great deal, the organization itself didn't necessarily learn it.

That distinction matters.

A person learns when what she knows changes how she behaves.

An organization learns when what its people discover changes how the organization behaves without requiring the person who learned it to be there.

That requires more than documentation.

Knowledge has to become architecture.

The System Has to Reflect Reality

I began building software inside the practice because I kept running into pieces of this problem.

BIVI handled appointment reminders and allowed patients to complete paperwork, update demographic information and sign consents electronically before procedures.

These weren't revolutionary ideas.

They were simply cases where asking the system to do something reliably was better than repeatedly asking people to remember.

An appointment reminder shouldn't depend on whether somebody remembered to make a call that afternoon.

A demographic update shouldn't remain on a piece of paper waiting for someone to reenter it.

A required consent shouldn't become a surprise when the patient arrives for a procedure.

BIVI solved pieces of the problem.

It did not solve the larger problem. I don't think I fully understood the larger problem yet.

What I was beginning to understand was that the system had to reflect reality.

And when reality changed, that change had to survive the journey to wherever the next decision would be made.

That sounds obvious.

It is remarkably difficult.

A Different Kind of Memory

When I left healthcare and began investing in real estate full time, the timescale changed completely.

A relationship between a patient and a medical practice can span decades if the practice keeps up its end of the bargain and the patient remains happy.

My real estate transactions were compressed. I might spend a few weeks acquiring a property and a few months selling it. Much of the important diligence could be crammed into only a few days.

If I missed something and discovered it after closing, there was no resetting the transaction.

I owned it.

Some of my early mistakes were expensive teachers.

I bought through foreclosure without fully appreciating the difference between purchasing property as-is, where-is and acquiring it pre-foreclosure with title insurance.

I learned that a piece of land could appear cheap until I discovered it lacked city water and sewer and was too small to support a septic system. The theoretical value mattered a lot less if a prospective homebuilder couldn't practically use the property.

I learned that Google Earth could make topography look harmless until closer investigation revealed that developing the site would require substantial civil engineering.

Each deal added another variable.

But something more important happened over time.

I stopped looking only for price arbitrage and started spending much more time thinking about demand drivers.

That wasn't another item added to a checklist.

My understanding of what constituted an opportunity had changed.

Understanding Before Encoding

There is a danger in saying that everything we learn should immediately become a rule.

Sometimes the lesson is wrong.

Had I perfectly encoded my earliest understanding of real estate, I might simply have built a very efficient system for finding properties that looked cheap.

Experience taught me that cheap wasn't enough.

Title mattered.

Utilities mattered.

Topography mattered.

Buildability mattered.

Ultimately, demand mattered.

Before knowledge becomes architecture, it has to survive contact with reality.

This is why I have become interested in moving between levels of a problem.

The individual case matters because that's where reality lives. But one case can mislead you.

You have to move up a level and ask whether what happened is part of a pattern. Then sometimes you need to move back down and see whether the pattern actually explains the individual cases.

Over time, understanding improves.

And eventually you reach a point where continuing to rely on memory becomes difficult to justify.

Knowledge Has to Become Architecture

Once you understand something well enough, the question changes.

Why are we still asking someone to remember this?

If payment needs to occur before a particular service, why should the workflow make forgetting that sequence easy?

If one event cannot safely happen until another has occurred, why does the system permit the sequence to be reversed?

If changing an important piece of information affects three other parts of an organization, why are we relying on someone to remember all three?

If an unusual action requires judgment, why shouldn't the system make that action deliberate?

This isn't about eliminating human judgment.

It's about recognizing where judgment is actually valuable.

A surgeon should exercise judgment.

An investor should exercise judgment.

A patient should exercise judgment.

But nobody creates value by remembering for the thousandth time that a known prerequisite must happen before the next step.

That's not judgment.

It's cognitive overhead.

And the solution isn't always software.

Sometimes it's a checklist. Sometimes it's changing the order in which work happens. Sometimes it's eliminating an unnecessary choice. Sometimes it's making important information impossible to miss at exactly the moment it matters.

The form is secondary.

The principle is the same:

Once you understand what should happen, stop depending on people to remember to make it happen.

Remember. Understand. Encode.

I've started thinking about this as a progression.

Remember. Understand. Encode.

First, preserve what happened.

An organization that cannot remember its own experience has to keep learning the same lessons.

Then understand what happened.

Move between the individual event and the larger pattern. Be willing to discover that your first explanation was incomplete.

Then encode what you have learned.

Change the workflow. Change the constraint. Change the environment in which the decision gets made.

Make the accumulated knowledge of the organization available to the person who needs it at the moment they need it.

Then keep watching.

Because encoding changes behavior, and changed behavior produces new information. Sometimes that new information proves that your understanding was incomplete.

So you remember again.

You understand again.

You encode again.

Over time, something important happens.

Experience stops living exclusively inside the people who happened to be there when it was acquired.

It becomes part of how the organization operates.

An organization doesn't learn because somebody figured something out.

It learns when what they figured out changes how the organization behaves.

The safe way shouldn't require the most experienced employee on her best day.

It should be the easiest way through the system.