Archive for the ‘Communication’ Category
A tale of two perceptions
Stan was the go-to guy in the IT department. He had a deep knowledge of many technical areas, and had the ability to come up with creative solutions to just about any technology-related problem. Further, unlike your stereotypical IT employee, Stan understood the business (he had worked at this company for several years) and was very articulate. All in all, the perfect IT guy…or so it seemed, until the day Stan was sacked.
His colleagues were shocked, stunned, and many other emotions of a similar shade. They asked the simple question, “Why?”, but got no satisfactory answer from anyone. Management wouldn’t say anything except the official line which was, “Consistently unacceptable performance” – a line his colleagues simply didn’t believe. Getting no believable answers, they indulged in wild hypothesising, which included a conspiracy theory or two. Stan himself wouldn’t say, which only added spice to the speculations.
It turns out the truth behind Stan’s dismissal was really quite simple. Stan was a victim of perceptions – or two perceptions to be precise. Let me explain…
Within the IT team, Stan was indeed the go-to guy. He wouldn’t hesitate to drop what he was doing to help a colleague resolve a technical issue. He’d spend hours reading up on and exploring technologies, writing nifty utilities and even contributing to the odd open source project. All this made him ever more valuable as technical employee. He was perceived by his IT colleagues as brilliant, approachable and always helpful.
Trouble is, folks on the business side didn’t share this perception. They perceived him as being arrogant and unhelpful. A typical complaint from an end-user would go something like, “I told him over two months ago that this report isn’t working, and he still hasn’t fixed it. I asked about it yesterday and he tells me he’s still working on it.”
On digging deeper it turned out that Stan was a serial postponer. He’d continually put off doing work that he found uninteresting. This included any business-related issues, application fixes, new reports or whatever. Stan claimed that his technical workload left him little time to do anything else. So, as the pile of unattended issues on his desk grew ever higher, the business-wide perception of Stan sank lower and lower. He got a couple of warnings which he ignored. Eventually, his manager gave up and put him on a performance management program. Stan dealt with this in the worst possible way. He immersed himself deeper into technical matters, to the further detriment of his business responsibilities. Paradoxically, he continued to grow in his IT colleagues’ estimation whilst incurring the increasing ire of the business. Then one fine day things came to a head and the rest, as they say, is history (as is poor Stan) .
Perceptions matter. Don’t let anyone tell you otherwise. This is particularly important to those who have to maintain a variety of professional relationships in the workplace. Corporate IT is a case in point: folks who work in IT must be able to deal with technical and business people. As illustrated by the Stan’s story, perceptions should be managed on both fronts. Mis-management of perceptions is what leads to the stereotype of the inarticulate, unhelpful, technology obsessed IT employee. Many corporate IT departments have a Stan or two (or more!) lurking within. Such folks would do well to heed this tale.
Communication impedance mismatches on projects
Introduction
Most folks have been in situations where something they’ve said or written has been comprehensively misunderstood by the recipient of the message. When this happens it’s as if the other party is on a different wavelength, thus completely missing what’s conveyed. In this post I propose the term communication impedance mismatch to refer to this phenomenon. Below I explain why this bit of jargon, which has its origins in electrical engineering, is an appropriate one to use in this context. I also look at some reasons why communication impedance mismatches are so common on projects. In this connection, readers may also want to have a look at my earlier post on obstacles to project communication.
What’s an impedance mismatch?
So, what is an impedance mismatch? A good place to start is with some definitions from Wikipedia. Electrical impedance is essentially a measure of opposition to the flow of alternating current in a circuit. The impedance of a circuit component depends, among other things, on the frequency1 of the alternating signal. Now, for a fixed frequency, it is possible to adjust the circuit impedance so that power transfer through the circuit is maximised. This is called impedance matching. Basically, if impedances aren’t matched, power transfer through the circuit isn’t optimal.
Impedance matching is the principle behind radio tuning (and hence a connection to communication). In brief, radio tuning works as follows: impedance varies with signal frequency (or wavelength); so, for a fixed impedance, signals of a specific frequency – the tuned frequency – will be “let through” while the others will be “blocked”2. Although I’ve been using frequency as the variable here, I could just as well have used wavelength as the two are related. So, the wavelength metaphor that I used earlier is really quite apt- if the other party is on a different wavelength they will not get the message.
Anyway, this technical term from physics and electrical engineering has a history of being appropriated by other fields (see this post, for example). As an example from software development, the object-oriented programming crowd use the term to refer to the mismatch between data representations in a relational and object-oriented worlds. The term has a nice “jargony” feel about it. And seeing that it’s been appropriated by others before, I have no hesitation in appropriating it for the communication lexicon.
Why are communication impedance mismatches common on projects?
OK, so why am I so fussed about communication impedance mismatches on projects? Here why: at least one study claims that poor communications are the most frequent cause of project failure. It is therefore worth looking at why communication impedance mismatches are so common on projects. Here are some reasons that come to mind:
-
Team members don’t know each other well: A project is, by definition, a time-bound undertaking with a clear start and finish. Hence, in many cases, the people involved in a project would not have worked with each other before. Even worse, they may not even know each other. Such a situation is fraught with the potential for communication impedance mismatches. To alleviate this, it is sometimes recommended that team members spend time getting to know each other before the project begins. This is often done via team building activities, which I confess I’m not a great fan of. I much prefer letting people find their own niche within a team, rather than forcing a false sense of togetherness through contrived activities. Either way, a project manager has to be conscious of the potential for misunderstandings caused by team members simply not knowing each other well enough.
-
Projects are high-stress environments: Projects can be high stress environments, especially when things aren’t going well. Paradoxically, it is when things aren’t going well that good communication is needed. However, in times of stress, one generally finds that communication impedance mismatches rule. Minor misunderstandings can be blown all out of proportion. At such times, a good project manager acts as an impedance matching device, getting all involved parties to communicate with each other on a common wavelength.
-
Communication gap between the customer and supplier: The objectives of customers and suppliers on projects are typically different, and often even contradictory (for example, the customer wants it done cheap whereas the supplier wants to make as much money as reasonably possible). This fundamental tension between the two parties often leads to communication impedance mismatches. These can be resolved by a project manager who understands both points of view, and looks for negotiated, or collaborative, solutions that take into account both parties’ objectives.
These are just some of the reasons for the ubiquity of communication impedance mismatches in project environments. There are a host of others, which I’m sure you may have come across in your work. I’d welcome additions to the list through your comments.
In Conclusion
Communication impedance mismatches occurs whenever communications – written, verbal or otherwise – are misunderstood. They often occur in a project environment because of the temporary and time-bound nature of projects, and also because projects are comprised of parties with conflicting interests. A project manager has to be aware of the potential for communication impedance mismatches, so that he or she can act to reduce them before they cause unnecessary strife.
1The standard mains frequency is 60 Hz (or cycles/second) in the US and 50 Hz elsewhere..
2I couldn’t find any good, non-technical online references, but see this short explanation or this longer one in Yahoo Answers for more..
Show, don’t tell
My five year old son looked out through our living room window this morning and said, “Dad, I can’t write on the window today.”
“Hmm…,” I said, not really listening. I continued with my breakfast, looking down at the article I was reading.
He repeated, “I can’t write on the window.” Then added, “I did yesterday but I can’t today.” …And shortly after came the inevitable, “Why?”
I looked up and realised what he was talking about: there was no condensation on the window. Yesterday morning our windows had a thin veil of condensation on which he could write with his finger. But it was less humid today, so the panes were clear. There would be no writing today. Quite naturally, he wanted to know why.
I launched into a long-winded explanation about water vapour, temperature and condensation. He listened to me politely, but (obviously) didn’t really understand what I was going on about.
I stopped. There had to be a better way to explain this to a five year old.
I got up and went to the kitchen. “Let me show you something,” I said. The little fellow followed, with a somewhat dubious look on his face. I had lost credibility and he wasn’t about to cut me any slack.
I filled the kettle with some water and turned it on.
“Wait and watch,” I said, unfolding a step ladder so he could have a good look-see at what was happening.
He clambered on and watched as I held up a glass near the spout. I had his attention now. “Tell me when you see something,” I said.
“I see it now, I see it now,” he said, pointing excitedly at a sheen of condensation on the glass. “I can write on the glass!”
I launched into another explanation of water vapour, humidity and condensation. But this time I could see that I was getting through. He listened, and asked questions which I answered as best I could. It was great!
I was late for work this morning, but it was worth it. I’d been given a refresher course on a vital aspect of communication: show, don’t tell.
Eight to Late 