A pattern is something I am passionate about, it was in your list, I believe, when you were introducing me. And thank you for that very nice introduction. A pattern is a way of capturing a solution to a problem when you’ve seen that many times and usually it’s written by an expert in that particular domain or in my case by interviewing other experts in that domain. And what you are doing is trying to bundle up little nuggets of expertise and the power and the patterns is of course that you have captured this expertise, but the bow around the package is a name and the name gives you a handle on the idea or the solution and so you are less likely to forget it.
And it gives you a way of referring to that sort of problem-solution package so that you can talk about it and if you have a lot of patterns in a particular domain you develop what is called a language that is made up of the names of the patterns. So now you can have a conversation about customer interaction or design or testing and you engage with others that know these patterns and it gives you a higher level view on the problem space in a way to talk about solutions you might implement. So it’s very powerful.
2. Given that definition, what is a customer interaction pattern?
We begin in the software community by looking at patterns for design. There was a very famous book called: "The Gang of Four" book that was published in 1994 and it transformed the way we think about software development. And I think in the beginning a lot of people in software believed that that’s what patterns were about, they were technical things. And so it was a bit of a stretch for us to move into other areas. So the patterns that I talked about on Monday actually came about when I was working at a company in Phoenix, Arizona, and we were moving to Scrum and things were going well and suddenly we realized that what we had done was we had turn developers loose on the customer.
Well, maybe that wasn’t the best thing to do. We began to experience some fairly serious problems. So my boss came to me and it has his suggestion that there might be patterns for doing this kind of thing, patterns for developers that wanted to interact with customers. I am not an expert on customer interaction, I am not a marketing or a business person, I am a technical person and always have been. So what I did was called "pattern mining". I actually interviewed just as an anthropologist or a psychologist would do in studying how people behave. I interviewed our business and marketing team and they gave me the ideas that became the patterns that make up now this collection for customer interaction.
There are collections of things that Agile teams do that were very different from the way we developed software in the past. There were paradigm shifts, if you will, and one of them we are now working in small teams and we really want to have some understanding of the customer’s view point, the user’s view point. And so, it was suggested that there would be an on site customer rep, someone that the development teams would actually converse with or have interaction with on a regular basis. This was a different way of thinking about development, that there wasn’t going to be a wall anymore.
Certainly we had developed software at this small company, but it was all done through an intermediary collection of the business team. Those were the experts, those were the people who talked to the customers. So the idea now that we were suddenly going to have the technical people who were implementing the solutions talk directly to the people who wanted or would be using the solutions, that was revolutionary. And it’s a very powerful shift because now the developers have real understanding or they have the possibility of a real understanding of what this solution is going to do.
Sometimes the product owner can be a customer representative, can be a customer. It depends on the product. Sometimes there are many customers and there will be a product owner who sort of represents the customer point of view. In our case these small teams were interacting directly with the customer, the sort of the voice of the source of the requirements. And in fact in many cases the customer was, I guess, developing this product with the developers. These were brand new innovative solutions and so the idea that we were going to just have requirements that were pretty clear and now the developers could run with that was just not possible.
So they worked shoulder to shoulder with people who were defining the product and so it was being developed. It was an exciting thing and those teams really enjoyed that after their experienced working in a large environment where they never saw a customer. But on the other hand there were issues, there were challenges, there were people problems that came up that we didn’t anticipated.
5. Let’s talk about some of those problems.
So there were stories. My manager came to see me asking about the patterns and I said: "I thought things were going well" and he said: "Well, let me tell you a couple of stories." And those stories were really the drivers for some of the patterns. I could take those stories to the business team and I could say: "Here is something that happened on one of our small teams". I wouldn’t always use the name of the team or the name of the people, but nonetheless, and they would say: "Yes, we could understand how that could happen", a misunderstanding, not realizing what is important, because developers concentrate on good technical solutions and they believe that is enough.
"Isn’t that what the customer wants, a good technical solution?" not realizing what you might be wearing, what vocabulary you are using, how you conduct yourself, what social practices you might be following around the customer meeting. In fact we have a pattern called "Meetings around the Meetings". Most developers hate meetings. I call them meeting-phobic. So when told they had to go to a customer meeting they would sort of zip in just like a bank robbery, zip in expecting a getaway car waiting outside, give the presentation and leave.
So the pattern "Meetings around the Meetings" was made to convey to developers this is not about the meeting, it’s about the chance to talk to the customer, listen, understand what the customer is thinking right now, ordinary social pleasantries: "How are you? How are your kids? How are their baseball games? How are their birthday parties?" things that developers don’t normally think about in the normal course of conversation with the customer. They didn’t realize how important that was. So just outlining very simple things they could do, show up a little early, engage in some small talk, that would make the meeting better.
And then stay after just a little bit to ask for some extra feedback, one on one personal touch so the meetings around the meetings make the meeting a better experience.
It did and we didn’t just hand off the patterns, we had a series of very small training classes, kind of the foundation for I do now. It’s a half day course for people who don’t have a lot of training in marketing. We go through the patterns, we talk about the stories, we actually act out some of the stories. There is something about the plays the thing you really see it, you feel it and so that makes the lesson in the pattern, I think, more effective. So we developed a little training course for the patterns and all the people who were on the new team went through it and they all said the same thing: "Ah, I understand now!"
It wasn’t that they couldn’t do it, it was that they were not thinking about it and they didn’t realize how important it was. For instance one team had been meeting with a customer from Washington DC. We live in Phoenix, Arizona. It’s a very casual environment, in fact it’s against the law in Arizona to wear a tie in the summertime. I am joking, but in Washington DC even in the summer it’s dark suites, ties, dress. So they’ve been showing up for some pretty important customer meetings in blue jeans, maybe t-shirts and it just didn’t sit well with the customer.
So simple things like being aware of cultural differences, what people expect makes a big difference and how that meeting is going to go makes a big difference in how well the customers are going to look at your very good technical solution.
7. Did you have any unexpected results as a result of getting these courses to the developers?
I don’t know. I think the most unexpected result was for me because I am the technical person and I have always worn blue jeans and t-shirts and it was for me to realize it’s just what my mother had been telling me all these years: "Maybe you should get a dress, maybe you should think about how you look, how you hold yourself, what you say" that those really are as important as the good technical solution, things I knew but not really.
The other thing that I am interested in right now is how our brains get us through the day. There is so much going on right now on cognitive neuroscience that we don’t know and a lot of that revolves around things that there would ordinarily be an opportunity for us to know. You said I had PhD in computer science, which I do. You didn’t say that I also have a Masters in computer science, a Masters in Mathematics, a bachelor’s degree in Chemistry. So you see the trend there. They are all technical degrees. I had one psychology course because it was required and I didn’t like it.
So I wasn’t exposed to the business world, what the sales and marketing, what is that all about, what is customer interaction, what is real communication all about, what are those things I was never exposed to that, I never thought about it, I probably wouldn’t have been interested if there had been a class or some seminar that had been offered a longer way. It was just something that was not available to me. So I feel now that I see how important it is. You know at Christmas we watch that movie about Scrooge and Marley and Scrooge has lived his entire life following a set of values that he thinks are the way that the world works and now and now his dead partner comes back and tells him: "Oh, Scrooge, we were wrong, we had it wrong. I am here to save you. I am here to tell you that things that we didn’t pay any attention to are really very important!"
Well, I am not dead yet, but I feel that maybe I can do that. The people that come to my sessions are so much younger and maybe it’s not too late to tell them: "Don’t make the same mistakes I did."
Absolutely. I know that when people understand that I have a very high technical degree and that I have decades of experience, coding, testing, that now I can talk about customer interaction. Now I can talk about retrospectives, implement strategies, I can talk about some soft things and people are willing to listen because they know I also can talk about the hard things, the technical things. So maybe that is a good combination and it will make it so that they’ll listen.
There are lots of personality tests that people do in the workplace. The last company I worked for did a Myers-Briggs test. I don’t know if you are familiar with that or you love to see long various dimensions on your personality, where do you stand. So I took that and I am an ENTJ, and at the end when the results were handed out the person from HR who was giving the test said: "This is so unusual, because all of the engineers here are INTJs, they are exactly like you, except you are an extrovert and they are introverted." So that is a characteristic of a lot of people who are in development of a lot of technical people, they are introverted.
That means they don’t prefer to get energy or their benefits throughout the day by interacting with other people. For them it’s a negative. It’s a dream, so they have mostly avoided thinking about interaction of any kind, not just customer interaction. It’s not something they do easily or well, or choose to do, so I think perhaps it’s difficult for them.
I absolutely do that even though as a technical person I had avoided it most of my life, that it was easier for me to accept it and be open to it. And of course, what my husband says about all the cognitive science. He says: "The reason you like that now is that it is technical, that psychology has become not a soft science anymore. You can slide someone into an MRI machine and you can do an experiment and watch segments of their brain light up. Now that is exciting, but it’s technical".
Ok. I will tell you a couple of others that were derived from the disaster stories. So here was the story: the team went to visit a customer offsite and they were all staying at a hotel. So when the team got there, they were tired so they went down to the bar and they got a little out of hand. In fact the bartender had to extract them from the bar because they were so noisy. And unfortunately in the corner of the bar were sitting the customers who saw the whole thing. So the next day when they walked in to the meeting and realized that the customers had been there it was bad. So the pattern is called: "Mind Your Manners". It’s exactly what your mother told you, that you have to be aware that your behavior is going to be seen by the customer even when you’re not aware of it.
You have to be careful, a little extra care in what you say, how you say it, what clothes you wear, what words you use, what jokes you tell, what inside little nudges you might make about each other. So we developed some simple rules about behavior in front of the customer: think about what to wear, think about what to say, think about jokes you might say, think about not saying certain things, even maybe not going down to the bar and getting carried away the night before. The customer might be there, you can’t be sure of that. If the customer is from another country then I can understand the inside jokes, slang, things like that. So just be more aware of appearances, things that you normally don’t think about.
13. You mentioned the customer from another country. Do these patterns hold true across cultures?
Yes. They absolutely do because they are all context sensitive. For instance, mind your manners sense you have to understand a little bit about your customer and that includes what are their cultural characteristics, what kinds of clothes do they wear, what kinds of food do they eat, what are their habits, is alcohol permitted or is it expected, what goes on in the workplace, what are accepted behaviors and not. And so it says this pattern takes place in a context and that would be culturally defined. So you have to understand what that is if you are dealing with our customer from another country.
Exactly. What Christopher Alexander who is a building architect who wrote patterns for architecture from which we stole the idea of patterns, said: "A pattern gives you a solution to a problem that you could use over and over a million different ways without ever doing it the same way twice." So the solution you are going to apply depends on the context always, whether you are building a building or whether you are interacting with a customer. So what you said is exactly right.
I think that whenever I teach anything, and now you are getting into something that I really care about, it should be my job not to teach something, but it should be my job to teach how to learn, how to teach, how to take whatever it is that I am giving and pass that on. So I am writing a new set of patterns and it seems like a leap, it seems like a long way away from what I do now, but I think it’s connected. So I am writing some patterns for helping people in the 3rd world. What we’ve done especially in the US, but we are not alone in this, the wealthier countries, is that we want to help people, just as I want to help developers.
Technical people develop customer interaction skills. It’s exactly the same. So we look at the 3rd world people who really need our help and we say: "You need roads, we will build those. You need a clean supply of water. You need wells, we’ll build those. You need some animals, we’ll give you those. You need better seeds, plants, we can do that. We will bring them in." So we build the roads and the wells and we import the animals and the seeds and then after a while we go away and the roads decay and the wells dry up and the animals die and they eat the seeds and they are actually worse off then when we arrived.
We haven’t taught them anything. We were well intentioned, we just didn’t know how to do it. We spent a lot of money doing that kind of thing, so I think it’s time for a shift. And what we have to do with people who need our help is exactly what you suggested. We have to help them learn how to help themselves and so when we go in with money and resources it can’t be with the idea: "Here is a gift, you can keep it", or it’s: "Here is a gift, but you have to pass it on." So my husband and I are writing those patterns and that is the first pattern in the collection is passing on the gift.
So we stole that from an international aid organization called Heifer which started after the end of the 2nd World War and their premise, their mission, their guiding principle is: "We are not here to bring animals, we are here to bring a gift" so you can then turn around and give a similar gift to someone else and that keeps it going and that makes it so that your assistance, your training, your aid is sustainable. So these are called patterns for sustainable development and I think it’s what we should all be doing. If we’re in the business of training or coaching or helping one another we should be helping people learn how to do that for themselves.