December 18, 2007

Technical Coordination in Engineering Practice

By Trevelyan, James

Abstract An empirical ethnographic survey of engineers using interviews and field observations in Australia provides evidence that coordinating technical work of other people by gaining their willing cooperation is a major aspect of engineering practice. Technical coordination in the context of this study means working with and influencing other people so they conscientiously perform necessary work to a mutually agreed schedule. While coordination seems to be non-technical, analysis provides evidence supporting the critical importance of technical expertise. Coordination usually involves one-on-one relationships with superiors, clients, peers, subordinates, and outsiders. Coordinating the work of other people seems to be important from the start of an engineering career.

Engineering education only provides limited informal coordination skill development and current accreditation criteria may not reflect this aspect of engineering. This paper suggests ways in which students can learn coordination, and describes some of the author's experiences in applying this research.

Keywords: coordination, engineering practice, informal leadership


Unfortunately, there are few reliable reports of research on engineering practice. Very few observations have been reported, for example, on the actual work performed by engineers, technical managers, planners, technologists, and technicians. Certain processes in engineering practice such as design and project management have been extensively studied, yet many other aspects such as maintenance have hardly received any attention at all. This is all the more surprising given the extensive debates and written literature on engineering education. An accurate account of engineering practice could help educators explain the relevance of coursework to students, helping to provide appropriate motivation for learning. Such an account may also reveal opportunities to improve curriculum design.

This project started as a comparison of engineering practice between South Asia and Australia. First hand observations of unexpectedly high end user costs for engineered services such as water supply, electricity, transport, and construction in South Asia prompted the question, "Is engineering practice different in South Asia compared with Australia?" At the same time, companies in Australia are reporting significant difficulties and financial losses in maintenance, and attempts to improve maintenance have often been ineffective. Solving these problems requires an understanding of both social and technical issues: a detailed systematic understanding of engineering practice is needed.

This paper presents initial results from an empirical study to establish a systematic framework to explain engineering practice in at least the majority of engineering disciplines. Technical coordination emerged unexpectedly as the most prominent aspect of the work performed by the 55 engineers interviewed so far, and it does not seem to have been mentioned in previous literature. Technical coordination in the context of this study means working with and influencing other people so they conscientiously perform some necessary work in accordance with a mutually agreed schedule. It is an informal process, unlike project management which has formalized written methods. Other aspects such as design appeared to be much less prominent than expected. This paper reviews relevant literature and presents a cross-section of quotations from the interviews before discussing some implications for engineering education. The author also presents some of his own attempts to create opportunities for students to learn about coordination and develop some basic skills in light of the results reported in this paper.


What do we mean by engineering practice? Distinctions between occupational groups can introduce arbitrary boundaries, especially between engineers as professionals and other workers such as technologists. In our search for relevant literature we have included all engineering disciplines and aspects, including the planning and organization that leads up to the ultimate production whether executed by production workers, technicians, tradespeople, or machines. It is essential to recognize that most engineering involves highly coordinated work by many people with different roles and responsibilities and success relies on the ultimate production being performed correcdy. Engineers seldom do hands-on production work, yet they are often held responsible for production and service delivery performed by other people: the production or service delivery workers. We can distinguish different aspects of engineering. Planning, analysis, design, organization, and administration precede the final hands-on production or maintenance that results in useful products, solutions, and services, yet all are part of engineering practice. There is no clear dividing line between the different aspects. Engineers engage in handson work and technicians are often involved in planning and coordination [1]. At the same time, we also need to be interested in diverse aspects of engineering work. Engineers may refer to some duties as "not real engineering" work or "all that administrative stuff." They even organize social activities. Yet these aspects are still part of the picture if we are to understand what engineering is all about.

In some discourse, engineering has been considered to be purely technical. For example, Hoag [2] presented a comprehensive account of continuing education and on-the-job learning for engineers without mentioning any non-technical skills training at all. Many academics and students have perceived engineering practice in terms of technical problem solving [3]. On the other hand, Connelly and Middleton [4] surveyed "personal and professional" skills (i.e., non- technical skills and knowledge), even though in the introduction they acknowledged that "enhanced oil and gas recovery methods, decommissioning, and abandonment will have an impact on the skills engineers need to acquire and develop." Barley & Orr [5, Ch. 2] provided evidence of a prevailing image that separates management from engineering. A person is either a manager or an engineer: the former has little or no technical content in his work and the latter has little or no social dimension to his work. Investigations into the loss of the Challenger and Columbia space shuttles also noted this dichotomy [6, pp. 125-6]. However, the research for this paper revealed that engineers were often coordinating the work of other people.

A recent survey of about 120 research publications [7] revealed two major groups of reports. Investigations of engineering education have stimulated about half of the reports on engineering practice. The other half has emerged from researchers who have been interested in engineering management. However, the vast majority of these results were obtained using presumed lists of engineering tasks which do not seem to be based on empirical observations [e.g., 8, 9].

Only a small number of empirical studies can be relied on, mostly using anthropological approaches based on qualitative research [e.g., 1, 5, 10, 11-39]. Several provided field observations and quotations which provide data for triangulating the interviews and field studies in this research. None of the research studies seemed to include a detailed classification of engineering practice or broad enough coverage to attempt to build one. The studies additionally informed by first-hand engineering experience were mainly on design, only one of many aspects of engineering practice. Design carries considerable glamour and status, particularly in high technology and aerospace, and has been studied extensively by many researchers. However, for most of them their interest lay in the design process rather than the less glamorous tasks that designers also have to accomplish. Eckert [40] has reviewed recent research and Vinck [25] presented examples of design ethnography.

Technical problem solving has also been studied by interviewing engineers revealing that technical issues seldom drive the choice of solution [39]. Schon [20] presented one of the earliest accounts written with the benefit of first-hand experience in planning. His interests lie in the reflective aspects of professional practice and he described engineers inventing a new process. He used the term "technical rationality" to describe science-based professionals as technical problem solvers. According to this model "problem-solving is a manipulation of available techniques to achieve chosen ends in the face of manageable constraints."

Solomon and Holt [23] used an ethnographic approach to study mechanical engineering practice with the stated aim of revisions to engineering education. Bucciarelli [10,11] is significant because he was one of the few engineers who has made extensive contributions to the literature on engineering practice. He introduced the useful notion of "object worlds"-domains in which engineers conceive their designs and explain how they work, analogous to the "planes of objects" described by Foucault [41]. Martin et al. [42] interviewed recent engineering graduates to evaluate how well they thought they were prepared to work in industry. In their collection of studies, Barley and Orr [5] attempted to define technical work. They suggested that such work "requires understanding and utilization of abstract knowledge" such as mathematics or science acquired through formal education. They acknowledged that many technical workers, particularly technicians and trades workers, acquire their knowledge and skills through their own experience and by working with more experienced workers (e.g., apprenticeships), rather than through formal education. They also suggested that "technical acumen is the result of contextual and tacit knowledge."

Several social scientists have studied engineering practice to understand the place it occupies in society and the work place rather than the detail of the work itself [e.g., 18, 26, 27, 30, 31, 43]. Social scientists have acknowledged difficulties in understanding technical work "Engineers continue to play havoc with conventional models of work even though they are the prototypical technical workers of high industrialization" [27, p. 34]. One of the obvious barriers for social scientists is technical knowledge, presenting an intellectual dimension that requires years of practice to fully comprehend: "... much of engineering is desk work based on thought processes whose character is manifest only partially in the various pieces of paper that are intermediate products.... Some aspects of engineering practice, especially its technical content, resist observation..." [30, p. 28-29, also p. 35]. More recently some researchers have examined engineering work by men and women to test gender-based models of working roles [e.g., 43].

Of course ergonomics and human factors engineering researchers have studied specific work practices, but the focus has predominantly been on specific machine and process operators (e.g., pilots and air traffic controllers). For example, Reason and Hobbs [19] provided a detailed analysis of errors in aircraft maintenance, yet a detailed description of the work seemed to be assumed as it was not described.

Vinck [25] provided an intriguing study of an engineering design intern that revealed the need for extensive coordination to establish working spatial boundaries. He also pointed out how weak our real understanding of engineering and technological work really was:

We live in an era of paradoxes. On the one hand, we are faced with an ever-growing array of technological developments that affect communication, work, travel, domestic and leisure activities, and political and ethical debates. ... On the other hand, in many ways we do not understand these technologies. The surprising thing is that this is true for technological professionals as well as for lay people. Our situation is characterized both by our ignorance of new technologies and by our faith in them.

It seems that our knowledge of the nature of most engineering practice remains near the state of our appreciation of management in the mid 1960s when Mintzberg [44] started his research on the nature of managerial work. The questions he posed then in relation to managers, such as, "What kinds of activities does the manager perform?," could just as well be asked about engineers and technologists today.

On reflection, the reason for this gap in the research literature might be explained by the relatively small number of people with appropriate research skills and tools and at the same time enough first-hand experience to understand the language and concepts of engineering practice. The question, "What do engineers do?," seems obvious with hindsight. Yet that was not sufficient for this author who had most of the required skills and 20 years of firsthand experience in different fields of engineering. It was the apparent contradictions in South Asia (low labour rates with high costs) that resulted in a serious search for explanations.


This paper reports initial results from a wider on-going study of engineering practice. The empirical research followed well- established qualitative research methods used by contemporary social science researchers. Most data came from transcripts of semi- structured interviews performed by the author. The sampling was partly opportunistic and partly purposeful for maximum variation. The ultimate aim is to include engineers in all major disciplines and types of business (e.g., consulting, private firm, manufacturing, maintenance, operations, sales etc.) with between three and 35 years experience, so sampling reflects this aim. Both companies and individuals were approached with this requirement for interviews. Some companies responded with a cross section of their engineers and others with individuals. Fifty-five engineers agreed to be interviewed so far, with more in mechanical engineering than other disciplines: a list of their graduation disciplines and job descriptions has been provided in appendix A. Three of the interview subjects were female and most had engineering degree qualifications.

Each interview took between one and two hours. Open-ended questions encouraged the respondent to talk about the details of the work he or she performed (appendix B). Follow-up questions (probes) elicited more detail and specific examples when the respondent generalized. The ethnographic method we used allowed interviews to follow the interests of the subject rather than sticking to a pre- defined rigid format [45]. Field studies were also part of the survey: a limited number of subjects were shadowed (with their consent) for one to two days to triangulate interview data. Most interviews were recorded and full transcripts were used for analysis. In cases where recordings were not available, the transcript reconstructed from notes was checked by the respondent for accuracy. We use standard ethnographic analysis techniques on interview transcripts, field notes, and other reference texts [e.g., 46, 47-49]. Similar methods have been used by earlier researchers studying engineering practice [e.g., 1, 11, 25, 28, 30, 32]. Their published data together with independent field observations provided the extra data to triangulate the interviews (providing independent evidence to test the analysis).

The first stage of analysis was a review of the first 25 interview transcripts and this led to a list of approximately 70 different aspects of engineering practice. Substantial engineering work experience was essential to distinguish subtle differences and technical jargon. For example, when an engineer was reviewing technical work performed by others, there was a difference between ensuring that it complied with technical and quality standards, and ensuring that it complied with client standards and requirements. In some cases both checks were performed together, in other cases there was separate checking. Short, non-discipline-specific descriptors appeared to be a useful way to classify aspects of engineering practice in disparate disciplines. The descriptors provided most of the codes for the qualitative analysis of the interview transcripts and other reference data [48].

The next stage consisted of carefully coding of the first ten interviews which revealed the need for a further ten additional coding descriptors, for example "planning maintenance" and "developing technical standards." There was little or no supporting evidence for some descriptors, and others had to be merged when it became clear that the evidence could not distinguish one from another. For example, separate descriptors for "marketing,""assisting clients develop projects," and "researching client needs" were merged into a single descriptor "influencing clients."

The coordination aspect of engineering practice emerged from the interview data unexpectedly. There were three questions in the interview to explore supervision relationships (with superiors, contractors, and subordinates). The initial review of responses led to a single descriptor for supervision and mentoring. There were also a large number of interview responses that referred to interactions with other people that were closely related to supervision in the sense that the interview subject was relying on other people to perform some work or provide information. The term "coordination" seemed more appropriate and general than supervision as most of the people were not subordinates of the respondent. Instead, they were clients, peers, and people in other parts of the same organization, superiors, contractors, and outsiders. These were mostly one-on-one situations and most references were in response to questions unrelated to supervision.

Willing cooperation also seemed to be important. This became apparent from an insightful first-hand comment about C. Y. O'Connor, the engineer responsible for the Perth to Kalgoorlie pipeline in 1895-1899, emphasizing his capacity to obtain the willing cooperation of others [50, p. 135]. The absence of formal authority in most reported interactions led to the conclusion that securing willing cooperation is an important part of coordination.

The very large number of references to this coordination descriptor led to a decision to code the first ten interviews again with a range of descriptors for different kinds of coordination (listed in a later section).

The final stage of analysis consisted of a careful review of all the remaining transcripts and detailed coding of a further 15 interviews using the descriptors described above to test for saturation. (Saturation in qualitative analysis means that further analysis leads to little or no change in the qualitative result.) This step yielded only two additional descriptors and only slight changes in the relative prominence of the different aspects of engineering practice, though further detailed evidence continues to emerge from individual quotations. This result helps to confirm that the sample size is sufficient to develop a map of engineering practice. Coding of quotations and first-hand observations reported in published literature, together with notes from field observations, provided triangulation for this result and did not reveal any gaps. Finally the descriptors were grouped into categories of engineering practice as follows:

1. Managing self and personal career development (8 descriptors)

2. Coordination, working with other people (15)

3. Engineering processes, project and operations management (12)

4. Financial processes (6)

5. Procurement, buying products or services (5)

6. Human resource development, training (4)

7. Business development or marketing, selling products or services (11)

8. Technical work, creating new concepts, problem solving, programming (13)

9. Technical reviews, checking, testing and problem diagnosis (9)

10. Hands-on technical work, construction or repairs (1)

It is important to realize that the framework of descriptors depends on the approach taken by the investigator. It is well known that classification of the kind needed to establish such a framework depends on the individuals involved in the process [e.g., 34, 51]. No similarly comprehensive framework for engineering practice seems to have been proposed before. Solomon and Holt [23] proposed a broad set of seven descriptors, but a more detailed approach has revealed many important aspects missed in earlier accounts. The real test will be whether the framework can be validated (or refuted) by other researchers: this will take time to establish.

A. Coordination in engineering practice

It is important to note that some aspects of coordination did not seem to be obvious to the interview subjects. If technical coordination, for example, was such an obvious aspect of engineering practice that interview subjects mentioned it explicitly, it might have appeared before in standard descriptions of engineering work [e.g., 52, 53]. This quotation from an interview with a highly experienced construction engineer showed how he was not necessarily conscious of the significance of working without formal authority. (The interviewer's question is in square brackets).

[Could we come back to the issue of supervision? Most of these interactions seem to involve supervision without direct authority, don't they?]

Okay, initially an engineer will be coordinating the work of other people. Later he will be given supervision authority over non- engineers. ... Now, of course officially, there is a line of authority. The engineer can take work to his head engineer who can pass the work to the head draftsman who can direct the drafties what to do. But you don't want to rely on that because it involves too many people and it's too slow. It's quite unwieldy and that's why horizontal interactions are essential. That's why engineers spend most of their time using informal coordination methods, working with people over whom, yes, I see what you mean now, people who they don't have any control over working along the traditional lines of authority. ... This kind of situation illustrates why an engineer spends a lot of his time managing up, managing sideways and managing down all at the same time ... you need lots of subtle negotiation. Resorting to authority is a total waste of time as it only creates resistance and the lines of authority may not even exist.

Technical coordination can be described as working with and influencing other people so they conscientiously perform some necessary work in accordance with a mutually agreed schedule. This usually requires three different phases of interaction.

Phase 1: Commissioning the work. The coordinator negotiates an agreement on what has to be done and when it has to be performed.

Phase 2: Execution of the work. Usually it is necessary to be present for some of the time while the work is being done to check that the results (perhaps intermediate) turn out as expected. The coordinator should be able to help spot mistakes and misunderstandings early enough for corrections to be made without delaying completion or adding to the cost. Some misunderstandings may arise from insufficiently detailed work instructions in the first phase. Again, when the results are unexpected, time and resource limitations or lack of technical understanding may necessitate compromises in the requirements. If possible, the coordinator needs to be able to foresee the technical and other consequences of such a compromise.

Phase 3: Checking the work. The final result needs to be carefully checked to make sure no further work or rectification is needed.

The coordinator may not know how to do the work (or even whether the person doing the work knows), nor even what the final result might look like, and may learn some of this through the coordination process. In other situations, the coordinator may need to provide some of the knowledge and help others develop necessary skills. Willing cooperation increases the chance that the work will be performed conscientiously with less chance of mistakes and re-work.

Coordination can seem to be unproductive and time consuming work as this short quotation reveals:

[Tell us what a typical day or working week involves.] I will pick one day rather than a typical day. Wednesdays were our meeting day on site...(describes example of site meetings) The rest would just be random madness, really...

A selection of interview quotes is one way to illustrate different kinds of coordination work. Explicit references to particular companies or individuals in quotations from the interviews have been changed to preserve the anonymity of the respondents.

Quotation 1: A recently graduated electrical engineer talked about his first assignment, working as a site engineer, and his experiences coordinating electricians with little real authority.

On my previous job I had to work with electricians and technicians and tradesmen. They were reporting to me on the previous job, not on this job. [How many?] Maybe three to five. They also reported to other engineers.

For example I had to show them how particular wiring is done. I had to make sure that things are done the way we specified in the cable schedules...and in the design diagrams and carried out in a timely manner.

[How did you know how the cabling was supposed to be done?] That was easy. You just follow the cable diagrams. Actually, one of my first tasks was to look at the cable schedules and make some modifications. That sort of got me to know how the cabling is done. It wasn't that difficult to pick up.

This quotation illustrates one aspect of technical coordination, working as a site engineer. The cabling was installed by electricians but the engineer was responsible for making sure the installation was correct. The electricians probably could read the drawings. However, examining each aspect shown in the drawings and relating the drawings to the actual situation on-site helped both engineer and tradesmen pick up details they might have missed by themselves. The engineer needed to know how the cabling should be installed, the meanings of all the symbols used in the drawings (documentation standards and methods), and he also needed to understand how the cabling is part of a larger system so he could understand the function performed by the cables and hence help to identify any mistakes in the drawings. He had to learn these details on the job because neither cable and wiring drawings nor installation techniques were part of his degree course. It is probable that he learned much of this from the tradesmen on site. He continues....

[And how did you know how long it should take, how could you tell when they were going slowly?]

Okay, I was doing a very hands-on job when I started, I was working alongside the electricians, I was working as an electrician, like a tradesman. I know how long it takes to commission a bus station. In a bus station we have PA systems, the communication system, we have 32 stations along the busways and they are all similar. So once you have done one you know how long each one should take.

His initial first hand experience would have involved learning about working methods and techniques from the tradesmen. He may not have reached their proficiency levels, but he had learned how long the work should take under normal conditions. The following excerpt also shows that a single passage can provide evidence to support several aspects of engineering practice, as in this instance both, "coordination" and "inspection and commissioning testing."

You can also know by the quality of their work They always make mistakes because some of them just cannot be bothered to follow the schedules. Some of them don't mark the cables correctly, others do not terminate the cables correctly. You can just go in and find out the quality of their work when you just start turning things on. Sometimes you can spend just as much time fixing up their mistakes. But that was all very valuable experience on how you handle this kind of commissioning work because you learn from their mistakes.

Spotting mistakes was frequently mentioned in reports of site engineering experiences. Rectifying the mistakes meant discussing problems with the tradesmen and arranging for the rework to be done.

.. .you would ask them "Hey, have you done this task?" They would say "yes, yes, it's fine, it's all done." And then you would go out there and you would find that it is 30 percent completed. There is very little control over the electricians because they are unionized and they get paid a lot more than us. They are direct employees but because they are governed by union guidelines they are not really controlled or managed.

Quotation 2: An experienced contracts manager talked about coordinating contractors. In his early career he qualified in several trades including welding. [In essence your technical knowledge allows you to save money because you can spot the mistakes that the contractor has made?]

Yes, it not only saves money but you can actually go and talk to the contractor while you walk through that paddock and ask, "Are you really serious about what you are trying to do here? What are you doing? This is wrong. I think you are doing it the wrong way round. Maybe you should try this." That's important for the process.

Here he referred to welding work being performed by the contractor. Earlier in the same interview he had shown how revealing aspects of his own knowledge helped to build informal respect and authority reducing the need to resort to formal lines of authority.

I think that one of the things in any contracting relationship is that often we talk about an "us and them" scenario, and too often it is confrontationalist. One of the important issues is to get the respect of both parties in the discussion. A contractor that succeeds means that me, as a client, has succeeded. He gets a good result and I get a good result. If he fails, I have generally failed. Rarely does a project work where everybody has not succeeded, that you have actually got a successful project outcome. You are either over budget or behind time.

In the next passage he finally referred to costs. The "threshold of pain" indicated the minimum cost at which the contractor would perform the work adequately. "Living with the outcome" implied being able to predict the technical consequences caused by accepting compromises in the work performed by the contractor.

So the issue is if you can both respect each other and you can both talk at the same level technically and then commercially you can help each other get a result, you hit that threshold of pain where it is not enough for him but it is more expensive for you but you can both live with the outcome. That's a good result.

Quotation 3: An experienced mechanical project engineer coordinated production personnel who were also working on other jobs. This quote illustrates why continuing interaction is needed: the production staff have skills that can improve the outcome when effectively combined with the engineer's knowledge.

.. .And different things happen, so you can always gain knowledge from people on the shop floor actually doing that. The skilled tradesmen and all sorts of other people, they might think of a better way of doing it. So that's where you gotta interact, otherwise you'd never be there to learn, would you?

Quotation 4: A recently graduated mechanical engineer took over responsibility for installation of a product treatment facility (in the unexpected absence of the project manager). He had to organize the work of each contributor in the right sequence to achieve the required result.

In that role I was the commissioning engineer so I had responsibility for the builders, the electrical engineer, the mechanical inspector, (and) the regional operations staff during that commissioning. We had a 48-hour window in which to get it working. .. .What a rush. I loved that job! I certainly had to have a very good rapport with... all the people I was interacting with.

Quotation 5: An experienced civil engineer talked about what recently graduated engineers learn in the first few years of their career, which in this instance, is site engineering.

Let's start at the beginning of a young engineer's career in a construction company. The first function an engineer would take on is working as a site engineer. Somebody else, some other engineers, have worked out how the job is going to be done. All the instructions will be passed to the site engineer either verbally or usually in writing as well. Now the job of the site engineer is to (a) collect all the information and instruct the foreman on what has to be done and when (b) ensure all the "tools" the foreman requires are delivered to site on time and in the right sequence (c) then he has to go round and see what's coming out of the other end, the quality of the work, whether it's being done efficiently and safely which creates the feedback loop to assess if the planning in (a) was successful and make the necessary corrections.

Collecting information usually required coordinating other people to provide it. Ensuring tool and equipment delivery required coordinating hiring companies and other company staff, and possibly transporters or truck drivers. If the results of the site work did not turn out as expected he may have had to coordinate the contractors to perform rework or corrections.

[What are the kinds of mistakes made by young and inexperienced site engineers?]

The most common mistake is inadequate preparation. Not having read the specification fully, not having looked at the drawings in every detail, not having read the site plan to figure out what's needed on a daily or weekly basis. The job of the site engineer is to make sure that everything that is needed arrives on the site at the appropriate time. You can't bring in everything at once because there will not be enough space to store it and protect it from the weather. And you can't store wet concrete! Forgetting to order enough nails can be a fatal mistake for a carpentry site.

Here we get some insight into the level of technical skills and knowledge needed for effective site engineering coordination. In the following excerpt we see where this could be put to the test.

The next kind of typical mistake is not having enough confidence in his checking role. It takes a lot of energy, time in checking drawings and the work, or the specifications, and a lot of technical knowledge to know whether the job has been done right. Then you have to have the confidence to assert that the job has not been done correctly and request further tests. Sometimes you can be wrong: the tests may show that the job was done sufficiently in the first place. You have to have sufficient strength of character to wear these mistakes and learn from them. The construction job really consists of bringing in hundreds, thousands, tens of thousands of parts and assembling them in the right sequence. You have to be able to understand the materials and how to assemble them correctly to do construction work. You don't have to know how to make all the parts.

B. Discussion

Even though only a small number of interview quotations have been included in this paper, they illustrate several factors.

First, even recently graduated engineers reported significant coordination, often without formal authority, conferred by an organization structure. Most respondents mentioned the importance of maintaining good working relationships and some commented directly on the counter-productive results of resorting to authoritarian or confrontational relationships. This aspect of engineering practice does not seem to have been mentioned in well-known texts on engineering management [e.g., 54] except in the context of cross- functional teams.

The importance of communication in engineering practice was frequently emphasized. In their recent study of graduate perceptions on their preparation for industrial work, Martin et al. [42] commented on the interactions between technical, communication and teamwork skills, and the importance of interpersonal skills. However, they did not show how these are linked in practice.

Although coordination is useful in team situations, most reports of coordination in the interviews did not refer to team work. A good example is coordination with clients, either directly or through staff employed by the client.

Another factor is the importance of technical expertise in coordination illustrated in some of the quotations reproduced. Technical knowledge can be a significant factor that confers informal authority in working relationships, which can result in a currency to trade for influence. Spotting mistakes in drawings and specifications is an important aspect of site engineering: this draws on technical expertise. Engineering practice is commonly separated into "real engineering" or "hard technical" work and "soft skills" including communication. The results of this study tend to support a different view: that coordinating people, and gaining their willing cooperation, is the most prominent aspect of engineering practice for many (but not all) engineers, and that this relies on technical knowledge and expertise as much as interpersonal communication skills.

A different observer might have considered coordination to be a part of management or even project management. Several interviews with engineers working as project managers yielded more references to coordination than other interviews. However, project management is a formal process that includes planning, resource allocation, budget and financial control, progress assessment, reporting, and measurement. Coordination, on the other hand, is an informal interpersonal process. Some aspects listed as part of the coordination group below, such as delegating technical work, could often be considered part of management. Management involves coordination, yet interviews with engineers who did not hold management positions yielded many references to coordination.

Qualitative analysis software provides an easy method to count interview references to codes (in our case to descriptors) that are specific aspects of engineering practice. This does not imply a corresponding proportion of work time, but it does provide strong evidence for the relative prominence of coordination in engineering practice. Figure 1 shows the average number of interview references to the ten different categories of engineering practice listed earlier. Coordinating people dominates the graph, followed by engineering process which includes project and operations management, change management, etc. The proportion of interview references to these aspects has the least variation between interviews.

The previous quotations illustrate several different aspects of coordination: site engineering, contractors, and in-house technicians. Coordination descriptors included: * Working with, and coordinating other people inside the organization, gaining their willing cooperation, mentoring

* Coordinating clients and/or their staff, gaining their cooperation

* Supervising, coordinating, and monitoring work by contractors

* Site engineering, supervising, and monitoring technical work in progress

* Coordinating other outsiders, and external agencies, gaining their cooperation

* Advocating, persuading, compromising, putting one's point of view (e.g., in meetings, one-on-one encounters, or preparing persuasive documents)

* Supervising staff (line management descriptor)

* Delegating technical work

* Delegating supervision of technical work

* Reporting progress to supervisors and peers

* Team building and leading

* Networking to support coordination

* Reverse mentoring: providing informal help for more senior or more experienced people

* Reviewing, developing standard procedures and policies for organization

* Organizing social and recreational activities

In the 25 interviews coded so far, 7.5 percent of all interview references were about coordinating people inside the organization: this was the most commonly referenced single aspect of engineering practice in our study. This was followed by managing projects (4.2 percent), design (3.5 percent), following procedures (3.5 percent), and coordinating clients (3.2 percent).

One must be careful not to place too much significance on the numerical results. The numerical values can be strongly influenced by the way the interviews and analysis were conducted.

We are planning to conduct many more interviews to continue this investigation of engineering practice, particularly with technologists and planners as well as more engineers, and it is possible that this will lead to further refinement of the framework used for analysis. The level of interview analysis has been more detailed than reported in this paper. The coding scheme included many aspects of technical knowledge used in engineering practice. We are also undertaking some quantitative surveys to enable us to estimate time allocated to different aspects of engineering practice as perceived by the respondents.


Engineering education is traditionally viewed as necessarily technical with "some management" or "soft skills" content. The prevailing social view reflects this and sees engineering as a technical discipline, applied science, or specialized technical problem-solving [3].

The science, technology, and society (STS) movement has argued that engineering is both a technical and social discipline because of its inevitable interactions with the society in which it operates [55]. Following this thesis, Ravesteijn et al. [56] argued that engineers should acquire communication skills through projects examining the social acceptability of technology. They saw communication competence in terms of the need to secure social consensus for innovation. However, the evidence from this research suggested that interactions within engineering organizations and with clients and contractors are much more prominent in engineering practice (more than 20 percent of interview references) than interactions with other social actors (average 0.5 percent of interview references). While the social context of engineering imposes constraints that largely define the way that engineering problems are solved [39], interactions at the individual level are largely within the immediate work context rather than external.

The data from this study show that coordination is a prominent aspect in the work of engineers, even at the start of their careers. The engineers we interviewed devoted little of their attention to handson technical work that was largely performed by other people (average 0.12 percent of interview references). Some observers might have included programming as hands-on work In a few cases this was a small but significant component of technical work (average 0.5 percent of interview references). The evidence showed that engineering work was coordinated and driven by engineers, but the end results were delivered through the hands of other people. The link between engineers and the ultimate production and service delivery was a complex series of social interactions. The strength of the evidence presented here leads one to conclude that engineering needs to be treated as a technical and a social discipline at the same time.

STS advocates have argued this on the basis that engineering cannot be separated from the social, political, and economic context in which it operates [25, 55]. However, the prominence of coordination strongly suggests that engineering relies on a social process at the microscopic level of individual interactions between people. Many of the difficulties reported by young engineers entering industries seemed to arise from the unexpected prominence of social interactions [e.g., 42, 57].

Engineering educators have relied strongly on accreditation criteria such as the ABET engineering outcomes [58] and Engineers Australia generic attributes [59] to provide guidance in course design ([60] provided a detailed discussion). None mentioned coordination or gaining willing cooperation specifically. While one might interpret "team work" to mean the same thing, and there are obvious parallels; working in teams is a different experience. Most of the coordination reported in the interview data occurred outside the context of a particular team.

There is no doubt that effective communication is required to win willing cooperation and this probably explains why accreditation criteria and job advertisements place strong emphasis on communication skills. However, defining "communication skills" as an educational objective can lead to many different interpretations that are not relevant for coordination. For example, communication skills could be interpreted as the ability to make technical presentations. However, a visually attractive PowerPoint(TM) presentation will probably not be very helpful in arranging well- timed concrete deliveries at a construction site.

Therefore, we can raise legitimate questions on whether current engineering accreditation criteria mentioning team work and communication skills are promoting effective acquisition of coordination skills in engineering students. Effective coordination relies on a hierarchy of many other more fundamental technical and interpersonal skills such as preparing instructions for technical work (drawings, written specifications), inspecting and checking technical work predicting consequences of technical changes, interpersonal verbal and non-verbal communication, written communication (verbal and visual), selecting appropriate communication strategies, negotiation, mentoring, and informal leadership. Coordination also relies on an accurate appreciation of both individual and shared technical knowledge domains and ways to represent technical knowledge in the working context.

The author is not aware of any engineering course with formal development of coordination skills. While it is not the main aim of this paper to explore formal ways to build effective coordination skills, it might be helpful to review some existing opportunities for informal skill development. Even though there seems to be no specific instruction, an engineering education can provide opportunities for students to learn about coordination and also for informal coordination skill practice.

It is worth posing the question as to whether less able engineering students, especially the least able who manage to pass the course, have acquired basic skills in coordination through necessity: securing the willing cooperation of more able students to help them complete assigned coursework (or even do it for them). This could, perhaps, give them a head start in what seems to be the dominant aspect of engineering practice. One could speculate that, paradoxically, the most able students intellectually may well have had least chance to develop effective coordination skills in a typical engineering course.

An engineering internship could provide opportunities for students to appreciate the importance of coordination by observing experienced engineers. However, in the absence of understanding the necessity and significance of coordination, an engineering student could be just as likely to see it as merely "administration" and not real engineering work Students can only begin to observe coordination if they have some idea of what to expect beforehand.

Engineering faculty could advocate that students develop coordination skills through active participation in community organizations. Both on-campus organizations such as student clubs and off-campus groups such as sports or community organizations can provide plenty of opportunities. Faculty staff could also help to counter a common misperception by students (especially those with work experience) that an engineer can use authority to obtain effective cooperation in engineering practice.

This research has been accompanied by a natural desire to use the results to improve learning outcomes, particularly in team projects. Uneven participation of team members is often reported by students and this may reflect weakness in coordination skills. Since 2001, the author has presented a second and third year course in which teams of students from both courses undertake semester-long mechatronics projects mostly requiring both hardware and software development. Each team typically had two third-year students notionally leading two second-year students. Even with extensive teamwork skills development, many groups have had very uneven levels of student participation that became evident in face-to-face assessments and individually written experience reports. Following this research, the author introduced a team review session in which students evaluated team performance on approximately 40 indicators [61]. The most common issue raised by students was the failure of one or more team members to deliver promised work on time or even at all. This was closely followed by team members reporting that their assigned work is completed when it actually needs further work Some students complained at the amount of time needed to help other students achieve the technical work needed for the project to succeed. In the review session we (the students and the author) worked through and eliminated many possible reasons such as motivation, other commitments (including part-time jobs), and insufficient equipment or tools. We ended up concluding that the most plausible explanation is that the team members did not know how to do the tasks they undertook to complete. We then posed the question, "How would you know whether this is the case?," and the students suggested asking each team member whether they felt capable of performing the task and then confessed that they would be unlikely to admit their own lack of competence. Some suggested requiring each team member to undertake a performance test and then realized how unpleasant this could be. Surprisingly, none of the students suggested sitting with the respective team member to watch them undertake the task and help if necessary. In terms of the model for coordination presented in this paper, the second and third phases of coordination were conspicuously missing. Once this had been pointed out there was some evidence of improvement in team dynamics judging from the difference in team performance before and after this review session but more systematic observations will be required to draw definite conclusions.

The students also visited a major mechatronic engineering installation as a part of the course. Partly as a result of this research, and also to help acquire additional research data, a semi- structured interview was incorporated with one of the engineers associated with the installation work The students conducted the interview using a subset of the research questionnaire [62] and cooperated to prepare an interview transcript. The students also prepared a report on what they learned about engineering practice from their own project experiences, the site visit and interview on which 30 percent of the course assessment was based. The reports suggested that most of the students had understood the significance and importance of coordination work that seemed to be so frustrating and time-consuming in their team project experiences.

Given the prominence of coordination in engineering practice, a more systematic approach to coordination skill development is probably essential for engineering education. This cannot happen without a more accurate view of engineering practice. Given the predominant view of the present generation of academics and students that engineering practice is technical problem solving [e.g., 3], it will take time for a more accurate view of engineering practice to emerge. This can only happen through sustained research. It is surprising that so little research has been conducted, even with the field of engineering education, to better understand the work that we are preparing students to be able to perform. Such research could have several benefits beyond improving our understanding of engineering practice. First, it is possible that serious research attention to the social dimensions of engineering practice could lead to practical improvements in ways to organize engineering practice. Second, academics performing this research would be well qualified to introduce formal methods for students to acquire coordination skills as a part of engineering education. Indeed, without such a cadre of researchers, it will be difficult for academics predominantly based in engineering science to achieve this. Third, engineering students assisting this research effort will learn systematic techniques to observe human behavior on which the results of much engineering practice depends. Fourth, detailed knowledge of engineering practice through systematic research provides greater credibility for a teaching academic to explain the relevance of course material to students.


This work would not have been possible without the support of my family. My colleague Sabbia Tilli searched for relevant literature in so many engineering and social science disciplines. My faculty colleagues Ruza Ostrogonac, Lee O'Neill and students Markus Petermann, Leonie Gouws, Sally Male, Adrian Stephan, Ernst Krauss, Emily Tan, Tim Maddern all contributed to this research. I need to provide anonymous thanks to all the engineers and others who have contributed, knowingly and unknowingly, through their interview responses, comments, voluntary contributions, and suggestions. Feedback from anonymous reviewers and editors greatly improved the manuscript and strengthened the arguments.


[1] Orr, J., "Talking About Machines: An Ethnography of a Modem Job," Collection on Technology and Work, S. Barley (ed.), Ithaca, NY: Cornell University Press, 1996.

[2] Hoag, K., "Skills Development for Engineers: An Innovative Model for Advanced Learning in the Workplace," IEE Management of Technology Series20,]. Lorriman and G. A. Montgomerie (eds.), London, UK: IEE, 2001.

[3] Sheppard, S., A. Colby, K. Macatangay, and W. Sullivan, "What is Engineering Practice?," International Journal of Engineering Education, Vol. 22, No. 3, 2006, pp. 429-438.

[4] Connelly, J.D., and J.C.R. Middleton, "Personal and Professional Skills for Engineers: One Industry's Perspective," Engineering Science and Education Journal, Vol. 5, No. 3,1996, pp. 139-142.

[5] Barley, S., and J. Orr (eds.), Between Craft and Science: Technical Work in US Settings, Ithaca, NY: Cornell University Press, 1997.

[6] Lawson, D., Engineering Disasters: Lessons to be Learned, London, UK: Professional Engineering Publishing Ltd, 2005.

[7] Tilli, S., and J.P. Trevelyan, "Published Research on the Nature of Engineering Work" School of Mechanical Engineering, The University of Western Australia, 2005, jpt/pes.html.

[8] Deans, J., The Educational Needs of Graduate Mechanical Engineers in New Zealand," European Journal of Engineering Education, Vol. 24, No. 2, 1999, pp. 151-162.

[9] Bons, W., and A. McLay, "Re-engineering Engineering Curricula for Tomorrow's Engineers," 14th Annual Australasian Association for Engineering Education Conference, 2003, Melbourne, Australia.

[10] Bucciarelli, L.L., "An Ethnographic Perspective on Engineering Eesign," Design Studies, Vol. 9, No., 1988, pp. 159- 168.

[11] Bucciarelli, L.L., "Designing Engineers," Inside Technology, W.E. Bijker, W.B. Carlson, and T.J. Pinch (eds.), Cambridge, MA; MIT Press, 1994.

[12] Lam, A., "Engineers, Management and Work Organization: A Comparative Analysis of Engineers' Work Roles in British and Japanese Electronics Firms," Journal of Management Studies, Vol. 33, No. 2, 1996, pp. 183-212.

[13] Lam, A, "Embedded Firms, Embedded Knowledge: Problems of Collaboration and Knowledge Transfer in Global Cooperative Ventures," Organization Studies, Vol. 18, No. 6,1997, pp. 973-996.

[14] Lynn, L.H., and H. Salzman, "What Makes a Good Engineer? U.S., German, and Japanese Perspectives," European Applied Business Research Conference, 2002.

[15] Mason, G., "Results of an Industry Survey on Manufacturing Engineering and Manufacturing Engineering Education," Journal of Engineering Education, Vol. 87, No. 3,1998, pp. 211-214.

[16] McCormick K., "Career Paths, Technological Obsolescence and Skill Formation: R&D Staff in Britain and Japan," R&D Management, Vol. 25, No. 2,1995, pp. 197-212.

[17] Mcllwee, J.S., and J.G. Robinson, "Women in Engineering: Gender, Power, and Workplace Culture," SUNYSeries in Science, Technology and Society, S. Restivo (ed), New York NY: State University of New York Press, 1992.

[18] Meiksins, P., and C. Smith, Engineering Labour: Technical Workers in Comparative Perspective, London, UK: Verso, 1996.

[19] Reason, J., and A. Hobbs, Managing Maintenance Error, Aldershot, UK: Ashgate, 2003.

[20] Schon, DA., The Reflective Practitioner: How Professionals Think in Action, Basic Books Inc., Harper Collins, 1983.

[21] Smith, C, Technical Workers: Class, Labour and Trade Unionism, London, UK: Macmillan Education, 1987.

[22] Smith, J.C., "Graduates into Industry-The Transitional Years," Engineering Science and Education Journal, Vol. 1, No. 2,1992, pp. 60-64.

[23] Solomon, F.L., and J.E. Holt, "On the Nature of Mechanical Engineering Work An Analysis of Practice," International Journal of Engineering Education, Vol. 9, No. 6,1993, pp. 442-452.

[24] Stanton, N., M. Ashleigh, and T. Gale, "Cave of Eve: Action Research in the Control Room," in Engineering Psychology and Cognitive Ergonomics, D. Harris (ed.), Aldershot, UK.: Ashgate, 1997, pp. 11-16.

[25] Vinck D., "Everyday Engineering: An Ethnography of Design and Innovation," Inside Technology, W.E. Bijker, W.B. Carlson, and T.J. Pinch (eds.), Boston, MA: MIT Press, 2003.

[26] WhaUey, P., The Social Production of Technical Work The case of British Engineers, MacMillan, 1986.

[27] WhaUey, P., and S. Barley, 'Technical Work in the Division of Labour: Stalking the Wily Anomaly," Between Craft and Science: Technical Work in US Settings, S. Barley and J. Orr (eds.), 1997, Cornell University Press: Ithaca, New York pp. 23-36.

[28] Winch, G.M., and J. Kelsey, "What Do Construction Project Planners Do?," International Journal of Project Management, Vol. 23, No., 2005, pp. 141-149.

[29] Wong, W.L.P, and D.F. Radcliffe, "The Tacit Nature of Design Knowledge," Technology Analysis andStrategicManagement, Vol. 12, No. 4, 2000, pp. 493-512.

[30] Zussman, R., Mechanics of the Middle Class: Work and Politics Among American Engineers, Berkeley, CA: University of California Press, 1985. [31] Crawford, S., Technical Workers in an Advanced Society: The Work, Careers and Politics of French Engineers, Cambridge, UK: Cambridge University Press, 1989.

[32] Darr, A., 'Technical Labour in an Engineering Boutique: Interpretive Frameworks of Sales and R&D Engineers," Work, Employment and Society, Vol. 14, No. 2,2000, pp. 205-222.

[33] Darr, A., "The Technization of Sales Work An Ethnographic Study in the US Electronics Industry," Work, Employment and Society, Vol. 16, No. 1,2002, pp. 47-65.

[34] Button, G., and W. Sharrock "Occasioned Practices in the Work of Software Engineers," Requirements Engineering: Social and Technical Issues, M. Jirodca and J. A. Goguen (eds), London, UK: Academic Press Ltd, 1994,. pp. 217-240.

[35] Brumm, T.J., L.F. Hanneman, and S.K. Mickelson, "Assessing and Developing Program Outcomes through Workplace Competencies," InternationalJournalof'Engineering Education, Vol. 22, No. 1,2006, pp. 123-129.

[36] Barley, S., and B.A. Bechkey, "In the Backooms of Science: the Work of Technicians in Science Labs," Work and Occupations, Vol. 21, No. 1,1994, pp. 85-126.

[37] Holt, J.E., and D.F. Radcliffe, "On the Nature of Mechanical Engineering Work Content and Process,"'InternationalJournal'of 'Engineering Education, Vol. 8, No. 5,1992, pp. 336-344.

[38] Holt, J.E., "On the Nature of Mechanical Engineering Work Generic Professional Competencies," International Journal of Engineering Education, Vol. 10, No. 3,1994, pp. 274-282.

[39] Jonassen, D., J. Strobel, and C.B. Lee, "Everyday Problem Solving in Engineering: Lessons for Engineering Educators," Journal of EngineeringEducation, Vol. 95, No. 2,2006, pp. 139-151.

[40] Eckert, C, A. Blackwell, L. Bucciarelli, J. Clarkson, C. Earl, T. Knight, S. Macmillan, M. Stacey, and D. Whitney. "What Designers Think We Need to Know About Their Processes: Early Results from a Comparative Study," International Design Conference-DESIGN 2004, Dubrovnik Croatia.

[41] Foucault, M., "The Order of Discourse: Inaugural lecture at College de France December 1970," Language and Politics, M. Shapiro (ed), New York NY: New York University Press, 1984, pp. 108-138.

[42] Martin, R., B. Maytham, J. case, and D. Fraser, "Engineering Graduates' Perceptions of How Well They Were Prepared for Work in Industry," European Journal of Engineering Education, Vol. 30, No. 2, 2005, pp. 167-180.

[43] Fletcher, J.K., Disappearing Acts: Gender, Power, and Relational Practice at Work, Cambridge, MA: MIT Press, 1999.

[44] Mintzberg, H, The Nature of Managerial Work, New York NY: Harper and Rowe, 1973.

[45] Trevelyan, J.P., "Definition of Engineering Roles," 2005, Perth: School of Mechanical Engineering, The University of Western Australia.

[46] Strauss, A., Qualitative Analysis for Social Scientists: Cambridge, UK: Cambridge University Press, 1987.

[47] Patton, M.Q_ Qualitative Evaluation and Research, 2nd ed, Newbury Park CA: Sage, 1990.

[48] Miles, M., and A. Huberman, Qualitative Data Analysis: An Expanded Sourcebook, 2nd ed, Thousand Oaks, CA: Sage Publications Inc., 1994.

[49] Huberman, A.M., and M.B. Miles (eds.), The Qualitative Researcher's Companion, Thousand Oaks, CA: Sage Publications, 2002.

[50] Evans, A.G.T., CY. O'Connor: His Life and Legacy: University of Western Australia Press, 2001.

[51] Garfinkel, H., Studies in Ethnomethodology, Englewood Cliffs, NJ: Prentice-Hall, 1967.

[52] McLennan, W., Australian Standard Classification of Occupations, 2nded, Australian Bureau of Statistics, 1997.

[53] Engineers Australia, "Stage 1 Competency Standard for Professional Engineers," 2005, Canberra: Engineers Australia. http:/ /www. publications/ publications-and-supportmg-doaimentation.cfm.

[54] Badawy, M.K., Developing Managerial Skills in Engineers and Scientists: Succeeding as a Technical Manager, 2nd ed, New York NY: Van Nostrand Reinhold, 1995.

[55] Bijker, W.E., "Of Bicycles, Bakelite's, and Bulbs: Toward a Theory of Sociotechnical Change," Inside Technology, W.E. Bijker, W.B. Carlson, and T.J. Pinch (eds.), Cambridge, MA: MIT Press, 1995.

[56] Ravesteijn, W., E. de Graaff, and O. Kroesen, "Engineering the Future: The Social Necessity of Communicative Engineers," European Journal of Engineering Education, Vol. 31, No. 1,2006, pp. 63-71.

[57] Edward, N.S., and J.C.R. Middleton, "Occupational Socialisation-a New Model of the Engineer's Formation," International Conference on Engineering Education. 2001. Oslo, Norway.

[58] ABET, "Criteria for Accrediting Engineering Programs 2006- 2007," 2005,

[59] Engineers Australia, "Accreditation Criteria Guidelines," 2005: Engineers Australia, about-us/ course-accreditation/publications/publications-and- supportingdocumentation.cftn.

[60] Shuman, L.J., M.E. Besterfield-Sacre, and J. McGourty, 'The ABET "Professional Skills"-Can They Be Taught? Can They Be Assessed?," Journal of Engineering Education, Vol. 94, No. 1, 2005, pp. 41-55.

[61] Trevelyan, J.P., 'Team Skills Review Questionnaire," 2005: The University of Western Australia School of Mechanical Engineering, Tutorial-team-skills-review.pdf.

[62] Trevelyan, J.P., "Mechatronic Engineering Work," 2006: The University of Western Australia School of Mechanical Engineering, engrs-workhtml.


School of Mechanical Engineering

The University of Western Australia

Author Biography

James P. Trevelyan is professor and Mechatronics Engineering Discipline Chair at The University of Western