Theory says that 90 percent of a project manager’s work is communication and if theory says that, there must be some truth in it. The real important thing is the fact that communication is all over the place for the project manager and the theory makes him aware of this from its first chapters. What we often don’t realize is that polishing our communication skills starts much sooner and it is part of our job and our lives more that we knowingly realize. Referring to our work environment only, communication goes around among people with different communication skills and different backgrounds (e.g. developer, tester, administrator, hr). Through all this, I think that one of the most delicate communication channel is the one with the customer and this is the one which I want to take under the radar in this article. Especially now, with all the new Agile methodologies, the entire team is exposed to client interaction. This opens a complicated communication channel between technical people and business oriented people. If, for a project manager playing with this channel is part of his day to day activity, the technical people may find it a little harder to build that bridge which translates the message from technical language to a non-technical one.
When we want to deliver a message we need to take into account, besides others, a couple of important aspects:
The content value: First of all, if we want to make a point, we need to emphasize the value which we are adding through our idea, but in such a way that our interlocutor clearly understands it. So one important thing is to know how to explain the content value.
The Content Value: explaining it is not only a tough thing to do, but at the same time, it needs to be done totally differently depending on the targeted audience. In order to choose our communication strategy, we need to understand first what value it brings to the other parties involved. For technical people, the value will be given by cool words as extensibility, edge technology, latest frameworks etc. For the client, most of the stuff needs to be related to business value. In a free translation, it would be “Will this edge technology / latest framework which you are mumbling about bring me more clients / money?”. For the HR team, the value would translate in people’s happiness / retention. In order to exemplify this, let’s try to relate on a possible situation.
Let’s say that a team wants to update a framework to the latest version for one of the project 3rd party controls which the team is using. Of course, there will be a research, there could be a prototype and finally, there will be tons of good arguments on why they need this. The benefits of this change will be explained in a totally different way. The implementation team discussions will go about the fact that the new version will allow easier integration with the security module; they will go to the fact that it’s easier to be customized and that it has support for unit tests, which the current version doesn’t have. If we go in front of the client (or project sponsor) the things are getting a little complicated. We need to be prepared to motivate how long it will take, how many people will be involved, because this translates in costs to the client. There are a lot of ways to highlight the benefits in front of the client for such a move. Unit tests will ensure a higher stability; therefore will reduce the maintenance costs. They will also increase the velocity in development, so after a couple of implementation cycles, the time invested in the update will be amortized. We will not always have a winning case, but knowing what makes a good value for the client for sure will increase our chances a lot. And after long discussions between team members and between the team and the client, on a smoke break, somebody from HR will approach the project manager and will ask: “So, I heard you guys had some heated discussions lately … is everything ok?”; “Yes, we just wanted to update a framework version and it was very difficult to convince the client”; “But why did you want this change?”; “Because it keeps the team motivated”. Three different targeted audiences, three different ways of expressing the value for the very same thing: a trivial framework upgrade.
The Content might be even harder to be delivered. This is at least as tough and we might need even more skills in order to cover this well. The language barrier is usually installed between the technical and nontechnical people. I participated in enough discussions which should have taken ten minutes and ended up after more than an hour. During that time the mic was turned off many times in order for some of the members to cool off. I participated in some discussions where one party only thought that the mic was off when choosing to cool off. They didn’t end up well. One focus that might allow these discussions to be more relaxed is to be aware of the different backgrounds of the people involved. Once we acknowledge the problem, we can adapt our arguments to what the other party understands. What do you think it’s easier: for the nontechnical people to find technical arguments or vice-versa? I saw nontechnical people with good intentions using buzzwords in order to fit in the conversation. It’s pretty funny. You can spot somebody who doesn’t know exactly what he/she is talking about from miles away. I strongly believe that the easiest way is for technical people to find samples on what they are talking about which relate to real life experiences, something which everybody can understand. And because client discussions are almost every time a sell, we need to choose our words very well in order to make our point. Let’s go again through some samples.
This is a sample that I heard, it’s not my personal idea, but I found it very trendy. Imagine that we have to explain the advantages of continuous testing during a sprint to a person who knows nothing about Agile and Scrum. We start talking about faster integration of testing and bug fixing in development process, we continue by talking about reduced number of bugs and we finish by talking about a more stable release at the end of the sprint. The client will look at you very impressed, all are very good arguments, but I imagine the monologue in his mind during our pleading: “Sprints …. sprints ... I know …. Usain Bolt is good at sprints … “. He smiles satisfied, our belief is that “the client loved the idea” and, two days after that, we are having the same discussion again. Another way of doing it is to compare the sprint with cooking for example. And I’m not saying this just because I love food. Everybody knows more or less about how the food is prepared. Let’s say that a release is compared with the plan to cook for seven days. Each day will be a sprint. Each day, we will have to cook something else. Testing and bug fixing would be very similar to washing the dishes. If we don’t do it as we go, the kitchen might be full of dirty dishes, maybe from day five. And after the seventh day, for sure it will take at least one day to clean them all and we might miss our commitment. But if we clean the dishes as we go, while waiting for something to bake for example, at the end of each day we will have both our kitchen and our plan impeccable. I’m not saying that at the end of the seventh day we will achieve our goal. Of course, the dish from the first day will be close to be expired and we will want to do it again, better, with the new cooler stove which was released lately on the market but that’s another story.
The previous sample is a simple one but we can think of other day to day samples which are more technical. Let’s explain to a client how a load balancer works or why we need composite indexes on a certain table. Now, a funny personal example comes to my mind: a couple of weeks ago, one of my teams had some issues with a release. I asked what the problem was. The answer was short and precise: we had problems generating a bundle. I stood there for a second or two, looking like I knew what they were talking about, before deciding to go over my pride and ask what that was. Again the answer was short and concise and very to the point. The problem is that those words are even harder for me to remember than the word “bundle”. A long time ago I was a technical person (when a pointer was the coolest thing ever) but since then, slowly, I’ve got less and less in touch with technical terms. Even for me it was hard to catch it from first explanation. Imagine how hard it is for a client, who doesn’t have a technical background at all. In my case, one of the team members started to notice the awkwardness of the situation and started to give me an explanation like he would explain it to a small child: you know Bogdan, there are all these files, which are put together and they are looking like a single one. Then, there is a little cool good wizard (not one ‘working’ for the dark side) which makes them smaller in order for the browser to get them faster from the server. I stopped him and I said to him that he had me from “there are all these files which are put together”. And sometimes, this is exactly how a technical people should think, that they need to explain it to a child.
I know that it is our nature, our genetic code, to act always in the conditions where we feel more comfortable. If we are discussing all day long in technical terms without restrictions, it is very hard for us to switch our mindset in that half an hour when we are talking to a client. This comes with experience, with work and with a proper mindset. And again, because of the evolution of the industry, because of the Agile methodologies which encourage a higher interaction between the technical people and the clients (especially in the outsourcing world), it is very important at least to get in touch with this mindset. First, we need to be aware of the current context and, after that, we need to adapt to what this context requires. Then, we have to be able to find the right words to explain the why and the what. And, for that, we need to be able to find the right correlations and analogies in order to play this game right. But once we have found the fine tuning on this, the game becomes really enjoyable.
by Mircea Vădan
by Călin Lupo
by Mădălin Ilie
by Ovidiu Mățan