Research Facilitation

A while ago, I posted the first tenet of my philosophy on instructional technology support, Stop Saying “Yes”. I’d like to follow that up with the second core tenet: Stop Saying “No”. Taken together, they represent my basic approach to working in instructional technology within higher education.

If my original recommendation was to stop saying “yes,” then why I am now suggesting to stop saying “no”? In reality, these approaches are complementary. My key point is that often we in ITS are too quick to dismiss ideas. This can happen for a number of (potentially valid) reasons. Two of the most common are 1) the idea goes against explicit or implicit policies, or 2) we have insufficient (temporal, financial, hardware etc.) resources. In either case, we might more or less immediately shut down the proposal with a flat “no.”

Both justifications are challenging to address, and it is impossible to prescribe systematic approaches to do so, as in either case potential solutions are tied up in specific processes local to each institution. A third – and particularly disheartening – response is that we are unwilling or unable to do something because “we’ve always done it a certain way” or “we’ve never done that before.” As a general rule, however, I have found that regardless of the underlying justification, the knee-jerk reaction to say “no” regularly becomes the default position; that is, we say “no” unless we can be explicitly convinced to say “yes.”

I always try to flip that script, so to speak, and instead make every attempt to get to “yes” unless there is a compelling reason to say “no.” Sometimes, this means looking at time or budget allocations and trying to rearrange priorities, or perhaps even stopping doing something else, in an effort to start a new project or initiative. Maybe policies need to be revised, created, or abandoned. It might mean exhausting all avenues of creative funding for a particular piece of software or hardware, such as departments or the Provost office. Perhaps the solution is rethinking network configurations to allow certain devices that up to this point have been prohibited (as is increasingly common in the BYOD landscape of higher education). And so on, endlessly.

Now, it may be that after much effort, the answer may still be “no”! And that’s OK, because going through this process at least provides a better framework for continued reflection, reflexive self-improvement, and ongoing discussions with all stakeholders. Moreover, arriving at “no” can provide justification for additional lines or resources. I’ve witnessed an entire unit say that because of their current projects, they would be unable to take on new projects or additional support responsibilities for the next year. And that’s fine if the institution is content with maintaining the status quo, but such a position provides no room for innovation (especially when we shouldn’t be afraid to fail when we attempt new ventures). (Note that due to Parkinson’s Law, which states that “work expands so as to fill the time available for its completion,” simply adding more people to a team usually will not solve underlying resource issues – in such cases, ongoing processes of reflection and continual adjustment of duties, coupled with a strong and effective project management regime, can help to combat growth for the sake of growth.) Or if the request is to fund or support a new piece of equipment or service for a certain department, saying “no” can force conversations with departmental leadership, the Provost, and so on to ensure, e.g., that budgets accurately reflect the current demands to support faculty initiatives and to maintain high-quality teaching and research support.

In so doing, we create an environment of discourse and partnership with the campus community, where ITS is viewed not as an impersonal unit from which to request “stuff,” but as an integral collaborator that works to support the core missions of our institutions.

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.