Figure 1. Relationships Among Customer Interaction Patterns
Copyright © 1998 AG Communication Systems Corporation
Permission is granted to copy for the PLoP98 Conference
With the increasing emphasis on business awareness, individual team members are asked to play a more active role in interfacing with customers. This new role poses a challenge for those who may need guidance to improve their effectiveness in customer interaction.
These patterns target developers and service providers in their direct interaction with customers. This collection has been developing for over a year and has acquired a structure that could produce a pattern language. In the following diagram, patterns at each "level" help form the context for patterns at the next lower "level." Connections between patterns indicate that the lower level pattern was part of the solution for the higher level pattern.
Figure 1. Relationships Among Customer Interaction Patterns
Copyright © 1998 AG Communication Systems Corporation
Permission is granted to copy for the PLoP98 Conference
Most of the Customer Interaction Patterns were mined from a presentation by David Saar, Senior Product Planning Manager at AG Communication Systems. Although developers in our company have had customer interaction experience, this was the first time a product development team had been formally prepared for their first interaction with the customer, in this case, GTE. The customer relationship is important to developers throughout the development life cycle. Many team members are involved one-on-one with a specific customer representative to coordinate the flow of information from the customer to the development team, and from resident subject matter experts on the team to the customer.
After capturing these patterns, I remembered a guideline from Jim McCarthy's book referenced below that seemed to fit the collection from David's presentation. I translated the guideline to the pattern, It's a Relationship, Not a Sale.
Kathy Kromrie-Williams, Product Development engineer, wrote Listen Up in a writing workshop. Kathy's pattern opens up this collection for internal customers as well as external customers. The pattern has a wonderful collection of stories!
Linda Leonard, Product Development leader, contributed the ideas for Be Responsive and Show Personal Integrity, which contain some important, down-to-earth suggestions for improving customer interaction.
The idea for Know the Customer came from Rod Veach, our on-site customer rep from GTE.
Pattern names are written in italics and are part of the narrative, following two patterns by Gerard Meszaros and Jim Doble.
McCarthy, Jim, "It's a relationship, not a sale," Dynamics of Software Development, Microsoft Press, 1995, pp. 71-73.
Meszaros, G. and J. Doble, "A Pattern Language for Pattern Writing," R. Martin, D. Riehle, and F. Buschmann (eds.), Pattern Languages of Program Design 3, Reading, MA, Addison-Wesley, 1998, pp. 527-574.
Pattern Name: It's a Relationship, Not a Sale
You are a product developer or a service provider. You may be part of a team or a single contributor. You currently play an active role in interfacing with customers or you have been asked to take on this role.
Bruce Whitenack's Customer Rapport (develop a rapport with the customer) and Jim Coplien's Engage Customers (closely couple the customer role to the Developer) define the context for this pattern.
The customer can become too dependent on you. You will be the one who gets all those late night phone calls, those last minute requests, those urgent fixes. Since the customer trusts you, you will be the one the customer turns to. [A pattern is needed here to solve this problem! Maybe this pattern is Just Say No!]
In his presentation, David Saar focused on the solution in this pattern, on the importance of developing a relationship with the customer. Developers need a customer contact to answer questions that arise during development and many times, team members simply want to be handed a name and a phone number. David emphasized that just having a person to call is not enough, that a relationship with the customer built on trust would give the kind of results developers wanted.
The relationship with the customer is like a dance. You take steps, and they take steps in response, and then you take more steps. You must be focused on the flow of transactions, on the overall pattern and direction, not merely on the latest transaction. Relationships are not formed instantly but develop slowly and evolve over time.
The following quote is from Selling with Honor referenced below.
In business as in life, it takes a long time to make friends.
The following is from Dan Behymer, director of quality systems at a manufacturing facility in Cincinnati. It appeared in a letter to the editor of Quality Digest, May 1997.
The quality-satisfaction gap is not about products and services. It is about feeling. In a culture where you are bombarded every day with advertisements, objectives and incentives, where someone is always after your hard-earned money, you just want to know that if you buy their goods, they will care once the sale is over. We want someone who cares and will take action. Caring can't come from a total quality improvement team, reengineering, just-in-time or any formula, objectives, or consultants. Customers are human, companies are collections of humans.
These patterns have many known uses. Usually David would say "Life!" when I asked him for a specific known use. Obviously, these patterns can be applied in any human interaction!
The following is from Nick Ash, senior telecommunications analyst for Caterpillar, in an interview for Inside AGCS, referenced below.
Now that [ROMEO is] up and running, [AGCS] is monitoring the system and alterting me if things don't look right. ...This wasn't a matter of installing the system, leaving, and now we're on our own. I feel like I have the support of AGCS on an ongoing basis.I think you have a very good product, and you should be proud of your company and the service employees provide. I'm impressed with AGCS as a company.
"Caterpillar Communicates with ROAMEO," Inside AGCS, July/August 1998, pp. 10-11.
Coplien, J.O., "A Generative Development-Process Pattern Language," in Pattern Languages of Program Design, J.O. Coplien and D.C. Schmidt (eds.), Addison-Wesley Publishing Co., Reading, MA, 1995, pp. 184-237.
Kohn, Lawrence and Joel Saltzman, Selling with Honor, Berkely Books, 1997.
Whitenack, Bruce, "RAPPel: A Requirements-Analysis-Process Pattern Language for Object-Oriented Development," in Pattern Languages of Program Design, J.O. Coplien and D.C. Schmidt (eds.), Addison-Wesley Publishing Co., Reading, MA, 1995, pp. 260-291.
Learn the "inside" of the customer's business and the "far side," the users and vendors whose products must work with yours. This will help ensure that products integrate properly for the customer.
Get "hands on" experience in the customer environment. Some customers will allow you to visit their site and take notes while you watch people work. Customers can also provide documentation for their business processes.
There is no substitute for an on-site visit. See the customer's world and the problems they face. One trip is worth hours of brainstorming about the customers' needs.
Understanding the customer enables a better understanding of customer priorities. This can be valuable if trade-offs between schedule and functionality must be made.
Applying this solution is not as easy as it may sound. Company culture and politics may be beyond your understanding. This is an on-going task; our environment and our customers' environments continually change. Our organization and the customers' organizations are "many-headed beasts" and present different views to different people at different times.
Learning how users' and vendors' products work with yours will help ensure that products integrate properly for the customer.
This pattern can be applied in many human relationships. Members of the ARC (Administrative Resource Center) were quick to point out that Tom Snelten, Product Development leader, was a good coach because he was able to see the world from the ARC viewpoint.
The following is from an AGCS team postmortem:
Once you get to know the customers, they would ask you about anything, including other products!
The following is from an AGCS team postmortem:
If you know someone, they'll do anything for you. You can call them in the middle of the night. If you don't have a relationship like that, you have to follow an official path and it takes longer.
Members of the ARC have said, "There are some people you can kid with and some you can't. You have to learn how to deal with people individually."
The following story is from ARC member Doris Freeman:
Suppose someone brings me something to scan in. Usually they just say, "Please scan this." I try to learn more by saying, "You want me to scan this so you can put it on the web? or send it in an e-mail? or edit it?" They will then say what they have in mind and I can help determine exactly what the end result should be. Sometimes the requester hasn't thought ahead and going through this exercise saves time for both of us! It's good to ask questions. Find out what the customer really wants.
The following story is from Carole Boese, Fe Pati, and Ellen Lara, about the Adopt-A-Printer Process instituted by the ARC:
The following customer satisfaction issue was noted in the 1995 ARC Customer Survey: Service of printers in Building 1, 2nd Floor, was #1 in negative rating and #6 in importance to those customers.Members of the ARC followed up and learned that no department was responsible for the daily maintenance of printers. As a result:
- The ARC formed a sub-team to work with ITS and Shipping to implement a solution to customer printer/toner concerns. ITS and Shipping agreed to stock centrally located cabinets weekly with massive supplies of paper and toner cartridges.
- The ARC would supply ALL printers in Buildings 1, 3, and 4.
- Header sheets are also collected and recycled as pads of scratch paper.
- Created the Adopt-A-Printer Process:
- Created signs for customers with instructions.
- A goal of 90% passing was adopted by the team.
- No concerns from customers in the 1996 survey. In fact, a great improvement in this service was realized.
The following is from an article by Rob Thomsett referenced below.
The question 'What are your requirements?' is the wrong question. The right question is, 'What is your world?' Once we have begun to understand our customers' organization, their concerns, and their way of working, we can begin to get a clearer idea of them, and it becomes much easier to understand their requirements.To understand their needs, we must understand their culture, their hopes, and their expectations. Doing this requires you to get to know your customers as people first and customers second. Understand your customers and you'll understand their expectations.
Thomsett, Rob, "It's the Expectations, Stupid!" American Programmer, April 1997, pp. 30-33.
Use the supporting patterns: Customer Meetings: Go Early, Stay Late; Show Personal Integrity; Listen, Listen, Listen; Listen Up; Be Aware of Boundaries; Mind Your Manners; Be Responsive.
It's easier to build a relationship than to re-build a relationship. Don't assume that a relationship is static. It must be supported and maintained over time.
Stephen Covey has observed,
If I make deposits into an Emotional Bank Account with you through courtesy, kindness, honesty, and keeping my commitments to you, I build up a reserve. Your trust toward me becomes higher, and I can call upon that trust many times if I need to. I can even make mistakes and that trust level, that emotional reserve, will compensate for it. My communication may not be clear, but you'll get my meaning anyway. ...When the trust account is high, communication is easy, instant, and effective.
Every customer encounter is a valuable opportunity to add to your Emotional Bank Account.
According to Scott Hunter, clients prefer to do business with people they like, with people who seem genuinely interested in them, who deal with their concerns. The worst customer interaction mistake for some customers is to get right down to business at the first meeting with the customer, while others do not want to waste time on preliminaries. It's extremely important to Know the Customer. The most critical result produced during an initial meeting is to begin to build trust.
As Mike Reynolds, Vice-President of our Business and Market Development Group, has observed,
People buy products from people.
The following story is from an AGCS team postmortem:
We did demos that flopped but the customer bought our product anyway. We were able to assure the customer that the product would work and spent time establishing a good relationship and building trust. We talked to the customer every day. This is especially important early on.
The following story is from Kathy Kromrie-Williams:
A customer at a remote site called up with a negative growth problem. They were getting an error message saying they hadn't deleted a device they had just deleted. I tried to reproduce the problem but everything worked fine here! We talked on the phone as I entered the commands. They swore up and down they had followed the User's Guide. Something didn't seem right.I knew Stan Ricksecker had a good relationship with the customer, so I asked him to help me. Minutes later, Stan told me they were afraid they would have to pay for a fix if they admitted that everything they had done wasn't as documented in the User's Guide. Once he found that out, it didn't take him long to find out they hadn't used the DELETE command to delete some devices; they had used a command that deleted the tables used for an EXAM on those devices. The fix was easy and provided without cost to the customer. (Fun was had by all!)
The relationship Stan had with the customer could not be replaced by my knowledge of growth processes or anything else. Once your customer knows you will work with them, together you can accomplish anything!
Covey, Stephen R., The 7 Habits of Highly Effective People, Simon & Schuster Inc., 1989.
Hunter, Scott, "Establishing and Maintaining Good Client Relations," http://www.thehost.com/hunter/clientr.htm
When you're attending a customer meeting, don't just spend time with friends. It's easier to socialize with people you know, but make an effort to meet and greet the customer.
If we are holding the meeting we should keep the meeting as short as possible.
Don't lose your sense of the time constraints of your customer and your team members. We are all under time pressure, so a fine balance is required to convey the right message to our customers.
Spending time socializing beforehand allows everyone to come to the meeting with a sense of camaraderie. Time after the meeting is more worthwhile, a benefit of the earlier socializing and more productive meeting. Often a post-meeting gathering is where the real work is done.
This pattern has broader implications than customer interaction. As our company includes more and more telecommuters, there is the increasing loss of visibility to these employees. This can be harmful both to the worker and the company. The employee feels removed from team interaction and the company loses sight of the employee's contribution.
Members of the ARC commented that their meetings begin with five minutes of socializing. The meetings are more productive and group interaction is improved.
The following story is from Kathy Kromrie-Williams:
Our group had a "meeting rep" who volunteered to go to all possible meetings to represent the group and save valuable time for team members. It sounded like a great idea. The volunteer was well-intentioned and was sincerely trying to save effort for the team.The result, however, was a real loss of visibility by the team. No one else was part of interface meetings, so they had no input to agreements and misunderstood some requirements. The real impact was to the team's visibility to the rest of the project. Team members missed valuable networking opportunities and visibility to project coaches.
Once the risks have been shared, the customer will expect regular status reports. Don't just leave the customer hanging with a list of showstoppers and no updates.
Integrity includes but goes beyond honesty. Honesty is telling the truth -- in other words, conforming our words to reality. Integrity is conforming reality to our words -- in other words, keeping promises and fulfilling expectations. Lack of integrity can undermine almost any other effort to...[Build Trust ]. People can seek to understand, remember the little things, keep their promises, clarify and fulfill expectations and still fail to build reserves of trust if they are [two-faced].
The following quotes are from Selling with Honor referenced below.
Don't lie, don't deceive, and don't overpromise. Tell the truth. What you sacrifice in immediate profit will be more than made up in referrals and repeat business.Don't hide even small defects. Always disclose something that would bother you, because it would also probably bother a potential...[customer]. And if they found out, they'd wonder what else you were hiding.
Don't oversell. Only make promises you know you can keep.
Covey, Stephen R., The 7 Habits of Highly Effective People, Simon & Schuster Inc., 1989.
Kohn, Lawrence, and Joel Saltzman, Selling with Honor, Berkely Books, 1997.
Pick up information. Learn what the customer is thinking. Hear what isn't said. Sometimes you need to push for more information. Ask probing questions.
Portray an agreeable, winning attitude. Be flexible and positive. Take action items. Work with the customer.
Remember to Be Aware of Boundaries and Mind Your Manners.
Listening is only one part of building a trusting relationship with the customer. In isolation it will not work. It must be part of an overall strategy with the other patterns in this collection.
As Stephen Covey has said,
"Seek first to understand" involves a very deep shift in paradigm. We typically seek first to be understood. Most people do not listen with the intent to understand; they listen with the intent to reply. ... When I say empathic listening, I mean listening with intent to understand. I mean seeking first to understand, to really understand. ... Empathic listening gets inside another person's frame of reference. You look out through it, you see the world the way they see the world, you understand their paradigm, you understand how they feel.
The following story is from David Armstrong's Managing by Storying Around referenced below.
A sales manager at Armstrong International wanted to add an obsolete feature to the division's new fish finder. This approach contradicted the company's strategy of always providing the latest and greatest technological advance. The sales manager wanted to add a simple flasher to a product that already provided information on the location and size of the fish. No one could understand why the simple indicator that a fish was nearby would be useful. The sales manager pointed out that many longtime customers were not comfortable with the new, computerized technology and wanted the simple interface they were used to.The feature was added. Customer response was great and the product is still on the market. The moral of the story is: listen, listen, listen.
As described by John Guaspari in the reference below:
It's not enough to ask customers, "How are we doing?" We have to ask, "How are you doing?" We need to understand what our customer's wants and needs are. If we really understand these things we'll be able to apply our expertise to meet the needs they express and some things they may not even know they need.
Be slow to speak and quick to listen!
The following is from Selling with Honor referenced below.
How can you find out what people really need? Ask lots of questions and listen more than you talk!Black & Decker has a reputation for listening to consumers. In the 1970s, the company discovered that consumers wanted a portable vacuum cleaner for small spills. This led to the hugely successful Dustbuster. In 1994, hearing that consumers wanted both hands free 75% of the time they use a flashlight, the company created the SnakeLight. How does Black & Decker stumble onto these innovative products? They ask lots of questions and listen for needs.
Armstrong, David, Managing by Storying Around: A New Method of Leadership, Doubleday Publishing Company, 1992.
Covey, Stephen R., The 7 Habits of Highly Effective People, Simon & Schuster Inc., 1989.
Guaspari, John, "The Hidden Costs of Customer Satisfaction," Quality Digest, February 1998, pp. 45-49.
Kohn, Lawrence, and Joel Saltzman, Selling with Honor, Berkely Books, 1997.
Don't think of "them" vs. "us" -- we are all "us"!
Not everyone appreciates empathic listening (listening and identifying with what is being said). Some feel it is a waste of time and view those who use it as slackers.
Empathic listening can only go so far. Both sides must want to change. If only one side does, it might not get much better. Fortunately, most people in this company are intelligent, reasonable people who really want to make things work.
If the customer perceives product quality as bad, that will influence the customer's willingness to change any requests or listen.
In the short term, empathic listening takes more time, but in the long term it pays off. Both sides acquire a certain amount of knowledge of why decisions are made from the others' perspective. Future considerations can take these things into account, as both sides are aware of what is important to the other. This saves time in the long run as you don't have to go over things that have already been considered.
1) Situation: In SVR1621, a lot of problem reports came to Recent Change from System Test that were nonproblems, merely confusion about how things worked.
Typical Response: The problem report would be closed stating it works as designed.
Customer (System Test) Rationale: The feature did not work as System Test expected. System Test had not been given access to or known where the pertinent design documents were. Their version of the User's Guide wasn't up to date. Since Recent Change does not typically test on the prototype, the easiest way to get action on this potential problem was to send them a problem report. This avoids a potential confrontation and saves them from any negative feedback if it isn't really a problem.
Provider (Recent Change) Rationale: Recent Change did not appreciate having to fill out problem reports on things that were working. They could not understand why System Test didn't just look at the design documents, the User's Guide or call before generating the problem report.
After Empathic Listening: System Test and Recent Change developed a much better relationship. Several test shots were shared and problems investigated jointly before any problem reports were written. The number of nonproblems reported was greatly reduced. System Test helped Recent Change develop a review check list and a template for test plans. This made things easier for both groups. Recent Change developed an understanding of what System Test had to do and found it easy to treat them with the respect they deserve.
2) Situation: In SVR1641, Call Processing wanted Maintain Status to write a system macro the day of the system macro freeze.
Typical Response: No, it's too late.
Customer (Call Processing) Rationale: An interface between Call Processing and Maintain Status would not work as effectively without the availability of the macro. The next system macro freeze is a month away. It's a simple macro, just write it!
Provider (Maintain Status) Rationale: If there was a great need for this macro, it should have been identified sooner. The day of the freeze doesn't give us much time to make things work and ensure a good review.
After Empathic Listening: The macro was written and used. Future interactions between Call Processing and Maintain Status were more pleasant than they had been in the past.
3) Situation: On the DACs project, AT&T wanted to change the way they interfaced with the customer regarding protection switching.
Typical Response: We had proposed this earlier and they hadn't liked the idea.
Customer (AT&T) Rationale: AT&T had finally sat down and looked at how protection switching was being done and the knowledge that would be required of the user. AT&T felt the customer would be required to know much more than they would be willing to learn in order to use it with the current interface.
Provider (DACs group) Rationale: It involved a lot of work on our part. It was not a timely suggestion. Now they wanted things changed in a very short time frame and the protection switching testing would need to be done all over again, making the amount of work we would have to do even greater.
After Empathic Listening: We changed the code so our interfaces and referencing of protection switching agreed with theirs. The retesting of protection switching was accomplished. The customer interface was much easier to use; they didn't have problems with it.
4) Situation: In SVR4000, Software found what they believed to be a Firmware diagnostic problem.
Typical Response: Firmware will not work on this or acknowledge it as a potential problem until Software provides a FACTs trace of the problem. We cannot tell if this is really a Firmware problem if we can't see the interaction between the two.
Customer (Software) Rationale: Many of the Software people don't know how to do FACTs tracing. Why should Software have to do it, after all, Firmware could just as easily do the trace. Software felt it had to be a Firmware problem.
Provider (Firmware) Rationale: Firmware felt it had to be a Software problem. Not only does Firmware not know how to use FACTs tracing, but they typically don't load Software on the prototype, they just load Firmware.
After Empathic Listening: Software and Firmware worked together to solve this and many other problems. Firmware doesn't always need a FACTs trace to understand what is going on. We took the time to listen to each other and understand exactly what took place during each step. Sometimes the problem was in Firmware. Sometimes it was in Software. Sometimes it was in both. If we cannot come up with a scenario that explains everything, we tested together and figured it out. A problem is never over until we have figured out every step -- sometimes it takes a while! We feel free to discuss problems with each other. It is good to have people you can go to for this kind of feedback.
Covey, Stephen R.,The 7 Habits of Highly Effective People, Simon & Schuster, Inc., 1989.
Treat every conversation with the customer as part of a negotiation. Take note of any questions and get back with answers.
Don't give away data or make instant judgments. Don't say, "Oh, that's easy!" or "That's impossible!"
Don't discuss commercial considerations, e.g., price, cost, schedule, and content.
Remember to Mind Your Manners.
It is not the intent of this pattern to allow a team member to cover up mistakes or avoid talking about risks; remember to Show Personal Integrity.
Boundaries are good for people. They set limits on actions and make it easier to act.
We must be aware that everyone represents the company and can impact current, future, and even past customer interaction. Off-hand remarks can have a lasting impact on the customer and current and future negotiations. There may be commercial implications of technical issues, e.g., real-time, memory size. We want to avoid setting up the customer for disappointment. Interactions with the customer can change not only customer perceptions but also dollar amounts in negotiations.
Boundaries are different for different team members. Some have the ability to make commitments at certain points. Each team member should be aware of the boundaries that are appropriate for the setting, the customer, and the point in the project.
Dress appropriately. Sometimes "business casual" is acceptable. At other times a suit is required, while on occasion, jeans are acceptable. If you Know the Customer this will help.
Show respect for everyone. Be especially careful with your interactions with others from our company in front of the customer. Avoid disagreement with a colleague from our company in front of a customer! Keep quiet and try to clarify things afterward or set up specific signals or body language to indicate disagreement without letting the customer know.
Don't be so concerned with minding your manners that your behavior is stiff or overly formal. Be your best polite self.
Our workplace environment may be very casual. We may not always be aware of pleasantries when interacting with our team, but these are important in customer interaction.
How we treat each other is an important sign to the customer about how we treat people in general.
The following story is from Mitchi Page:
I recently placed an order with Boise Cascade. I asked when the new catalog was coming out. The reply, "Oh, our brilliant marketing department decided not to issue our new catalog until the first of the year," made me feel uneasy. When a customer contact makes sarcastic remarks about the company or someone in it, I feel uncomfortable dealing with them.
The following quote by Dave Thomas, founder of Wendy's Hamburgers, is from Selling with Honor referenced below.
Be nice to everyone. Be polite.
Kohn, Lawrence, and Joel Saltzman, Selling with Honor, Berkely Books, 1997.
Always return customer phone calls the same day, even if you know the customer will have already left the office and you will only be able to leave a voice mail.
Never let the customer wait more than a week for a response on anything or more than a day for acknowledgement of the request. When you receive the request, contact the customer to say you received it and how you plan to resolve it. If you can't get final resolution in a week, contact the customer, and say what you have done so far.
Members of the ARC get back to customers immediately and try to complete requests in a day. They ask customers, "What is your deadline?" to determine an appropriate response time.
Always have a message on your voice mail and autoreply on your e-mail if you are out of the office. This notifies internal as well as external customers that you're away and whom to contact in your stead.
Don't let your enthusiasm for a quick response lead you to overpromise. Remember to Show Personal Integrity.
Nothing annoys customers more than thinking you're not being responsive. It doesn't help to be working hard on their behalf to resolve something if you don't let them know you're working on it.
The following story is from Kathy Kromrie-Williams:
A remote site was experiencing database problems that were interfering with providing certain services to the customer.All attempts to recreate the problem using FORCE (the interactive RC simulation tool) or the prototype failed. We had an entire week's database changes shipped to us. Using the same load they had, I tried to recreate the problem by entering an entire week of the same commands. This took me several days, working day and night. During this time, the customer received no word from us.
Finally, the customer called and wanted to know what was going on. By this time, all the commands been entered and everything looked like it worked fine. The customer wanted to know what would be done next. I suggested an audit of their patches. The customers were sold on the idea. Greg Kistler proceeded with the patch audit and found several missing patches.
Our customers are very knowledgeable. I wish I had kept them more informed. We might have come up with the idea of the patch audit sooner. Certainly they would have felt more involved. It's too easy to be on one side of a problem and not benefit from expertise on the other side. Keeping the customer informed is only one of the many lessons I learned from this experience, but one of the most important.
Thanks to David Saar for the initial inspiration for these patterns, for spending time reviewing the patterns and for providing the quote from Mike Reynolds. Mike read the patterns and said he liked them!
Thanks to Greg Gibson for the aliases and the positive feedback. Thanks to Paul Bramble for the improvements to Listen, Listen, Listen.
Thanks to Lizette Velazquez, my PLoP '97 "shepherd," for helping me eliminate the recursion from this pattern language. Her comments showed me how to make the patterns stronger.
Thanks to Charlie Schulz, Linda Leonard, and Rod Veach for their valuable suggestions.
Thanks to the members of the PLoP '97 Workshop on People and Process for their insightful comments: Brad Appleton, Mike Beedle, Steve Berczuk, Charles Crowley, David DeLano, David Dikel, David Kane, Don Olson, and Bill Opdyke.
Thanks to Ralph Cabrera, Kathy Kromrie-Williams, Jim Peterson, and Oscar Villa for the valuable workshop discussion on these patterns. Thanks to Kathy for the great stories!
Thanks to Julie Kemp, Ellen Lara, Debbie Liebman, Lynn Mattila, Mitchi Page, and Chalice Webb for giving me the ARC perspective and having such fun doing it!
Thanks to Carole Boese, Doris Freeman, Rita Huard, Tracy Kelty, Annette Meyer, Fe Pati, and Nancy Schulte, and special thanks to Ken Arnold for the masculine viewpoint!
Thanks to Peter Sommerlad, my shepherd for PLoP '98, for all his helpful comments and to Bill Opdyke, my program committee member, for contributing valuable feedback.