We engineers take great satisfaction in the accuracy of our calculations. But little in the real world is so precise. There are rarely right answers—only trade-offs, the often-messy realm of pros and cons.
Professionals and managers readily consider trade-offs, but engineers tend to be uncomfortable with them. For one thing, our education focuses us on precise, correct answers. Our raison d’être is finding the lowest-cost solution. Finding two acceptable answers seems somehow incorrect, unprofessional, or downright incompetent. Formulas, tests, professional engineer license exams—they all require getting the right answer. I once got a 79 on a structures exam (one of my better grades!), but the professor, seeing my satisfaction, asked me: Would I like to travel across a bridge that was designed 79 percent correctly?
Engineers can go to another extreme—thinking that ever more precise calculations will be that much more valuable. Often, however, those extra decimal points reveal nothing so much as a lack of understanding. Engineers at the U.S. Federal Aviation Administration once nixed a project of mine for people to get flight arrival times by touch-tone phone. Time of arrival calculations from the FAA’s computers were estimates within 10 or 15 minutes; the FAA engineers could not tolerate giving out such ”inaccurate” information to the public. Of course, that level of accuracy would have been enormously helpful to anyone picking up someone from the airport, and flight-tracking information is now part of most airlines’ Web sites.
Evaluating trade-offs requires a nuanced understanding of the matter at hand. To be sure, most of the work we engineers do does require technical precision. But that precision then gets carried from engineering into the business and social arenas—areas in which we engineers feel much less qualified. That’s one big reason trade-offs are so hard for us, but it doesn’t make them any less important to our careers, as well as our projects.
It isn’t just that the engineers who understand these nuances will be better able to advance their careers into management and policymaking. Deciding how you want your career itself to go often involves trading off one goal—compensation, security, job challenge, recognition—for another. For example, would you take a lower salary if your job security was increased? How much lower a salary? And what about vice versa?
Trade-offs like that are fairly easy if they can get translated into the universal scale of money. Not all can be. Would you take on a higher profile role, one with a lot more recognition, if it also made your job less secure? Most trade-offs are classic apples-versus-oranges ones. Fortunately, a number of techniques for weighing two dissimilar alternatives exist. My favorite is the Kepner-Tregoe decision analysis, where you list your ”needs” and ”wants” and then rate the degree to which each option meets the wants. It’s a bit like coming up with a single scale—like money—for the alternatives, and it’s helped me with several projects and with buying a house and several cars.
When doing such an analysis for a project, the first step is to identify the goals of all stakeholders by asking them to specify what they’d like to see accomplished. Then incorporate these trade-off factors into the design and evaluation steps. I used this process in managing a study of transit access alternatives to Newark Liberty International Airport. We prepared a spreadsheet showing the alternatives and key findings for each one. The spreadsheet was about 6 meters long and 60 centimeters tall, and we hung it on a wall so people could walk up to it and look at every cell. We rounded every number appropriately (”capital cost = $12.2 million,” for example) and put all text in plain English (for instance, ”requires two transfers”). This gave the assurance that we had considered every important trade-off and had provided a proper basis for decision making.
We live in a complicated world, and we technical folks add to this complexity every day. While it may be appealing to simply go by the numbers, it’s better to follow the saying: ”Don’t look for simplicity on this side of complexity; look for simplicity on the other side of complexity.” (If someone knows where this comes from, I’d appreciate hearing!) Considering and understanding trade-offs in your designs and projects will make you a more effective engineer.
About the Author
Carl Selinger is a contributing editor at IEEE Spectrum who writes regularly about careers. He is the author of Stuff You Don’t Learn in Engineering School (IEEE Press/Wiley, 2004).
To Probe Further
How different are managers and engineers? Very. See last month's article, ”Managers Are From Mars and Engineers Are From Jupiter.”