Professional problem solving strategies in 10 steps

2 hours ago

4 min read

You can spend a long time working hard on a problem and still make very little progress.

Sometimes the problem is genuinely difficult. Sometimes you are missing one piece of information. And sometimes you have become very good at answering the wrong question.

That last one is frustrating, because doing more work doesn't necessarily bring you closer to the result you need.

Professional problem solving needs more than persistence. It needs a way to decide what to check next.

The approach behind my book, 10+1 Steps to Problem Solving: An Engineer's Guide, is to make those checks practical. Here is a working overview you can use to review your own approach.

The stages of problem solving like a pro:

These checks aren't a requirement to perform ten actions in order. Use the next useful step, return to earlier ones when the evidence changes and work within the limits of your role.

On operating equipment, tests and changes need the appropriate authorisation and controls. A clever idea is still a change to a real system.

1. The Question

What, exactly, is happening? What should happen instead?

“It's slow” is a starting point. “The display updates twelve seconds after the input changes, while the controller log updates immediately” is a much more useful description.

Separate what someone observed from their explanation of it. Then agree what a successful result would look like.

2. The Obvious

Check the simple explanations that fit the symptom.

That could mean the selected mode, a disabled setting, a missing prerequisite or the wrong version of a file. Obvious checks are worth doing because they are often quick and informative.

But don't restart or disconnect a running system just because that would be an obvious test on your home computer. Context determines what is appropriate.

3. Eyes

Get a direct view of the evidence.

Look at the display, drawing, log or physical arrangement yourself where you can. A description passed through several people may have lost an important detail.

If you cannot inspect it directly, ask for a timestamped screenshot or a precise observation. “What did you see?” is different from “What do you think caused it?”

4. Check Yourself

Test your own assumptions before building more reasoning on them.

Are you connected to the intended device? Are the units correct? Is the drawing current? Is the clock on the log using the same time zone as the event record?

Experience helps you recognise patterns. It can also make a familiar explanation feel correct before you have checked it.

5. Doctor G

Use research to narrow the possibilities.

Search for the exact error, product and version. Give priority to original documentation and relevant technical support information. An answer about a similar product can suggest a question, but it doesn't prove the same fix applies.

Write down what a source says and why it is relevant to your situation.

6. The RTFM Protocol

Read the manual, including the sections surrounding the setting you were about to change.

Look for prerequisites, limitations, supported configurations and the intended sequence of operation.

You might discover that the behaviour is expected, that another condition must be met or that the feature works differently in this release. Reading is often cheaper than undoing an assumption.

7. Strip

Reduce the problem to a smaller, controlled example.

In a suitable test environment, remove unnecessary inputs or components until you can explain the remaining behaviour. For software, that might be a minimal test case. For a design, it could be one interface examined separately.

Keep a known baseline and record what you removed. Smaller is useful only when you still know what the test represents.

8. What about the Environment?

Consider what surrounds the component.

Timing, load, temperature, permissions, network conditions and interactions with other systems can all change behaviour. A component that works alone may fail under a particular combination of conditions.

Compare a working case with a failing case. The difference between them may be more informative than another inspection of the same component.

9. Phone-A-Friend

Ask someone else to review your evidence.

Give them the problem statement, what you have checked, the results and the decision you're stuck on. That lets them contribute a new perspective without repeating your entire investigation.

Sometimes explaining it clearly is enough to expose the missing assumption yourself. That's still a useful outcome.

10. Pray

This is the tongue-in-cheek reminder that you can reach a point where you feel completely out of ideas.

Treat that feeling as a cue to pause, escalate or get a fresh review. Repeating the same failed test because you are tired is not a strategy.

Leave notes that let you or someone else restart from evidence, rather than from frustration.

The secret step

When everything that should work has failed, challenge what you have ruled out.

Ask, “Which assumption would have to be wrong for this result to make sense?”

That can suggest a test which initially feels unrelated. Perhaps the issue follows an account rather than a device, or appears after a particular sequence rather than at a particular load.

The test still needs a purpose, a safe setting and a result you can interpret. Random changes make it harder to know what happened.

Triggering correlations

An unexpected result gives you a clue. It doesn't automatically establish the cause.

If a fault disappears after a configuration change, record the other things that changed too. Then design an appropriate follow-up check to distinguish the explanations.

Finish by confirming the original requirement, documenting the result and communicating any remaining uncertainty.

The aim is to reduce wasted effort and make the reasoning repeatable. If you'd like the wider explanation behind these checks, explore 10+1 Steps to Problem Solving.

You don't need every answer before you begin. You do need a better next question.