During Thanksgiving dinner I was asked how work was. A typical topic for conversation, especially during the holidays, so I answered with the typical answer of “oh, it’s been fine.” Typically the conversation would peter off there – as many of us know, explaining what we do for work isn’t always the easiest to articulate – but this time I was pressed to talk more about life as a QA tester. I continued on about how I just needed to test a bunch of websites because a javascript error was impacting the CDN and those impacts manifested in the entire website being duplicated continuously.
I was met with a blank stare. The person I was speaking to was not involved in the tech world at all, so expecting them to understand anything at all beyond “that’s bad!” wasn’t a fair ask. I needed to express it in a way the other person could understand so I reworded my description: “all images and text were appearing multiple times on the page.” They said (claimed) they understood after that and the conversation moved on.
In a setting where communication is done remotely, cues like a blank stare are not available to gauge reception off of. Conversations can, and often do, occur where one party will say something that another completely misinterprets. Professionally, these misunderstandings are often related to conversations about work effort – what’s to be done, what’s needed to ensure the work is done, who needs to be involved, and so on – and in the space of web development these misunderstandings can happen easily.
Working within development has certainly highlighted that not everyone has the same level of knowledge. Developers will obviously know more about development than anyone else, and automation testers will usually be able to follow the technical jargon a developer uses far easier than manual testers or business analysts, and vice-versa, where less technical team members may struggle to articulate to developers their ideas. Going out further, some teams overall may have a higher level of knowledge than another team that they directly interact with.
Knowing how to communicate effectively involves knowing how to recognize an audience. On a project, this may require asking oneself who their message is for: is the recipient in the same role? Do they have more or less years of experience? If not the same role, then is it a technical or non-technical role? Knowing these details can impact how many details are given, what details are given, and even what words and descriptions are used. Communication becomes easier when an audience is recognized.
Let’s say that as a developer, I’m trying to talk to someone about an issue with a third party tool not displaying on a page. If I know my audience, I know how to address items such as:
- Vocabulary and Acronyms:
- Different words and phrases hold different definitions for different people. “CMS” for a Sitecore developer may mean “Content Management System” but for someone in healthcare it could mean Centers for Medicare and Medicaid Services. If I were emailing another developer I may not need to explain what a CMS is, but if I’m emailing a stakeholder or even a junior developer I could include the full title once in my documentation/correspondence so the recipient knows without a doubt what I am referring to.
- Context clues can often help at the very least fill in a gap (“I couldn’t log into the CMS to create a new page” can indicate I’m referring to the former acronym instead of the latter) for those unfamiliar but situations may and often do arise where individuals interpret statements differently.
- Concepts and Tools:
- With there being so many development tools out now, the naming convention seems to have only gotten wilder: Unicorn, Screaming Frog, Python, CockroachDB, to name a few. These tools that may be used by one person every day may not even be on the radar for another. While writing up a report on the results of a ScreamingFrog scan explains the details of a report, the recipient of the report may not even know what ScreamingFrog is, let alone what it’s used for and what the results are actually saying. A sentence detailing what ScreamingFrog is could be beneficial; on the flipside, if the recipient of my message is the one who told me to use ScreamingFrog, then I obviously do not need to explain what it is.
- Organizations may run different ceremonies or operations differently. Explaining at first the intent behind different concepts (example being what should happen in a bug triage) can set expectations off the bat.
- Details:
- Knowing what details to include and how many also ties into knowing the audience. In some cases, additional details can provide additional context, but in others additional details may not be needed and can bog down the overall intent of the message. If I’m communicating with another developer, I may not provide as many details about a solution to one who has more experience than me, whereas a junior developer may benefit from the additional information.
In my anecdote, the impact of my Thanksgiving conversation was insignificant: just two people sitting at a table making small talk. In a professional setting, conversations between people with differing levels of knowledge can result in misunderstandings about how long work items will take to be completed, what exactly is needed to complete a work item (who is needed for what task, what tools are needed, what prerequisites need to be addressed before working on the item), how work items are expected to function, and so on, all of which can impact a project’s budget and timeline. Having everyone on the same page throughout the project can reduce the number of follow-up meetings and ensure that development teams are focused on the work that matters; in some cases, it can even reduce the number of defects logged, as work items are both developed correctly to begin with, and those testing know how to properly use a product rather than logging false bugs.