Transferable Skills Training for Engineers

Training for Engineers

This article is not about turning students into engineers. It is about training established engineers in such "transferable skills" as communication, negotiation, team-working and other "soft" workplace requirements. So, the article is mostly aimed at trainers, though all readers are welcome - even engineers!

Who are the engineers?

For the purposes of this article I use the title "engineer" to describe anyone currently employed in a highly technical capacity, and with a sound learning background in Engineering or Science. Clearly there are many such people who do not have engineer as their job title, just as there are many called engineer who deserve the title barely if at all, but for convenience I had to choose one word, and selected engineer.

Training for engineers roughly divides into two branches. There is specialised technical training which is well understood and straightforward in its demands. Or at least it's only as difficult as the subject matter. However there is also a growing demand for non-technical training in a range of topics that feature on the portfolios of most "management trainers": presentation skills, customer service, etc. And this is a minefield.

Ask a group of engineers what training they would like to receive and you could be forgiven for misinterpreting the replies to be a string of car number plates: the Jones-Xerxes JX 73, this new RLK 27 series . . and so on. The point is that everyone currently working in a technical field is constantly assailed by new equipment and sometimes by whole new technologies, to the extent that life can seem like one endless battle just to keep up to date. No surprise, then, if an offer to spend some of an already inadequate training budget on let's say Customer Awareness training is met with something less than enthusiasm.

The problem is of course a common one: the engineering role is often perceived very differently by the post-holders and by their managers. This is especially true when the managers are working to a strict financial agenda while the engineers are dedicated to the notion of absolute rather than relative quality. Add to this the spectre of reorganisation and possible redundancies, and communication between management and engineers is often the first casualty. Sooner or later someone suggests a communications course. And this is where the trainer must boldly go. Into a room of mildly suspicious, partially briefed, largely unconvinced, thoroughly preoccupied, politely hostile, highly intelligent technical wizards. Five minutes to establish a rapport, seven hours to turn them around and re-launch them as born-again communicators.

Of course this is not the way it should be, but there is a long tradition within engineering of throwing short training courses at problems. The course is seen as the most efficient way of acquiring knowledge quickly, to be refined and applied later at work. And there are sound arguments to support this view for technical material. So it is only natural that as engineering ventures into more non-technical training the short course is often seen as the first (and only?) approach worth considering. In time, the idea will filter through that less formal and more continuous methods could be more appropriate, but as every trainer knows there is a time to persuade and a time to acquiesce, if only temporarily.

As trainers we all understand the need to establish and maintain rapport as a matter of course, and it is common knowledge that it can prove a great barrier if the trainer holds, even unknowingly, any preconceived ideas about the course participants. Briefly, I would like to look at three such stereotypes concerning engineers. I have heard all three expressed on many occasions by various management trainers (all of whom, strangely enough, find engineers difficult to work with).

1. Engineers are only interested in equipment

In fact engineers are vitally interested in solving problems. Their interest in equipment depends only on its efficacy in solving their immediate problem. "Equipment freaks" can be found among the ranks of computer or photography hobbyists (now there's a stereotype!) but rarely among engineers. Unfortunately this distinction is only obvious to those who themselves possess considerable technical sophistication.

2. Engineers talk in impenetrable jargon

Physician heal thyself. It wasn't an engineer who gave us "Functional analysis is the first step in developing a standards framework for units and elements of an NVQ". And it is by studiously avoiding training jargon that I hope to make this article readable by engineers as well as trainers. It's true of course that engineers use many "ex-directory" words and acronyms, but is this better or worse than the standard boardroom technique of taking words that everyone knows, secretly endowing them with new meanings and unleashing them on the public with neither explanation nor apology?

3. Engineers are poor communicators

So are the French to a monolingual Little Englander. But the politics of the situation should be understood. Engineers "became" poor communicators in recent times when they were suddenly required to talk like accountants or salesmen. But if the political climate changes again, will accountants be able to talk like engineers? The entirely serious point is that those whom circumstances put in the ascendancy often see little need to meet others halfway, preferring to forget that communication is a two way process.

Having I hope shot down these few stereotypes, let's turn now to some of the pitfalls and surprises that await a trainer facing a group of technical specialists for the first time. Again I would like to look at three innocent mistakes that can irredeemably destroy much of the trainer's credibility in the eyes of the group.

1. Accidental Patronising.

To patronise our participants ranks high in the trainer's list of capital crimes. We wouldn't ask professional orchestral players to clap along to nursery rhymes, so why do we think it's OK to ask engineers to build towers and bridges with Lego and rolled-up newspaper? Of course the point of the exercise may be to illustrate teamwork, and the Lego is then no more than a vehicle, but why give ourselves the uphill struggle of having to justify a very dubious choice of exercise? More generally, newly appointed managers, from whatever discipline, often realise that in spite of a creditable background as expert practitioners, their promotion to management has effectively reduced them to total beginners (a phenomenon that deserves to be called shrinking into the job, but never is.) As such they welcome and do not feel patronised by conceptual training using simple models - the simpler the better in fact. However engineers who are still working in their field of expertise have not made this transition from fighter to sponge (if I may so characterise it) and are therefore much more likely to feel patronised.

2. Accidental misinformation.

It is a common enough presentation technique to use graphs to illustrate trends, but even this can be dangerous. A non-technical group will latch on to your spoken words and happily accept that your graph somehow reinforces your message, perhaps even lending it some authority. But present a graph to an engineering group and you had better be absolutely certain that it's valid. It is not always appreciated that though a graph explicitly presents the information used to draw it, it also makes implicit statements that can be read instantly by any engineer used to mentally extrapolating, integrating and differentiating as routine procedures. If even one of these implicit conclusions contradicts your message, you can quickly find yourself forced into an indefensible corner.

Just as an aside, if you do show graphs to engineers don't waste time explaining them. Either the graph is correct and properly presented in which case no explanation is necessary or else it isn't in which case none is possible!

3. Gross oversimplification.

Show me a management trainer and I'll show you some pretty pictures. Like these:

let's oversimplify, shall we?
let's oversimplify, shall we? | Source

Figure 1 represents the influences felt by an individual within an organisation. Or at least it would if we wrote the right words in the circles. But then so does figure 2. And either sketch could equally well serve to represent any number of unrelated business or social phenomena. (Someone should publish a book called "100 favourite training blanks".) As a general rule these oversimplifications fail to impress engineers. If you know only too well how quickly the system diagram can grow for even a simple deterministic machine, you are unlikely to accept that human behaviour can usefully be reduced to three lines and a dot.

"Why are they so negative?"

Even if we manage to avoid the pitfalls mentioned above, we can sometimes be taken aback by engineers' apparent unwillingness to accept or even to try new ideas. But we shouldn't be surprised. What we are seeing is scientific method at work. In applying scientific method, you first try to prove that an idea is false, and only if you can't do it should you consider adopting it (on the grounds that it might be true). Imagine yourself maintaining thousands of pounds worth of equipment and you soon see that this is the only way to avoid costly mistakes.

Nevertheless it can be soul-destroying to feel your ideas subjected to often devastating analytical criticism at every step of the way, especially if you don't quite realise what's going on. Then again, the rewards of convincing the group (which in practice means helping them to convince themselves) are all the greater for the intensity of the process.

Finally, I'd like to round this article off with a few thoughts about how engineers like to approach learning. First an example: A "typical" engineer decides to take up the flute. Two weeks later he (and the typical engineer is still male although this is slowly changing) will be able to expound on the relative merits of conical and cylindrical tubing and their effects on the harmonic structure in the top octave, but he will still play like any other rank beginner - all wind and no toot.

This illustrates the engineer's ability and need to assimilate data and to intellectualise an activity. Unless the aim of a training event is to change this learning style, the trainer is well advised to cater for it and to be prepared to provide all the necessary facts and arguments early in the proceedings. This is not as reactionary as it might at first appear. It is merely recognising that in engineering the heart follows the head, and, if you would inspire your technical team to change their approach, you should first help them to the intellectual conviction that a change is a good idea.

More by this Author


Comments 9 comments

topstuff profile image

topstuff 8 years ago

Excellent information about engineers,i will keep in mind all this good and bad about engineers.i do think it cannot be implicated to all.thanks


Paraglider profile image

Paraglider 8 years ago from Kyle, Scotland Author

Thanks topstuff. Of course there are many generalisations in the article, but I've worked extensively as an engineer and as a trainer, and know the 'typical' characteristics of both groups.


Jen 8 years ago

Do you have any recommendations for non-technical / skills training?


ArchDynamics profile image

ArchDynamics 7 years ago from Orlando, FL

Hey, D.-

This is an older Hub, obviously, but near and dear to my heart. As a tech person who moved into corporate training, I'm aware you could easily expand this into several volumes.

One of the first things I learned was the psychology of technical jargon as applied to 'civilian' situations, as follow ...

There are only two reasons to use technical terminology:

1. (Bad Reason): To impress yourself and by extension, simultaneously confuse and impress a client, and

2. (Good Reason): When a technical term allows you to use one word in place on ten.

If you're using that term for Reason #1, you have ego issues and you're fired.

If you're using it for Reason #2, you need to take the time to meticulously define the term and ensure the Client is crystal-clear on said definition every time it's used. In which case, you took 5x the time you should have anyway. Oh, and by the way, you're fired.

This was drummed into our heads repeatedly to avoid self-congratulatory technical bombast and create Client empathy. It also blew 8 out of 10 of us out of the training program.


Paraglider profile image

Paraglider 7 years ago from Kyle, Scotland Author

Thanks AD - this was actually an article I wrote for Practical Training magazine in my far off BBC days. But much of it still feels current. Thanks for your examples. They ring true.


Neil Ashworth profile image

Neil Ashworth 6 years ago from United Kingdom

This is good information and an interesting topic to write on. Thanks for sharing your knowledge.


Paraglider profile image

Paraglider 6 years ago from Kyle, Scotland Author

Thanks for commenting, Neil. I'm considering writing more on this field, but it will have to wait till after my current project.


Andy Betts 2 years ago

Did you ever write any more on this subject? I found your observations pithy and accurate (I specialise in training for engineers). Thanks for writing this article.


Paraglider profile image

Paraglider 2 years ago from Kyle, Scotland Author

Andy - I did write a few articles on related subjects which were published in the (UK-based) Institute of Training and Development's monthly magazine, before the ITD was subsumed into the Institute of Personnel Management (which then became the Institute of Personnel and Development). But that was nearly 20 years ago. Thanks for commenting.

    Sign in or sign up and post using a HubPages Network account.

    0 of 8192 characters used
    Post Comment

    No HTML is allowed in comments, but URLs will be hyperlinked. Comments are not for promoting your articles or other sites.


    Click to Rate This Article
    working