10 Steps to Problem Solving for Engineers

With the official launch of the engineering book 10+1 Steps to Problem Solving: An Engineer's Guide it may be interesting to know that formalization of the concept began in episode 2 of the Engineering IRL Podcast back in July 2018.

As noted in the book remnants of the steps had existed throughout my career and in this episode I actually recorded the episode off the top of my head.

My goal was to help engineers build a practical approach to problem solving.

Have a listen.

Who can advise on the best approach to problem solving other than the professional problem solvers - Yes. I'm talking about being an Engineer.

There are 2 main trains of thought with Engineering work for non-engineers and that's trying to change the world with leading edge tech and innovations, or plain old boring math nerd type things.

Whilst, somewhat the case what this means is most content I read around Tech and Engineering are either super technical and (excruciatingly) detailed. OR really riff raff at the high level reveling at the possibilities of changing the world as we know it. And so what we end up with is a base (engineer only details) and the topping (media innovation coverage) but what about the meat? The contents?

There's a lot of beauty and interesting things there too. And what's the centrepiece? The common ground between all engineers? Problem solving.

The number one thing an Engineer does is problem solving. Now you may say, "hey, that's the same as my profession" - well this would be true for virtually every single profession on earth. This is not saying there isn't problem solving required in other professions. Some problems require very basic problem solving techniques such is used in every day life, but sometimes problems get more complicated, maybe they involve other parties, maybe its a specific quirk of the system in a specific scenario. One thing you learn in engineering is that not all problems are equal. These are

 The stages of problem solving like a pro:

1. Is the problem identified (no, really, are you actually asking the right question?)

2. Have you applied related troubleshooting step to above problem?

3. Have you applied basic troubleshooting steps (i.e. check if its plugged in, turned it on and off again, checked your basics)

4. Tried step 2 again? (Desperation seeps in, but check your bases)

5. Asked a colleague or someone else that may have dealt with your problem? (50/50 at this point)

6. Asked DR. Google (This is still ok)

7. Deployed RTFM protocol (Read the F***ing Manual - Engineers are notorious for not doing this)

8. Repeated tests, changing slight things, checking relation to time, or number of people, or location or environment (we are getting DEEP now)

9. Pray

10. Go to the bottom level, in networking this is packet sniffers to inspect packets, in systems this is taking systems apart and testing in isolation, in software this is checking if 1 equals 1, you are trying to prove basic human facts that everyone knows. If 1 is not equal to 1, you're in deep trouble.At this point you are at rebuild from scratch, re install, start again as your answer (extremely expensive, very rare)

And there you have it! Those are your levels of problem solving. As you go through each step, the more expensive the problem is. --BUT WAIT. I picked something up along the way and this is where I typically thrive. Somewhere between problem solving step 8 and 10. 

The secret step

My recommendation at this point is to try tests that are seemingly unrelated to anything to do with the problem at all.Pull a random cable, test with a random system off/on, try it at a specific time of the day, try it specifically after restarting or replugging something in. Now, not completely random but within some sort of scope. These test are the ones that when someone is having a problem when you suggest they say "that shouldn't fix the problem, that shouldn't be related" and they are absolutely correct.But here's the thing -- at this stage they have already tried everything that SHOULD fix the problem. Now it's time for the hail mary's, the long shots, the clutching at straws. This method works wonders for many reasons. 1. You really are trying to try "anything" at this point.

2. Most of the time we may think we have problem solving step number 1 covered, but we really don't.

3. Triggering correlations.

This is important.

Triggering correlations

In a later post I will cover correlation vs causation, but for now understand that sometimes all you want to do is throw in new inputs to the system or problem you are solving in order to get clues or re identify problems or give new ways to approach earlier problem solving steps. There you have it. Problem solve like a ninja. Approach that extremely experienced and smart person what their problem and as they describe all the things they've tried, throw in a random thing they haven't tried. And when they say, well that shouldn't fix it, you ask them, well if you've exhausted everything that should have worked, this is the time to try things that shouldn't. Either they will think of more tests they haven't considered so as to avoid doing your preposterous idea OR they try it and get a new clue to their problem. Heck, at worst they confirm that they do know SOMETHING about the system.

Go out and problem solve ! As always, thanks for reading and good luck with all of your side hustles.

If you prefer to listen to learn we got you covered with the Engineering IRL show!

For Youtube please go to:

https://youtu.be/EHaRNZhqmHA

For Spotify please go to:

https://open.spotify.com/show/3UZPfOvNwQkaCA1jLIOxp4

And don't forget to subscribe if you get any value from the Engineering IRL Content