Acronymization and Inclusion (and Robin Williams)
Many organizations and industries fall into this practice, but none can compare with the government’s unrelenting use of acronyms.
29th Jan 2020
Acronymization and Inclusion (and Robin Williams)
Many organizations and industries fall into this practice, but none can compare with the government’s unrelenting use of acronyms. When you work in the government technology space, one might begin to wonder if there is an acronym-per-minute quota that no one wants to talk about. I googled “acronymization” and discovered that it is, in fact, a word. If the government were to adopt it, they would probably call it “ACZ-25” and no one would know where the 25 came from.
This affectation is not born of malice. People slide into acronym-world as a means of demonstrating that they “get it”. As if to say, “You and I are speaking the same language. I understand this space. I can add value here.” Taken on its face, this is not an entirely bad thing. It’s shorthand for getting through the preamble before the “real talk” begins. It instills a feeling of being in-the-know and part of the team.
But there is an unintended consequence: the reflexive exclusion of outside voices and ideas. Have you ever been trying to mingle at a party and it becomes clear that other party goers have an inside-baseball dialect and asking them to elaborate will just slow down the conversation? How long do you keep trying to be heard before you give up?
I have worked for three private sector companies that serve the government space and have witnessed first-hand the immediate barriers to communication that are introduced by the overuse of government acronyms when trying to infuse industry best practices into a government project. You might have a team of developers and experience designers who are eager to work on a government project, but their eyes quickly glaze over once the acronym brigade begins. Once you lose them, it’s very hard to get them back.
Take a quick minute to watch this oldie, but goodie, clip from the inimitable Robin Williams in Good Morning Vietnam: https://www.youtube.com/watch?v=wXlvy3sTTBk
“Excuse me, sir. Seeing as how the V.P. is such a V.I.P., shouldn’t we keep the P.C. on the Q.T.? ‘Cause if it leaks to the V.C. he could end up M.I.A., and then we’d all be put out in K.P.”
Replace Robin’s acronyms with ATO, IL-4, NIST RMF, DODin, SIPR, TIC/CAP, PRA and countless other government IT acronyms and you will sound like a conference call I had four separate times this week.
This problem isn’t unique to private sector companies serving the government. A few years ago, I had the eye-opening experience of playing the role of translator to a group of private sector technologists who were called upon to lend their expertise to government technology projects as part of an experimental White House swat team. You can recruit the best site reliability engineers in the world to scrub-in on a government tech project, but you’re operating at a deficit when you require them to learn your special language before they can begin to diagnose a problem. Countless hours were spent trying to translate and referee a dialogue between the team in hoodies on one side of the mahogany conference table and the team in suits on the other both talking past each other in their disparate native tongues before we could even begin to discuss why a system had a latency issue. No one side was to blame, but it brought the communication barrier into very clear perspective.
Digital service delivery in government is extraordinarily challenging due to the diversity of the user base and the complexity of the services that need to be delivered. We can’t build products that serve only a subset of the general population and you rarely have the luxury of simplifying the product in order to streamline the delivery. Government needs to be able to deliver to the old, the young, the digital natives, the non-English speakers, the “unbanked” and everything in between. There is no edge case. These are hard problems and we need the highest degree of inclusivity to solve them. When you limit the number of your coworkers who can understand what you’re trying to convey, you may find that the very people you need input from — people with diverse backgrounds and experiences — are the very people you are shutting out. We won’t get the input we need to be successful by espousing a cavalcade of acronyms into an echo chamber of uniform perspectives.
Let’s try this. If you work in the government technology space and you find yourself slipping into acronym-world while explaining something, stop for a moment and read the room. Does everyone understand your dialect? Does everyone know your special acronyms. No? Then stop, take a moment and talk it through. Any time you spend doing this will be more than compensated by the ability to retain talent and attention to whatever hard problem you are trying to solve. It’s a very simple way to put inclusion into action.