The one element of my job that completely transformed my ability to perform my role as an Instructional Technologist more than anything else was the freedom and encouragement to stop saying “yes” every time I received a request for support.
Think about that for a second.
Because a core principle of our jobs is effective support, it may seem anathema to discourage a practice that seems, on the surface, to make people happy with us. And that appears to be a reasonable, rational assertion. Professor Jones wants you to help her create a forum in your LMS, so your natural instinct likely is to say “Sure, no problem” and do just that. The request just as easily might be to help configure a particular type of ungraded assignment, or perhaps they want assistance connecting to a colleague with Skype for a guest lecture. Or any one of the other infinite possibilities for support, both large and small, we see day in and day out.
Rather than defaulting to “yes,” I suggest you take a step back and reframe the request by asking a simple question of your own: “What are you trying to accomplish?” Let me explain why…
When I started my career in liberal arts higher education, I had come from a background of ITS support at major state “R1” institutions with enrollments far north of 30,000. The difference was dramatic once I entered the world of so-called “highly selective” institutions with enrollments less than 10% of what I was used to. My supervisor demonstrated that the key to success in such an environment was not completing tasks as quickly as possible, but rather in building relationships with faculty, staff, and students such that I would come to understand not just what they were doing, but why they were doing it. She said that the primary weapon in the arsenal of crafting these relationships is the simple step of asking “What are you trying to accomplish?” nearly anytime someone wants my assistance, for all but the most trivial of requests.
Asking this question “flips the script” and forces the requestor to consider the ends rather than the means. Too often we all become caught up in a particular approach. Perhaps a faculty member saw a colleague using a particular LMS tool, or maybe they think a certain database application is just what they need to house their personal image collection. But as Instructional Technologists, we might know of a better way to accomplish their goal, and many times it may be far simpler than what they initially had in mind. Does this faculty member, for instance, really need a custom MySQL image database for his course? Why not Omeka? Or perhaps a gallery in WordPress? How about even a simple image gallery right within their LMS course?
I can’t tell you how frequently this happens. As a small example, often the original request is something relatively small and rather specific, such as “My gradebook Homework category isn’t calculating correctly.” That appears innocuous enough, and might require just a quick tweak or fix. But instead of simply saying “Sure, I’ll fix that for you,” I usually take a look to see what might be going on and then ask what they are trying to accomplish with their grading scheme. More often than not, I’m able to work with them to simplify their grading scheme, which saves them tons of time in the long run, but which more importantly helps me to build a relationship and rapport with them. I can, for example, see and ask about what types of assignments or assessments they give, which helps me to understand their teaching style. This in turn might afford opportunities to discus their courses or pedagogical approaches more generally, all of which can provide a solid foundation for future work with them. What started out as a minor request turned into an opportunity for so much more.
(As an aside, it goes without saying that, in general, I try to meet with faculty in-person as much as possible. Even if the initial request comes in via a ticketing system or phone call, so much is lost trying to support most users over the phone or via email.)
Does this approach work all the time? Nope. Sometimes, the requestor (or you) simply may not have the time at that moment to delve too deeply beyond the simple ask. You can at such times say something like, “OK, we can take care of this right now, but at some point soon I’d welcome the opportunity to talk about possible other options to address this more broadly.” Other times it’s rather clear the requestor is not now, nor will ever, be interested in such dialogue. Part of my toolkit for this type of work is to know when “good enough is good enough,” so to speak. Sometimes this process works in reverse, too, meaning that the requestor will assume their issue is straightforward and easily accomplished, while in reality something much more robust is required. Which is fine, since it sets the stage for ongoing collaboration. And other times – let’s face it – the requestor may not be receptive whatsoever to being “questioned” about their motives, particularly if they view staff as “the help.”
Even though it won’t work all the time, or may not be the most appropriate approach for every situation, I suspect making this simple question a default go-to approach for your general support has the power to be transformative in your career.