Ask Them

Before you redesign the work, talk to the people who actually do it.

Organizations spend enormous amounts of time trying to understand why something isn't working.

Leaders meet. Reports are reviewed. Processes are mapped. Systems are analyzed. Consultants are hired. Data is collected. Recommendations are developed.

All of those things can be valuable.

But sometimes there is a remarkably simple place to begin.

Ask the person doing the work. They may already know exactly where the problem is.

The process on paper isn't always the process in practice

Every organization has processes. Some are carefully documented. Some live in training manuals. Some are embedded in technology. Some exist in spreadsheets. And some live almost entirely in the collective memory of the people who perform them every day.

On paper, a process may look perfectly reasonable: Step 1. Step 2. Step 3. Done.

Then you sit beside the person actually doing it.

Step 1. Step 2. Open another system. Look up information. Copy it. Return to the first system. Discover something is missing. Email someone. Wait. Receive the answer. Enter the information. Update a spreadsheet because the system doesn't capture something everyone needs. Send the spreadsheet to another department. Keep your own copy because sometimes the information gets changed later. Then Step 3.

The process map said three steps. The employee knows there are seventeen.

Workarounds are information

People are remarkably good at finding ways to get their work done.

When a process doesn't quite work, they adapt. They build a spreadsheet. Create a checklist. Keep notes. Develop a naming convention. Save information somewhere else. Ask someone in another department to send them something every Tuesday. Create an unofficial report. Add a manual review. Build a workaround around the workaround.

Eventually, those adaptations become so normal that nobody thinks of them as unusual anymore: “That's just how we do it.”

But those workarounds are telling us something. They're showing us where the official process, technology, information, or organizational structure isn't fully supporting the work.

A workaround isn't necessarily evidence that an employee is doing something wrong.

Sometimes it's evidence that the process is asking them to solve a problem the organization hasn't solved yet.

Ask a different question

When organizations examine a process, they often ask: “What do you do?” That's useful. But there are better questions.

What's harder than it should be? What do you have to do manually? What information do you wish you had? Where do you enter the same information more than once? What do you have to remember because the system doesn't? Where do mistakes usually happen? What causes you to stop and wait? What do new employees struggle to understand? What do you do outside the official process to make the official process work?

If you could change one thing about how this works, what would it be?

Watch, too

Sometimes people don't know what to tell you. Not because they're withholding information. Because they've done the work so many times that its complexity has become invisible to them.

Ask someone how they complete a familiar task and they may say: “I pull the report and update the file.”

Then watch. They pull the report. Change three filters. Export it. Rename the file. Delete four columns. Add two formulas. Look something up in another system. Correct a formatting issue. Compare the result against yesterday's spreadsheet. Investigate two exceptions. Save one version. Email another. And update a tracker showing that it was completed.

None of that felt noteworthy to them. They've been doing it every morning for six years.

Familiarity can make friction invisible.

Knowing the problem isn't the same as designing the solution

The people closest to the work often have something extraordinarily valuable: deep knowledge of what the work requires.

They know the rules. They know the exceptions. They know what has to happen for the outcome to be right. They know where the process slows down, which information they can't find, what frustrates customers or employees, and what they wish were easier.

And often, they have very good ideas about what could improve.

But that doesn't mean they should be expected to design the entire solution.

Sometimes people have performed a process for so long that the workarounds they've created have become almost invisible to them. Sometimes they can describe exactly what they need the outcome to be but don't know what's technologically possible. Sometimes they know their role exceptionally well but don't see what happens three departments downstream.

And sometimes translating a business requirement into process design, system architecture, automation, financial controls, or computer logic simply isn't their expertise.

It doesn't need to be. Their expertise is still essential.

Knowing what the work requires and knowing how to build the solution are different forms of expertise. Great solutions respect both.

Build the solution together

This is where process improvement becomes collaborative.

The people doing the work bring reality: Here's what has to happen. Here's what goes wrong. Here's the exception nobody knows about. Here's what makes this difficult. Here's what would make my job easier. Here's what a good outcome would look like.

Other people bring different pieces. A process expert may recognize that three steps can become one. A developer may realize that something employees assumed had to be manual can be automated. Finance may identify a control that has to remain. Technology may understand how information can move between systems. Another department may explain that changing one field upstream would eliminate an entire reconciliation process downstream. Leadership may see how the solution needs to support where the organization is going - not merely how it operates today.

And someone has to bring those perspectives together into one solution that works across the organization.

The goal isn't to ask one person for the answer. It's to make sure we have the right people helping us find it.

Don't ask just so you can say you asked

There is a big difference between involving people and collecting their comments.

Employees know the difference, too.

If a decision has already been made and nothing they say can meaningfully affect it, don't pretend you're asking them to help design the solution. Tell them what's changing. Explain why. Listen to concerns. Be straightforward.

But when there is genuinely an opportunity to improve something, invite people into the thinking. And then take what they tell you seriously.

That doesn't mean every suggestion becomes part of the solution. It shouldn't. No single perspective is the whole answer - including ours.

The best question may come after “why?”

Suppose someone tells you: “We have to enter that information into the spreadsheet.”

Why? “Because Payroll needs it.” Why does Payroll need the spreadsheet? “Because they can't get that field from the system.” Why can't they get it from the system? “I don't know. We've always sent them the spreadsheet.”

Now we have something worth investigating.

Maybe Payroll really does need it. Maybe the system can provide it and nobody realized it. Maybe the requirement disappeared three years ago. Maybe another department needs the same information and created an entirely separate process to collect it. Maybe changing one field could eliminate hours of work across several teams.

The objective isn't to challenge everything simply for the sake of challenging it. It's to understand why the work became the way it is.

Curiosity turns observations into opportunities.

Listen for the sentence everyone knows

Every organization has them.

“That system doesn't really do that.” “Don't use that report. The numbers aren't right.” “Maria has a spreadsheet for that.” “We have to call Finance when that happens.” “Technically you're supposed to do it this way, but…” “Only James knows how to fix that.” “We tried changing it once.” “That's just how we've always done it.”

Those sentences are gold. Not because they necessarily identify something that must change, but because they identify something worth understanding.

They point toward dependencies, institutional knowledge, system limitations, control issues, training gaps, duplicate work, data problems, risk, and sometimes enormous opportunities for improvement.

When you hear one - get curious.

No one sees the whole picture

Executives see across the organization. Managers see teams, priorities, performance, and resources. Finance sees economics and controls. Technology sees systems, architecture, and possibilities. Process experts see connections and opportunities for improvement.

And the person performing the transaction at 10:37 on a Wednesday sees something none of them can see from their vantage point: what actually happens at 10:37 on a Wednesday.

No one perspective is enough.

The best solutions emerge when we bring those perspectives together - not by asking everyone to become an expert in everyone else's work, but by allowing each person to contribute the expertise only they have.

That's collaboration.

That's how we move from: Here's what's wrong. To: Here's what better should look like. To: Here's how we can actually build it. To: Let's make it work.

Good solutions need all of them.

There is another benefit

Something changes when people realize their experience matters.

Instead of: “Here comes another new process somebody designed without understanding what we do,” the conversation becomes: “We talked about this. They understood the problem. I can see why we're changing it.”

That's not merely getting buy-in. It's something better.

Participation creates understanding.

People understand the reasoning behind the change because they were part of the conversation that shaped it. They can identify problems before implementation, challenge assumptions, help test whether the solution works in reality, and become some of its strongest advocates because the final result reflects knowledge they contributed.

That doesn't mean change becomes effortless. It does mean we're no longer asking people to adopt something that happened entirely to them.

Ask. Listen. Then act.

Listening isn't the end of process improvement. Eventually, something has to change.

The purpose of listening is to make the action better informed.

Ask the people doing the work. Observe the work. Understand the workarounds. Follow the information. Bring together the perspectives that matter. Then design something better.

And after you implement it? Ask again.

Is this better? What did we miss? What became easier? What became harder? What would you change now that you've actually used it?

Because implementation isn't the moment when listening stops. It's when you discover whether you understood correctly.

A question worth asking

Think about one process in your organization that everyone agrees is harder than it should be.

Before scheduling the leadership meeting. Before buying another system. Before redesigning the workflow. Before deciding what the problem is.

Find the people who perform that process every day. Sit beside them. Watch. Listen. Get curious. And then –

Ask them.