Engineers as Problem-Solving Leaders - IEEE Xplore

Engineers as Problem-Solving Leaders: Embracing the Humanities KATHRYN W. JABLOKOW

I

n 1902, David Starr Jordan, President of Stanford University, remarked: “There are very many things besides engineering [that] go into the making of a real engineer” [5]. Over a century later, in 2005, Charles Vest, President of MIT, admonished the attendees of the National Academy of Engineering’s “Engineer of 2020” National Education Summit [15]:

Todd Davidson/Stock Illustration RF/Getty Images

“As you develop the concept of a new curriculum and new pedagogy, as you try to attract and interest students in nanoscale science, large complex systems, product development, sustainability, and business realities, don’t be tempted to crowd the humanities, arts, and social sciences out of the curriculum. The integral role of these subjects in U.S. engineering education differentiates us from much of the rest of the world. I believe the humanities, arts, and social sciences are essential Digital Object Identifier 10.1109/MTS.2007.911075

IEEE TECHNOLOGY AND SOCIETY MAGAZINE

|

winter 2007

1932-4529/07/$25.00©2007IEEE

|

29

to the creative, explorative, open-minded environment and spirit necessary to educate the engineer of 2020.”

ing of one of the core elements of the engineering discipline as well. Specifically, I will propose that framing the situation

Using problem solving as a backdrop leads to insights about what it takes to move beyond engineering competence to engineering leadership. Other distinguished engineering scholars and practitioners have made similar observations and recommendations in the interim. In 1995, for example, delegates from 12 nations at an international symposium sponsored by the European Society for Engineering Education (SEFI) agreed that “the humanities and social sciences are vital for the full intellectual development of an engineer” [4], and Florman [5] noted several years later: “the vital first step is to convince engineering students that technical brilliance is not enough”. Clearly, at least one message coming from those in the highest and most respected positions in our profession has not changed a great deal in 100 years: engineers must know more than engineering in order to be good engineers. Equally clearly, a large number of engineers must remain unconvinced, or there would be little need to repeat the message with such urgency at those same high levels of influence. What, then, can be done to bridge this gap in the appreciation of non-technical subjects? How might we do a better job of convincing engineers that non-technical knowledge and skills are both relevant and useful? How can we implement the common vision of Jordan, Vest, Florman, and others more effectively? In this article, I offer a new perspective on this quandary that may provide both a path to its resolution and better understand30 |

in terms of problem solving – one of the activities with which engineers are most familiar (in a technical sense, at least) – provides a view of non-technical subjects and their practical value that may be more appealing and compelling to engineers. This framework suggests and enables a new mode of discourse, one that may be more effective in reaching those who remain as yet unconvinced; in essence, the language of problem solving is the language of engineers, and I believe we can (and should) use it more effectively. In addition, using problem solving as a backdrop leads to insights about what it takes to move beyond engineering competence to engineering leadership – a goal toward which we must strive if we are to remain competitive in the current fast-paced global economy.

Communicate, Collaborate, and Do the Right Thing Let’s begin by considering a few of the non-technical subjects most often identified as relevant and important for engineers. Among the designers of engineering degree programs and those programs’ accreditors, it is generally agreed that in addition to some well-defined standard of technical material, the “competent” engineer needs knowledge and skill in several key areas that have their roots in the social sciences and humanities [1], [15]. Some of the most familiar of these are:

Communication Collaboration n Ethics and social responsibility In the first case, engineers need to be able to communicate to others what they do, accurately and persuasively (both orally and in writing), and to understand what others want them to do, where these “others” are becoming increasingly diverse in terms of both discipline and culture as problems expand to cover more different areas of specialization and the corporate workplace spans the globe [7]-[9], [18]. Second, due to the increasing difficulty and complexity of today’s problems and what Florman refers to as the “changing social order” [5], engineers must learn to work effectively in teams (i.e., to collaborate), making best use of diverse human resources (of knowledge, skill, and/or strategy, for example) in order to solve the problems with which they are faced [9]. All of these conditions also lead to increasing demands for higher sensitivity on the part of engineers to the social impact of their actions [6], [14], [20]; engineers must behave ethically and responsibly within a broader social context than ever before. Unfortunately, in the view of many engineers, even these few key subjects are too widely separated from engineering to be relevant or useful, and sadly, this opinion is held by students, faculty, and practicing engineers alike. Their ambivalence (which sometimes borders on hostility) is demonstrated in a number of ways. Florman [5] reports, for example, that many engineering students choose engineering precisely because it is “viewed as having no political or cultural component”; in essence, they see engineering as a discipline that deals with things, not people – and they find the apparently greater predictability of “things” more attractive. In addition, engineers often perceive that non-technical subjects “don’t n n


|

WINTER 2007

count in the real world” despite repeated claims from companies that new hires must be “team players” who are able to communicate and collaborate effectively, both within and across cultures. For the most part, companies continue to employ new graduates (and experienced engineers as well) based primarily on their technical abilities [5], paying lip service to non-technical qualifications or attempting to introduce them through training after the hiring is done. Finally, engineering faculty members themselves are frequently cynical about nontechnical subjects, viewing them as a drain on already limited resources of time and effort within a crowded engineering curriculum.

Problem Solving: A New Perspective on an Old Quandary Part of the challenge in convincing engineers (in any sphere – academic or corporate – and at any rank) that non-technical subjects are relevant, important, and useful lies in demonstrating concrete benefits in exchange for their efforts in mastering them. What, for example, will they do better as engineers if they become proficient in aspects of the humanities or social sciences? Will they design more and better products? Will they build systems more rapidly and efficiently? Engineers are taught to identify and use sound metrics to assess the outcome of any new venture: what kinds of metrics might we use to support the value of non-technical education for engineers? Here, I suggest that moving the discussion into the general domain of problem solving may help us answer these questions and more. Based on the early work of Rhodes [17] and the more recent contributions of Kirton [9], problem solving can be modeled as the interaction of four components that incorporate both technical and non-technical factors (see Fig.

1). Within this model, a “problem” is simply and broadly defined as a gap between some current state and a desired state. To solve a particular problem, one or more problem solvers (person) engage in a problem-solving process (alone or in collaboration) within a given environment, resulting in an outcome or product.

generally and as I have discussed for scientists and engineers in particular [7], a person’s problemsolving style is directly related to his/her preference for structure. In the end, successful resolution of any problem depends on the problem solver(s) identifying and assembling all of the resources (levels, styles) required by that

The language of problem solving is the language of engineers. Kirton [9] uses four fundamental variables – opportunity, motive, level, and style – to describe the problem solver and his/ her interaction with the remaining components of the model. In particular, the environment is the prime source of opportunity (i.e., problems); each problem solver chooses which opportunities to exploit (which problems to solve) under the direction of motive and then attempts to resolve them by bringing to bear the levels and styles required. A key contribution of Kirton lies in his clear definitions of and distinction between level and style, which – despite their independence – are often confounded, with style being the most frequently misunderstood. Level refers to “by or with how much” a person solves problems (e.g., his/her capacity, knowledge, skill), while style refers to one’s preferred “way” (i.e., manner, strategy, approach) of problem solving. As Kirton [9] describes


particular problem and managing those resources well. This notion is best explained using Kirton’s distinction between Problem A (the original problem a team has come together to solve) and Problem B (the automatically inherited problem of managing differences among team members): successful teams spend more time and energy on Problem A than on Problem B [9]. All this means that engineering leaders need to manage diversity well – both diversity of problems and diversity of problem solvers. The latter are diverse in level, style, and motive, but all must remain focused on a common aim within a common process. Engineering leaders need to help everyone in the team concentrate on Problem A and resolve any emerging Problem B’s as mutually undesired distractions. This introduction to Kirton’s work, though very brief indeed, reveals the new mode of discourse I hinted at earlier – one that might be used to

Environment

Person

Process

Product

Fig. 1. A general model for problem solving.

|

WINTER 2007

|

31

“translate” some of the non-technical challenges engineers face when collaborating, using language that sounds more familiar and consistent with the technical aspects of their work. Using these concepts (and corresponding language) as a backdrop, the concrete benefits engineers might

great distances. Returning to the schema in Fig. 1: to avoid misunderstanding, the problem solver (in this case, the engineer) must be able to communicate well in order to perceive all the relevant opportunities within his/her environment, assemble and help guide his/her team (making best use of

Engineers often perceive that nontechnical subjects “don’t count in the real world.” rightfully seek in exchange for the effort they spend studying (say) the humanities or social sciences might include, among others, some or all of the following outcomes: n

n

n

n

Solving more problems (i.e., more Problem A’s) Solving more difficult and complex problems Solving problems more quickly and efficiently Learning how to manage Problem B’s more effectively.

The associated metrics required to assess progress in these areas seem clear: the number of problems solved, their degree of complexity, the time required for solution, the costs involved, the level of satisfaction, and so on. If we can link the study and mastery of non-technical subjects to these goals (and others like them), the value of those subjects may become a bit clearer to a professional community that generally prides itself on its problemsolving function in society. Returning to communication, collaboration, and ethics/social responsibility, we can see immediately the role and importance of communication as an underlying factor in all of the problem-solving goals listed above. Misunderstanding (i.e., miscommunication) is a common cause of project failure – particularly at 32 |

its problem-solving diversity) in order to exploit those opportunities, manage all the processes required, and introduce the product back into the environment, where it will be used and evaluated by other problem solvers, who – in turn – will try to communicate their assessments back to the original problem solver(s). If communication breaks down in only one of these stages, problemsolving performance will suffer. Collaboration, as a second example, lies at the very heart of complex problem solving, as we consider the vast range of levels (knowledge, skills, types of expertise) and styles (preferred strategies, approaches) that may be necessary in order to solve such problems. No one problem solver (engineer) can single-handedly supply the vast breadth and depth that is so often required. From this perspective, collaboration shifts from a “necessary evil” that must be tolerated (a view all too often held by engineering students and experienced practitioners alike) to a fundamental necessity, which – while admittedly a challenge to manage – is absolutely critical to success. The different levels, styles, motives, and perceptions of opportunity provided by other problem solvers (especially those not like us) become added tools in the problem-solving toolbox of the

engineer, along with differential equations, computer simulations, prototypes, and other more familiar tools of the trade. An example of a current, complex engineering problem in which communication and collaboration play particularly important roles is distributed software development. In such projects, multiple teams of software designers and programmers – often located on different continents and in different time zones (and cultures) – must regularly communicate and coordinate diverse and detailed requirements, constraints, resources, outcomes, and feedback asynchronously while maintaining the integrity of the final product and maximizing efficiency. In this context, Sangwan et al. [18] have suggested that a problem-solving framework (such as the one described above) can be used to help project leaders measure, monitor, and manage the gaps in knowledge and skill (i.e., level) and approach (i.e., style) that occur (seemingly without fail) between members of the same team, between teams, and between individuals and/or teams and the tasks they must complete. The results, they propose, are improvements in shared understanding (which is critical to the resolution of any shared Problem A) and valuable insights into the convergent and divergent behavior of collaborating development teams [18]. Finally, knowledge of ethical principles and experience with socially responsible professional practices can also be linked to problem-solving goals. Such knowledge and experience represent additional (level) resources that can be used to support the resolution of many (if not all) complex problem-solving scenarios; we have only to look to the events surrounding the Challenger Space Shuttle disaster or the case of the Citicorp Tower [6] to realize their


|

WINTER 2007

importance. In her discussion of the similarities between ethical problem solving and engineering design, Whitbeck [20] notes: “People confronted with ethical problems must do more than simply make judgments; they must figure out what to do.” In other words, they must develop the skills required to actually solve problems with ethical dimensions, not just analyze them in principle (or in hindsight). According to Lynch and Kline [14], “investigating the socio-technical aspects of engineering practice” will help engineers build those skills by enabling them to recognize ethical problems in real-world settings, thereby preparing them “to address issues of public health, safety, and welfare before they require heroic intervention.” Harris et al. [6] agree, stating: “A significant part of responsible engineering practice is the exercise of preventive ethics: the practice of sound ethical decision making to avoid more serious problems later.”

From Engineering Competence to Engineering Leadership Using problem solving as an underlying framework, we can see now how non-technical subjects might be linked to the successful practice of engineering in ways that are reasonable and potentially more appealing to engineers than those used elsewhere. The model described above also provides a comprehensive framework for the study of problem solving itself within scientific and other disciplines, a matter which I have taken up in other works [7] and to which I will return below. Even more importantly, perhaps, by examining engineering through the lens of problem solving, we can obtain valuable insights into the strategic development of our profession – in particular, insights into how we might move from engineering competence to en-

gineering excellence and beyond – to engineering leadership. In confirming that all humans are problem solvers with the potential to assume leadership roles within problem-solving situations, Kirton [9] notes that problem-solving leaders in any discipline need to have three things: n

n

n

enough domain knowledge to be competent, knowledge and understanding of problem solvers, and knowledge and understanding of the problem-solving process,

where “domain knowledge” refers to content from the relevant discipline – here, engineering. Within engineering education, we seem to have the delivery of our domain knowledge fairly well in hand (although there is always room for improvement, of course). In adding communication, collaboration, and ethics to the pedagogical and practical menu, we are beginning to cover more of the territory Kirton recommends for developing engineering leadership, but we must take care not to separate these subjects (and others like them) from the underlying framework we have built to support and link them together. In other words, we must add knowledge about the general domain of problem solving to the menu as well (which will bring in psychology by default), broadening the scope of each engineer’s non-technical expertise still further. The greatest weakness in the problem-solving education most engineers receive today is simultaneously its greatest strength: namely, its almost exclusive focus on the technical aspects of problems and their technical solutions. Even when students are exposed to situations designed to give them experience in collaborative problem solving, they are rarely given a theoretical frame-


|

WINTER 2007

work for problem solving that can help them manage professional collaborations in the future. As Jonassen et al. [8] describe: “Workplace problems are illstructured and complex because they possess conflicting goals, multiple solution methods, non-engineering success standards, non-engineering constraints, unanticipated pro blems, distributed knowledge, collaborative activity systems, the importance of experience, and multiple forms of problem representation.” A few “team project” experiences in school will not provide young engineers with the foundation they need to handle these far more difficult workplace problems. The problem-solving education that engineers need – though it may not be fully comprehensive – must be rigorous and based upon sound theory and proven application (avoiding some of the pitfalls of the trendy creativity literature – e.g., that nothing works except the wildest “innovation”). Beveridge, a Cambridge scientist, provides a familiar and useful analogy [3]: “It is not necessary to be a mechanic in order to drive a car, nor trained in cognitive psychology (study of the thinking process) or philosophy in order to think or reason. But there are times when the car will not go and times when the usual thought processes do not solve a problem and then it is useful to have a working knowledge of the machinery one is using. This knowledge need not be profound; it often helps to get the car going again if one just knows the general principles of how the machine functions and some techniques that are useful in overcoming common difficulties.” |

33

Here, the “machinery” we are talking about is the human brain – the most powerful and versatile

with which we are concerned, but with the process of problem solving in general: how it is done, and

The engineering leader must understand and be able to manage technological change. “engine” we have at our disposal. Engineers who aspire to leadership need to know at least the “general principles” of how the brain solves problems (i.e., the problem-solving process) – both alone and in collaboration – in order to optimize their own performance and to facilitate the performance of the teams of which they are a part. The problem solver is the leader’s prime resource, and a leader must be well-prepared to manage the problem-solving diversity available within his/her team in order to make best use of it in solving problems successfully. The engineering leader must know how to manage problemsolving diversity for another reason as well: s/he must understand and be able to manage technological change. We, as engineers, expect the users of our products to understand enough about them to use them safely and wisely (or so we hope). In return, it is our responsibility as engineers to consider how our creations influence society, and we can only do so if we understand how technologies and societies change and how individuals respond to both [2], [19]. Engineering is based on the development and validation of models and theories, as well as the development and testing of new technologies. Understanding how those models, theories, and technologies develop is critical; how else (returning to Fig. 1) can we improve the processes and products of engineering? It is not only the solution of any particular problem 34 |

how it is done most effectively. Above all, in this complex world of large, profound problems, we must understand how other, different problem solvers operate, their value in being different, and how to manage them, differences and all. This knowledge (and appreciation for difference) enables us to be good followers and able leaders – as Kirton points out: leaders need to master the management of diversity in order to master the management of change [9]. The questions we must ask in order to gain this kind of understanding are fundamentally philosophical [2], [13]: What kinds of patterns do we find in the development of new theories, models, or technologies? How do we know when a new theory or technology is needed, and how much (and in what ways) should it differ from what already exists? How do we compare and choose between different theories, models, or technologies? These are the kinds of questions that can help us characterize technological change; to understand and facilitate such change, engineering leaders must have a solid, working knowledge of both the history and the philosophy of science and engineering as well. Both of these subjects deal with how science (or scientific change) “works”: history provides an essentially inductive view through its vast collection of examples (we learn from the past failures and successes of ourselves and others), while philosophy provides the theoretical framework in which those

examples can be placed. For excellent examples of contributions made by engineers and scientists to the history and/or philosophy of science and engineering, one need only look to Petroski [16], Florman [4], [5], Lienhard [11], [12], Lipton [13], and, of course, Kuhn [10], among others.

Implications for the Future: Toward a More Esteemed Profession While it may be more expensive in terms of time and effort, the broader view of what an engineer needs to know is surely safer (by including more, it is more conservative) and more sensible to the well-educated person; today, it is also, in fact, critical. As we have noted, while engineers may not need to know everything about other disciplines (indeed, this would not be possible in a lifetime), the complexity and difficulty of the technological problems we now face mandate greater diversity in the knowledge and skills with which we must be familiar in order to succeed; we must know more, and about different things [7]. In considering the general management of such a vast array of diversity, Kirton offers some sound advice [9]: “As with our own bodies (including, critically, our brains), all diversity within a group is potentially useful to its members except that which is manifestly hostile. If the diversity is neutral, then its presence should be seen as yielding more reward than cost. To worry about diversity that is neutral or to spurn one that has a net advantage are the prime ways of mismanaging diversity. Tolerance of neutral diversity is a long-term strategy of survival; acceptance of the cost of managing diversity is a price of survival.”


|

WINTER 2007

In an engineering context, the social sciences, arts, and humanities (among other non-technical disciplines) are at worst neutral diversity; in actual fact, they offer a net advantage more often than not. Engineers must remember that when the value of these subjects is not immediately apparent for a particular problem, it does not mean they are not useful at all; as we have discussed, without them, we will lose problem-solving power in the face of complex challenges. If we spurn them, it is at our own risk. Becoming versed in non-technical subjects promises other rewards as well. As Florman [5] reports, many engineers feel that their profession is not properly esteemed and that engineers are not viewed as leaders in U.S. society, even when they achieve social prominence (consider President Jimmy Carter during his term in office). Clearly, we need to improve the prestige of the engineering profession through – as BenHaim remarks [2] – the “subtle and intellectually sophisticated interplay between science, technology, and man’s understanding of nature and of himself.” Florman [5] claims (and I agree) that we, as engineers, can enhance our position in society (i.e., achieve esteem and higher social status as a profession) by developing and presenting ourselves and the profession as willing and able to “reach out”

to the rest of society (on society’s terms); society, in exchange, will be more likely to reach out to us in return. To propel this vision of prominence and prestige into the future, we must convince engineering students, faculty, and practitioners that non-technical subjects do have value, they do “count” in the grand scheme of things, they are useful and relevant, and they will make them better citizens through greater effectiveness and power in general. The key to delivering this message more directly and more persuasively may lie in showing them how non-technical knowledge will make them better problem solvers as well.

Author Information The author is with the Pennsylvania State University, Great Valley School of Graduate Professional Studies, 30 E. Swedesford Road, Malvern, PA 19355 U.S.A. Email: [email protected].

References

[1] ABET 2005-2006 Accreditation Policy and Procedure Manual. Baltimore, MD: ABET, Inc., 2004; www.abet.org. [2] Y. Ben-Haim, “Why the best engineers should study humanities,” Int. J. Mechanical Engineering Education, vol. 28, pp. 195–200, 2000. [3] W.I.B. Beveridge, Seeds of Discovery. London, U.K.: Norton , 1980. [4] S.C. Florman, “The whole engineer,” Technology Rev., vol. 99, no. 3, p. 67, 1996. [5] S.C. Florman, “Non-technical studies for engineers: The challenge of relevance,” Euro. J. Engineering Education, vol. 22, no. 3, pp. 249–258, 1997.


|

WINTER 2007

[6] C.E. Harris, M.S. Pritchard, and M.J. Rabins, Engineering Ethics: Concepts & Cases, 3rd ed.. Belmont, CA: Thomson Wadsworth, 2005. [7] K.W. Jablokow, “The catalytic nature of science: Implications for scientific problem solving in the 21st century,” Technology in Society, vol. 27, no. 4, pp. 531–549, 2005. [8] D. Jonassen, J. Strobel, and C.B. Lee, “Everyday problem solving in engineering: Lessons for engineering educators,” J. Engineering Education, pp. 139–151, Apr. 2006. [9] M.J. Kirton, Adaption-Innovation in the Context of Diversity and Change. London, U.K.: Routledge, 2003. [10] T.S. Kuhn, The Structure of Scientific Revolutions. Chicago, IL: Univ. of Chicago Press, 1962. [11] J.H. Lienhard, The Engines of Our Ingenuity: An Engineer Looks at Technology and Culture. New York, NY: Oxford Univ. Press, 2000. [12] J.H. Lienhard, How Invention Begins. New York, NY: Oxford Univ. Press, 2006. [13] P. Lipton, “The Medawar Lecture 2004: The truth about science,” Philosophical Trans. Royal Society B, vol. 360, pp. 1259–1269, 2005. [14] W.T. Lynch and R. Kline, “Engineering practice and engineering ethics,” Science, Technology, & Human Values, vol. 25, pp. 195–225, 2000. [15] National Academy of Engineering, Educating the Engineer of 2020. Washington, DC: National Academies Press, 2005. [16] H. Petroski, “Technology and the humanities,” American Scientist, vol. 93, pp. 304–307, Jul.-Aug. 2005. [17] M. Rhodes, “An analysis of creativity,” Phi Delta Kappan, vol. 42, pp. 305–310, 1961. [18] R. Sangwan, K. Jablokow, M. Bass, and D. Paulish, “Asynchronous collaboration: Achieving shared understanding beyond the first 100 meters,” in Proc. 2006 ASEE Ann. Conf. & Expo., Chicago, IL, 2006. [19] C.P. Snow, The Two Cultures and the Scientific Revolution. Cambridge, U.K.: Cambridge Univ. Press, 1959. [20] C. Whitbeck, Ethics in Engineering Practice and Research. Cambridge, U.K.: Cambridge Univ. Press, 1998.

|

35