Engineering Solutions

There can be no question that engineers are one of the cornerstones of any successful technology oriented business organization. It doesn’t matter if they are hardware, software, electrical, mechanical, chemical or even civil engineers. Their role and importance cannot be overstated. We need to be very clear about that. I will try to walk the fine line of discussing the work of engineers in business without sliding into the realm of picking on engineers in business. Wish me luck.

It has been said:

“With great power comes great responsibility”

The origin of this quote is attributed to two wildly different sources: Voltaire, the eighteenth-century philosopher, and Uncle Ben, the Spiderman character, not the instant rice one. Both are acknowledged as saying something close but not quite like this, hence the somewhat open-ended attribution.

If I have a choice I’m going with Uncle Ben. Just because I haven’t seen that many entertaining movies about Voltaire and the French Enlightenment. However, I am sure that Marvel Comics will eventually get around to it. Probably after Thor – Thirteen, or some such time.

Mark Twain however, is widely acknowledged as the source of this quote:

“To a man with a hammer, everything looks like a nail.”

I believe the modern technology equivalent of this statement is now:

“To an engineer, every question looks like it needs an engineering solution.”

Herein is where we get to the topic of engineering solutions. Engineers have a great power and responsibility when it comes to finding solutions to today’s customer based technological opportunities. A solution usually cannot be created, or implemented without them. Somebody usually has to put them together, and that somebody is usually an engineer.

Engineers have been trained starting in school to create the best solution. It usually entails a single variable. The strongest solution. The highest. The most secure. The longest. The tallest. Very seldom is there a scale or constraint added where there is some sort of trade off versus another variable. This can have a tendency to be the mindset that engineers use when creating real world solutions.

But even in this high technology, engineering dependent environment, it must be remembered that engineering is only part of the solution, not the entire solution. We are no longer in a time where a president can challenge a country to reach a goal, and the engineers can spend whatever is necessary to reach it. Doing things because they are difficult is a great challenge, but doing them within a budget is even a greater challenge.

About this time, I will have lost all readers that have an engineering degree, an engineering role or even just an engineering predilection. To mention that there are items other than engineering that are important to customer solutions, in their eyes can border on blasphemy. Unfortunately, that is the business world that we now live in. I have talked about this evolution before. It is the transition from the best solution, to the solution that is good enough. This idea is likely to drive engineers crazy.

Little things like money, time and resources must also be taken into account when creating a customer centric solution. This is because, contrary to standard engineering thought, the customer does not necessarily want the best engineered solution. They want the best solution that matches their money, time and resource constraints.

Engineers must be continually reminded of these real-world business constraints: money, time and resources. Otherwise it is not uncommon for them to develop the ultimate engineered solution, that is wholly implausible or unimplementable in the real world. It may be the best technical solution, but there will be very few that can afford to buy and implement it.

When engineering customer solutions, it is best not to think in terms of “absolutes”. Words like the “greatest”, “most” and “best” need modifiers otherwise engineers have a tendency to take them as literal objectives and work to them accordingly. This can result in some of the most elegantly over-engineered solutions imaginable.

Pareto Analysis is a statistical technique in decision-making used for the selection of a limited number of tasks that produce significant overall effect. It uses the Pareto Principle (also known as the 80/20 rule) the idea that by doing 20% of the work you can generate 80% of the benefit of doing the entire job. (

Many think that it was the Italian economist Vilfredo Pareto who created the Eighty – Twenty rule. To a certain extent this is somewhat true. Pareto first observed that 80% of income in Italy was received by 20% of the Italian population. However, it was management thinker Joseph M. Juran who actually suggested the principle and its far wider applications. Because of Pareto’s observation and work, the technique was named for him. (

Business, in all its simplest forms, is about investment and return. How much you put in versus how much you get out. This is the basis for employment decisions (if the company thinks that a person will generate more value for the company than the company will have to pay that person in compensation, then the company makes the hiring decision), and it is that way in purchasing decisions (amount paid versus expected return), and it needs to be that way in generating customer solutions.

Customers are not blessed with infinite resources. As I have said, in many instances they cannot afford to pay for what may be considered the “best” solution. Time and money always come into play for them. How much must they pay for each solution? What definable value does the solution generate (reduced costs, increased sales, etc.)? When would they expect to see these returns (the sooner the better)?

Engineers are excellent at the quantifiable. It is the nature of their work. However, if left unchecked they do have a tendency to view costs, time and resources more as “variables” instead of “constraints”. This is where business and leadership reinforcement is required.

When working with engineers, boundaries and constraints are a necessity. An upper limit on costs must be set. This can be in the form of a specific number (The cost cannot exceed…) or a derived relationship (the customer requires a pay-back period of….) based on costs, value generated and specific time frames. This will enable the engineer to modify various combinations of these business variables, but also provide a limiting constraint on the solution.

This customer pay-back period can also be used to help generate the value limit as well. If as Pareto has asserted that first eighty percent of the value can usually be derived with the first twenty percent of the effort, then it should follow that each additional amount of engineering effort (or any effort for that matter) will only provide a continually decreasing return. If the desired customer pay-back is based on returns and time, there is a limit as to what can be engineered within the constraint. Only so much can be done before the cost or pay-back period are exceeded.

It should be noted that not all engineers are so single-mindedly focused on engineering solutions. I have had the opportunity to work with several who understood that good customer solutions are the result of many, sometimes opposing forces in the solution creation process. These are the engineers that have recognized that real world issues and solutions have both a cost and a value associated with them.

A few final comments and observations on the engineering of solutions:

The optimist will look a glass that is half full of water and say that it is indeed half full.

The pessimist will look at the same glass and say that it is in fact half empty.

The engineer will look at it and say the glass is twice as big as it should be, and will set about trying to engineer a smaller glass that will be much more efficient in the holding of that specific amount of water.

Before they are allowed to do that, it is best to check to make sure that the customer wasn’t all that thirsty to begin with, and the amount in the glass is all the water that they wanted at this time. It might actually save more time, money and effort than the solution the engineer would create.

There are probably many engineers that would like to argue this point of view. I have found that for an engineer, the next best thing to trying to engineer the best solution to a problem, is to argue about what is the best engineered solution to a problem. For those of you that have not had the opportunity to argue with an engineer, this is a good time to remember the following quote:

“Arguing with an engineer is a lot like wrestling in the mud with a pig, after a couple of hours you realize the pig likes it.” (anonymous).