1300 130 447
internal and external
Source - HDI Report
About the Knowledge Base
Search all the Knowledge Base
Testimonial: I have found that the new HDAA Knowledge Base reduces the time it takes me to research industry stats & reliable information for the ITSM sector. It’s easy to use search functionality encompassing KCS principles, helps to filter & tailor my searches more accurately & there are numerous new services now available through the website. Every time I return to the site there is new information published. Very impressive.
Chris Powderly, Support & Services Manager, Allens
supportworld , customer experience , support center , ITSM
No Result Found
One Saturday afternoon a long time ago I was leading a family karate class made up of about 80% kids. I’ve been involved in martial arts for almost 25 years, and this day I was teaching a particular movement from a karate kata (a pre-arranged form of techniques). Giving some instructions, I also demonstrated the movement for good measure. Then I gave the command for everyone to try it and...no one did anything. Complete deer in the headlights looks. “OK,” I thought, “let me try this again.” So again, I demonstrated, and explained in even finer technical details. Same thing; just stares. Finally, I tried one more time, and somewhere into my “Now turn and then facing 45 degrees this direction with your weight 60/40 on your back leg” spiel, one of the parents interrupted me and said, “They’re kids. They don’t understand angles and degrees. Just tell them to face the clock….”
It was a watershed moment for me in my instruction. And not for the reason that most people think: that I was just being too technical for a kid’s class. That was obvious. It was the power of his strategy of speaking (talking out of place to tell me vs. pulling me aside after class) with something that was easily seen (the clock on the wall), that those two things in conjunction were extremely effective. But why? And could it be something I applied to my profession in IT as well? Summarizing the learnings I’ve absorbed over the years from that analysis is the goal of this article, and it hinges on understanding the nuances between being transparent and having effective communication.
I’ve touched on this subject in a few of my other articles, but I’ve never really delved into the nuts and bolts of it. So, I’ll start off by explaining what I mean by transparency and how that is different from communication. Transparency is “operating in such a way that it is easy for others to see what actions are performed. Transparency implies openness, communication, and accountability.”
What’s interesting is that by this definition it implies communication; it itself is not communication. I would also keep a very close eye on the word “easy.” This is subjective, and I would argue is necessary but not sufficient. OK, well then, what’s communication? Communication is “the act of conveying meanings from one entity or group to another through the use of mutually understood signs, symbols, and semiotic rules.”
Notice here that communication is an act—you’re doing something. Also notice the word “mutual.” The effectiveness of communication is based on mutual understanding. So transparency is basically how easy you can see something, and communication is an action conveying meaning and intent.
At this point, I’m sure at least some of you are saying, “I mean really, we’re digging at semantics and wordplay here.” To that, I would argue this article is meant for you. Why? Because think of the last time you either were caught or tried to catch someone in a process error that was “clearly” evident (“transparent”)...in the middle of a paragraph...in a three page email (an electronic form of communication)...from two weeks ago...sent on the weekend (a strategy for that communication). Get my drift?
Or, put another way, suppose you’re driving during a stormy night in an unfamiliar area. It’s raining, and you happen to miss a stop sign. Don’t worry, you’re fine (no other cars are coming), you just get the jitters and kick yourself for the infraction but are otherwise OK. Well, what could be a better symbol of communication than the stop sign? It’s mutually understood, it conveys meaning, and it’s huge and red. But given the conditions of the storm and your unfamiliarity with your surroundings, it wasn’t transparent to you that it was there. The stop sign itself is still just as communicative as before, but it wasn’t effective. Understanding the nuances and interplay between these two concepts is critical.
Let’s look at an example of this in our IT service offerings: rolling out a new feature or process. Hopefully when that’s done, there is some communication that goes out to the customer with basic details: why this was done, how it’s different than before, who to call for issues, key features, etc. OK, great. But is that being transparent? Or, is it having effective communication? Or both? Well, it depends. Suppose this was communicated by email, and that email happened to be fairly long, with some key details somewhere in the middle. Are you still being transparent? Sure, technically. But it’s wordy. We also hid it with normal fonts in the middle of a paragraph (vs. say using bullets). Remember, “easy” is necessary to be transparent. If it’s hidden three paragraphs down in the middle of the sentence, how easy is this for people to find? Not very. Remember, yes, you can be transparent by throwing all the details in. But some details are more important than others. No one wants a “fine-print” IT department.
Now that we’ve decided on what we want to be transparent about—and it can’t be everything, that’s neither effective nor best practice—how do we communicate it? Let’s revisit the example before. You sent out an email (even a good one—we made it easy because we care about transparency), and so you’ve got your CYA card. But then you get inundated with tickets after the roll-out, and “Why didn’t you read the email?” wasn’t a close code last time I checked. Why is this? Well, it’s because email may not always be the most effective form of communication. Should this have gone out on a Slack channel as well? Have you put up flyers around the office? Was this preemptively spoken about during stakeholder meetings? Something else?
Transparency has to do with the openness and clarity of what you’re trying to convey. Communication has to do with the strategy with which you choose to convey it. So what are some of the ways we can improve these in our service offerings? Here are some examples:
So why did I title this article, “Keeping the Man Behind the Curtain”? It’s because all communication involves value judgements. In fact, judgement calls are an a priori necessity for decision making; how can you choose between A or B without thinking that one or the other will serve you better? There will always be chaos in the system, someway, somehow. Keeping that chaos out of site from the customer is paramount to building confidence and efficiency in your IT processes.
Be too transparent, and you create information overload, leave yourself open to criticism, and transfer responsibility to places that perhaps it shouldn’t be. Communicate too often, and you get into an IT “boy that cried wolf” scenario. So, yes, be transparent. But not too much. Communicate effectively. But not too often. Understand that they are different and understanding how and where they influence each other is paramount. The cost of effective communication almost always outweighs the cost of confusion.
Adam Rauh has been working in IT since 2005. Currently in the business intelligence and analytics space at Tableau, he spent over a decade working in IT operations focusing on ITSM, leadership, and infrastructure support. He is passionate about data analytics, security, and process frameworks and methodologies. He has spoken at, contributed to, or authored articles for a number of conferences, seminars, and user-groups across the US on a variety of subjects related to IT, data analytics, and public policy. He currently lives in Georgia. Connect with Adam on LinkedIn.
No Result Found
- Contact Us
- IT Membership
- Support Centre Association
- Comparison Guide
- Price Guide
- Membership Conditions
Training & Workshops
- Training Courses
- Recent Workshops
- Cancellation & Transfer Policy
- ITIL Training
- ITIL Foundations
- Support Centre Consulting
- Service Desk Consulting
- Help Desk Consulting
- Media Kit
- Update your details
- New account
© Copyright HDAA. All rights reserved.
HDAA - Energising the Service & Support Profession
Help Desk Association Australasia Pty Ltd trading as HDAA
T: 1300 130 447 T: +61 (0) 2 9986 1988 F: +61 (0) 2 9986 1330
E: firstname.lastname@example.org W: www.hdaa.com.au A: PO Box 303, Turramurra NSW 2074 Australia
ABN: 20 088 292 755
Our Services: ITIL | ITIL Training | ITIL Foundations | IT Membership | Service Desk Association | Support Centre Association | Support Centre Training | Service Desk Training | Help Desk Training | Support Centre Consulting | Service Desk Consulting | Help Desk Consulting
ITIL® and PRINCE2® are registered trade marks of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
RESILIA™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
The Swirl logo™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
DevOps Foundation®, is a registered mark of the DevOps Institute.
HDI® is a Registered Trade Mark. HDAA is the Australasian Gold Partner of HDI®.
KCSSM is a Service Mark of the Consortium for Service Innovation™.
SIAM™ is a registered trademark of EXIN.
Apollo 13 Insignia image by 'NASA Johnson' (copyright-free) June 2017 via https://www.hq.nasa.gov/alsj/a13/images13.html
WEB DEVELOPMENT PARTNER