Communications of the ACM
Tech User Responsibility
Some years of experience with faculty assistance has led me to speculate that the well-known frustrations of IT user support hide even deeper problems. Many of us with such experience know the chronic difficulty suffered by both client and consultant in the support scenario. Each day promises, and delivers, repeated problems, trivial issues, and deep misunderstandings attendant on the use of applications and devices. Users ask the same questions, individually and severally, over and over, requesting help when what they really want is someone who will do it for them. In my own experience providing technical support to faculty and also to members of a volunteer civic organization, I deal with well-educated and competent people. Whereas most clients are cooperative and grateful, some are brusque and demanding, some are apologetic and jocular, many are just not listening.
On the tech support side, malfeasance includes over-explanation, under-explanation, incorrect explanation, and impatience, all transgressions of which I have been guilty from time to time. Why is this all so hard? As the perceived burdens of technology build up on users, cheerful cooperation gives way to weary resignation and then to foot-dragging resentment. And this against an activity that is for their own good! Users resist reading manuals, or even short instructions, let alone working through a checklist, though learning the fundamentals would help them immensely. I have offered the briefest possible explanations of the client-server environment ("where your programs run"), HTML and URLs ("how to reach websites"), and cloud storage ("where your files are stored"), to no avail. Direct orders, such as, "Read this" or "Practice this," even to people who are sincerely motivated (no matter their intelligence, job satisfaction, rank, or personality), have no effect. I have gradually come to the unsettling belief that this is not just exasperating, but revealing. (We acknowledge without comment the obvious possibility that I, and my fellow user support professionals, are just lousy instructors or repellent individuals.)
On the happy assumption that the average reader thinks that the philosophy of computer science deals with lofty issues, this subject may seem pedestrian for the philosophy of computer science. Yet a problem so perplexing and intractable is ripe for a bit of philosophy. We might learn something about education or training from its apparent failure in such cases and thereby something about intelligence. We might learn something about the acceptance of responsibility from its apparent failure in such cases and thereby something about ethical duty.
As we look more closely (at naive users, at technically competent users, and even at us experts when we are faced with new technology), we see a reluctance to learn definitions, commands, good practices, and workflow. The hapless user does not built the cognitive scaffolding necessary to organize the concepts, so does not grasp which feature is relevant to what; that context is then even farther out of reach for the consultant. Subsequently we see attenuation of commitment, where the followup tasks are put aside until a better time, the initial momentum fades away, and the skills necessary for effective participation decay. This leads ultimately to an adversarial stance, where frustration morphs into resentment. Whose fault is this?
Although there is plenty of research and commentary on the responsibility of the vendor, there appears to be no inquiry into the responsibility of the consumer with respect to technology selection, mastery, and use. Should there be? Let's interrogate some analogies: We impose a minimal degree of responsibility on someone for checking a book out of a library—he or she should return it. The reading of it may a norm, but not an obligation. We do impose a high degree of responsibility for driving a car, but that's because it can kill people. We expect some degree of responsibility in the use of natural resources, because the effects are broadly dispersed. In domestic finances and budgeting, we assume that the agent will eventually achieve independence, making unaided decisions and taking appropriate actions, out of self-interest. It's not clear that any of those inform our view of the products of technology. Indeed, the very idea that software and hardware users have any responsibility toward their technology appears to stand in direct conflict to pervasive expectations on their part, as expressed thus:
- This is a nuisance.
- My duties involve real things, whereas this is just management of those things, not what I signed up for. Record-keeping and bean-counting should not take time from the job.
- This is clerical.
- These tools are complex, sure, and they require skill, the kind of skill embodied in a good secretary, who can handle tedium, the quirks, and the exceptions. But I deliberately avoided that career.
- This is supposed to be easy.
- These products are supposed to magically improve my life—vocational, social, and intellectual—immediately and painlessly. (This attitude, of course, is cultivated by technology vendors and promoters.) Because the product is fabulous, and intended explicitly for me, the trouble must lie with IT.
There's not much in those expectations that can be corrected by user support staff. So where does responsibility lie? Garrath Williams's philosophical treatment of the notion of responsibility [Williams 2008] notes the emergence of that notion only in the last two or three centuries, a brevity consistent with the lack of scholarship on client responsibility (also, to be fair, raising the question whether there really is any such thing). He locates responsibility not in the person, but in the multifarious modern world. "What is central is the moral division of labour created by our institutional fabric. This scheme of cooperation delimits the normative demands upon each of us, by defining particular spheres of responsibility. Given the fluidity, plurality and disagreement associated with normative demands in modern societies, this limitation is crucial."
If there is indeed a limit on each sphere of responsibility, then there should be a boundary on user support. Right now, no one understands the proper extent of support; no limiting structure is defined for the benefit of either user or support staff. To define such a limit is to grant support staff authority to demur. Unthinkable as it may seem, modern technological society needs to consider, define, and sanction a point at which consultants can say "no." Better yet, they won't need to, because everyone will understand the limits; everyone will know where user support ends and user responsibility begins. Everyone will know that the manual should be read (and should be written in the first place), and they will know from accepted and ingrained cultural mores rather than from simply being told so by pesky IT people.
But we can't work that out here and now! In the best case, the tribulation of tech help is a temporary issue, reflecting ordinary workplace stress in the face of upheaval, similar to legal and safety compliance demands. The problem will resolve as society grasps tech more firmly; that, however, will take some time. We wait for the emergence of norms of responsibility in this and other aspects of technology.
References
Williams, Garrath. 2008. Responsibility as a Virtue. Ethic Theory and Moral Practice. 11:4, 455-–470. DOI:10.1007/s10677-008-9109-7.
Robin K. Hill is a lecturer in the Department of Computer Science and an affiliate of both the Department of Philosophy and Religious Studies and the Wyoming Institute for Humanities Research at the University of Wyoming. She has been a member of ACM since 1978.
No entries found