Sometimes “no” is the kindest word

Posted on April 17, 2020 by

I absolutely dislike saying no, but during this COVID-19 situation I am finding the need to say no more often. Sometimes it does feel like I am pushing too hard, especially if the person I am saying no to is experiencing feelings of anxiety, uncertainty and stress over moving their entire course to remote/online.

In 1996, I moved from a divisional information technology (IT) unit to the enterprise IT unit at the University of Guelph. When I joined, there was a strong perception from the community that the central IT department always said no. It really was a bit of a running joke and led to some heated discussions and a distinct “us vs. them” culture. As we know, there are always two sides to every story and having this new job I had the privilege of seeing it from both sides. At the enterprise level, the rapidly increasing demands were outpacing their ability to effectively meet those demands and someone had to manage expectations – hence the frequent no. This was frustrating for the local technical people because they knew that sometimes it was technically possible, so why did they just not do it? This inevitably led to more decentralized support models and the challenges that come with that. Sidebar: I do note there are benefits as well.

Fast forward two plus decades and I still think we are playing catch up. Resources have increased significantly, but have still not kept up with increasing demands. This is especially evident in our response to COVID-19. If you have any doubts, ready Alex Usher’s blog on March 24 blog entitled CORONAVIRUS (7) – The Decision – especially the last paragraph.

So what am I worried about? Why I am wanting to say no?

  1. There is a proliferation of tools in the community and this leads to several issues:
    1. We simply do not have the capacity to learn every possible tool and how it integrates with our systems. Everyone expects support for what they choose, or prefer. We should be thinking strategically, defining requirements and then picking tools that meet the broadest possible set of these requirements. So it is in our best interest to say no, to supporting all tools, especially if there is duplication.
    2. As we use technical tools to create and/or access information that is personal, confidential and/or contractually restricted, we need to ensure we take the time to properly assess the risks. If we don’t, then we lose visibility into our assets and we potentially introduce unacceptable risks. So it makes even more sense saying no, until we have time to do proper assessments.
    3. There is a lot of discussion about the potential fiscal challenges that are coming. In times like that, the University financial benefits from negotiating a licence for one tool may significantly outweigh the benefits from having a diversity of tools. That relates back to realistically defining our requirements as a collective and sometimes that means we are better off saying “no” to some requests.
  2. With most people working at home, we may be losing visibility into some of the on-going and serious cyber threats in this landscape. We are unable to offer the same protections that we could when the majority of people were working on campus. That means we need to take additional precautions in regards to virtual private networks (VPNs), locking down home routers, ensuring encryption and further securing endpoints. It also means we are going to need to say “no” to certain types of risky behaviours, like sharing the computer you use for University business with family members.

    I am focused on providing the right tools to meet the diverse needs of the University, but there may be situations where we, as a community, need to say “no” to better protect our information and privacy and ensure fiscal prudence post COVID-19.

The health and safety of our staff, students, faculty and community remain a priority of the University. Read the latest official U of T updates here. Check out the ITS prep web page for IT specific FAQs and information.