Wow: PASS Summit is so diverse regarding sessions! It’s not just about geeks enjoying the latest new things in tech. Of course tech is the foundation for what we do and we all love it but everyone needs soft skills as well and Pass Summit is a great place to learn from other data experts about that topic.

So I went to Denise McInerney‘s session on how to successfully communicate with customers. Denise had some excercises for the group which were just amazing. Can you think of a better way to improve on your communication skills then ehm…right communicating ;-)?

First of all we identified who our customers are. It came with no surprise that there often is indeed a chain of customers and we as tech enablers most time start at the very end of that chain. There are developers asking us to do things, product managers talk to us to have xyz put in motion farther down stream possibly is a sales department who needs solutions which in turn then benefit our end customer (of whom we often don’t know much being at the other part of the chain).

Four important tools for customer communication

1. Empathy: walk in your customer’s shoes
2. Attitude: leverage partnership and overcome traditional “us vs them”-thinking
3. Speech: most of the time as tech people we are giving too much information…slow down and pause every now and then
4. Writing

Work out what the goals of your customers are

We all have experienced that customers approach us with a technical solution they developed like “I need you to send me an excel sheet with columns a to d each friday.” This might sound appealing to us as tech people as we have clear instructions what do and it might be a requirement in the end but it is far away from a goal.So step back and don’t jump to a solution right now! Listen carefully and ask questions to work out the goal. This reminds me very much of the great Mico Yuk’s approach which includes asking Why as often as 7 times. A little bit of foreshadowing…but today Edwin Sarmiento told me about the same thing and that he asks his customers the same word “Why” over and over until he get’s right to the motive behind a statement. Mico however has developed her own elegant way of doing that without irritating the conversation partners by varying the questions a bit. I had the honor to get to practice that with Denise. In the role play she approached me as a business analyst needing to have a report for a new product ASAP mostly based on another existing report. I then took some of the rush out of the discussion by asking “What are we trying to achieve here? What’s the overall goal?”  and later summarized what she said. A few minutes later my ability to argue elegantly in English left me however I received great feedback about the way I managed to work out the goal.

Another participant did a comparable practice exercise and played the card of “I really would like to help you but that’s all about prioritization so please talk to my boss first”. Quite an effective technique as well however that’s not the kind of answer I would like to give and in my situation in a small company my boss would probably get back to me asking why I could not find a solution with my colleague without escalating.

Additional communication techniques

Denise put it great saying that often tech and business people talk to each other but are not communicating. It is like if they are talking two different languages and don’t get what the counterpart is talking about. In that regard is extremely important to practice active listening which means summarizing in your own words what your partner just said and checking if you understood correctly.

Regarding meetings it is vital to end 5 to 6 minutes earlier for a summary. Written documentation afterwards is key for clarity and sign-off. It is best to do this documentation in a system which is accessible by everyone like a corporate wiki or a ticket system.

Status updates

Give regular status updates (for example right on that wiki site) and be consistent about it.  Status updates are best with the colors green (everything on track), yellow (potential problem) and red (problem). Don’t beautify a fact that you are lagging behind and be honest about the status. Nobody is keen about being on a project like the airport Berlin-Brandenburg so do your share to avoid such grave project failings with being honest. The hard part of course is that you have to have a plan how to get out of the situation and turn the red into a green. It was incredible watching another participant handling an excercise where she and the customer were forced to reset priorities due to timing constraints for a release. Bringing the bad news like “Key Feature x won’t be available in the next release” for me is quite a hard thing and I could just watch in aw and try to learn from this really skilled colleague. One last important thing is to set expectations right.

Regarding the introduction of changes during development and talking them through with developers Denise noted that it’s just like most developer have a hidden change budget in their head they are willing to handle. So the conversation will start out friendly and all of the sudden the developers will get angry to the product manager continuing to ask for more and more changes. Thus the request: Be open about what’s acceptable to you right from the beginning and where things tend to get challenging for you as a developer.