EDiTorial BoarD THouGHTs | DEHMlow 53 Mark DehmlowEditorial Board Thoughts The Ten Commandments of Interacting with Nontechnical People M ore than ten years of working with technology and interacting with nontechnical users in a higher education environment has taught me many lessons about successful communication strategies. Somehow, in that time, I have been fortunate to learn some effective mechanisms for providing constructive support and leading successful technical projects with both technically and “semitechnically” minded patrons and librarians. I have come to think of myself as some- one who lives in the “in between,” existing more in the beyond than the bed or the bath, and, while not a native of either place, I like to think that I am someone who is comfortable in both the technical and traditional cliques within the library. Ironically, it turns out that the most critical pieces to successfully implementing technology solutions and bridging the digital divide in libraries has been categorically nontechnical in nature; it all comes down to collegiality, clear communication, and a commit- ment to collaboration. As I ruminated on the last ten plus years of work- ing in technology, I began to think of the behaviors and techniques that have proved most useful in developing successful relationships across all areas of the library. The result is this list of the top ten dos and don’ts for those of us self-identified techies who are working more and more often with the self-identified nontechnical set. 1. Be inclusive—I have been around long enough to see how projects that include only technical people are doomed to scrutiny and criticism. The single best strategy I have found to getting buy-in for technical projects is to include key stakeholders and those with influence in project planning and core decision-making. Not only does this create support for projects, but it encourages others to have a sense of ownership in project implementa- tion—and when people feel ownership for a proj- ect, they are more likely to help it succeed. 2. Share the knowledge—I don’t know if it is just the nature of librarianship, but librarians like to know things, and more often than not they have a healthy sense of curiosity about how things work. I find it goes a long way when I take a few moments to explain how a particular technology works. Our public services specialists, in particular, often want to know the details of how our digital tools work so that they can teach users most effectively and answer questions users have about how they func- tion. Sharing expertise is a really nice way to be inclusive. 3. Know when you have shared enough—In the same way that I don’t need to know every deep detail of collections management to appreciate it, most nontechies don’t need hour-long lectures on how each component of technology relates to the other. Knowing how much information to share when describing concepts is critical to keeping people’s interest and generally keeping you approachable. 4. Communicate in English—It is true that every spe- cialization has its own vocabulary and acronyms (oh how we love acronyms in libraries) that have no relevance to nonspecialists. I especially see this in the jargon we use in the library to describe our tools and services. The best policy is to avoid jar- gon and explain concepts in lay-person’s terms or, if using jargon is unavoidable, define specialized words in the simplest terms possible. Using analo- gies and drawing pictures can be excellent ways to describe technical concepts and how they work. It is amazing how much from kindergarten remains relevant later in life! 5. Avoid techno-snobbery—I know that I am risking vir- tual ostracism in writing this, but I think it needs to be said. Just because I understand technology does not make me better than others, and I have heard some variant of the “cup holder on the computer” joke way too often. Even if you don’t make these kinds of comments in front of people who aren’t as technically capable as you, the attitude will be apparent in your interactions, and there is truly nothing more condescending. 6. Meet people halfway—When people are trying to ask technology-related questions or converse about technical issues, don’t correct small mistakes. Instead, try to understand and coax out their mean- ing; elaborate on what they are saying, and extend the conversation to include information they might not be aware of. People don’t like to be corrected or made to feel stupid—it is embarrassing. If their understanding is close enough to the basic idea, letting small mistakes in terminology slide can create an opening for a deeper understanding. You can provide the correct terminology when talking about the topic without making a point to correct people. 7. Don’t make a clean technical/nontechnical distinction— After once offering the “technical” perspective on a topic, one librarian said to me that it wasn’t that they themselves didn’t have any technical Mark Dehmlow (mdehmlow@nd.edu) is digital Initiatives librarian, hesburgh libraries, University of notre dame, notre dame, Indiana. 54 iNForMaTioN TECHNoloGY aND liBrariEs | JuNE 2009 perspective, it just wasn’t perhaps as extensive as mine. Each person has some level of technical expertise; it is better to encourage the development of that understanding rather than compartmental- izing people on the basis of their area of expertise. 8. Don’t expect everyone to be interested—Just because I chose a technical track and am interested in it doesn’t mean everyone should be. Sometimes peo- ple just want to focus on their area of expertise and let the technical work be handled by the techies. 9. Assume everyone is capable—at least at some level. Sometimes it is just a question of describing con- cepts in the right way, and besides, not every- one should be a programmer. Everyone brings their own skills to the table and that should be respected. 10. Expertise is just that—and no one, no one knows everything. There just isn’t enough time, and our brains aren’t that big. Embrace those with different expertise, and bring those perspectives into your project planning. A purely technical perspective, while perhaps being efficient, may not provide a practical or intuitive solution for users. Diversity in perspective creates stronger projects. In the same way that the most interesting work in academia is becoming increasingly more multidisci- plinary, so too the most successful work in libraries needs to bring diverse perspectives to the fore. While it is easy to say libraries are constantly becoming more technically oriented because of the expanse of digital collections and services, the need for the convergence of the technical and traditional domains is clear—digital preservation is a good example of an area that requires the lessons and strengths learned from physical preservation, and, if any- thing, the technical aspects still raise more questions than solutions—just see Henry Newman’s article “Rocks Don’t Need to be Backed Up” to see what I mean.1 Increasingly, as we develop and implement applications that better leverage our collections and highlight our services, their success hinges on their usability, user-driven design, and implementations based on user feedback. These “user”-based evaluation techniques fit more closely with traditional aspects of public services: interacting with patrons. Lastly, it is also important to remember that technol- ogy can be intimidating. It has already caused a good deal of anxiety for those in libraries who are worried about long-term job security as technology continues to initiate changes in the way we perform our jobs. One of the best ways to bring people along is to demystify the scary parts of technology and help them see a role for themselves in the future of the library. Going back to Maslow’s hierar- chy of needs, people want to feel a sense of security and belonging, and I believe it is incumbent upon those of us with a deep understanding of technology to help bring the technical to the traditional in a way that serves every- one in the process. Reference 1. Henry Newman, “Rocks Don’t Need to be Backed Up,” Enterprise Storage Forum.com (Mar. 27, 2009), www.enterprise storageforum.com/continuity/features/article.php/3812496 (accessed April 24, 2009).