Diagnose Before You Prescribe: Why Good Advice on Big Technology Decisions Starts With Questions

In short

• When a lot is at stake, the best advisors ask questions before they give answers.

• Machine assistants today often skip that step and go straight to a plan.

• On a big IT decision, the right first move is often a conversation, not a recommendation.

• The gap is not a lack of knowledge. It's not knowing when to stop and ask.

• We believe the next big step for machine advice is learning when a question matters more than an answer.

What does "diagnose before you prescribe" mean?

A good doctor doesn't hand you medicine the moment you say you feel sick. First they ask where it hurts, how long it has hurt, and what you've already tried. Only then do they decide what to do. The questions come first because the wrong medicine can do real harm.

Good advisors in business work the same way. A seasoned consultant, analyst, or senior IT leader who is called in to fix a serious problem does not open with a plan. They open with questions: what happened, who knows the most, what has been tried, and what "fixed" actually means to the person asking.

We call this diagnose before you prescribe. It is one of the oldest rules of good advice, and it matters most when the stakes are highest.

A simple story: the failing SAP program

Here is the kind of situation we have been looking at.

A large company is running a big SAP program. It is late and over budget, and people are worried. The CEO wants a rescue plan within 48 hours. The program has an experienced program manager who has been on it since the start and knows exactly where things went wrong.

Someone on the leadership team asks a machine assistant: "Our SAP program is failing. The CEO wants a rescue plan in 48 hours. What should we do?"

When we tried situations like this, the answer came back as a complete, confident plan. It had steps, timelines, governance changes, and ways to reset the scope. It read well. But it skipped two simple things any good advisor would have done first:

1. Talk to the program manager. The person closest to the problem knows the most, and a short conversation would uncover more than any general plan.

2. Read the past status reports. The history of the program shows where it started slipping and why.

The plan was not wrong because it lacked knowledge. It was built for a made-up company, not the real one.

Two ways to respond to the same problem

Why is skipping the questions risky on big decisions?

On small questions, a quick answer is fine. If you ask for a meeting agenda and get a decent one, nothing is lost.

Big technology decisions are different:

• The cost is high. A wrong move on a large program can waste months and a great deal of money.

• Many people are affected. Teams, partners, and customers all depend on the outcome.

• The real cause is often hidden. A program that looks like it has a budget problem may really have a people problem, a vendor problem, or a scope problem.

• A confident answer is persuasive. A polished plan can get approved just because it looks complete, even if it aims at the wrong problem.

That last point is the most dangerous. A weak answer that sounds unsure gets questioned. A wrong answer that sounds sure gets used.

When should an advisor stop and ask?

Not every question needs a diagnosis first. These signs suggest it does:

When two or more of these show up together, the best first answer is usually a short set of questions, not a plan.

Why do machine assistants skip the questions?

Here is our view in plain terms:

• They are built to be helpful fast. A question in usually means an answer out.

• People reward quick answers. A full plan feels more useful in the moment than a set of questions.

• They can't see what's missing. Without being told, a machine does not know a program manager exists or that status reports are sitting in a folder.

• They treat every question the same way. A meeting agenda and a failing multi-year program get the same kind of reply.

None of this is a flaw in knowledge. It is a flaw in judgment about when knowledge is not yet enough.

Is this a knowledge problem?

No. When a machine is given all the facts up front, including what went wrong, who is involved, and what has been tried, its answers are usually sensible. It knows a lot about how programs fail and how they get fixed.

The gap is earlier. It lies in noticing that the facts are missing and asking for them. That is a judgment skill, and it is the skill that separates a good advisor from a well-read one.

What should leaders do when they use machine advice on big decisions?

Until machines learn to ask first, leaders can make up for it:

1. Tell it the stakes. Say plainly that this is a big, costly decision.

   
   

2. Ask it to question you first. For example: "Before you give me a plan, what do you need to know?"

   
   

3. Name the people involved. Mention who is closest to the problem, so the advice can point you to them.

   
   

4. Share the history. Past reports, earlier decisions, what was already tried.

   
   

5. Check the plan against the ground. Before acting, run it past the people who know the real situation.

Questions a good advisor asks first on a failing IT program

These are common-sense starting points, not a formula:

What this means for how technology decisions get made

Big technology decisions are increasingly shaped, at least in part, by machine advice. That makes this gap matter more every month. A tool that answers every question the same way will be most wrong on the decisions that matter most.

At Analyst Layer, we study how big technology decisions actually get made, by people and by machines. What good advisors have always known applies here too: on the decisions that count, the first question matters more than the first answer.

Frequently asked questions

• What does "diagnose before you prescribe" mean in business?
  It means understanding a problem before recommending a fix: asking questions, talking to the people involved, and checking the history before giving a plan.

  
  

• Do machine assistants ask clarifying questions before giving advice?
  Often they don't. In our experience, on big business questions they tend to reply with a complete plan straight away, even when key facts are missing.

• 
  

• Is the problem that machines don't know enough?
  No. When given the full facts, their answers are usually sensible. The gap is in noticing that facts are missing and asking for them first.

  
  

• Why does this matter for IT programs in particular?
  Large IT programs are costly, involve many people, and often fail for hidden reasons. A confident plan aimed at the wrong cause can waste months.

  
  

• When is a quick answer fine?
  When the stakes are low and the question is complete. Drafting an agenda or summarizing a document doesn't need a diagnosis first.

  
  

• How can leaders get better machine advice on big decisions?
  State the stakes, ask the tool to question you first, name the people involved, share the history, and check any plan with the people closest to the problem.

  
  

• What should be the first step in rescuing a failing IT program?
  Talk to the person who knows the program best, usually the program manager, and review the past status reports before writing a plan.

  
  

• Who is Analyst Layer?
  Analyst Layer is a research and analyst firm that studies how big technology decisions get made, both by people and by machines.

Terms used in this article