Like so many of the engineers we interviewed for our research, you may think that your job does not really challenge your technical abilities.
This could be because the technical work that you’re involved with seems to be very simple and does not demand the kind of abilities that you were able to demonstrate in your university studies. Another reason could be that the technical aspects are challenging but you have so many other things to do that you don’t get enough time to resolve them properly. All the other parts of your job seem to get in the way.
Well, you’re not alone. Even engineers in full-time research and development make similar remarks.
When you see the research evidence in the book, especially chapter 3, you will find that almost all engineers spend most of their time on collaboration activities, working with other people and communicating with them. That’s normal in engineering.
Engineers tend to think that this is “non-technical” or “administrative” work. Yet, in our research, when we asked engineers whether the non-technical aspects of their work could be delegated to clerical staff or handled by management, almost invariably they told us that this would not be feasible. Although it seems to be non-technical, this work still requires technical knowledge and understanding. Much of it involves monitoring the work of other people like following-up suppliers, contractors, and accounts staff involved in procurement, even following-up on other engineers to make sure that other work will be ready on time.
In the book, I describe how this collaboration work lies at the core of engineering practice, for practically all engineers. It is completely normal and usually takes 60% – 80% of the time.
The difficulty comes in recognising it as “real engineering”.
We are accustomed to associating the notion of real engineering with the kinds of activities that we learned at engineering schools. It involves the technical knowledge that distinguishes us as engineers.
In chapter 5,”What engineers know”, I explain how engineering relies extensively on knowledge carried by lots of different people. Usually it is impractical to you to acquire this knowledge yourself: you just don’t have time. It’s easier to get other people to contribute their skills and knowledge by gaining their willing and conscientious collaboration. And that takes time to organise.
Finally, we have to remember that the value created by engineering almost always relies on work performed by people who are not engineers themselves. They are the people who make and sell the products that engineers design, deliver the services to people who need them, operate the machines and so on. The special knowledge that we contribute as engineers enables all this, but we don’t do that work ourselves. It all relies on collaboration.
The challenge for us engineers, therefore, is to make sure that our specialised knowledge is applied appropriately, so that the results match with expectations. All too easily, other people re-interpret engineering ideas in their own way, a way that seems right to them. All too often, we have to check these interpretations and make sure that the results will be close enough to our original predictions that our clients will be happy with the results.
All this involves a complex series of social interactions in which technical knowledge plays a critical role. In the book I have tried to explain how this happens in a structured sequence of “collaboration performances” so that engineers can begin to see consistent patterns in all this technical collaboration work. In that way, engineers can see that this work still requires their specialised knowledge. Therefore it can be seen as “real engineering”, just as real as solitary design and technical problem-solving work that we have traditionally seen as real engineering.
It’s often called “teamwork” and it is, in a way. Teamwork has been extensively studied by organisational behaviour psychologists. However traditional understandings of teamwork exclude the technical content. It is usually assumed that teamwork is the same regardless of context.
In the book I explain how technical issues often require a different approach. For example, in chapter 9 “Technical coordination: Informal leadership” I explain how an engineer’s technical knowledge is a crucial component and technical collaboration demands something different from what is usually taught in management schools.
As engineers, we have to deal with complex socio-technical issues all the time and they can be much more challenging and demanding than the technical issues that we learned to deal with in engineering schools. That’s the real challenge of engineering.
Is it possible to escape these socio-technical issues by seeking to become a technical expert? That’s how I saw myself, early in my career. I was shy and saw myself as being fairly hopeless when it came to social interactions. However, I soon realised that being a technical expert made you even more reliant on other people to put your ideas into practice. Technical expertise was no escape from having to develop socio-technical proficiency.
In the book I explain how anyone can do this. Becoming an expert is within the reach of all engineers with enough determination and help from other people.