An Appreciative Approach to Understanding
the Power of Tech-talk
A Research Project conducted at
The National Research Council
Purpose
The purpose of this analysis is to describe and profile both the power and the most helpful uses of technical language. Through this analysis, the most helpful methods for communicating technical language as well as some suggestions for improvement will be extracted and analyzed through a method know as Appreciative Inquiry (AI). The term Core Values will be used to describe the most meaningful Characteristics of the technical-based exchange. Also, the AI process has been modified somewhat to accommodate the following: 1) the focus on technical language and the exchange between technical (computer-related only) and the "end-user" and, 2) some restrictions guiding this research project at the National Research Council.
Disclaimer
The use of this data will be used in accordance with NRC Guidelines regarding non-sanctioned studies. It should also be noted that this study and its contents are the sole responsibility of the author, Brian Gore, and that the National Research Council has not commissioned this study nor given consent for the publication of the results. Appendix contains a memo from The Office of the General Counsel regarding specific guidelines.
Appreciative
Inquiry Consultant:
Brian Gore
LRNG 792
– Spring 1999
George Mason University
Adviser – Dr. Don Lavoie
Overview of Appreciative Inquiry
Discussion and Interpretations
Surprises and Special Learning
More Questions: A Theoretical Bent
Appendix A - Consent Form / Questionnaire
Appendix B - Electronic Responses
Appendix C - AI Session Summary
Appendix D - Verification Interview Responses
Appendix E - Selected Bibliography
Appendix F - Memo from General Counsel
Appreciative Inquiry
Appreciative inquiry is a philosophy for change. It assumes that within every organization, something works. By identifying what works, change can be managed more easily through these areas that work. Rather than the traditional theory of "Change Management," that looks at/for the problem in an organization and focusing on what’s wrong or broken, appreciative inquiry looks at what is right in the organization. What works is key to appreciative inquiry. The methodology for AI is simple. Through a collective gathering of employees/people, moments of success are shared and discussed, creating positive energy. Taking that positive energy and turning it into a "living process" is how AI works. Since the statements are from real people and are real experiences, the success can be repeated. This approach is used by organizations to discover, understand, and foster positive innovations in organizational processes. To apply AI the following six steps of are followed:
Step
1. Identification of organizational core
values or life giving forces (LGF’s). (This step takes place in a
2-3hour session with a group of about 20 people).
Step 2. Expansion of core values or LGF’s using
interviews designed and conducted by an AI team of consultants. (Once
the core values are identified, find which ones sustain the LGF’s.)(This is
accomplished through the appreciative interview.)
Step 3. Thematic analysis of the data
undertakes organizational analysis. (A model is developed to frame the
organizational analysis. A matrix is developed and agreed upon, then the LGF’s
or core values are matched against organizational factors.)
Step 4. Constructing possibility propositions.
(States ‘what is’ rather than, ‘what might be’. This step recognizes and
focuses on what organizational practices maximize the potential for
participation. Then the ‘what is’ is expanded to "what might be".)
Step 5. Consensual validation of the
propositions. (This is where a survey is conducted based on what was set
between possibility propositions in Step 4 to gauge them, and tabulation is
performed afterwards to prioritizes those propositions in the organization.)
Step 6. Creating and mandating an
implementation team. (This is the most important step in the AI process.
Groups must begin implementation either through individuals, teams or
committees.
These six steps are a small part of the AI process. Ideally throughout the process appreciation, focus, envisioning, open dialogue and innovation are all occurring. What an organization focuses on becomes reality.
Consistent with my intention to focus on computer-related interactions between technical support people and end-users (as people who actually use computers are so labeled), some steps will be customized and the use of the terms Life Giving Forces (LGF) and core values will be substituted with the term Characteristics, to denote desirable characteristics of a technical help-related interchange from the end-user perspective.
The National Academy of Sciences is a non-profit organization chartered by the Congress of the United States in 1863, by order of the President, Abraham Lincoln. The charter requires the Academy to provide the US Government with Scientific advice. Thus the current nickname; Advisers to the Nation. Since the original charter, the National Academy of Engineering, the Institute of Medicine, and the National Research Council have joined the NAS to form what is now known as The Academy Complex. The National Research Council constitutes the operating arm of the Academies, and is staffed by more than 1,200 employees who provide support to the research of the Academy member’s and other scholars who participate in the work of the Academy. The organization structure of the Academy is fairly complex, and organization charts depicting the Program Organization and the Administrative Organization are attached for reference. Also, you may click on the links and view the charts directly from the NAS website. Other charts depicting various organizational structures may also be viewed via links from the pages referenced above.
The President of the National Academy of Sciences also serves as Chairman of the National Research Council, and various Executive Offices serve to support the staff and program functions of the NRC. These offices include the President’s Office; NRC Executive Officer; NAS Executive Officer; Office of General Counsel; Office of Congressional and Government Affairs; Office Public Understanding of Science; Office of News and Public Information. It is among these offices, along with one program unit – the Commission on Physical Sciences and Mathematics Applications - that this research was conducted.
Another fascinating element of the Academy is its academic, collegial environment, seemingly mixed with a government agency "feel" to it. Eighty percent of the studies and reports generated by this non-profit organization of scholars in the medical, engineering, and natural sciences are requested by United States government agencies. As a result, the perception is that this organization is characterized by many qualities unique to both academic institutions and government agencies alike.
The Office of Information and Technology Services (ITS) provides such services to the entire institution. One characteristic of this is that the program and administrative units of the NRC pay a tech rate for such services as computers; network connectivity; internet; computer support; Help Desk services; application development; much like a typical contractor relationship. However, technology-related employees are fully employed by the NRC just as all other NRC staff. A basic rate paid per computer residing on a user desktop provides certain services to the units. Special requests such as website development, custom application development, are paid for at a specified rate. The NRC units become "paying customers" as a result of this relationship and, as such, have high expectations. They want to be sure, and rightly so, that they receive services commensurate with the costs so associated.
The initial methodology as outlined in the attached document entitled "Practicum Proposal", was customized to accommodate both the needs of the National Research Council staff who participated in the study as well as organizational, time, and legal restraints as provided by the Academy’s Office of the General Counsel (see attached).
The original plan required the use of a version of a technique called Appreciative Inquiry. A summary of the process is attached. Participants will be asked to limit their initial "stories" to those of a technical nature; experiences when technology and technology support people were helpful, and why. Normally, participants would be asked to share a generic experience illustrating when they felt valued, excited, etc.
Data Collection and Instrumentation – In the process of Appreciative Inquiry, I will gather at least fifteen (15) participants each to 1) share stories for the gathering of themes or values related to technology-based experiences and 2) to "verify" the themes. I am hopeful that some of the participants in the first phase will help to facilitate the second phase. I will need to study the impact this may have on the latter’s responses.
Thirteen users initially committed verbally to participate in the project. The process and the intention were explained to each individual. Most expressed a sincere and enthusiastic interest in participating. Due to the constraints listed above, the initial group meeting was canceled. I then sent an E-mail to each participant that included the following:
Each participant was informed of the changes to the process and the reason for this departure from that previously explained to them.
Along, with the electronic forms, I also had face-to-face conversations with five participants who did not respond to the electronic survey. Five participants responded to the electronic, five were informally interviewed face-to-face, five participated in verification interviews, two participants requested that they be excused from the project, and one participant left employment at the NRC and did not participate in the project at all. Five more people participated in verification interviews which were done face to face. These interviews provided rich data that supported the findings from the electronic surveys and the group meeting
Data from the electronic responses were analyzed for various themes that could be interpreted as Core Values for the purposes of the AI Model. Also extracted from the data were Characteristics, which replace the traditional AI Factors that Enhance Core Values. These Characteristics represent aspects of the technical interchanges described in the interviews. Therefore, the AI Matrix describes Values and the Characteristics of the technical interchange that Enhance those values.
Those users who did not respond to the electronic survey were asked the following triggering question:
After this initial question, some of the other questions originally on the survey were asked, but generally the conversation was allowed to flow around the difficulties I now assumed - but had not anticipated - that people had with the electronic survey. Responses to these conversations are recorded and Analyzed in the Section titled Surprises and Special Learning.
After this data was processed, another group meeting was scheduled. Three (3) volunteers participated in this meeting in which some new data was collected regarding characteristics of a positive technical interchange were revealed. Also, this meeting produced some validation of the results gleaned from the initial electronic interviews. Six (6) volunteers who could not attend the meeting were then scheduled for personal interviews in an effort to validate further the results from the electronic interviews and the group session. These results are all documented in the Results section of the paper.
Fifteen volunteers participated in the project in one of the three ways: 1. Responding to an electronic survey, 2. Participating in a group AI session, or 3. Participation in a "verification" interview. The original model calling for some thirty (3) participants was clearly too aggressive. Despite this, I believe that the process and the fifteen (15) participants revealed some extremely valuable, and valid, information.
Results
The results of the study were actually not very surprising. The assumptions outlined in the Practicum Proposal which prompted the study were strongly supported. However, the objective of the study was not to verify the assumptions but to provide some insights into the characteristics that compose a positive and helpful interchange between technical support personnel and the computer user.
Following is a list of Themes that I extracted from the stories shared by those who responded to the electronic survey form. An * next to an item denotes that this theme was noted more than once by a given respondent. A + means that the theme was listed by more than one respondent. Accompanying each characteristic is a definition based on cumulative participant response.
Availability (of Technology) - Users attributed value to the fact that technology tools (computers) exist at all. This is insightful: Despite the frustrations, the value-added by computers is readily apparent.
Productivity (Technology Increases) + - Again, despite frustrations, computers do allow us to do more than we can do without them. The level of expectation increases with technology, and so the psychological fall is farther and harder when the computer doesn't perform as expected.
Calm - A judgment by users of the nature of the techie. Users are generally in trouble (and may display this) when seeking help and they need someone involved in the situation to remain calm.
Professional - Another judgment, much harder for people to define. This word actually encompasses for the users many of the attributes listed here.
Simple English + * - This is straightforward. Users are not interested in being wowed with technical jargon. Some may nod or say yes to avoid looking dumb, but then end up not being able to help solve the problem. Techies need to speak the language of the consumer in dealing with them.
Technical Terms Explained + - Sometimes a technical term may be used because no other word exists to describe some thing. Techie needs to be able to translate these into Simple English as described above.
Learning Opportunity (for User) + * - Many users wasn’t to learn something, including how to avoid the same problem when possible. Anything that can be learned is of value; a word, a concept, technique, etc.
Technical Skill (of Techie) - This one is a little more grey. Users base this judgment on one's ability to figure out and solve the problem, Another aspect of this is the social skill the techie displays in dealing with the user. Show technical skill, but use it in a "nice" way.
Team Effort (Techie and User) * - A judgment based on the user's perception of how helpful the techie wants to be. Users may be able to sense when the techie really wants to help the user and considers them a partner in the process. Otherwise, the user may be perceive that the techie is trying to "dumb down" to them in a "shut up and do what I say" kind of way. The techie loses points if this is perceived.
Patience + * - Tone of voice tells almost all here. People can sense this as well.
Trust - This happens over time. If the techie sounds bored or irritated every time a particular user is encountered this will become clear to the user. In person, this is much more obvious.
Confidence - The techie must display confidence that the problem can be solved, and the user must have confidence in the techie. The latter seems to be most important.
Communication - Techies need skill in guiding users through the process of describing what is wrong. A big part of communication is listening, so the techie must be willing to hear the complaining that may accompany the problem description. As well, users recognize that they must listen, follow instructions, and be clear about their problems to make the situation successful.
Understanding (of Techie) - Understanding has two meanings here as well. 1) Understanding of the problem by both parties and 2) understanding of the difficulty the problems places the user in. Users must also understand that even though the techie is an "expert", these situations often present technical challenges for them as well. Also, each must understand that occasionally problems exist outside of the local techie's ability to solve.
Competence (of Techie) - If you can solve my problem and are pleasant in the process, then you are competent. That you know what you are doing is manifest in how few problems I have or in how readily the techie solves them when problems do occur.
Helpful Attitude - Be helpful. Genuine helpfulness is usually apparent.
Time + * - Everyone is doing more with less and expected to do so faster. Appreciation of deadlines is important for the techie to know. Users also must be honest about what is critical and what can wait.
Knowledge Sharing + + - Users often feel intimidated by computers. The perception is that computer people make a lot of money and so sharing the knowledge with users closes the gap that may come from these perceptions (or realities). Willingness to share knowledge builds trust and confidence.
Customer Orientation + * - Users want to know that the techie is there to support them in their work. The customer isn't always right, but the customer's need to get their work done should always be the focus of the techie. This characteristic was broken down into three major areas:
Support - User need to feel supported by technology and technical people, not the other way around. Does the technology and support staff do this?
Organizational Orientation - Technology is meant to support the mission of the organization. Users perceive that there are times when the master/servant relationship seems backwards.
Role Recognition - This is related to Organizational Orientation. When technical people understand their role in a service capacity to support the business then their orientation to users and their work probably changes.
Persistence + * - User need this. If their problem is not solved, keep asking for help. If the techie doesn't know the answer, I don't know isn't an acceptable answer. "I don't know, but I will find someone who does" is. (Techie can't play this card too often or it goes to trust, confidence, knowledge, etc).
Knowledge (User/Techie - know "what" to ask) + * - This is related to troubleshooting ability. Asking the right questions to get problem-solving answers is a critical skill. "What's wrong" will usually get the "It's broken" answer.
In extracting the data, it was interesting to note that 4 of the 5 respondents alluded that they hoped to be a part of the process of solving the problem. One respondent stated that he/she had never received help from a technical person. This was an interesting because I have personally been involved in situations where technical help was provided to this individual. I have worked hard to not regard this as a personal affront, but I am also still trying to make some sense of this response. At some moment that "seems" right, I will ask the respondent about this answer. It is hard to tell whether the individual may have misunderstood the question or simply found it difficult to put an experience into words.
Several characteristics were verified as key elements by the five interviewees who did not respond to the electronic survey. The top four are listed on the graphic in the Discussion and Interpretations section. However, four of these five individuals shared the view that fixing the problem quickly was the most important element, and that how it was done and any learning gained was not important. As a note, from personal experience, all of these users generally prefer what we call deskside assistance in trouble situations.
The AI session group verified much of the data collected in the electronic survey. They also added some new elements to the list of critical elements. As a watchful participant in the group session, the story-telling and interaction appeared to critical to the process. And, while the group was small, the discussion produced several important characteristics. As a note, this group did not receive any data from the original respondents prior to their meeting.
Of much interest was the discussion regarding Customer Service Orientation. Under this characteristic, 3 elements were identified; Support, Role Recognition, Organizational Orientation. Technical help people need to be supportive. Because this process assumes that a problem has already occurred, the end-user is clearly looking for help. "Support" can be somewhat "subjective", so defining it broadly is difficult. In the personal interviews, people were asked, if this characteristic is validated, what that means to them.
Role Recognition implies that the technical person understands who is supporting who. It can appear at times that institutions support IT in its efforts. However, it is clear that a technical support shop that understands its role as a support group to the rest of the organization will act differently in its role than one who would presume that this relationship is somehow reversed. This problem is clear in many places in the industry and certainly needs to be addresses!
Organizational Orientation follows closely on the heels of the role recognition. Recognizing the role and how that fits into and supports the mission of the larger organization is key. Trying to create a Word macro or format an e-mail message are not isolated tasks that can be taken lightly. Obviously, these tasks impact the ability of an unit to accomplish its role in the larger context. The main business of the NRC is informational. So, whatever happens that facilitates the dissemination of information is vital to its function. From the user perspective, understanding this role shows through the technical help situation.
The issue of personal knowledge (as power) also came through clearly in the group experience. This is a two-way street, but mostly seen as one that the techie would be most responsible for. A willingness to gain knowledge and endure the process of getting it lies with the user. Most of the trouble here seems to revolve around how this knowledge is communicated. Language is often used that one side of the conversation or the other does not understand.
Another characteristic that this group expressed as important is persistence, which is allied with knowledge and the way it is being communicated. Examples of techies "giving up by saying something like, "gee, I don't know", are too common. Some users become frustrated and give up in their own way by saying that they will figure it out on their won, or by avoiding the help in the first place. How we fix these things is really what this is all about.
The stories shared included many of these characteristics. It seems unrealistic that we could expect all of them to occur when we are talking about human interaction with a machine, and another human trying to help with that interaction! It seems almost hopeless, but raising these issues to a level that people even talk about them will go a long way in helping those positive characteristics to be displayed more often.
Clearly the priority for people is to have their problems resolved quickly. There are certainly differences in preference as to how this occurs and much depends on the particular situation.
Discussion
and Interpretations
Thematic Analysis/Implications
Examples
of Factors that Enhance Technical Communications (Figure I)
Characteristics: Þ Factors That Enhance Them:ß |
Plain English |
Courtesy |
Knowledge |
Understanding of Problem by Techie/User |
Attitude of Techie |
Helpful |
|
Has Kowledge and can Communicate effectively |
Patient |
Attitude of User |
|
Patient |
Desire to Learn |
Patient/Persistent |
Learning Opportunity |
|
|
|
Know What to Ask |
Timeliness |
|
|
|
|
Resolution |
|
|
Quickly |
Persistent |
Role Understanding |
|
Help |
Share |
Patient/Persistent |
Participants responded differently to their commitments to participate in the project.. After some careful reading along with some insightful discussions with Dr. Lavoie, I have a better idea now of some things that may have happened. The fact that more than half of the original candidates did not participate along with some reasons that may have contributed to this have had significant impact on the study. One obvious result is that there is simply not as much data as originally anticipated. So, some of the interpretations and discussion result not only from the data but from these other factors as well. For these reasons, this discussion seems to fit best here.
As some users either did not respond in a timely manner or expressed their desire not to participate, time demanded that the process change some, as outlined earlier in this paper. The original group discussion was replaced by a standard questionnaire which was distributed electronically. I had not anticipated that the way the questions were asked would have such an impact on the response. D. Nadler made a comparison between various methods of data collection(Cummings and Worley; p.114). The four major potential problems he associates with the questionnaire method follow:
1. Nonempathy
2. Predetermined questions/missing issues
3. Overinterpretation of data
4. Response bias
One user expressed all of these problems in her response to my electronic query:
"I have not had a 'positive experience' where I understood and used technology well. I may not be the person to respond to these questions. The questions are so obviously asked in such a way that you will get positive responses only."
It seems that the restriction that seems to be placed on users by asking them to recall a situation when they understood and used technology well was too overwhelming for this user. One of my assumptions is/was that most of us do not understand technology well at all. Secondly, that my questions were geared to solicit only positive experiences also caused a problem. I had made an assumption that people would enjoy the opportunity to share positive experiences. This proved difficult for all respondents, and two users stated this specifically in slightly different ways.
Also, this method seemed to provide users a blank sheet on which they were required to provide some positive experience about the "thing" they were required to use in drafting responses: their computers. In my personal interactions with all of these users, I recognize frustration levels of varying degrees regarding the use of computer equipment. The group interaction would probably have provided a much less threatening environment and a refreshing break from their computers. We might ask who wants to talk about computers using a computer?
The NRC recently completed the organization-wide upgrade to Microsoft Office 97. For many this caused tremendous stress. WordPerfect 5.1 for DOS users are feeling particularly threatened. According to the Force-Field Analysis method, a derivative of Kurt Lewin's three-step mode of change, Group Performance Norms, Well Learned Skills, and Member Complacency are all factors in resisting change (Cummings & Worley; p.125. As a group of sensitive users, these factors must come in to play as we "force" software upgrades upon them.
These factors also appear to come into play within the context of this study. As some users recognized the real impact and intention of the research, I wonder if there was some concern that these areas might be threatened. Afterall, if we make things better as a result of our efforts, we will be accountable for that input which may require an increase of output and the learning of new skills. It is hard to say exactly what is going in people's minds without asking them directly. Even then, one would be hard-pressed to flesh out all of the root causes of behavior.
My own sense is that software upgrades threaten these areas; that discussions about how to use technology well threaten these areas; and that sharing information about what works well may be used as evidence for driving the user community further from their comfort zone. Professor Yasmin Kafai, in briefing an NRC committee assembled to address information technology literacy, stated that the term "fluency connotes the ability to reformulate knowledge, to express oneself creatively and appropriately, and to produce and generate information (CSTB/NRC; p.viii; 1999). This concept of "cluency" could potentially create some apprehension for computer users. Many already feel intimidated by the machine that occupies their desktop. But many also feel "fluent" in the processes that they have "memorized" to accomplish certain tasks. Events that appear to threaten ones fluency must certainly exacerbate any previously existing feelings.
This data along with the attending discussion and interpretations denote several significant implications, not only for the NRC but for all technical organizations that provide support to computer users. The assertion in the Practicum Proposal as originally suggested by Dr. Lavoie is that techies and users appear to be operating within a system that does not necessarily promote cooperation and understanding. In short, the road that can bridge the apparent gap between the techies and the community of computer users is certainly a two-way street.
Techies become expert in understanding how computers work and in navigating their interfaces. But, this does not require that the techie understand the business of the user. Conversely, users know what it is that they want to accomplish but have been given a tool to help without having a good grasp of how these tools work. The what and the how don't seem to always connect nicely. Computers want to "force" users into accomplishing the user's objective in a predefined way. This may account for the many forms of vain use of the name of Bill Gates.
Candace Sidner of Lotus Development Corporation admits that "today's user interfaces are just too hard to use". She continues, "they are too complex even for the narrow range of users for whom they were designed (More Than Screen Deep; p. 315). Ms. Sidner made this assertion in a Proposition Paper submitted for a study conducted by the Computer Science and Telecommunications Board of the National Research Council. Now, what chance do we have to close the gap I have discussed when an executive from the developer of Lotus Notes software makes such an admission? And who are these interfaces designed for? It appears that these interfaces were designed for a few users who "fit the profile of use for current interfaces" (NRC; p.319), whatever that really means.
Ms. Sidner suggests that the lack of research in the areas of "human discourse communication" and of "human-to-human collaboration" and thus the lack of application of these principles to the design of user interfaces contribute to their lack of usability. Dr. John Warfield, Professor at George Mason University, asserted in a lecture from his course entitled, "Resolving Complexities in Organizations, that the main problem with software to day is that it is not designed at all. Conversely, more research in these areas would "offer a means of integrating various modalities and of extending the range of computer users (NRC; p.315). She also suggest that industry will be less interested in this type of research because the payoff is questionable (NRC; p. 317). Consequently, government and institutions such as the National Research Council are in a position to make an impact in this important area. A collaboration between developers and designers may have to occur to bring us closer to interfaces that more closely resemble the natural processes of human discourse (see Possibility Propositions 6 & 7).
In many typical consulting models, this section would most likely be entitled "Recommendations". Having identified problems, the natural next step for the Consultant would be to recommend changes, or fixes for the organization’s problems.
Previously, the implications and interpretation of the results of this inquiry are represented in a matrix (Figure I) which references the relationship between particular Organizational Factors and the Core Values, otherwise known as Life Giving Forces (LGF’s). The results of this thematic analysis represent the status quo, or the "What Is", in the AI Model.
From this perspective then, the natural next step is to reflect "What Will Be". As the previous matrix illustrates the relationship between Organizational Factors and the LGF’s, the following matrix (figure II) shows Propositions related to factors that enhance the Core Values (LGF’s).
Possibility Propositions
Matrix Illustrating
Characteristics and Factors that Enhance Them (Figure II)
(This matrix models how data would
be extrapolated to form Propositions. Propositions are too lengthy to actually
fit into the matrix.)
Characteristics: Þ Factors That Enhance Them:ß |
Language (Plain English) |
Courtesy |
Knowledge Sharing |
Understanding of Problem |
Attitude of Techie |
Propositions related to Attitude T that Enhance Language |
Propositions related to Attitude T that Enhance Courtesy |
Propositions related to Attitude T that Enhance Knowledge |
Propositions related to Attitude T that Enhance Understanding |
Attitude of User |
Propositions related to Attitude U that Enhance Language |
Propositions related to Attitude U that Enhance Courtesy |
Propositions related to Attitude U that Enhance Knowledge Sharing |
Propositions related to Attitude U that Enhance Understanding |
Learning Opportunity |
Propositions related to LO that Enhance Language |
Propositions related to LO that Enhance Courtesy |
Propositions related to LO that Enhance Knowledge Sharing |
Propositions related to LO that Enhance Understanding |
Timeliness |
Propositions related to Timeliness that Enhance Language |
Propositions related to Timeliness that Enhance Courtesy |
Propositions related to Timeliness that Enhance Knowledge Sharing |
Propositions related to Timeliness that Enhance Understanding |
Resolution |
Propositions related to Resolution that Enhance Language |
Propositions related to Resolution that Enhance Courtesy |
Propositions related to Resolution that Enhance Knowledge Sharing |
Propositions related to Resolution that Enhance Understanding |
Note the complex relationships that exist between all of the Factors and Values. Also, not all relationships include a specific example for the relationship. Those without examples are given for reference only. From this matrix I will extract the relationships which I see as having Possibilities. It may be assumed that among these other relationships, the present, or What Is", already represents What Will Be.
These possibilities will be illustrated from the matrix in the form of Possibility Propositions, as opposed to Recommendations. These Proposed Possibilities will be for the client to use as desired.
Proposition 1:
As part of the ITS philosophy, we do not assume that all computer users understand completely, nor do we expect them to, how it is that the computer technology they use works. We appreciate that for them computers are a tool, not "the job". Recognizing that computers are much easier to use if we understand some basic concepts, we provide as part of our regular "Brown Bag" training courses, a course in basic computer and network terms and functions.
Proposition 2:
We describe those who use computers to do their work as "interacter's", as opposed to mere "users". This attitude helps our technical staff to appreciate and respect those who interact with computers to accomplish the vital mission of the National Research Council. This helps us to shed a more positive light on the abilities of those interacters and on the often difficult challenges that today's computer interfaces present to them.
Proposition 3:
We are developing a short-course training program that sensitizes technical employees to the challenges faced by computer interacters. This program is intended to help technical employees appreciate that it is in fact their job to completely understand the computers that are used in the institution. Likewise, it is intended to remind technical employees that it is an unrealistic to expect all interacters (or even a majority) to understand all aspects of the computer and its operations and functions.
Proposition 4:
In helping interacters understand the often un-scientific nature of computers, we hope to create an atmosphere of patience and tolerance in resolving problem technical situations. That direct cause and effect relationships are not always clear and that troubleshooting processes can be as much intuitive as logical is a goal of this initiative. Another outcome of this proposition is a more realistic compromise to the often stated expectation: "fix it now!".
Proposition 5:
Our technical organization recognizes the community of interacters as customers. As such, each ITS employee recognize him or herself as a customer service representative. As such, a total service orientation exists which absolutely extinguishes any feelings of superiority by technical staff regarding computer interacters. Service is our motto. Customer satisfaction is the Clarion call.
Proposition 6:
The ITS organization at the NRC is so serious about customer service, it has commissioned the Computer Science and Telecommunications Board to launch a study in the areas of concern outlined in Candace Sidner's Proposition Paper as part of the NRC publication entitled "More Than Screen Deep". The two areas of focus are:
1. Principles of Human Discourse Communication
2. Principles of Human-to-Human Collaboration
All applications developed "in-house" will be designed based on the findings of such a study.
Proposition 7:
In conjunction with Proposition 6, ITS and the NRC are working actively to promote the implementation of the principles of design consistent with the study findings into future revisions of software.
Conclusions
The first and, possibly, most obvious conclusion is that doing research at work is a challenging task. A technical person doing research among computer users about the helpful qualities of computer-related exchanges may be considered either brave or fool-hearty! Not because the people among whom the research was conducted, but because this computer world effects everyone. And it effects everyone in different ways. Some people really love using computers to get work done. Others recognize that they cannot get their work done without them. Some want to understand them and make computers really useful tools. Others seem to look behind the computers to the people who build them at write the software they use with as sort of contempt. I can appreciate this because I have my own gripes with the design of so much software and hardware today.
Computers are everywhere. Auto mechanics use computers, attorneys use computers, scientists and clerks use computers. At the Academy, there is no shortage of highly educated people who could run circles around computer-related techies in discussions about biology or chemistry or physics. But while average person experiences these things daily, they are somewhat invisible to us. We don't have to how we breathe to do it. We don't have to know the properties of water to drink it or cleanse ourselves with it.
But everyone has a computer on his or her desk. It is an in escapable thing that sits on our desks and forces us to do things its way. And so often computer-related techies seem to take advantage of the pervasiveness of the computer in our lives. We have to use them and, in many ways, it is difficult to use one effectively if we don't have some idea of how it works. Put gas in your vehicle, turn the key, and drive along the country enjoying the view. Combustion, voltage, spark, air pressure, cooling, etc. All of these things and more make the car go. But we don't have to understand it all to drive to the grocery store or to Grandma's house. But if want to type a letter to Grandma and send it to her electronically, we may need to understand a little about how the computer works.
Not necessarily when everything is going the way we are accustomed. It is when something goes wrong that we find ourselves at the mercy of the techie. While there may be several ways to perform an operation, we may only know one of them. Knowing how the process actually works would provide us with the knowledge to try a new of doing something that may work. Then again, maybe not.
Clearly, many are convinced that they do not, cannot, and never will understand
computers. As a Techie, I am not sure that I do either. But something in my
training and experience guides me through a process of trying a new way if
something isn't working right. Computers are a tool, just like a car. And we
expect those tools to work properly, and that is fair. We may also wish that
they would work the way we want them to and they may never happen. Because
people learn differently, like and dislike different things, etc., it is
unrealistic to think that this will ever happen. But it appears that these
expectations often cause us some difficult in the computer revolution era.
Computers also generally do what we tell them to do. And they don't always respond
well when we tell them to do something that they are not programmed to do. They
will never understand us, so our only choice seems to be to try and understand
them. Scary!!
Here is an example: An individual was working in a Microsoft Access database. This database had tables and forms. A nice feature allows a user to sort by form. So, while looking at a table, one users attempted to use the Sort by Form feature. Unfortunately, tables are populated by Fields, not Forms. So this function did not work. Well it did sometimes. That was the strange part. This should have NEVER worked in this way. But because it had somehow worked once or twice, the perception when it did not work was that the software, well, wasn't working. It was enlightening for all of us as we learned more about this. So, a frustration that was initially blamed on bad software (and I agree on the point that the function should never work so as not to confuse users regarding its proper use), was merely a result of not having a clear and broad view of how a database works. So, while one may be able to enter data and create a database, interacting effectively with that data may require some deeper conceptual understanding of how databases actually work.
So, can we conclude that all users are dummies and don't understand computers? I don't think that would be fair. The computer revolution is moving rapidly and changes daily the way people do their work. People who provide computer support normally understand technology well. People who use technology to try and do their jobs understand their business function very well. But where do the two meet? This is what I am not sure of. We have some more questions to ask, but hopefully this is a good start on the path to bridging the gap between technology and those who support it, and those who use it everyday, often under extremely frustrating circumstances, to accomplish their work.
So really much of this seems to come down to language, though attitudes play a large role as well. In fact, it is probably those attitudes that guide the language used. If I as the techie understand well my role in the organization then I am much more apt to do all I can to help the organization accomplish its purpose. And as I recognize my role as a service provider then my communication style is more likely to bend to assure success in helping others accomplish their roles. A technical communication course would probably serve many people - techies and users alike - extremely well.
Surprises
and Special Learning
As this section title suggests, I was surprised by several aspects of this study and, consequently, have learned some things I had not anticipated. I also have several unanswered and, in many cases, still unformulated questions. I will make no intentional attempt to draw any conclusions in this section. Rather, I wish to share some of these surprises, learnings, and questions with a hope that this will generate some more discussion that may not only help to fill in gaps in this paper, but also to assist with research processes that may have helped to avoid some of the difficulties of this study. However, I do believe that some of the surprises I encountered may be associated with the technology system that we function and cannot be attributed solely to any flaws in the approach.
As stated elsewhere, I was surprised by the shift of enthusiasm for the project by people who had originally committed to participate. I am not angry with these individuals, but I hope that somewhere along the way I can get a better handle on "what happened" that "caused" individuals to withdraw from the study. My initial impression - and resulting from a limited conversation with one user - is that the change in process form group interaction to electronic survey format had an impact on some people's willingness to participate. I have not been able to verify this with those individuals and, because of my work relationship with them, may never feel able to approach this topic. I will be open to opportunities as they arise.
Another surprise, and hopefully a learning, was the response by some who stated that they had never had a positive experience using technology and/or with a technical help person. My initial gut reaction to this was along the lines of personal offense. I know that I have helped all of these individuals to some degree with technology. But I was asking the question from my perspective and so, as I reflected on this, recognize that I may have simply asked the question in a way that did not carry the same meaning for them as it did for me. Was it the way the question was phrased, or the format provided for answering the question? One nagging question for me is what results may have been afforded had the original plan for a group session actually occurred? My assumption is/was that as individuals shared positive stories that others would also have been able to "piggy-back" on the stories of others. In this sense they may have realized that they do share positive experiences and that interaction with others may have brought those to light.
On the other hand, it is possible that many do not feel that a computer can be a medium for a positive experience. I don't know what basis I have for that feeling except that in my interactions with many computer users, there seems to be an almost constant, antagonistic "relationship" that exists between user and machine. A near-hatred for the computer seems to hang like a shroud over one's ability to recognize the computer as a powerful tool and a useful facilitator of certain activities that would otherwise be much more difficult to accomplish. Among many users, however, talking on the telephone, and face to face conversation are really the "tools of the trade". In this context, the computer may be seen as a hindrance to the more human-oriented, natural course of communication.
Yet, others explicitly stated their appreciation for these machines which allow them to be more productive, when the machines actually work. Many tasks are near impossible to accomplish effectively without the aid of the computer. E-mail, in particular, has revolutionized the way we do many things. It may also have disabled many of us in our ability to effectively communicate in other ways.
Many users also appreciated the process as much or more than they did any final results. "venting" in a mild way seemed a part of this process. Some users look forward hope that our interactions will improve as a result of their participation. Many seemed to just simply appreciate the opportunity to talk with one another about both positive experiences as well as frustrations.
More Questions: A Theoretical Bent
This paper highlights some very strong relationships between technical support people and those who use computers, along with characteristics that help (or hinder) the communicative process between the two groups of people.
There are still many questions to ask. This section is intended to provide some theoretical basis for some of the actions described along with conclusions. Some historical background will also shed some light on the progression of technological impact in society. This should be a fascinating journey that will not only serve to fill in some gaps in this paper, but to serve as a catalyst for asking some deeper questions in trying to sort out what appears often to be a cultural clash. Not only between technical people and the users of that technology but also the intrusion of technology into our social systems, changing completely many ways that we function and even the way we think about the world around us.
In his book titled Technopoly: The Surrender of Culture to Technology, Neil Postman illustrates the impact of technology on societies through plato's story of Thamus and his interaction with the god Theuth. Theuth had invented several useful tools such as number, calculation, geometry, astronomy, and writing (Postman). Theuth displayed his inventions before the king Thamus, who inquired as to their purpose and use. From Socrates the story goes as follows:
"Thamus … judged Theuth's
claims to be well or ill founded" and "is reported to have said for
and against each of Theuth's inventions. But when it cam to writing, Theuth
declared, 'Here is an accomplishment, my lord the King, which will improve the
wisdom and the memory of the Egyptians. I have discovered a sure receipt for
memory and wisdom.' To this, Thamus replied, 'Theuth, my paragon of inventors,
the discoverer of an art is not the best judge of the good or harm which will
accrue to those who practice it. So it is in this; you, who are father of
writing, have out of fondness for your off-spring attributed to it quite the
opposite of its real function. Those who acquire it will cease to exercise
their memory and become forgetful; they will rely on writing to bring things to
their remembrance by external signs instead of by their own internal resources.
What you have discovered is a receipt for recollection, not for memory. And as
for wisdom, your pupils will have the reputation for it without the reality:
they will receive a quantity of information without proper instruction, and in
consequence be thought very knowledgeable when they are for the most part quite
ignorant. And because they are filled with the conceit of wisdom instead of
real wisdom they will be a burden to society."
Of course, Thamus judged Theuth's "invention" of writing to be a burden while appearing to miss the potential benefits of this discovery. It is fascinating to note their completely opposite perspectives toward this technology. Theuth was enthralled with his invention, while Thamus saw only the downside. Donald Norman describes this phenomena in terms of a machine-centered view of technology and a human-centered view of technology (Norman, p.9). In this case, Thamus was probably over zealous in his wholesale condemnation of the art. Yet, the contrast between the two points of view is undeniable. And the point is well taken and worthy of discussion. Clearly, one side often only recognizes the benefits while the other may only be able to recognize the criticisms. While both are probably valid, they are not sufficient to stand alone. As Thamus and Theuth needed then, and as our techno-culture certainly does today, a recognition of the total impact of any technology on society is vital.
The case for computer technology is no different today. Writing was sold by Theuth as a tool for increasing memory, etc. Actually, the opposite is true. Writing, and computers as well, may be viewed as crutches that allow us to forget things with the knowledge that we can retrieve them later. This should not be viewed necessarily as a judgment, for I highly value both writing and the ability to use a computer. It is obviously important to note that any technology will certainly deliver some benefits, but should not be accepted with one's proverbial eyes closed! The impact of technology cannot be measured only in terms of contribution. This crutches metaphor may be also substituted for more favorable ones. Conversely, computers should also allow us to know less, because so much knowledge becomes "embedded" over time. Instead of the computer being looked at as a crutch that allows us to remember less, it may be viewed as a tool that should allow us to remember less, but doesn't always work well.
Gutenberg, for example, perfected the printing press, allowing the Bible to be made available to a much larger audience (Postman). Gutenberg surely did not anticipate was the newly found ability of people like Martin Luther to use this technology and its resulting mass-produced book of scripture to poke holes in the religious thinking of the day. Had he anticipated this, would he have proceeded as he did? As Theuth, he only saw what he defined as the good that would result from his invention without - and probably without all the information necessary to do so - considering what he may perceive as undesirable effects resulting from this new technology.
There are hundreds of examples of technologies which came about as mankind searched to better his lot in life. The clock, for example, came about as Monks sought to keep a tight schedule for prayer and ritual. As we all know, much of our lives are now regulated by the clock. Time and motion studies, with the clock as the central figure, were meant to help business become more efficient and produce more. This contribution is indisputable. But what has happened to the worker as a result? This represents the qualitative element that is so often missing at the launch of new technology and, possibly even more critical, missing as technologies make their weak effort at assimilating into our societies.
Computers do not work the way we work. They do not think at all, but if they did, the process would be much different than our own. And, somehow, this is judged worthy of our acceptance and even our giving in to the demands of the technology. Truly we must question the value of a tool that is not molten with our own hands with our own needs in mind! From the machine-centered perspective (Postman, p.17), the infallible technology provides a form of "unreal knowledge" to the technocrat. But how long will this so-called knowledge be held in such high esteem? Along a similar vein, Donald Norma admits, "… that technology aids our thoughts and civilized lives, but it also provides a mind-set that artificially elevates some aspects of life and ignores others, not based upon their real importance but rather by the arbitrary condition of whether they can be measured scientifically and objectively by today's tools" (Norman, p.15). Likewise in the words of Thamus to Theuth, "the discoverer of an art is not the best judge of the good or harm which will accrue to those who practice it" (Postman, p.4). It certainly would not take a genius to see who is preaching the value of computer technology today! But, if anyone needs any help, software vendors and manufacturers of computer hardware are leading the cheering section touting the value of their "wares"!
So, what does this discussion have to do with the communication between technical people and the end-user of computers today? From my perspective in a technical support role, this knowledge as power issue provides a strong base from which to operate. An arrogance and even a disconnect from reality (Norman?) is pervasive among technical people. The clash between the machine-centered micro-world and the reality of the human-centered world is stark and often intense. I submit then that much of our communication problems stems not necessarily from a purposeful plot on the part of the technician to exercise some power and control over those who use the technology. Rather, there seems to a problem built into the very nature of technology, why we seek and deploy it, how it is administered, and who understands it.
Yet this should not be viewed as a case for abandoning the technology
revolution completely - or at all. Rather, it seems important for us to
consider as much as we can regarding the development and deployment of computer
technology. Some of the views expressed above may very well be extreme. But the
questions really cannot be ignored but considered carefully in their context -
that we have a challenging issue here. Computers are extremely useful tools.
Some people seem to acclimate to their demands more readily than others. We can
do more to make them easier to use. Users of computers can probably do more to
be patient and recognize that the technology isn't perfect and never will be. So,
what can we all do - as users and
administrators of technology - to work together to make it better for everyone?
Hopefully this paper helps to answer that question at least in part.
Appendix A - Consent Form/Questionnaire
INTERVIEW
CONSENT FORM
Brian Gore is completing a Master’s Degree in a George Mason University program titled Organizational Learning and is required to do a project for completion. The purpose of the project is to do an organizational analysis using a new methodology called appreciative inquiry. The project should normally provide valuable insights about the organizational dynamics of the firm and generate concrete propositions that are based on the core values of the organization.
Your participation in this project is requested. If you participate, you will be interviewed using variations of the questions listed on the next page. The interview may be audio-taped (optional) and transcribed for later analysis. The information will be used in writing a project report and turned in to the professor as an assignment. Should the results of this project be published in the future, the permission of the organization will be sought. If your organization requests a copy of the project report, it will be given to a designated person who may share the findings with you.
This project will be performed according to George Mason University procedures governing your participation in this research. The student’s Adademic Adviser is Professor Don Lavoie, who may be reached at 703 993 1142 for questions. You may also contact the George Mason University Office of Sponsored Programs at 703-993-2295, if you have any questions or comments regarding your rights as a participant in this research.
I have read this form and agree to participate in this project.
________________________________ _____________
SIGNATURE DATE
Appreciative Inquiry questions that will be used in the interviews
1) Think about a few recent positive experiences you have had in this organization. Describe one such event when you felt you understood and used technology well.
Follow-up questions
a) What made it a significant positive experience? Or, What is it about the experience that you continue to cherish?
b) What did you learn from that experience?
2) Name an event where a technical person was particularly helpful. (outstanding/highly successful). What did s/he do?
Follow-up questions
What did you admire in her/him?
a) How has that (what s/he did) contributed to the success of the organization?
b) What kind of language did he/she use?
3) What are your images for the successful use of technology? What would you like to contribute to make that happen?
4) Tell me something about what attracted you to this organization? How did you start out? What were your initial excitements and impressions?
-----------------------------------------------------------------------------------------------------
5) Several people in your organization have identified ______ as a core value. Can you tell me something more about it?
Appendix B - Electronic Responses
Following are transcripts of the electronic responses to the survey questions. The original question is listed followed by the answers given by respondents.
1) Think about a few recent positive experiences you have had in this organization. Describe one such event when you felt you understood and used technology well.
Brian: I have not had a "positive
experience" where I understood or used technology well. I may not be the
person to respond to these questions. The questions are so obviously asked in a
way that you will get positive responses only.
A recent positive experience was updating and
designing webpages for three units. I was asked to modify existing sites to
update information, make the sites easier to maintain, and/or to make the sites
more usable for readers.
Our office inadvertently deleted the data in
one of our databases. It was a significant amount of data that was entered over
the course of an entire year. To recreate the data would have been an enormous
amount of work. We contacted the help desk and requested a file restore from
the backup tape. However, it didn’t work and the data wasn’t restored. One
member of our office was frustrated and began reentering the lost data. The
other member of the office and I felt that we should try the file restore
again. I contacted the help desk and explained the situation. After discussing
the sequence of events, the person from the help desk determined what went
wrong on the first attempt and arranged a second file restore that worked. We
were all very relieved that we recovered our data and avoided a tremendous amount
of extra work.
My boss and I were working on a form in
Access and I learned a few new ideas in making the form more user friendly. I
used that experience to complete the form and prepare it for the person who
will enter the data.
a) What made it a significant positive experience? Or, What is it about the experience that you continue to cherish?
This was a positive experience because it
allowed me to be creative, while balancing amount of information with
ease-of-use.
The fact that the technology worked and saved
us so much time and effort. It was a particularly gratifying experience for me
because it involved working with someone to solve a problem. The help desk
person and I were able to solve a problem by effective communication and
patience.
I love to learn new things, especially in
databases, and it is nice to know that people are willing to share their
knowledge.
b) What did you learn from that experience?
I improved my understanding of html coding
(which I had previously been encouraged to learn on the job), how to work with
the relevant units to figure out what information they wanted available, how to
design the sites so they will be easy to maintain for people without an html
background, and how to prioritize the information to determine what should be
posted.
That technology is more effective when there
is good communication between IT providers and users, and patience and
understanding as well.
Mainly the technical knowledge of fitting
combo boxes with typed in options as opposed to combo boxes linked to queries
of tables. Also new ideas of how to make to form easier to input data.
2) Name an event where a technical person was particularly helpful. (outstanding/highly successful). What did s/he do?
Though it did not have a huge impact, one
such event was when a coworker developed a macro to fix formatting errors in
Microsoft Word. They then distributed the macro and described how to install
it.
I have to use the same event as above because I’m relatively new to the Academy (9 months service) and have not had a lot of contact with IT folks. She was able to arrange for a file to be restored from the backup tape. This was after an initial file restore failed.
I am sorry to say I have no such experience.
What did you admire in her/him?
I was impressed by the person’s willingness
to attempt to write such a macro (they are not a trained programmer, just
someone who saw a software need and fixed it).
Her competence and willingness to work with me
to solve the problem.
a) How has that (what s/he did) contributed to the success of the organization?
While it has not contributed widely, the macro can save a fair amount of time when handling text either pulled from the Internet or received from outside sources. The time alleviates very boring work and allows one to spend it more effectively.
Her assistance saved our office a
considerable amount of time that would have been expended in recreating the
lost data.
b) What kind of language did he/she use?
When I was given the macro, the author
explained to me in plain language what each line of the macro was doing, then
attempted to explain the programming code used to accomplish it. I understand
fully how the macro works, though I would not be able to duplicate the writing
of the program. How to install the macro was clearly described.
She used mostly non-technical language, which
facilitated effective communication between us. Of course, the problem was not
very technical in nature. However, I had the feeling that, even if it were a
very technical issue, she would have been able speak to me in a way that would
be understandable.
3) What are your images for the successful use of technology? What would you like to contribute to make that happen?
I believe that making technology successful
depends on the amount of time the creators of the technology take into account
the end use. It is equally useless to have a wonderful technology that users
cannot figure out as it is to have an easy-to-use technology that no one needs.
Similarly, if the technology is not widely disseminated, or at least
advertised, to the user community, it is useless. I try to make people aware of
helpful functions in known technology and spread the word when I hear about new
useful technologies.
The effective delivery of technical support
to end-users is, obviously, the most important element for the successful use
of technology in an organization. My contribution to make this a reality is to
understand that the IT Dept and the end-users are a team, both working toward
the same objective. The relationship should not be one of, "us
against them".
Logical and precise dissemination of
information, improving medical care and education in general
4) Tell me something about what attracted you to this organization? How did you start out? What were your initial excitements and impressions?
The nature of science policy and combination
of writing with science attracted me to the organization. My initial
impressions had to do with the quality of the staff members and committee
volunteers, the amount of non-scientific office work done, and the ease of
communication with people within the Academy complex.
I was familiar with the Organization and was
impressed by its stature and reputation. I am most impressed with the fact that
the studies that are undertaken by the Academy affect virtually every aspect of
our lives. I also feel that this is a very good place to work, both in terms of
compensation / benefits and quality of working conditions and workspace.
It is fun to work with the Academy members. I
started at the Annual Meeting and had a chance to meet about 200 members and
listen to interesting lectures.
Appendix
C - AI Session Summary
The AI group session in room 225 of the NAS building on Thursday, 21 October, 1999. For the record, the long gap between the initial electronic survey and the group session is due to the need to regroup and make a new call for volunteers.
Three volunteers participated in this session while one person who had originally committed did not attend. The session started with Brian reviewing the slide presentation that each participant had received via email prior to meeting. Participants were able to ask questions regarding the process. Also, a discussion ensued regarding the nature of the goals of the project and the importance of the participant's role. Questions regarding restrictions specified by the Office of the General Counsel and eventual dissemination of the final paper were asked and discussed. It was agreed that the paper would be posted to a private web site and that participants would be given the url to this site, instead of distributing hard copies to each participant.
Each participant was given a copy of the consent form and the questionnaire. Each participant signed the consent form and returned them to me. Questions regarding the questions were asked and responded to. The group was then charged with working together to answer the questions and make notes for one another. Because the group was small, the group agreed that each would take some notes from the others and then share in the responsibility to share those stories again. I left the room for a few minutes to allow the group to work.
Appendix D - Verification Interview Responses
Those participating in the Verification Interviews were asked to respond to the characteristics identified by the initial group that they felt most strongly about. This format resulted in rich discussions with each participant. The essence of those discussions are captured below.
Respondent 1
Customer Orientation, including Role Recognition and Organizational Orientation, were extremely critical characteristics for this participant. He said that something that often seems to be missing is a customer orientation and a strong appreciation by the "techie" of his/her support role in the organization. He lamented that he has learned sometimes it is better to just "give up" on trying to resolve some technical issues. He has actually heard, "I don't know" as a response, ending the discussion. Persistence was raised at this point, but he was adamant that some things just weren't worth pursuing. This is a two-way street, but the perception is that the bulk of the responsibility lies with the techie to pursue a solution, including "that it cannot be done".
This participant also recognizes that problems lie at different levels. "Bugs" in software are clearly not controlled by the user-level analyst, so there isn't much that can be done. Frustration comes when one who can control appears not to.
The topic of "who is serving who" was also raised by this participant. It really seems to be the job of the technical people to help us make the technology work for us. But when techies respond by saying that we don't do things that way or we don't support that, the role of the technical support in the larger organizational context is brought into question. We can often detect an "Us vs. Them" dynamic brewing, and we can wonder who is right or telling the truth. In other words, it can be hard to tell if people know they aren't supporting the organization or if people really aren't being supported by IT. The participant made two very profound statements: 1) Truth is both sides, 2) What you know is what you experience.
The participant offered a possible solution to this "Truth Gap": more non-user/techie contact. By this the users suggested that bringing techies and users together to server on committees to solve a variety of issues may be helpful. One rule he insisted on: No two techies or users could sit next to one another. One of the problems he sees is that each "side" doesn't appear to really appreciate what the other "side" is all about. ("Sides" is obviously not the preferred language here - because that is the perception it seems appropriate to describe the situation this way). He called this potential for "Permanent Corrective Action". "Moving People Moves Knowledge".
ITS (Information and Technology Services) was described as a place-kicker in football. The kicker is called into kick the ball and, when finished, leaves the field as either the hero or the villain. What would happen if ITS were more like a regular player? Always in the game pulling their weight for the full 60-minutes? This was an extremely insightful metaphor for our technology organization. This discussion goes to a fascinating group called Computer Professionals for Social Responsibility (CPSR). This group has launched a working group called Participatory Design and Computers in the Workplace. (Click here for more info: PDC 2000 - the Participatory Design Conference). This kind of activity may go a long way in bridging gaps between technical help people and those whom they support.
A significant example of "the gap" on an institutional level includes an accounting package that the participant states does not support the reality of our non-profit. Millions of dollars were spent on developing this package in-house, yet does not provide for multiple cost-centers and unique billing and accounting functions required. The question: Since our business is to produce studies in the form of documents, why don't we spend millions producing systems that the support the business of producing documents? Having to mark up paper copies of drafts and then manually re-type changes is silly work in the year 2000! Good question - Good point!
Respondent 2
Though initially expressed in different terms, recognizing in a technical person a customer orientation was the main ingredient for a techie/user interface. The term "goodwill" was first used to describe the basic attitude that must be displayed by the techie. Goodwill in this case was defined (or would be manifest by) as politeness, regardless of the attitude of the user.
This person acknowledged that a user requests technical help generally because there is a problem, which means that the "relationship" between the technical person and the user may start off "on the wrong foot". The person also acknowledged that the user also bears some responsibility for separating the technical person from the actual problem (the techie may "represent" the technology and it becomes easy to vent hostility and/or frustration on the technical person).
Because technical people are in a service business, they may have to accept that people are going to be frustrated and may not be as patient as one might wish. Also, it would be a naïve techie who would think that technology is so great that people will never experience problems, and equally naïve to think that the problems people have with computers are generally due to the stupidity of the user. This user suggested that they felt this frequently while interacting with certain technical help people. The feeling because of the user's feeling that the techie(s) assumed that the user knew nothing. One experience shared was regarding problems printing to a network printer. This user had done all of the initial troubleshooting steps learned over time by experience and things shared by techies to help the users solve their own problem!) as well as checked with a neighbor who was also experiencing problems printing to a different network printer. The techie seemed to dismiss this effort and requested that the user repeat these steps until the techie finally acknowledged a network problem (and not a USER problem, as the user felt the techie was assuming as first).
There are many other factors that might go into analyzing this experience - experience of techie; knowledge by techie of user abilities (this takes time to learn); problem that techie has in not being there; etc. So, the user acknowledges that distance and these factors listed introduce extra burdens to the technical help process. This user also sees each of these experiences as a learning opportunity for everyone involved.
Respondent 3
This person is hesitant to request technical help at all. This person has learned to work through many problems and prefers to do all possible before requesting help. This individual was not able to share any experiences because their orientation is such that they believe that first-line technical people cannot be helpful anyway.
Respondent 4
This user provided an extremely useful story about an experience with a technical help person. His was a positive one where his desire to have his problem resolved was paramount. He also found pleasure in the opportunity to learn something new and to apply this knowledge practically in helping to solve his own problem.
The technical person displayed understanding and patience in responding to the participants plea for help after what appeared to be a hard disk drive crash. Hoping for the best the participant called. The techie displayed expert knowledge and was tolerant of the participants frustrations. The techie did all he could to help the user avoid losing data and having to replace the hard disk. The techie also clearly understood his role in the relationship as a "servant".
The elements of role recognition, patience, knowledge, persistence, and creating a learning opportunity were all elements of this exchange. The fact that the participant was able to apply some techniques in discovering and helping to resolve the problem made the process less mysterious and actually served to empower the participant with useful knowledge.
Suummary of this respondents story:
One Saturday morning when I turned on my computer I was
unable to
reach the win 95 platform.
I was prompted to reinstall the operating
system. I spent
several hours and a lot of frustration trying to reinstall it, with no success.
About 9pm that night, after spending an hour on hold with tech
support, a tech answered the phone. I was not sure what the problem was or
exactly how to explain it.
The tech started asking questions that were easy
for me to answer that ultimately led to discovering the
problem. The tech
was careful not to talk down to me when it was obvious I did
not have the
technical prowess he did. It was nice not feeling
intimidated on top of my
frustration.
The tech walked me through some dos commands and then asked
me to format my
hard drive - something I'd never done before or had any idea
how to.
Ultimately, my hard drive had to be replaced.
This was a very positive interface with one whose technical
skills far
surpassed my own. It
was positive because the tech empathized with my
dilemma, spoke in terms I could relate to and took time to
explain things I
did not understand.
Though very frustrated my computer was not working, I
was thrilled by the tech support!
The hard drive arrived in the mail a couple days later and
because of the
excellent step by step instructions from the tech, I was
able to install the
new hard drive and have the full use of my computer in just a few minutes.
This respondents comments on specific Characteristics:
Learning
opportunity...I guess that was a real teaching moment for the tech
and a learning
opportunity for me. I never thought of
it that way. I wonder
if the tech
did. Even though unaware, teaching and
learning were happening.
The gap between
the tech's understanding and mine was narrowed by the
experience. About a year later, I formatted the hard
drive on my computer
and
rebuilt/reinstalled the operating system, drivers and software
successfully. I did that to "clean up" my
computer. I used some of the
commands that I
had learned from the tech.
Attitude...My
attitude was altered by the exchange with the tech. For one,
because I knew the
problem, I was able to relax and let go of some of my
frustration. The tech's attitude, in many ways as much as
his knowledge
contributed to
this. I realized it was not my fault
that my hard drive
failed and that
until I got the new hard drive, there was no sense in
sweating over it
anymore. My temporary disdain for
computers was put into
perspective.
Respondent 5
This participant described several experiences where many of the elements discovered in Phase 1 were applied. The participant called for technical help after exhausting all personal knowledge. The participant's orientation in this relationship allowed her to call and seek help, and with an attitude of learning. This participant has good technical knowledge and can recognize when a problem is over her head. This is role recognition (as the learner). This participant understood that it was not her obligation to make sure that the techie understood their role, and so the participant's recognition of her own role aided the process.
Appendix E - Selected Bibliography
Computer Science and Telecommunications Board; National Research Council, "Being Fluent with Information Technology," National Academy Press, 1999.
Committee on Developments in the Science of Learning; National Research Council, "How People Learn: Brain, Mind, experience, and School," Innovative Adult Learning With Innovative Technologies, Bransford, Brown, & Cocking (eds.), National Academy Press, 1999.
Steering Committee, CSTB, National Research Council, "More Than Screen Deep: Toward Every-Citizen Interfaces to the Nation's Information Infrastructure," National Academy Press, 1997.
Lavoie, Don Dr., Lecture notes and personal discussions, 1998-1999
Cox, Brad Dr., Lecture notes and personal discussion, 1998
Postman, Neil, Technopoly: The Surrendering of Culture to Technology, Alfred A. Knopf, 1993
Norman, Donald A., Things That Make Us SMART: Defending Human Attributes in the Age of the Machine, Addison-Wesley, 1993
Appendix F - Memo from NRC Office of the General Counsel
To: Suzanne Woolsey@NAS
cc: Jim Wright@NAS
Subject: Re: Research Project - Help
Sue,
If you're inclined to grant approval, I would
recommend that Brian observe the following conditions:
1. Any use of Academy computers and related equipment
should be limited in nature and should occur during non-working hours, and in
all other respects, be consistent with the institution's policies, including
the policy on Access to Information and Use of Equipment Owned by the Academy
Complex (HRP&P 600.10) and policies on time-keeping. The institution,
consistent with its policies, reserves the right to review the situation and to
determine at any point that any use of this nature constitutes an unreasonable
cost or burden to the institution.
2. All individuals asked to participate by
Brian, in addition to signing the consent form he has indicated he will use,
should be expressly informed that their participation is voluntary, that the
study is neither sponsored or endorsed by the institution, and that if they
decide to assist Brian in this endeavor, they should do so during non-working
hours.
3. Any resulting written report, whether
published or not, should carry an express disclaimer that the study was neither
sponsored or endorsed by the institution and that the results, conclusions,
opinions expressed in the report are solely those of the author.
4. Brian's consent form indicates that
publication of the report would require permission of the institution. In
considering any request, any publication would require compliance with the
Guidelines for Staff Publications in Non-NRC Publications.
Audrey