How to Think Like an Engineer

Author: Joe H., Inflow Engineer

When most people envision an engineer, the image that typically springs to mind involves a short-sleeved dress shirt, a set of thick lensed glasses, and a pocket calculator, modeled by an individual who spends their day computing set after set of important yet boring equations. To be fair, there is no shortage of equations involved in most engineering projects, but engineering as a discipline is not fundamentally focused on calculations. Engineering is, to quote Billy Vaughn Koen, “the use of heuristics to cause the best change in a poorly understood situation within the available resources.”[1] In other words, engineering is the art and science of taking extremely complex systems and getting them to do approximately what you want them to do. And given the amount of complexity in the world today, knowing how to think like an engineer is an advantage in any field.

So, how does an engineer actually approach a complex problem? The best way to understand the engineering method is to look at an example. Perhaps the most complex engineering project in the history of the world is the Large Hadron Collider. It is housed in a tunnel 17 miles long, buried up to 574 feet underground, and uses magnets cooled to less than 2 degrees above absolute zero. When operating, the magnets store 10GJ of energy[2], enough to power the average American household for approximately 250,000 years. Where would you even start on designing something this complex?

The engineering answer is actually very simple:

  1. Gather your requirements. (System has to smash protons together at high energy levels.) 
  2. Create a high level design. (System needs three detectors, two accelerators, etc.)  
  3. Determine the requirements for each subsystem. (Power needed, system output, etc.)
  4. Design the subsystems. (Using this procedure or something very similar.)
  5. Integrate the subsystems and review your design. (Does it work? Are all subsystem requirements met?)
  6. Create list of change requirements and go back to Step 2.

Now to be fair, there’s a lot more than that involved and each item on the list has a huge number of tasks contained within it, most of which require a solid understanding of physics, electronics, computer science, and a host of other highly technical fields. Moreover, the same general approach has to be followed for each subsystem, which can lead to subsystems of subsystems, subsystems of subsystems of subsystems, and the like. However, the high level process acts as a framework into which other tasks and processes can be inserted, making an otherwise overwhelmingly complex problem manageable.

This use of processes isn’t exclusive to engineering of course, nor is the list I gave above applicable to every engineering task; that’s not the point of the example. The point is to show that at its core, engineering is a processes driven discipline. Depending on the task at hand, the process might have different steps, but there are a few similarities that you’ll see in any engineering process. First and foremost, it will be composed of a few relatively simple steps. Secondly, each step will assume that the person reading it possesses the knowledge to follow through with whatever calculations are needed. And finally, there will be at least one review step to ensure that nothing has been missed. This methodical approach to problem solving is the key to thinking like an engineer. It’s the reason so many college engineering tests are given open book and open notes; if you don’t know how to approach the problem, all the equations in the world won’t help you.

If you think the process described above sounds like a checklist, you’re absolutely correct, and there’s a good reason for this. If your goal is to simplify a complex problem, you don’t achieve anything by creating an equally complex process. Likewise, it would be impossible to create a single step-by-step process for designing something; there are just too many permutations that need to be addressed at each step. A checklist creates structure and ensures that you don’t skip a basic task, but also allows for creative approaches to problems. Let’s take a look at a different engineering task to see exactly how this can work.

Unlike designing a system based off a set of requirements, reverse engineering involves taking an existing system and determining how it works. But despite being the exact opposite of our previous example, the approach to the problem is extremely similar:

  1. Identify known components.
  2. Create a diagram of the system to determine overall design.
  3. Determine which components perform complex functions. (Microcontrollers, subsystems, etc.)
  4. Analyze the complex components. (Using this procedure or something very similar.)
  5. Plug the results of your analysis into the higher level diagram.
  6. Review analysis and conduct verification testing. If any questions remain, go back to Step 2.

Again, there’s a lot more detail involved, with each item having its own set of procedures and checklists. The example above requires a good deal of technical knowledge to execute properly, but even an individual with no technical background can look at this list and ask if all the steps have been completed. And if you do have a background in the right areas, this kind of list frees you from having to keep track of basic best practices and allows you to focus that training on solving the actual problem at hand.

That brings us to the real beauty of this process based approach – it works regardless of the field it’s applied too. If you have ever botched a task because you forgot a basic step (and let’s be honest, we all have), then you’ve been in a situation where a checklist could have helped, especially if it’s a task you do on a regular basis. In some fields, there may be checklists and procedures already in place. If not, you’ll have to put together your own. In either case, I highly recommend picking up a copy of “The Checklist Manifesto” by Atup Gawande. Dr. Gawande provides a great look into the power of checklists in a non-engineering field, and provides a host of real world examples of how checklists can be used. Give it a read and take the time to apply this type of process based thinking to your day-to-day tasks. I think you’ll be pleasantly surprised with the results.

-Joe H., Inflow Engineer

 

[1] Koen, Billy Vaughn (2013). Discussion of The Method (1 ed.). New York Oxford: Oxford University Press. p. 59. ISBN 0-19-515599-8. Retrieved 23 July 2015.

[2] John Poole (2004). "Beam Parameters and Definitions" (PDF)

 

At Inflow we solve complex terror and criminal issues for the United States Government and their partners, by providing high quality and innovative solutions at the right price through the cultivation of a corporate culture dedicated to being #1 in employee and customer engagement. We Make it Matter, by putting people first! If you are interested in working for Inflow or partnering with us on future projects, contact us here