A new employee is trying to process a customer request.
She has the procedure open beside her. She follows the first few steps carefully, but what she sees on the screen does not quite match what the document says. One field asks for a code the customer never provided. Another instruction sends her to a menu she cannot find.
After twenty minutes, she asks an experienced colleague for help.
He looks at the screen and immediately knows what to do.
“Ah, don’t follow that part. Click here first. Use this code. Then send the file to Carlo. If that warning appears, just ignore it.”
Thirty seconds later, the request is moving again.
Everyone returns to work.
The new employee has learned something useful. The experienced colleague has once again demonstrated why people depend on him.
Problem solved.
Problem preserved.
Because tomorrow another person can encounter exactly the same confusion and need exactly the same rescue.
Workarounds can become part of the culture
Almost every workplace develops workarounds.
There is the actual procedure and the way experienced people know it really works.
There is the official folder structure and the shortcut everyone secretly uses.
There is the approval process on paper and the person you message because that is the only way anything moves.
Some workarounds are clever. They emerge because people closest to the work notice something the formal system missed. Without those adaptations, the organization might move much more slowly.
The problem is not that people find better ways to work.
The problem begins when useful knowledge remains trapped in the workaround and every new person has to rediscover it.
The experienced employee stops noticing the inconvenience because he already knows what to do. The five extra clicks feel normal. The confusing label no longer confuses him. He knows which instruction is outdated and which person to call.
Experience has removed the friction for him.
It has not removed the friction from the work.
Familiar friction stops looking broken
Human beings are remarkably good at adapting.
If a form asks for information nobody uses, people learn what to enter. If an approval path is unclear, employees learn who really makes the decision. If the file system is confusing, veterans memorize where things are.
Eventually, those adaptations become part of what it means to be experienced.
“Don’t worry. You’ll get used to it.”
Sometimes that is true because the work itself is complicated and mastery takes time.
But sometimes “you’ll get used to it” means:
You will eventually memorize enough hidden knowledge to survive a poorly designed part of the system.
Those are not the same thing.
One of the best times to see this is when someone new arrives.
A new employee hesitates where experienced people no longer hesitate. A customer asks the question employees stopped realizing was unclear. Someone from another department cannot follow a process everyone inside the team considers obvious.
Our instinct can be to blame the person.
“They need more training.”
“They didn’t read the instructions.”
“Everyone else knows how to do this.”
Maybe.
Or perhaps the new person has revealed a piece of friction everybody else has simply learned to tolerate.
Familiar friction stops looking broken to people who have learned how to survive it.
Ask what the person had to know that the system did not tell them
Return to the new employee from the opening.
The experienced colleague knew four things she did not know.
The written instruction was outdated.
The customer code should be entered a certain way.
The warning message could safely be ignored.
And Carlo was the person who needed the file next.
The solution took thirty seconds because all four answers already existed in somebody’s memory.
That gives us a useful question:
What did this person have to know that the system did not tell them?
That question can expose hidden work almost anywhere.
Why does everyone keep asking which template to use?
Why do customers call after receiving the same message?
Why does every new supervisor ask the same question about approvals?
Why does this report always need somebody to explain it before managers can use it?
Why does one employee receive ten messages a day about something that appears to be a standard process?
Do not assume the answer is always “fix the system.”
First understand what the repeated question is telling you.
A workaround is evidence
A workaround tells you that people encountered a gap between the formal work and the real work.
That gap deserves attention.
Sometimes the workaround is better than the original process. Frontline employees discovered a faster or clearer move because they deal with the situation every day. If the workaround produces a better result without creating unacceptable risk, perhaps the system should learn from it.
Sometimes the workaround exists because people do not understand why an awkward step is necessary. A safety check, compliance requirement, or financial control may feel like unnecessary friction until you understand what can happen when it disappears.
Removing that step casually could make the system easier and worse.
And sometimes the workaround is simply compensation for poor design. People are spending time, attention, and memory on something that could reasonably have been made clearer.
The useful question is therefore not:
How do we eliminate all workarounds?
It is:
What is this workaround teaching us about the work?
That keeps improvement connected to reality rather than fashion.
Do not make the next person learn the same secret
When repeated friction is genuinely unnecessary, ask a second question:
Can what people currently carry in memory be moved into the work itself?
Sometimes the change is embarrassingly small.
Rename the field.
Update the instruction.
Put the final template where people actually look for it.
Add one example showing what acceptable work looks like.
Move the decision rule beside the moment when somebody needs to decide.
Remove a redundant approval that no longer protects anything useful.
Create a visual cue so people do not need to remember the same exception every time.
Make the owner visible.
Not every improvement requires software development, consultants, a process-mapping workshop, or executive sponsorship.
Sometimes contribution means noticing that twenty people are repeatedly losing three minutes to the same unnecessary confusion—and removing it.
You do not have to transform the organization.
You can leave one recurring moment better than you found it.
Do not make the system heavier while trying to make it easier
There is an irony in process improvement.
A problem appears.
Someone creates a form.
Another problem appears.
Someone adds another approval.
A mistake happens.
Someone adds a checklist, mandatory field, confirmation email, tracking sheet, and weekly report.
Every addition made sense when it was created.
Five years later, people are performing twenty steps to prevent three problems nobody remembers.
That does not mean controls are bad.
It means improvement can easily become accumulation.
So when you encounter friction, do not automatically ask what should be added.
Ask what is actually causing the difficulty.
Sometimes you need a clearer cue.
Sometimes you need a better rule.
Sometimes you need to remove something.
The goal is not to make the process look more managed.
It is to make the right move easier to perform without weakening what genuinely needs protection.
You may see the problem without having authority to fix it
This is common.
You work inside a process every day and can see exactly where people get stuck. But the system belongs to another department. The form is controlled by headquarters. The policy is regulated. The software requires technical changes you cannot make.
Seeing the problem does not give you permission to change everything.
It also does not make your observation useless.
You can collect the repeated cases.
Instead of saying, “This process is terrible,” show what happens.
“Eight of the last ten new employees asked the same question at this step.”
“Customers called 23 times this month because the message does not explain what happens after approval.”
“Every request requires someone to message Carla privately because the formal workflow does not identify an owner.”
Now the friction has a shape.
You can propose a bounded change.
You can test something inside your authority.
You can bring the person who does have authority a clearer problem and a practical option.
This is the same kind of responsible initiative explored in Turn Assigned Tasks Into Visible Value. You do not have to own the whole system to improve the part of reality you can see clearly.
Sometimes your contribution is changing the process.
Sometimes it is making the need for change impossible to ignore.
The cost of friction is not only time
When a process is difficult to use, the usual business case is efficiency.
How many minutes are wasted?
How much rework occurs?
How many additional transactions could we process if the friction disappeared?
Those questions matter.
But people experience bad systems emotionally too.
A new employee repeatedly encounters hidden rules and starts wondering whether she is simply bad at the job.
A customer sees another confusing error message and wonders whether they did something wrong.
A supervisor learns that every unusual decision requires help from one particular manager, so eventually they stop trying to decide.
The system begins training dependence.
This is especially important because helpers can become very good at rescuing people from broken systems.
The expert solves the problem quickly. The manager steps in again. The experienced colleague answers another question.
Everyone is grateful.
But repeated rescue can hide the fact that people keep falling into the same hole.
Sometimes the more useful help is not another rescue.
It is making the hole harder to fall into.
Stop solving the same friction twice
The next time you encounter a familiar workaround, solve the immediate problem if someone needs help now.
Then do not stop there.
Ask:
What did this person have to know that the work did not make clear?
Then:
Should that knowledge remain inside someone’s memory?
If the answer is no, look for the smallest responsible way to move it into the work.
Change the label.
Improve the cue.
Clarify the rule.
Update the example.
Remove the unnecessary step.
Bring evidence to the person who can change what you cannot.
Then wait for the moment to happen again.
This is important.
Do not judge the improvement only because the revised procedure looks cleaner.
Watch the next person.
Do they still hesitate?
Do they still ask the same question?
Does the expert still have to rescue them?
Reality gets another turn.
Improvement often makes good work disappear
There is a strange reward for tolerating inefficient systems.
When you repeatedly rescue people from the same problem, your activity is highly visible. People know you are needed. They see the messages you answer and the situations you solve.
Remove the friction and much of that activity disappears.
The questions stop coming.
The extra steps vanish.
People no longer need you for something that once made you look extremely busy.
That is why Stop Measuring Effort. Look for Movement. matters here. A quieter process may be evidence of better work.
Of course, that creates another challenge.
Six months later, everyone may experience the easier system as normal. The old frustration fades from memory. People who joined afterward may never know that the recurring problem existed.
The improvement becomes almost invisible because it succeeded.
That does not reduce its value.
But it does create a reason to preserve enough evidence that useful contributions can be understood and learned from.
Leave less secret knowledge behind
In Do the Work the Next Person Can Use, the question was whether one output forces the receiver to search, guess, or reconstruct information you already knew.
This article moves one level outward.
What if the same confusion keeps appearing across people and across time?
That is when you begin looking beyond the document to the recurring system around it.
You will not fix every awkward process you encounter.
Some systems are larger than your role. Some problems deserve much more investigation. Some complexity exists for good reasons.
But you can become the kind of person who notices when unnecessary difficulty has become normal.
And when the opportunity is within your reach, you can leave something better.
Not grander.
Not more impressive.
Easier for the next reasonable person to use without acquiring all the secret knowledge you had to learn.
Do not make the next person solve a problem you already understand.
When an improvement succeeds, however, the old problem can quickly disappear from memory—and so can the contribution that removed it. The next article looks at how to preserve credible evidence of the value you create before asking other people to recognize it.
Continue with Create Evidence Before You Ask for Recognition.