Recently, I was giving a talk about free software and open source in libraries at a state library consortium meeting. The attendees of the meeting included many library administrators. One of the questions I received after the talk stumped me. Although I came up with one good answer I'm still confident about and share below, it's taken me weeks to come up with more helpful answers to this question, for which many answers are possible. The question is, "How do you hire and manage technical staff whose work you don't understand?"
Communication in the Hiring Decision
A common answer I've heard from managers before, and the one I had for that person who asked, is that good communication skills are first and foremost. If you don't have good communication skills, no other qualifications or recommendations should matter. And I'm not talking about an awkward turn of a phrase in a cover letter or a clear indication that your applicant's native language is different from your own, however fluent they may be in your native language - it's the whole package that matters. The ability to express complicated ideas clearly and concisely, strong listening behaviors that aren't exaggerated or contrived, sustained attention to listeners while you speak, and a good memory for what others said earlier in a conversation are noticeable skills that can be evident during the briefest of interviews. And an absence of these skills can be evident in the first few moments after meeting somebody new.
The best interviews I've been involved in (whether as the applicant or an interviewer) are the interviews in which I've learned something about the nature of the work required of the applicant. It might be an explanation of a systems protocol, a lesson learned from how a past project evolved, or even just a small detail about an institutional process that might be easily overlooked but has an important impact. Whatever it is you've learned, though, when you have that moment of realization that, "I've learned something here today," you can look around the room and be confident that everyone there will probably be able to work well together because you're already learning from each other. And if you're already learning from each other, it's almost always the case that you're communicating well with each other. Remove good communications from that scenario and that learning might not happen so readily, if at all.
One good test of the ability of an applicant who is more technical than you is to ask for an explanation of a system he or she developed or an interesting technical problem he or she solved recently. If you indicate that the technical details are a bit beyond you, can the person modulate the explanation usefully, providing missing background without getting lost in the details? Or does the applicant grow impatient and shrug it off? If you're going to work with this person, he or she needs to understand that there is information you need to know in order to make critical decisions. It is important to share technical details that are necessary for making these decisions.
Documentation in the Hiring Decision
Another thing to ask about is documentation. Documentation is often the bane of everyone's existence around technical projects, but how a developer or systems administrator thinks about documentation can tell you a lot. Does that systems candidate keep network and server diagrams up-to-date and plan out changes visually before implementing them? Is the developer comfortable sketching out the pieces of an application he or she has built recently and explaining how the pieces fit together? And does that person understand that documentation isn't just about giving something to your boss or leaving notes for a co-worker but primarily about writing down notes for your future self? You might be rolling your eyes as you read this, thinking of all the undocumented stuff in your purview ... and, sure, things haven't necessarily blown up around you because of the absence of good documentation. …