You are currently viewing SemiWiki as a guest which gives you limited access to the site. To view blog comments and experience other SemiWiki features you must be a registered member. Registration is fast, simple, and absolutely free so please, join our community today!

  • Anger in the Field

    When an Applications Engineer's (AE's) response to customer anger is more anger, things can get rapidly out of control. Fortunately, the situation that I am about to describe happened in a training course. It showed up some interesting points:

    1. Role-plays produce realistic behavior and real emotion (although participants sometimes claim that role-plays are not like real life, in my experience people quickly settle into their usual behavior patterns)

    2. When emotions start to boil over, the words used will continue to be rational and adult, but a completely different message is passed at the psychological level. Unfortunately, this is the real (operational) message.

    3. We often suppress emotion to the point where it is not perceptible externally. Nevertheless, our decision-making process is guided by it.

    In this example, the customer complained that the project was being delayed and that, since his was a state-owned company, the political fallout could be gruesome. In reply, the AE said that he understood, that he was himself a part-time elected official (which was true), that he could easily sympathize with the customer’s embarrassment, that he would take the necessary steps, and so on.

    This was a great message, at least in terms of its content. However, in saying this the AE had abruptly interrupted the customer, he had leant forward, eyes blazing, and his voice betrayed an irritation barely under control! Not surprisingly therefore, the customer was unappeased by the AE’s response. He raised further objections and started to define quite rigid demands (the AE should stay on site until all the problems were fixed, etc.).

    To cut a long story short, the conversation degenerated into an unhealthy contest to see who was right.

    The exchange reminded me why training can be fun and frustrating at the same time.

    It is fun because we can discuss and enact interesting scenarios in a safe setting (nobody gets fired, no business is lost); we can fit models to behaviors, and play with theories; we can exercise tools and experiment with processes for solving issues, past, present and future.

    It is frustrating on the other hand because of the difficulty in passing from an intellectual understanding of what to do to genuinely improved operational capability.

    In the above role-play, the AE (and probably the customer) had incoherent behaviors at the intellectual and operational levels. He knew what to do, and he thought that he was doing it (as the debrief showed), but he wasn’t. I will attempt to explain this phenomena using the Transactional Analysis (TA) theory of personality [Games People Play, Berne].

    The TA “ego-state” model splits our personalities into three components: Parent, Adult and Child (see diagram). In brief, we use the Adult component when thinking and conversing rationally at work. The Parent component is what we picked up in our formative years from our parents and other influential figures (teachers and so on). This component causes us to say and think, for example, “honesty is the best policy”, “you shouldn’t eat between meals” and “hard work pays".

    It is from the Parent part of his psyche that the customer remonstrates with the AE. Not explicitly of course. He does not shake his finger like an angry parent. A polite protocol is observed and the words used remain adult. On the surface, the AE replies in the same adult way. Hence, at the intellectual level, everything is fine.

    But, as I just indicated, the customer’s real, psychological message comes from his Parent component (“you naughty little boy!”) and the AE reacts with the angry emotion that comes from the Child part of his personality (in short, the spontaneous component).

    Hence the role-play is a classic example of intellectual, Adult-to-Adult conversation crossed with Parent-to/from-Child, emotional undertones. It clearly demonstrates the gulf between what we think we are communicating and what is really being said.

    I will finish this blog by going back to point 3, above.

    As engineers, we almost always communicate in a logical, detached, Adult-to-Adult manner. Emotion has no place in this type of communication. If 417 more buffers are needed to route the clock tree, then that is exactly what I say – I would not normally explain my emotional reaction to the buffer count.

    Nevertheless I must not confuse absence of emotion in a message with absence of emotion per se.

    Failure to recognize emotion when it arises – for example, anger when a customer is unreasonable – will prevent me from managing that emotion, which is then likely to spill over into my tone of voice and my body language in general. It may also cause me to make irrational decisions, even though I pride myself on my engineering logic.

    My suggestion for dealing with all this is not to abandon logic. Quite the contrary – sound reasoning is needed to solve customer-facing issues. I recommend, however, that engineers expand the number of inputs that they consider when deciding how to act. These inputs must include emotions that they feel inside and emotions that they detect in the people around them. These are additional parameters to take into account - no more, no less. In general, we are not short of computing power, it is simply that we are (unconsciously) ignoring important inputs to our algorithms.

    Opening up to these inputs is not the easiest thing in the world. However, it can be very rewarding and it will help to close the intellectual-operational gap.

    If you are interested in tools and methods for use in field encounters, please watch out for these “... in the Field” blogs. To go further: http://www.icondasolutions.com

    <script src="//platform.linkedin.com/in.js" type="text/javascript">
    lang: en_US
    </script>
    <script type="IN/Share" data-counter="right"></script>