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.