Tackling Communication Breakdown: Communicating using benefits and features

Communication Breakdown

Communication Breakdown

Sometimes when I witness conversations between software leads and their non-technical colleagues it makes me want to weep… openly! The reason is that I know that minutes later I’ll have first one, then the other of them come and complain that no-one else understands what is needed to make the project happen. I’ve given up on the number of times I’ve heard a sentence start with the words, “They need to understand that…”

The response that flashes through my mind, that I usually manage to catch before it comes out of my mouth is, “Well clearly they don’t understand so what are you going to do about it?”

There is often a wide communication gulf between an engineering team and its project manager or product owner and it’s not at all uncommon that a gap like this will be picked up by someone in a management rather than a technical role who will immediately attempt to fill it in the only way they know how i.e. with plans, spreadsheets or worse, general alpha wolf stroppiness.

I thought I’d try to do my bit for the sanity of all parties by offering my thoughts on how you can take practical steps to cross this communication chasm.

I was originally going to write a ’10 tips’ style post but there’s way too much for one article so I thought I’d start out by tackling communication breakdown in conversations relating to progress and if people are interested, move on to a few other tips and tricks that I’ve picked up along the way. Hopefully it will be of some use to someone out there.

Incidentally, I’d also love to hear your views too. Lack of communication kills projects and I’m sure you all have your own views and experiences that would benefit others. If so I’d be interested to hear them.

I’ll discuss things that are blindingly obvious to engineers but utterly incomprehensible to everyone else in a second but first off, I want to start with something that is blindingly obvious to everyone else but for whatever reason seems rarely to be understood by engineers.

Now engineers if this next bit is news to you I implore you to read it, understand it, internalise it and live it every day at work because I truly believe it will improve your working relationships with those strange, non-technical folk. If it’s all old hat to you you can always skip over it, I won’t be upset.

Engineers, some basic facts about the company you work for.

  1. The business you work for exists so that someone somewhere has a way of investing some of their hard earned cash in something that will deliver a better return than sticking it in a bank.
  1. The product or service you are working on today only exists because someone, probably your product owner, had balls big enough to convince someone fairly high up the food chain that in their opinion, and probably based in part on cost and timescale information provided by engineering, the value of the product or service in the market minus the cost to build and run it, will make enough money to help deliver that return for the investors.
  2. Your job depends on that being true!

Basically, in order for you to have job security, your product owner needs to know that the system is being developed in such a way that its value continues to exceed its cost by the margin agreed at the start with the company senior management.

With that in mind, the importance of understanding the value of what is being created is clear. Value is the measure of understanding what it’s worth to your customers. In order to be worth something to your customers it needs to provide them with tangible benefits i.e. it needs either to be a tool that allows them to generate money or a tool that allows them to save money. The value of the product or service is a function of the benefit it provides.

Understanding benefit is about understanding features. I would categorise benefits and features by saying that the benefits of the system are the positive impact on the customers business that result from the features of the system provided to the customer’s staff or in other words: value exists where customers can derive business benefits from the system’s features.

So this should give us a big clue to the first thing we need to consider when communicating progress with a non-technical audience .

Always talk in terms of benefits and features.

How about this as a practical example?

The product owner asks the architect / technical lead what he/she thinks will be complete by the end of the week.

Architect responds, really excited because it’s been quite an interesting job, that by the end of the week they’ll have successfully integrated memcached into the architecture which will allow the storage of session data across a load balanced cluster.

Product owner looks frustrated and disappointed, architect can’t understand why.

The reason for the disappointment is that the question he/she was really asking was this, “what features will be in the product at the end of this week that weren’t in there last week and what benefit does that give to our customers?”

By the way, that probably sums up 95% of the questions you ever get asked by people from outside the project so it’s probably worth considering it as the possible question behind pretty much every question that comes your way!

Now while the architect’s answer may have been the literal truth, the architect really didn’t answer the question behind the question and furthermore, while it may be blindingly obvious to him/her what the implications are, their response sounded like this to a product owner:

“110011010101111110110000001111111100010101010110001100”

In order to give an appropriate response you need to start working up what I’ll term the ‘implication hierarchy’. Working up the ‘implication hierarchy’ means starting with your initial technical answer and repeatedly asking yourself, “what does that imply?” until you start to get to things that can be directly related to features, benefits and therefore can be translated by the product owner into value to the business.

Using the example above, if you take the raw engineering, in this case the integration of memcached and work upwards.

– We integrated memcached so we can cluster the web servers.

– By clustering the web services we can serve more customers in a more resilient way than we could before.

– Being more resilient means we can offer better service level agreements than the competition and handle the additional business that will arrive as a result.

Now it may be tempting to stop there but if you want a gold star, you need to get really specific.

– Now that we have a system clustered across 10 web servers we can handle an additional 8,000 customers with a system availability of 99.95% at a total cost of USD30K per year.

Now that’s the answer your product owner was looking for!

Advertisements
2 comments
  1. A good argument for why it would be useful for more people to have an understanding of basic code, perhaps? a bridging of the gap between the programmers and those overseeing the project? Interesting point about different points of view from different sides.

    Lin (ICTinAction.com)

    • Yes, I’m all for people learning how to write code and we need to come to some kind of understanding in this industry. We have a long standing joke in the office that if a developer crosses over into management, they are immediately sent for a corporate lobotomy to remove any memory of what it was like working in the development team 🙂

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: