The Car That Won't Levitate
There is a thought I have never said out loud to a client.
It arrives when a faculty member emails me wanting Canvas to do something Canvas simply cannot do. Or when a student expects their newly-enrolled course to appear in their dashboard before the student information system has had time to process it. The thought is vivid, and entirely unhelpful:
Well, I want my car to levitate 120 feet in the air so I don’t have to deal with rush hour traffic. But my car can’t do that.
I have never said this. I will never say this. The thought stays where it belongs — inside my head.
There are three flavors of “Canvas can’t do that” and they require different handling.
The first is genuine limitation. A teacher wants a feature added to their course that the platform simply isn’t built to support. My response: “Unfortunately it is not possible to [their specific request] in your course.” No bureaucratic softening. Clean. Direct. If there’s an alternative that gets them close to what they need, I offer it. If there isn’t, I say so and leave the door open. For the ones I know have a sense of humor, I lead with ‘Now please don’t shoot the messenger’ — a line that usually gets a chuckle and defuses whatever frustration was building in the subject line.
The second flavor is a feature that exists but hasn’t been implemented yet — often because the Canvas community forums are documenting enough bugs that deploying it during an academic term would create more problems than it solves. My response sounds like this: “Based on numerous comments in the online Canvas forum describing errors with the feature, we have chosen to exercise caution with releasing it this academic term. We’ll be watching the forum posts and will evaluate whether next term is an appropriate time once the bugs have been addressed.” Diplomatic. Specific. And true.
The third flavor — which isn’t really a limitation at all — is the expectation gap. A student enrolls in a course online and immediately expects it to appear in their Canvas dashboard. It doesn’t. They email me, mildly panicked. My reply: “Unlike the Google Docs experience, which saves changes in a few seconds, it takes four to six hours for enrollment changes to be updated in Canvas courses each weekday. If you still don’t see your course by tomorrow morning, send us an email and we’ll be happy to troubleshoot.”
I never hear back from them. The course appears. They move on with their day. The anxiety was real and the resolution was simple — they just needed someone to explain the clock.
What all three of these responses have in common is something that took me years to develop deliberately: the client never feels refused. They feel informed. They feel considered. And they feel like the relationship is still intact on the other side of the answer.
Most technology support treats a “no” as the end of the interaction. Not one why given. Ticket closed. Move on. I treat it as a transition. If their email is unclear about what they’re actually trying to accomplish, I offer a Zoom or Teams call to talk through it. Sometimes what they’re asking for isn’t what they actually need, and five minutes of listening reveals a path that the email exchange never would have found. Every response closes with something like “do keep me posted on any future issues or annoyances you encounter with your courses” — because the goal isn’t to resolve one request. The goal is to be the person they think of when the next one arrives.
The answer to the request may be no. The answer to the relationship is always yes.
Here is what the backstage of my work looks like. It isn’t always clean.
When an angsty faculty member doesn’t accept my answer — when “it’s not possible” meets a temper tantrum and a forwarded email to my upper management demanding the impossible — I don’t have the luxury of institutional backing. Management with low trust of their employees is unlikely to respond with, “he’s right, he’s the admin, he’s the expert.” What they want is cited quotations from an external source. Documentation. A Tier II support transcript from the company that makes Canvas. Proof that the car genuinely cannot levitate, sourced from someone other than the person whose job it is to know.
So before I deliver a “not possible” to anyone I suspect might escalate, I confirm with Tier II support and save the transcript. Not because I doubt my own expertise. Because I’ve learned that expertise without documentation is an argument I’ll lose, and an argument I lose costs the client more than it costs me.
The levitating car thought stays internal. The transcript goes in the file. That’s the job.
The relational technologist’s version of no isn’t a door closing. It’s a conversation continuing in a different direction — toward what’s actually possible, toward what they actually need but haven’t considered, toward the next time they’ll need someone in their corner who already knows their name.
The car can’t levitate. But I’ll tell you what it can do.
More later...