It's incredibly moving, and slightly dizzying, to be standing here today talking to this audience about technostress. For those of you who don't know me, let me begin by saying that I am one of you (for although I am not presently working in a music library, as we all know, once a music librarian always a music librarian). My interest in this topic, in fact, dates back to the time when I was still in MIT's Music Library and applying for the position of Associate Head of the Humanities division. As part of the interview I was asked to make a presentation to library staff on the topic of technostress. At first I was very pleased because having only recently been given my first PC and an account on the campus network I felt that technostress was something about which I would have a lot to say. I had spent the preceding months mulling and fuming and cursing in the privacy of my office as I tried to figure out basic DOS and WordPerfect and UNIX and e-mail - all, of course, without much in the way of training or documentation - and I felt that that experience would be an excellent background for a paper on technostress. But it wasn't long before panic set in as I realized that my audience might well expect me to have not just the questions but also the answers.
Well, somehow I made my way through that presentation, got the job, and decided to continue reading, thinking, writing, and speaking about the impact of technology on the work that we do in libraries. I also continued to mull and fume and curse in the privacy of my office as I tried to figure out various user interfaces and CD-ROM's and HTML and web browsers - well, I'm sure you all know the feeling. Today I stand before you having only recently assumed the position of Information Technology Librarian for Public Service at MIT. Confidentially, let me tell you that you might look upon my appointment to such a position as a source of modest inspiration. The way I see it, if I can mull and fume and curse my way into something resembling enlightened competence, there's hope for every single one of you. .
So now, what about technostress? As I said before, when I first began to work in this area I thought I knew the problem intimately but despaired of ever finding The Answer. Now, all these years later, I find I'm continually redefining the problem; answers, too, feel like a moving target. This talk will attempt to tell you how I see the problem today, and what answers suggest themselves; I'd be misleading you if I pretended to be in a position to offer you definitive solutions. .
Debbie [Pierce, the session moderator] introduced the subject with Craig Brod's classic definition of technostress. I come back to this definition again and again with considerable skepticism. At various times, Brod has described technostress as "a condition resulting from the inability of an individual or organization to adapt to the introduction and operation of new technology" or "a modern disease of adaptation caused by an inability to cope with the new computer technologies in a healthy manner." While these definitions may have validity from the clinical standpoint, from the organizational or management standpoint I find them troublesome in a couple of ways. First, there's the ill-disguised stigma attached to medical terminology like "condition" and "disease," and second, there's the assertion that this so-called "disease" is caused by "inability" on the part of some individual or group. Now, I would like to propose that the past years have given the lie to the accusation of "inability." We are able to adapt and cope and even flourish in an automated environment: after all, we have been doing so for years, and everything suggests that we can look forward to more of the same. Thus, if the stress were merely symptom of an inability to adapt and cope, and if you agree with me that we have adapted well, then why are we still so stressed? .
As for Brod's use of medical metaphors to describe technostress: Certainly stress is a clinical condition worthy of serious attention. On the other hand, simply labeling a complex phenomenon as a disease caused by inability trivializes the problem. Such a limited definition of technostress misses all the many, many social and environmental factors behind it. .
Technostress is a problem. The problem is real. But it is not a problem that lies exclusively within the afflicted individual, and it's not an attitude problem (or at least not primarily so). In my view, the problem lies with the interaction between the user of technology and the technology itself. Consider for a moment some all-too-familiar organizational dynamics, causes, and expressions of technostress (and these were just the ones that were foremost in my mind the day I wrote this). How many of these sound familiar to you?
Now consider the possibility that your personal stress is a function of all or at least some of the above. They're not all in your head. They're not about your inability to adapt. They are, in short, legitimate and external. .
In her article "Technostress in Libraries," Julie Bichteler, reporting on discussions with technology users in libraries, says:
"Technostress ... in library staff can be attributed to four general areas: fear, hostility and apprehension resulting in typical resistance behavior; dissatisfaction and frustration with the planning and implementation of automated systems; physical complaints; and inadequate training."
I'd like to user Bichteler's four general areas as an outline, but I'm not going to address them in that order. About ergonomics I shall say very little since we are lucky to have the fabulous Lou DiBerardinis, MIT's patron saint of the carpal tunnel and workstation design, here to speak to us today on this topic. What does need to be said, though, is that we have a responsibility as library managers to educate ourselves on workstation design and to advocate for the needs of our staff and our users. Far too often, we think with longing verging on lust of that new piece of computer equipment, but never think about the experience or the health of the person who's going to have to use it all day long. We should get into the habit of thinking of a piece of equipment and the piece of furniture it will sit on and the chair its user will sit on as one purchase. In other words, you don't just ask for money to buy a new computer. You ask for money for a workstation - the computer, the ergonomically correct table, and the ergonomically correct chair. It's one purchase. This will require an institutional commitment, I know; but we have to start now to educate our institutions to the fact that they owe their staff and probably their users appropriate working conditions, and that means properly set up workstations. (Incidentally, I must tell you up front that my bias is to look out for the well-being of library staff first. After all, we are the ones who sit all day at our terminals. Our users typically drift in and do a quick look-up; at most, they may use a particular application intensively for an hour or two; but usually an individual reader does not expect to live at one of our public installations for hours and hours each day, indefinitely. This is, I repeat, my bias; I understand that your users may demonstrate radically different behaviors and patterns of library use, and if so, the ergonomics of the public stations may be a very high priority for you.)
Let's talk for a minute about training, another one of Bichteler's broad categories. I don't know about you, but around MIT I continue to hear this a lot: "The librarians are responsible for learning this themselves." "It's a Windows application, you'll be able to figure it out as you go." "Everyone should take responsibility for making sure they understand how this works." Now I'm sorry, but I just don't see this as a productive approach to training. It's true that some of us do prefer to roll up our sleeves and learn as we go. That's a valid approach to learning and it works really well for some people. But this approach reflects only one of many learning styles, and if we're serious about reducing the causes of technostress then we have to get serious about training and we have to think seriously and expansively about how people learn. If you are a person who likes formal training, then go for it; if necessary, insist on it. Find a class if there is one, or find a tutorial or a workbook, but in any case don't be bullied by those colleagues who tell you it's your professional responsibility to learn something all by yourself. Further, if you're in a position to provide or even just to lobby for training for the staff of your library, do so. For everyone who feels comfortable with exploring on their own, you can count upon there being someone else who'll be paralyzed until they are shown it, or taught it.
We in the library profession have a long and noble history of striving for perfection; right now, the urge to get it right is at odds with the much-publicized need to move quickly. And indeed our sense of urgency when it comes to automation isn't merely a question of PR; the technology itself is highly volatile, change happens incredibly quickly, and we're all worried about whether the jobs or indeed the profession we now occupy will exist five years from now. I submit that this is a healthy tension (albeit at times an extremely uncomfortable one). In my work with computing professionals at MIT I've come to value their urge to move quickly to meet a perceived need, and I think in turn they have come to value the librarians' insistence upon quality and service standards. In general, we librarians do need to move more quickly than is our custom; we do need to question all our assumptions about the need for perfection; and at the same time, we must be prepared to dig in our heels and fight when there's an issue worth fighting for. This tension between the urge to do it right and the urge to do it fast may be at the heart of our chronic problems in the area of planning and implementation. We're trying to move fast so we take all kinds of shortcuts. Planning and implementation are time-consuming but it's time well spent. One of the most important and valuable things you can do is get your whole staff involved in the planning process. Take time to let staff know what's going on, and include all levels staff in all the stages of a project. Get the people who will be doing the work to plan it, as much as possible. As a colleague of mine used to say when we were planning the implementation of a new system, "I don't want staff to feel involved, I want them to be involved."
This is also a good place to talk about the value of building and sustaining a good relationship with your systems department or other computer support people. Make time to talk with them, to ask them your questions and to explain your issues. Make sure that they understand that involving you in the planning and implementation will be to everyone's benefit. At MIT the Music Library has an excellent track record for educating the library administration and the folks involved in library computing to the notion that a system that can handle music materials well can probably handle all materials well. When I became the library director at the Manhattan School of Music many years ago, Suki Sommer (the source of about 90% of the wisdom I possess in the world) advised me that as the head of a conservatory library absolutely the most important ally I could make would be the head of physical plant. Naturally I listened to Suki's advice and naturally she was right. Today, were I to be in Suki's position and having a similar conversation with a young professional, my advice would be to seek out and make an ally of the head of your systems department. You're going to need that person on your side in order to get your job done.
Let's return to the four general areas of technostress in libraries as described by Julie Bichteler. I've saved my favorite for last: "fear, hostility and apprehension resulting in typical resistance behavior." I want to draw your attention to the list of recommended readings which you should all have received. One of my very, very favorite pieces of writing on this subject is the article by Sara Fine. Fine doesn't talk about technostress; she talks about resistance to change. Further, she defines resistance as a natural response to anxiety. To me this seems a much more useful approach than Brod's, which assumes that the stressed one has a problem (or even is him or herself a problem.) In Fine's view, resistance and how it plays itself out in the life of an organization is not an illness, it's a process; indeed, a necessary and even a healthy one, although not an easy one. In fact, Fine turns Brod's classic definition upside-down by describing clinical symptoms of phobia displayed by computer users as "a new, learned form of resistance." In other words, where Brod sees technostress as an illness caused by an inability to cope or adapt, Fine sees technostress in its most extreme form as a successful adaptation to an unhealthy political or organizational situation. (Obviously, such an adaptation has a very high price tag and I hope we all can find other solutions.)
I particularly like the political overtones of the word "resistance." I think it's appropriate to think of this as an organizational and societal issue that has profound impact on the individual. If any of you have heard me speak on this topic before I must now apologize to you because I want to quote briefly from Fine's article; it's a section I often quote because I find it both eloquent and powerful. Fine writes:
In any organization, resistance may be an untapped source of information for administrators and planners, pointing against real dangers facing the organization and targeting unanticipated consequences of a proposed change. Many studies show that when confronted with resistance, most managers discount its meaning... And how do resisters then behave? Intelligently. They learn to keep quiet, or to sulk, or to act out their resistance in unbecoming and sometimes destructive ways.
Resistance in an organization may have so much value that by trying to wipe it out - like a disease or a species of predator - we may be creating new, unforeseen, and in the long run, much more serious problems... In fact, it is the very purpose and value of resistance to hold us back and create tension with progress... It is out of the tension between pushing forward and pulling back that healthy growth takes place... The most important thing I have learned about resistance in all my studies is to respect it.
How shall we translate respect for resistance into action? To bring my talk full circle, I'd like to suggest that the answer depends upon how we define technostress. I wish to propose the following paraphrase of Brod's definition of technostress; I'm calling this Nina's New Definition of Technostress:
A condition resulting from having to adapt to the introduction and operation of new technology, particularly when equipment, support, or the technology itself is inadequate.
I'm very pleased with Nina's New Definition, because it has two aspects. First, there's the having to. The having to is real; we do have to use technology and its ubiquity in our lives is beyond our ability to influence. In this regard, as the Borg say in Star Trek, resistance is futile.
However, the second aspect of technostress as described by Nina's New Definition is the presence of flaws in the application itself or in its implementation, and in this regard, resistance is not only not futile, it is essential and it is productive. (And, if you accept my definition, it follows logically that trying to address the flaws in an application and/or its implementation will, by definition, reduce your stress.) We should advocate for the needs of ourselves, our staffs and our users. I mentioned this in the context of ergonomics but it's doubly important in the arena of functionality. And I'd like to urge you not to be intimidated. If the documentation doesn't work for you, then it probably won't work for the freshmen in September; if you think the new interface is lousy, and if you're prepared to explain and demonstrate why, you'll probably be saving your faculty a lot of misery by speaking up and saying so. We should accept, and even relish, the tension between the urge to move quickly and the desire for perfection. We should find what we think is the right place on that continuum but always be willing to revisit it and consider new compromises and new priorities.
Within our organizations, we need to put our money where our mouth is. If you want something to happen, make sure it's somebody's job to do it. Technology is now absolutely central to the operation of most of your libraries, I imagine. That being so, we need to be aware of job descriptions, and then we need to agitate for appropriate pay increases. A lot of places continue to rely on local "gurus" or ask librarians or committees to build or support mission-critical applications. I am a firm believer in validating people's work - and the tasks themselves - by making a rational decision about who is responsible for computer support, by defining a job or jobs accordingly, by officially allocating positions and budget lines. I understand that you personally may not be the one who can just go forth and do this, but you personally can talk it up and harp on it every chance you get. It's quite amazing how much you can accomplish in this way over time.
Similarly, if you want your staff to perform in a certain way, make sure you're rewarding them for it. If you want to encourage creativity, build it into your evaluation process, or at least notice it and compliment it when it happens. If you want to reduce technostress in your workplace, encourage people to take breaks, to eliminate low-priority functions, to hang out, to laugh, to talk about music or even to make music together. What better antidote to technostress could there possibly be?
And we should organize. The history of MLA shows that we can have a remarkable impact on issues of interest to us. Well, guess what; we need to do it again. We must create partnerships with campus computing, with music faculty, with vendors, and possibly also new alliances within our library systems. As a profession, I hope that soon we will be in a stronger position to have an impact on the marketplace. It sometimes seems that there's just no limit to what the traffic will bear right now - that designers of both software and hardware don't care about our comments, because they know that their products are going to sell no matter how we complain and no matter what they cost. This is quite depressing but I do believe the picture has to stabilize. (When, of course, is anyone's guess.) But even now, I urge you to take advantage of every advantage to offer feedback (whether it's been asked for or not) on applications or equipment you're going to use. Don't be intimidated if the person receiving the feedback is condescending, and don't think that being a naïve or a terrified user of technology means your comments aren't worthy of attention.
Richard A. Hudiburg suggests that there are two broad categories of coping responses: the emotion-focused, strategies which attempt to help us feel better, and the problem-focused, strategies which attempt to improve the situation by making things actually be better. The emphasis of my talk has been the latter, largely because of who I am and how I work but also because I believe the standard definitions of technostress neglect the possibility that one important way to attack the stress is by improving the conditions that cause it. Nevertheless, let me close by saying that I firmly believe we need both categories of coping technique. When you find that you or someone on your staff is unduly stressed or unduly resistant, consider whether there is anything you can do to make the situation itself be better. Do you have comments or criticisms of an application? Do you have concerns or complaints about how a piece of technology is being implemented? Consider all the "political" avenues: what healthy use can you make of your resistance? As Fine says, resistance should be respected, not ignored; once you've identified the source of your resistant response, do all you can to improve that problem. At the same time, take seriously the need to take care of yourself, your staff, and your users. Attend to your health, your heart, your happiness, and your sense of humor. I have a feeling we're going to need all of them in the years to come.
Thank you.