Nerd-wrangling, or What IT people can and should do for you

In moving this site to WordPress I decided to add and update a section on presentations.

As with so many things, tabulating one’s results brings up interesting correlations. The presentations all seem to be about people, not technology. It would be easy to think, looking at the topics, that I don’t spend much of my day on very technical issues. In fact, that’s not actually the case. So why don’t I give more presentations on technology per se?

For one thing, computers are delightfully binary: they work or they don’t. Yes, there can be all sorts of exciting complications to the statement “it doesn’t work”, but in fact when a piece of technology doesn’t do what the customer expects it to, I’ve never found customers to be that interested in why.

And that’s one of the main reasons I don’t give a lot of talks about technology itself. One of the primary reasons academic IT people exist, I firmly feel, is to protect faculty from having to worry about anything technology-related that they don’t have to worry about.

(I’d like students to achieve a certain computer literacy before they graduate – in fact I’d like faculty to achieve it too. But I don’t confuse that goal with the day-to-day operations of a service department. We are always ready to slip a little education about technology topics into every customer interaction, but we don’t require customers learn about technology in order to get our help, and I think that’s a key distinction.)

That doesn’t mean customers don’t have to worry about technology. Far from it. But I assume they are not interested in the internal workings of our data snapshots, hosted servers, or wireless networks. If they are, they probably know so much that they don’t need me to tell them about it.

I try to reserve my interactions with customers, colleagues, or the public about technology to things they really should worry about, like digital citizenship, technology literacy, the limitations of possible technology funding, or (lately) the changes in the world wrought by the explosion in wireless access and personal devices.

When I serve as the instigator or participant of a project, I try to think through all the technological questions so that my customers don’t have to.

That doesn’t mean that I don’t find them fascinating. I am deeply interested in the possibilities of alternatives to Crystal Reports for SQL reporting and the scalability of virtual LAMP environments (and how to write application layers that scale with them for cloud use). I like a nice clean interface that doesn’t depend excessively on Javascript but I like the ability to output my data as Excel or CSV files even more. I worry about the sustainability of constantly needing to patch Java or Adobe products on our managed desktops. I check in with my staff as much as I can to find out what we think about HTML5 versus iOS or Android-specific development and whether or not we now think H.264 is passé as a video compression algorithm. We spend a lot of time internally talking among ourselves or with vendors about implementing products or how to accomplish our goals with the tools we have. We even write products from time to time, though as a development shop we are tiny.

But my staff and I tend to focus on services, and we don’t think it’s good service to subject customers to those discussions unless the customers are interested. We’re always happy to educate – we all used to be faculty and/or students ourselves! – but we don’t see the need to require that customers become technologically savvy in order to work with us. It’s fun and interesting to work with customers to draw out of them their functional requirements for a project. But subjecting them to all the technical ins and outs of how that project is going to be executed is just cruel. (Unless, as I say, they’re in that group of customers who want to know.)

In our Catalyst Boot Camp “Nerd-wrangling” was a specific topic we addressed, and as much as I used the term to get a laugh, it always drew a great deal of interest from faculty. They were interested to know a little more about how technical people tackle questions and problems and how to get the results they wanted. I suspect, from my work with them, that this is a problem that a lot of faculty face. In fact, I suspect now, from working with other groups, that it’s a problem that just about everybody faces at some point – unless they’re a technical person themselves.

Fortunately at Hofstra we’re lucky enough to have a great Faculty Computing Services, including instructional designers who not only speak technology, they speak pedagogy. Instructional designers make great bridges between faculty who want to accomplish some specific goal with their class and all the technology-savvy folks in Information Technology as a whole. In fact, even our instructional technologists, who usually handle technology acquisition and deployment, are very informed about pedagogy and very good at sitting down with a faculty member, getting their functional requirements, matching them to existing tools, locating (or writing) new tools where necessary, and executing the project of implementation successfully – which means not only matching the project goals, but doing it on time and on budget. My staff make great translators as well as great project managers. These are the kinds of things a good IT staff should be able to do for faculty (aside from just the basic “it’s broke, fix it” kinds of questions and solutions – which we also provide).

In our Student Computing departments, Learning Support, where students learn how to use specific applications for academic purposes, is also different from Tech Support, where students just get their problems solved. Those customers are approaching us with different expectations in mind depending on which window they’re coming to, and we want to meet them where they are.

That, to my mind, is what IT people ought to be able to do for you. I have tips and tricks on how to get the results you want – and I have a great staff who deliver results by meeting customers where they are. But the bigger challenges that we all need to discuss aren’t actually how to productionize a web server. We’ll do that or we won’t. (We can do it, if you’re interested. And if you want more details, call me.) Hopefully, ideally, if you are not an IT person yourself, you get to elect how much – or how little – of those details you want to know. Those details probably are only ancillary to the task of achieving some specific pedagogical or learning goal with technology.

Knowledge is power, of course. If you do dive into the technical details, you can control a lot of what you get out of the project you’re undertaking. But most faculty don’t need that level of control to get started. And stopping yourself from starting by thinking that you have to set aside weeks or months to learn something technical and new is counter-productive. You don’t need to do that. Really.

Personally, I think you should be able to work with IT people who can protect you from a lot of the technical details but still help you achieve the results you want. You’ll probably learn a lot about technology along the way no matter what you decide to undertake with our help. But I don’t think you have to become an enormous techy to make great strides in teaching or learning with technology. Your interactions with the IT people should be about your activity and how to do it, not the technology itself, which the IT people hopefully got working before you ever stepped up to the plate. To me, that’s what good IT people can and should do for you.