It’s well known that many professionals have difficulty communicating with people outside their speciality and it’s not unusual for start-ups to be frustrated by an indifferent world – “why does nobody appreciate our great idea??”!

Ironically, this problem exists because we’re intelligent. If we weren’t preoccupied by the complexity of our subject, then we’d get to the point more easily, our explanations would resonate with others and we’d grow in confidence and skill. As it is, we tie ourselves in knots, nobody understands, and we get nervous about repeating the experience.

The very abilities that constitute our added value inhibit the expression of that value.

10 years ago, I started carving out a niche to address this issue for engineers, particularly Applications Engineers and others involved in customer facing work. Trainings and workshops, events, a book, team leader coaching … all aimed at making client encounters more enjoyable and productive for technical specialists.

Looking back on failures and successes (they happen in that order :-), it seems to me that:

1.    The niche is like a narrow radio band – people tuned into it are very receptive while those who are out of band hear nothing

2.    When people do get tuned in, then you can really help them to improve their communication skills and to get more out of client encounters

3.    Walking the talk is key – it’s not possible to work on client encounter skills if you are not out there doing this stuff yourself

For several years, colleagues have been urging me to expand the niche and exploit the potential of my material outside of engineering. This brings me to a final learning point:

4.    Although well-meaning, these suggestions were taking me away from my original objective, which still holds good: to transfer to engineers the most valuable knowledge and best practices on client communication in the minimum time.

To achieve this objective, it’s necessary to be selective, synthetic and specific. That is, to make hard choices about what material is relevant, to condense the chosen material into an easy-to-use format and to demonstrate its use with activities and examples that are adapted for each audience.

Looking forward, my plan is to pursue this strategy by further distinguishing between three types of client-facing engineer. In work with companies of all shapes and sizes, I’ve realised that the issue of dealing with clients changes significantly depending on the context in which an engineer is working:

  • Context 1: Interfacing with clients is a core part of the job (e.g. Application Engineers)
  • Context 2: Interfacing with clients is an important but peripheral part of the job (e.g. Development or Product Engineers with unique expertise that customers need access to)
  • Context 3: Large companies where colleagues in distant departments essentially have to be treated as though they were external customers

Of course, this classification is imperfect, but it has helped me to better adapt training courses and workshops, with their attendant activities and examples, to these different cases. There is a common thread – taking advantage of engineers’ logical inclinations, I bridge the gap between clear cut problems and the subtleties of communication with a simple toolset, providing a practical way to rapidly switch mindsets. Not only that, the models behind the tools help explain why they work, which is an important point for people with a strong need to understand what they’re doing.

In parallel with all this, and in keeping with point #3 above, I am very happy to be working on Business Development for two great companies in the area of Functional Verification: AEDVICES Consulting and Truechip.

I work internationally, getting help and inspiration from contacts all over the world. If you have an interest in the niche I describe, I would love to hear from you. To learn about my activity, please go to www.icondasolutions.com

Many thanks to Paul Pianu, Saurabh Agarwal and Séverine Hessel for their thoughtful comments on this article.