Engineers are problem solvers

This idea is one of the most deeply embedded misconceptions about engineering.

Our research tells us that engineers see themselves, more than anything else, as technical problem-solvers and designers. However, once we properly understand the context of engineering practice, we can understand that the act of problem solving needs to be seen very differently from the perspective shaped by our experience of solving several thousand ‘textbook’ problems from which young engineers learn their fundamental engineering science.

Students and novice engineers often think that . . .

Research shows that . . .

Solitary work on technical problem solving and design form the main components of engineering practice.

Other aspects are either irrelevant or of lesser importance.

Solitary design and problem solving usually make up less than 10% of working time;

analysis and modelling also make up less than 10% of your time (except for a few engineers).

Expert engineers know how to avoid problems, rather than having to solve them. Problems without well-known, tried, and tested solutions only add to uncertainty.

As we shall see in the next section, there is much more to engineering than design and problem solving.

There is no question that many engineers see the intellectual challenge of solving difficult technical problems as one of the most satisfying aspects of their work. In our research interviews, many engineers talked about particular problems that they had managed to solve as though they were milestones in their career. However, a more interesting finding was that most engineers could recount a relatively small number of these instances. Engineering is much more about routine process than solving difficult technical problems. Much of the routine has evolved as a way of avoiding the need to find unique solutions for problems that have been effectively solved many times before.

Studies of engineering problem solving show that engineers seek solutions from other people as often as they try to set about solving the problems for themselves.

Knowing who to ask is one of the best ways to find a solution for a technical problem in the workplace.⁸

Some engineers might counter this by claiming that nearly all their work amounts to seeking solutions to technical problems: it is just a matter of the particular approach

that is used, while most problems can be solved using routine processes. However, once we expand the idea of problem solving to embrace most of what an engineer does, problem-solving itself becomes much less ‘special’. In fact, every human being is a problem solver in that sense. Life is a succession of problems; we all solve problems every day of our lives. How do we drive to work and avoid the worst areas of traffic congestion? How do we find a parking place? Which is the best train or bus to catch to match my schedule today? What should I do first when I start work this morning?

We all deal with these problems in a routine way without even thinking about them.

So, yes, engineers are problem solvers . . . but so is everyone else. The fact that engineers are problem solvers doesn’t get us very far in understanding the engineering practice.

Design and technical problem solving are certainly significant aspects in the work of most engineers, but as we shall soon see, other aspects take up much more time and attention from engineers.

Practice concept 5: Engineering is much more than design and problem solving

A research study on our own graduates⁹provided strong evidence that social interac-tions and communication (mostly on technical issues) take up much more time than solitary technical work, such as designing and problem solving. Separate research stud-ies on engineering problem solving have revealed that it is actually social interactions that provide access to the necessary expertise for expediting solutions.¹⁰The following tables show perceptions from our own graduates on how they spent their working time after 6–9 months in their first engineering jobs.

126 respondents (graduate engineers in their first 9 months of employment) esti-mated the time spent in a previous week on each of the aspects of their work that was listed in the tables. They could choose from the following: none, <2 hours, 2–5 hours, 5–15 hours, or >15 hours. Responses were interpreted as median time values: 0, 1, 3, 7, or 15 hours, respectively. The total for different respondents varied (both as an artefact of the discrete choices and also possible overlaps, e.g. calculating while inter-acting with people face-to-face). Therefore, the time fraction for each category was calculated, and the resulting fraction was averaged across groups of respondents in each discipline shown in Table 3.1. Some respondents may have interpreted <2 hours as indicating a nil response; therefore, percentages at the low end should be treated as negligible amounts of time.

Most engineering students expect that solitary technical work will be a big part of their working life and hope that they will enjoy the challenge of working with dif-ficult technical issues in the context of advanced technology. The results of our study, particularly the relatively small proportion of time devoted to solitary technical work, have helped to explain some of the frustrations I have so frequently encountered among engineers. Many felt frustrated because they did not think that their jobs provided them with enough technical challenges. Others felt frustrated because they thought that a different career choice might have led to a job that would enable them to make more use of the advanced technical subjects they had studied in their university courses. Many of them were actually planning to leave their career in engineering. In our research, we found that more experienced engineers, those who had stuck with it for a decade

Electrical Pilot

Civil Mechanical Electronic Mechatronics Others Study Ave.

Face-to-face 13 13 10 11 12 11 11.6

informal

Writing documents 9 10 12 11 13 10 11.0

Calculation and 12 9 3 7 18 7 9.2

Table 3.2 Average perceived percentage of working time.

Ave. Cum.

Face-to-face informal 11.6 11.6

With people on site 5.4 17.0

Meetings 6.6 23.6

Note: These tables report perceptions of time spent on different aspects of engineering work nine months after commencing the first job. The highest figures in each row in table 3.1 have been highlighted. The pilot study group was predominantly involved in mechatronics. ‘Others’ included environmental and petroleum engineers and both these disciplines involved more extensive com-puter modelling work than their counterparts. Table 3.2 reveals that about 60% of the time was spent interacting with other people, either directly or through documents.

Figure 3.2 Perceptions of working time spent on design and software coding by 126 graduates in their first nine months of engineering employment.

Figure 3.3 Perceptions of working time spent on calculations and computer modelling.

or more, had mostly realised that the real intellectual challenges in engineering involve people and technical issues simultaneously. Most had found working with these chal-lenges far more satisfying than remaining entirely in the technical domain of objects.

The data in the tables consists of averages. The following charts reveal more about the variability in the data: the time spent on different aspects of engineering varies from week to week, as well as from person to person, and between disciplines and settings.

The first two graphs demonstrate how most novice engineers in our sample spent less than 10% of their time working on designs and calculations.

The next set of graphs demonstrates how social interactions dominate engineering practice.¹¹Qualitative analysis and field observations demonstrate that social interac-tions cannot be classified as ‘non-technical’. Most of the social interacinterac-tions, whether face-to-face, by telephone, e-mail, or written documents, concern technical issues. The graphs show how there is significant variation for different engineers in any given week. However, notice how the extent of the variation between individuals, expressed as a proportion of the average, is much less than the variation in the time spent on solitary technical work that is shown in the graphs above.

Figure 3.4 Perceptions of total working time spent on social interactions and searching for information prepared by other people, mostly on technical issues.

Figure 3.5 Perceptions of total working time spent on face-to-face and telephone social interactions.

In other words, all novice engineers in our sample consistently spent a lot of their time interacting with other people.

What’s going on here? How can we explain the apparent fact that engineers spend a much greater proportion of their time talking with and writing to each other (and other people) than they do on the solitary technical work for which their university education has prepared them?

I was legitimately surprised with these results. A study performed in 2010 in Portugal and Spain provided similar data. Therefore, these results do not seem to depend on where the engineering is being performed or in which industry the engi-neers are working.¹² Several other studies on more experienced engineers over the last 50 years have provided similar data: engineers spend about 60% of their time on communication activities and socio-technical work.¹³What was particularly surpris-ing to me was that novice engineers, most in notionally technical roles, with little or no management responsibilities, were spending exactly the same proportion of their time (on average) on social interactions as more senior engineers. The proportion of time

Figure 3.6 Perceptions of total working time spent on social interactions performed by preparing, exchanging, and reading documents and text messages.

spent on social interactions seems to be independent of discipline, experience level, and geographic location.

Another study using data obtained from interviews and field observations provided similar data for engineers with three or more years of experience. The qualitative data revealed much more about what they were doing in these extensive social interactions.

For a majority of engineers, between 25% and 30% of the time is spent conducting informal leadership in the form of technical coordination: influencing other people so that they conscientiously and willingly perform some form of technical work to con-tribute to a combined result within an agreed time schedule. Examples of this include asking other people to provide information and arranging for people with appropriate expertise to perform part of the work. This is an informal activity: this coordina-tion work is only documented in brief notes in personal diaries, e-mail messages, and reminder lists.

These studies have contributed to a more defined picture of engineering practice that is illustrated in the following diagrams.

The first diagram portrays engineering as an activity with two distinct threads. The upper thread is comprised of three phases. It starts with discerning, comprehending, and negotiating client and societal needs, and then discussing engineering possibili-ties with clients and the broader society through various means. The second step is conceiving achievable and economic engineering solutions that will meet those needs.

The last phase is performance prediction: working out the technical performance and the cost of those proposed solutions. Engineering education focuses almost entirely on analytical tools to support technical performance prediction, along with some basic design skills, which are shown in the dashed rectangles.

The lower thread is rarely mentioned in engineering education: delivering solutions that meet the needs and requirements on time, on budget, safely, with the predicted performance, and with an acceptable environmental and social impact. Despite how commonly it is overlooked, this is where most of the work for an engineer lies. Without this second thread, engineering would not yield anything useful. Solutions on paper,

Figure 3.7 A simplified model of engineering practice.

no matter how elegant, provide little value until they can be translated into reality.

Effective engineers are able to deliver; they get things done.¹⁴

The large arrow represents the idea that experience in the delivery aspects of engi-neering in the lower thread enables an engineer to develop expertise that helps with discerning client requirements, creating new ideas, and predicting performance in the upper thread. This is like a feedback loop: engineers progressively develop more and more expertise as they learn from experience.

What we can take away from the data is that the socio-technical aspects of engi-neering practice that are required for effective technical collaboration dominate the time and attention of engineers. That’s why the core of this book is devoted to tech-nical collaboration. Aspects that tend to dominate engineering education curricula, namely solitary technical work such as calculations, modelling, and design, as well as the aspects that engineers identify as ‘real engineering work’, are a small, yet critical, part of actual practice.

Practice concept 6: A sequential project life cycle model

Figure 3.8 illustrates an engineering project as a vertical sequence of stages (starting from the bottom: each stage builds on the results from the lower stages).

At the bottom, every project starts with discerning needs and negotiating possi-bilities, along with securing funding approval and regulatory approval. In practice, funding and regulatory approval precedes each of the main stages through a ‘stage gate’ decision-making process that is usually unique to a particular enterprise. I will describe this in much greater detail in later chapters.¹⁵Different engineering ventures naturally place different emphasis on each of the stages. For example, in the context of an engineering consultancy the ‘product’ is usually information. In construction, plans and specification documents may be the product, while construction supervision may be an optional service. Plans, procedures, contracts, specifications, and estimates would still be a critical stage.

Figure 3.8 Sequential stages in an engineering project, starting from the bottom, explained in the text below. Not all phases have been included in the diagram.

Design and technical problem solving come next, to the extent that they are needed.

Again, in practice, design and problem solving are often interwoven with analysis and prediction processes in a series of iterative refinements. Even the requirements may be renegotiated in the early stages.

Detailed planning and preparation of all project documentation is usually the last step before the critical financial investment decision is made to proceed with the rest of the project. Typically, by the end of this stage, between 5% and 10% of the project budget will have already been spent. From this point, everything gets much more expensive.

Procurement and logistics, manufacturing, installation, commissioning, and acceptance testing use up the bulk of the capital investment in any project. Predictabil-ity is the key in this stage: engineers are under a great deal of pressure to make sure that everything is completed safely and on time, within the planned budget, and delivered with the required technical performance.

Only in the last step does all this investment start to provide some useful value for people through the tangible products or services provided. This is when payments start to flow back to the investors who provided the funding for the venture. The product has to work reliably for its expected service life, and often much longer. Maintenance plays an important part in achieving this, which means keeping everything working so that the predicted performance is achieved throughout the service life of the product or process. Ultimately, there will be a decommissioning step when the artefacts are removed for reuse or recycling. In the case of a manufactured consumer product, this can happen throughout the life of the product.

Figure 3.9 Invisible engineering.

Few engineers work on the early feasibility study stages of a project, before the final investment decision. However, lots of engineering projects never pass the invest-ment decision point. Many engineers spend much of their time working out which of hundreds of possible projects is likely to be sufficiently valuable enough to be worth presenting to investors. Most of the projects they work on never go ahead;

these engineers create value by providing information for investors that will help pre-vent financial losses by reducing information uncertainty, resulting in better financial decision making.

Many aspects of the work performed by engineers remain invisible and cannot be directly related to the blocks shown in Figure 3.8. Many of these constitute work that engineers don’t regard as ‘real engineering’.¹⁶Figure 3.9 represents similar activity to Figure 3.8, but this time we are looking at a cross-section to expose what is not visible in Figure 3.8. What we see in Figure 3.8 is only the ‘top deck’ of engineering practice;

Figure 3.9 shows the other decks that provide the ‘structure’ without which the top deck would never remain intact. The proportional sized of the different ‘decks’ correspond to the relative significance of each aspect, according to what we have derived from our research so far. From this we can see that, like an iceberg, the invisible engineering aspects are much more significant than the top deck. Technical engineering work that you learn about in your engineering degree course represents, at best, only two ‘planks’

of the top deck. Perhaps you can now begin to appreciate just how limiting it is to see engineering practice only in terms design and problem solving.

These ‘invisible’ aspects of engineering practice have evolved over time to manage all the uncertainties and unpredictable elements of engineering practice that arise from the reality that engineering is a social system that depends on countless individuals and, to some degree, unpredictable human performance.

Many engineers find it hard to even predict their own work. Between scheduled meetings, they react to problems as they occur, so the results from their work will be inherently unpredictable.¹⁷Engineers report that they can have 60 or more separate, simultaneous, ongoing issues for which they are personally responsible. Many do not seem to have a systematic way to choose which ones to work on each day, or in what order these issues should be handled.

Most of these hidden aspects of engineering practice provide a measure of pre-dictability for the end results of individually unpredictable performances by the participants. One of these hidden aspects is helping engineers comply with appropri-ate technical standards to reduce the chance that mistakes will be made that otherwise would not be picked up in time. Technical standards have been created through the experience of other engineers and are carefully negotiated within each specialised engineering discipline, striking a balance between restrictions to promote safety and ease of use, while also avoiding constraints that would inhibit innovation and design freedom.¹⁸

The social process by which this expertise is shared contributes a significant portion of the hidden layers in Figure 3.9 and helps to explain why building relationships with experienced engineers is so critical for engineers that are just beginning their career.¹⁹

Figure 3.10 combines the invisible elements of Figure 3.9 with the sequential life cycle model shown in Figure 3.8. The stack of blocks representing the life cycle of an engineering project is enclosed within a coordination ring that continually guides the implementation steps towards the intended objectives. A web of social relationships

Figure 3.10 combines the invisible elements of Figure 3.9 with the sequential life cycle model shown in Figure 3.8. The stack of blocks representing the life cycle of an engineering project is enclosed within a coordination ring that continually guides the implementation steps towards the intended objectives. A web of social relationships