The subject is really a follow-up on the last subject of being an engineer. We’ve all heard of the Scientific Method, and in many ways, it’s used to define what a scientist does. As previously discussed, coming across the definition of what an engineer does is much more complex. So how can there be an analogous process for an engineer?

“Analogous” may be a little too extreme. We require more “flexibility” than a scientist in approach, as our end goals are often squishy, so it’s never really clear when we’re “done”. Let’s start with the scientific method as defined by Merriam-Webster:

principles and procedures for the systematic pursuit of knowledge involving the recognition and formulation of a problem, the collection of data through observation and experiment, and the formulation and testing of hypotheses

Perhaps we need to break it down a little more systematically. I’m sure we’ve all seen some version of this in high school science.

1. Define the knowledge you want to gain. Examples include, “Why is the sky blue?”
2. Create hypothesis on the answer to the question posed. Examples include, “An airplane full of blue paint exploded a while back and we’re still seeing the color spray.”
3. Develop a test to validate the hypothesis. An example would be, “I’ll buy a 737, fill it with as much blue paint as it can carry, fit it with autopilot, fly it to a visible part of the sky, and blow it to smithereens.”
4. Perform the test and evaluate the validity of the hypothesis. “Well, I guess a part of the sky was a little blue, but in the end, I just ticked off a neighborhood in New Mexico and have the EPA all over me, so I guess that’s probably not how the sky got blue.”
5. Repeat…with a more plausible theory.

Of course the example is in jest, but in all reality, it’s a very sound system for gaining core knowledge. And it is incredibly important that someone do this work so we can understand the world around us. But it’s not the job of engineers. Engineers need to let the scientists do their work and understand the successes and failures of their experiments so they can extrapolate the experience into other areas. Engineers are “reprocessors” of scientific knowledge, not creators of it.

So how do we modify that for engineering? It’s surprisingly similar:

1. Define the problem. This is both simpler and harder than it sounds. Usually, when someone tells an engineer they have a problem, either they actually don’t know what’s important, or have a preconceived notion of the solution. Both of these issues need to resolved at this step. This can be a simple as stepping back and taking an objective view, to as complex as doing a full failure analysis. And unlike the scientific community, we are beholden to people that want things and results, so often a charm offensive is necessary to ensure that the correct problem is addressed.
2. Develop a designed solution to the problem based on experience, technical knowledge, limitations, etc. This is the heart of what most consider engineering, which is coming up with a solution to a problem with a specific set of constraints. This is the definition of an engineer in the previous newsletter paraphrased. So this step would be considered “engineering”, but it’s not the entirety of the engineering process.
3. Have independent reviews of your solutions. This is deeper than just a check to make sure there’s some reasonable expectation you didn’t mess anything up technically. This is a review of the reasoning behind all of the design decisions made. The importance of this step cannot be overstated, and often it is the step most likely short changed. People don’t like conflict, and this is intentional conflict. As engineers, we must have a reason for every decision made, but also be capable to accept that better reasons exist for a different path. Flexibility and leaving our design ego at the door is necessary. We must be confident and collaborative at the same time.
4. Iterate the design as much as possible. You are never going to be “done”, but you are going to run out of resources (time, money, people, knowledge) at some point. The more you learn about the design, the better the product, so this iteration is important to root out any issues not addressed by the review. As an engineer, there will always be something that you do not address, whether intentionally or unintentionally. It’s really upon engineering judgement to make sure you are focused on aspects of the solution where critical failures could occur and addressing those during the iteration to increase confidence in design success. Sometimes this can take the form of a risk informed approach in focusing the design optimization effort. That is ideal, and should be the model on which all design efforts should be iterated, but this can take many forms based on the complexity of the problem, resources available, and criticality of the solution.
5. Implement the solution. This is where the rubber hits the road. At this point, usually an engineer’s reputation is at stake, as even if the solution is non-critical, or can be adjusted in process, it’s the first time the client will see the solution in action.

Now, this is just my interpretation of the process, and it is far from set in stone. Every time I revisit this subject, I change my mind a little bit. This could almost be a yearly segment and look different every time. But much like the engineering method in general, I will continue to iterate it until I run out of resources, but since those resources are at my disposal, they will not be exhausted until I stop thinking, which hopefully is very far in the future.