Talk to me - barriers to communication affect everybody

I just ran across a podcast, available on Eddie Awad's blog, that was the first part of a discussion between Awad, Bob Rhubart of the Oracle Architect Community, and Jeff Davies, a Senior Principal Product Manager for Oracle. Rhubart moderated the discussion, which focused somewhat on communication between developers and architects. While I can't really comment on that part of the discussion, part of the discussion was more general, and concerned barriers to communication.

Jeff Davies cited an example that he previously blogged about in October 2008:

Last week at Oracle Open World I had the opportunity to meet a number of folks interested in Oracle products in general and SOA in particular. One gentleman that I spoke with was very technical, but asked me to explain what I meant by, “point-to-point integration”. At first, the question surprised me. Then I realized that I use terms like “point-to-point” and, ‘EAI” so often that I’ve simply come to assume that everyone knew what they meant. This is a hazard of specialization in any field: you assume that everyone you speak with not only recognizes your particular jargon, but also that they have the same definition for those terms that you do.

Eddie Awad went farther back, taking an example from 2006 when he had to start a new project and had to learn service-oriented architecture - not just the technical sections, but also the language that was spoken. This proved to be a challenge, even to someone like Awad with extensive technical experience (Awad has been recognized by Oracle as an "ACE Director," or an expert in Oracle technologies):

I have found the tutorial to be very useful and essential to getting started with SOA and especially BPEL and ESB....

Notice that in the short paragraph above, I used three acronyms: SOA, BPEL and ESB. Well, if you want to dive into SOA, you will be swimming in a sea of acronyms.

Both of them used their blogs to communicate some of the terms and acronyms that they had encountered. Hopefully their blog posts have helped others who are faced with the same situation.

Well, I'm not an Oracle developer or architect, but I certainly run across enough acronyms and special terms in my line of business - some from the industry in which our products compete, and some from our internal processes. For example, the following phrase is extremely meaningful to me:

BCA needs ESB support, and since we know this now, we don't need to CCB it in. We can start with FEC and write the appropriate STRQs and MRs to get us to M-11. Of course, we'll follow P_RGP in the SPP to do all this. And of course BCA will need all the ANSI/NIST and EFTS stuff we do - you know, WSQ and all that. But the ADS handles that with no problem, as does the DES, of course.

Of course.

Of the billions of people in the world, there are at most a few dozen people who understand all of the acronyms that I cited. Several of them are industry standard acronyms (I assume more of my more technical readers know that ESB = Enterprise Service Bus), but some of them are very specific to the building in which I work.

And you can't assume anything. I work for a Fortune 500 company that produces many, many products. My particular group writes software, but some of our software runs on other products that the Fortune 500 company produces. One of these products - let's call it the 57CM - was recently featured in the media, and one of our marcom people let everyone know that the 57CM would be featured. He received e-mails from three people, including people with extensive experience in our products and industry, who had never heard of the 57CM. All of us who work with the 57CM just assumed that everyone in our building knew what it was...

...just like I recently assumed that all of you reading this blog post are aware that "marcom" is shorthand for "marketing communications."

When we're writing for others, we need to remember to look at the communication from their eyes and make sure that it's comprehensible.

Sphere: Related Content