The power of words is immense. A well-chosen word has often sufficed to stop a flying army, to change a defeat into victory, and to save an empire. - Emile de Girardin
The exact right words can convey a tremendous amount of meaning and can bring clarity to a murky situation. Who had ever heard of "airplane mode" a few years ago? How about "ransomware"? These are words that were created to, so we didn't have to explain the concepts each time.
How clunky would it be to say in the first case that you are putting your phone into a state wherein you are still able to use it to run some apps but in which it is not able to communicate over any of its radios? Or in the second case that someone has encrypted the files on your laptop, thereby depriving you of access to them, until you agree to pay them a bounty via a difficult-to-trace medium?
We in IT are infamous for creating our own acronyms as short-hand for big concepts, but unfortunately these acronyms tend still to be technical or to be a little pejorative. Knowing what ITIL, DHCP, PEBCAK, NVRAM, or POP3 stands for does not necessarily mean that a non-technical person understands any single thing in more detail. Our job should be to create the right words to convey the meaning behind the concepts we are describing.
Several years ago, my IT team and I were trying to explain the different levels of quality assurance testing we did on incoming files from our clients. The first level of QA was around the structure of the file itself. The second level was around the format and contents of individual records in the file. The third level was on the file as a whole and, specifically, its suitability for our business purposes.
We had explained these over and over, but we got a lot of glassy-eyed stares when we said that file was in the wrong structure, a field did not contain reasonable data, or the file couldn't possibly be complete. The point was that we were not conveying how we were progressing toward getting the right files to bring the client on-board to our solution.
What we ended up developing was our own vernacular to refer to the complicated concepts and the likely next steps. The beauty of the vernacular was its simplicity:
A file successfully passed QA1 when it was named correctly, had a header and a footer record with the right information in them, and had the right number of fields. A "QA1 failure" was likely a programming failure and so we knew we needed to work with the client's programming team to get to the next step. We also knew we were not close to being complete!
A file successfully passed QA2 when it has passed QA1 and when the individual fields were correct within each record. This meant that names were made up of characters, telephone numbers were made up of the right number of numbers, dollar values had decimal points, and so on. Since there were always some unfixable exceptions due to bad source data, QA2 actually returns a percentage-compliance score for some test. A "QA2 failure" was likely a database query error or a source data issue, so we knew we needed to work with the client's business analyst or database administrator to move forward.
A file successfully passed QA3 when it had passed QA1, had passed QA2 to a certain threshold percentage, and when it was deemed suitable for our purposes. For example, a file that was named correctly, with a header and a footer with control totals, and a single record with correct fields, could pass QA1 and QA2. However, it that file was supposed to be all open Accounts Receivable records, a one record file was unlikely to be correct, so it would fail QA3. A "QA3 failure" was likely a SELECT issue in a database query or a source database error, so we probably needed to work with the database administrator.
I wanted you to understand a little of the depth that "QA1/QA2/QA3" conveyed to our team, back then, so you can, today, appreciate the value of creating our own language. We got to the point that everyone from the help desk to the implementation team to operations team to the CEO to the Board understood what QA1, QA2, and QA3 meant. This common understanding, and common language, allowed us to communicate large quantities of information simply. It kept us from having to stop to explain what we meant every time we needed to explain where we were in an implementation. It also made for good looking graphics charting our progress!
In your environment, what do you find yourself explaining over and over again? What do you wish you had a short-hand for that everyone understood? You may not be able to invent the next "airplane mode" or the next "ransomware" moniker, but maybe you'll be able to move beyond merely technical acronyms to create the next "QA1/QA2/QA3."