Guest Post: Language Matters

This guest post was written by Koven J. Smith, who makes technology things at the Metropolitan Museum of Art. He writes about the lessons he's learned about how to talk tech with curators, educators, and other museum beings who don't know what "OCR" means (like me).

So here you are, a Sincere Technology Professional with a Great Idea. This idea, which gels rather nicely with your museum’s stated mission, will do great things. You’ve been working on it in the lab (your desk) for months, you’ve done all sorts of proof-of-concept demos, and you can clearly demonstrate that the benefit to your museum of implementing this project will be immeasurable. And best of all, your Great Idea won’t even cost the museum anything! All you need is the approval of your Executive Gatekeeper (usually your director/head curator/lead educator), and you’re good to go. You prepare for months, getting ready to answer every question you think you’re likely to get with well-thought-out, reasoned answers. Then The Day comes. You go to The Meeting with your Executive Gatekeeper, and it goes really, really well. Everyone seems happy, and you walk out feeling excited that your Great Idea is finally about to take flight.

Then weeks pass. Months. You hear nothing. One day, another Sympathetic Professional mentions casually that your Great Idea has been killed off, for reasons that seem to you to be at the least, asinine, at the worst, paranoid. It’s almost as if (gasp!) no one in The Meeting really understood your Great Idea after all, despite the fact that everyone appeared to be in total agreement. As a Sincere Technology Professional, accustomed to working for the greater good of the museum, you become dejected. You go to Museum Technology conferences and begin to complain that your Executive Gatekeeper just “doesn’t get it.” Other Sincere Technology Professionals even agree with you: “Yeah man, my director is a total Luddite.” “Right on! Our chief curator is terrified of things not written on papyrus.” And so on. You become dejected and stop coming up with Good Ideas. You turn into a Cynical Technology Professional. You spend a lot more time muttering to yourself. You start wearing a tie. It’s not pretty.

If you’re working in a non-traditional Information Technology role in a museum, this is probably a familiar scenario to you. A great project, with incalculable benefit to the museum and little drain on resources, is killed before it even makes it out of the conference room, often for reasons that seem to have little to do with the project itself. Why does this happen?

Unfortunately, we Sincere Technology Professionals are at fault more often than we’d like to admit. Because we work in an environment in which technology itself (much less the individual Great Idea) is rarely accepted as an a priori good, and the default answer is typically “no,” we are always selling the very idea of technology alongside the Good Idea itself. And when that is the case, we cannot risk even a moment of misunderstanding, lest our Good Idea be killed.

In trying to understand why my own projects have failed to pass muster with the Executive Gatekeeper(s), I’ve come to realize that much of the misunderstanding, sadly, was my own doing. Although I was careful about aligning my Great Ideas with the museum’s mission, and made sure I addressed issues I knew would be of concern to my audience, I wasn’t careful enough with the language I used to describe my ideas. I failed to explain basic terminology, or I dumbed down concepts, which led to obfuscation rather than clarification. So in thinking about how to improve my own performance at future Meetings, I came up with a few simple guidelines, which I hope will be helpful.

Always explain acronyms.

This is an easy one—tech people (myself included) love their acronyms. It’s certainly easier to say/write “API” than “Application Programming Interface” hundreds of times. However, we must realize that an acronym that we as tech folks have long since taken for granted is still a new concept to that curator across the table. A simple act of explanation, even for something that seems incredibly obvious, can come across as an overture of inclusion to the less tech-savvy.

I remember a meeting a while back with a large group of curators and educators about digitization of archives. Those of us who had worked on the project, myself included, kept tossing around the term “OCR” without ever having explained exactly what “OCR” meant. At some point (probably a good half-hour into the meeting) I looked up and, seeing a bunch of blank faces, casually asked if everyone in the room knew what “OCR” was. Only about a third of the attendees raised their hands. I backed way up, and explained Optical Character Recognition in the most straightforward way I could. The whole room lit up, and we found ourselves suddenly engaged in active conversation.

The point here is that most of the people in that room were bewildered enough about what we were discussing that they were unwilling to ask to have one of the founding principles of the project explained to them. Without that simple act of explanation, two-thirds of the people in that room would have left The Meeting not fundamentally understanding the project, and it probably would have died. Explaining OCR suddenly included everyone in the process, and made the technology (slightly) less terrifying.

Don’t dumb it down.

Another mistake we often make is to use non-specific metaphors to describe specific concepts. Although the impulse to do this, which has its root in an attempt to make alien terms more relatable, is a sincere one, it is ultimately self-defeating more often than not. By taking something specific and describing it in a generalized way, we open the door to all kinds of (potentially dangerous) misunderstandings.

Let’s use as an example the oft-heard phrase “electronic publication.” This term is applied variously to virtually any piece of digital information made public by a given museum. Online collections database? That’s an electronic publication. Blog? That’s an electronic publication. Interactive educational feature? You’d better believe that’s an electronic publication.

We started using this term to try and bring the kind of legitimacy that has always been associated with “being published” in the academic/scholarly world to Web-based media. Technology professionals therefore attempted to incorporate that language to make their projects more comprehensible (and prestigious) to that scholarly audience.

The problem is that the term “publication” has a specific meaning for scholars and academics that is quite apart from what we as technology professionals mean. A traditional publication, with its production/vetting/editing process and clear publication dates, is significantly different than a multi-output, ever changing Web application. A good Web presentation brings with it demands well after the delivery date (constant updates, responding to commenters, etc.) that a traditional publication does not. The tech professional may assume the scholar understands these demands; the scholar may not know enough about the given application or platform to know what questions to ask. Using the term “publication” causes the scholar to make assumptions about the nature of the Web application that may or may not be true. The language itself has prevented a critical conversation from taking place.

Don’t use meaningless terms.

This is probably the most pervasive language problem I encounter in describing technology projects to potential clients, sponsors, or Executive Gatekeepers. This is a particular brand of language obfuscation in which we group many disparate concepts together under a single, broad designation, and use that designation so often without explanation that it ceases to have any meaning at all.

A good example of this problem is our use of the phrase “Content Management.” Ugh. How many times a day do we hear this phrase? I often hear it used as a selling point from vendors—”our application features a content management system!” We then dutifully check off “CMS” on our list of requirements, without ever asking whether the vendor means what we mean when they use that term.

Lazy terms like “Content Management,” that could potentially encompass so much territory that they cease to actually mean anything at all, and prevent us from asking the questions we should be asking. Because these terms could potentially mean almost anything, they act as a panacea for all problems, and cause people who should know better (including Sincere Technology Professionals) from asking the right questions.

In closing...

So in short, watch your language. While language alone won’t solve all of our problems, being cautious about the terminology we use certainly helps get us through the treacherous “selling” phase of a technology project. I hope these guidelines prove helpful to you as you work through your own Great Ideas. Good luck!