Diagnose Before We Prescribe

No responsible clinician prescribes treatment before understanding the patient's condition.

After more than twenty years in emergency care, behavioral health, and oncology, that sequence became instinctive for me. You gather evidence, locate the source of the problem, and understand the risks before deciding what should happen next.

Businesses reverse that order when they buy technology. A team hears about a new capability, purchases access, and then searches for a problem that might justify it.

The tool may work. The business still feels the same.

The tool arrives before the question

The pattern is easy to recognize. Leadership wants the team to move faster, so it purchases an AI assistant. Staff attend training and begin producing drafts, summaries, and options.

Then the same work returns to the same leaders for review.

Managers still approve routine exceptions. Priorities still change without a clear owner. Staff still wait because nobody has defined what good looks like or which decisions they can make without permission.

The tool increased output. It did not remove the decision that was slowing the work.

A faster tool can make weak structure harder to manage

Technology performs the task you give it. It cannot decide who owns the result or which standard the organization expects.

Consider a team that spends hours reconciling customer information. Software may reduce the manual work. But the problem may begin earlier: two departments collect different information, use conflicting definitions, and disagree about who corrects an exception.

Automating the final step leaves those disagreements in place. The team produces the conflict faster and still sends it to a manager to resolve.

Adding speed to an unclear process creates more material for someone to inspect. It does not create clarity.

Diagnose the work before choosing the tool

A useful diagnosis names the exact point where movement stops.

“We have a communication problem” is too broad. “We need to be faster” does not identify who is waiting or why.

A specific diagnosis sounds different:

• •Customer requests sit for two days because three people can assign them, but nobody owns the final handoff.
• •Managers spend Friday afternoons reconciling reports because sales and marketing use different definitions for a qualified lead.
• •Routine client exceptions reach the owner because the team has no approval limit or decision criteria.

Each statement identifies the people involved, the stalled decision, and the condition creating the delay. That level of detail makes it possible to decide whether the fix requires clearer ownership, a better process, or technology.

Stabilize the process first

A team needs a stable path before it can improve the speed of that path.

Name the owner of the work. Define which decisions that person can make. Set the conditions that require escalation, then agree on the standard used to review the result.

Once those pieces are clear, you can see where technology belongs. It may remove repetitive data entry, summarize a large record, or flag exceptions for review. The team still needs a person with the authority and judgment to act on what the tool produces.

This order prevents the pilot from becoming another subscription attached to an unchanged process.

Readiness begins with a testable diagnosis

"Be ready, so you don't have to get ready."

— My mother

In this context, readiness means understanding the work before pressure forces a decision. The diagnosis should be specific enough for the team to test it.

Track where the work waits. Count how often the same question reaches leadership. Identify the exception that staff cannot resolve without approval.

The evidence may show that the tool is useful. It may also show that the organization needs to clarify ownership before buying anything.

Clarity determines the prescription

The first question should not be, “Which AI tool should we use?”

Ask, “Which decision or step is creating the weight, and why can't the team handle it now?”

That question changes the project. The team stops searching for uses for a product and starts fixing the condition that affects the work.

A successful pilot needs more than working technology. The organization must know who owns the output, how people judge its quality, and what happens when the result falls outside the standard.

Diagnose those conditions first. Then choose the tool that supports the structure you have built.