A quick Google search shows that Transactional Communication is a) not in Wikipedia (Oh NOES--does it still exist if it's not represented accurately or inaccurately in Wikipedia?) and b) is a phrase associated with a child learning from an adult what conversation is supposed to be like as part of his/her development.
The reason that I use the phrase "Transactional Communication" is that, much like higher math skills elude me, the concept that someone other than the person talking is supposed to get something out of the communication eludes a lot of other well-meaning people. Aside: I can probably be bothered to figure out how tall a tree is from its shadow but if you ask me about the spin on a baseball I'm going to start whistling and pretend I cannot hear you.
This is, again, not to say that all people wander around declaring orders and expecting that they will be obeyed blindly; what it is to say is that people are often mistaken about the transaction in question, or about the way to get what they want to get out of the transaction while still making it possible for the other person to get SOMETHING, too.
For example: IS/IT has moved a development code creation to production. There is silence. Information Services/Technology assumes that you and the devs will know that if they contact you, there is a problem, and that otherwise, all is ok. You and the devs, however, are on pins and needles as there is severe disapproval (tm) in the future if this code change takes down the website.
Setting up a communication plan for releases can relieve this burden and set up the transactional part--where both parties get what they need. In this case, IS/IT learns to let the devs know immediately to let them monitor backend information which, in the long haul, saves them from having to do it and the devs are Johnny on the Spot in case something goes wrong. I could go on at length about release process, but I would bore even myself if I did so. The moral of the tale is that if they know they are getting something, they'll give something. That's a transaction. Communication is how you get to the right set of circumstances that everyone is
Another example: this works when you're a project manager and you need information from a developer; the developer, no matter how gently you tell him his or her feet will not be held to the fire for their estimates, will be hesitant to provide them (even if you've been great about those estimates the last five times you've asked). But, if instead of just ASKING for something in the transaction, you GIVE something to them, and they're more comfortable giving you the estimates. You give them a promise to send them an email indicating that you are not setting these numbers in stone, that they are just preliminary, and that you will cc the people who want your estimates, the developer, and his/her boss on that email. Top that off with something the developer wants--anything from chocolate to an hour or two with a subject matter expert to get through a thorny problem--and all future transactions of the estimate nature will go far more smoothly.
Consciously or not, people are constantly considering these questions in a work place conversation: 1) What am I getting out of this? 2) Is it worth my time I might otherwise be using to do something else? 3) Is this going to get me in trouble if I do/don't pay attention? 4) Am I going to end up with more work/my favorite project taken away? 5) How reliable has this person I'm talking to been in the past?
You need to make answering those questions part of your every day conversations. It won't be seamless at first, but letting people know that working with you, giving you what you need, will not only spare them trouble, but will get them something they need (tangible or intangible) makes the transactional nature of communication work FOR you, instead of haphazardly or against you.
Now I want chocolate.
No comments:
Post a Comment