How do you explain highly technical subjects in a non condescending way to senior members of a company?

Question

For my job I am working doing various technical tasks for a company, which often involves explaining said highly technical details to members of the board or the CEO so I can get them to spend 10s of thousands of pounds on things that will help.

I am new to this job, and am not super used to communicating with such people. I asked advise from my manager on this, and he said that when doing any sort of explanation, make it a PowerPoint, don't make it more than three pages, and make sure at least half of those three pages is pictures. I've received some similar advice on technical communication.

I do intend to as best I can follow this, but I am worried when dumbing it down this massively that I'll appear condescending by over correcting my communication style. I have a while before I am expected to do this job fully since I am new, but have already been asked for some technical advice on issues and want to make sure I communicate at the correct level.

How do I communicate key technical information for making important decisions which cost large amounts of money without appearing condescending or like I am treating them like children?

Other questions don't seem to make the assumption that the chosen ideal to explain an idea is 2 PowerPoint slides of pictures and 1 of words, and I want advice on that particular situation.

As an example, they might want to know what they're legally allowed to do on their products so they can talk to other high up people about how to advertise their products and the broad strategic goals for changing their lineup on shelves, and want to know the timeline of when they can use a particular quirk in the law, how the timelines might change with politics and how I can ensure they can use this quirk for longer and in addition how supermarkets will react to them having this particular quirk so they can negotiate with their ceos about it and make coherent arguments about why its good.

I can't just skip the technical details for this sort of proposal and focus on the business questions, because I have been asked direct technical questions which I need to explain in a simple way.

Answer 1

I've watched (and sometimes helped) people doing that in a meeting. They were used to doing that, but, nevertheless, they never forgot they were talking to a bunch of non-technical but very smart people, so they were always using a simple technic:

1. give facts (what we have/do now).
2. improvements that are needed.
3. needs to improve (what do we need, at what costs)
4. justify everything in a simple manner.
5. benefits for the company.

If/when interested, they'll ask for more in-depth data, so have a document ready for them.

Once provided with crystal clear explanations, facts and numbers, they'll be able to draw their own conclusion.

Answer 2

You never want to "dumb it down". By using that phrase, you are setting yourself up to fail, and fail badly.

You need to think about what those people care about, and what background they have, and what is irrelevant details to them. I am almost certain that your "key technical information" is all irrelevant detail. By trying to explain that, you will bore them. By providing a highly simplified explanation, you run the risk of appearing condescending or (in the case of those who understand your field) being so over simplified as to be wrong.

So, what to do? Do not explain the problem or the solution from your point of view. They don't care. Explain it from theirs.

An example:

About once a month the site becomes unusable. When it first started happening it would last an hour or more. We've managed to reduce that to 5 or 10 minutes by installing some alarms and paying people to be on call, but the underlying problem persists. This not only costs us sales when it happens, but is hurting our reputation. And even with the extra pay, staff don't want to be on call or dealing with this. There is a solution which will cost X and take 3 months. I have the details about why it's so expensive if you need them. We considered 4 other solutions but two wouldn't work without enormous changes to the rest of the system and two would have been more than twice the cost of this approach.

There is nothing in there that is childish, "dumbed down", or condescending. If someone cares why the bad thing happens, they can ask. If someone wants to be convinced the solution will work, you can tell them. It's brief, as you've been advised: "The site is unusable" is four words. You don't need the technical details about what makes it unusable or what has to be done to fix it. "There is a solution" is also four words. The details of it are there if someone asks for them, but you don't walk the whole room through them without being asked. Letting go of your conviction that they need the technical details is the key that will unlock this puzzle for you.

Here's another one:

The system was built with a particular suite of tools from [vendor.] They only support their tools for [5 years or whatever.] It has now been [7 or 8 or whatever years] and our developers are concerned they are using unsupported tools. Unfortunately we can't just start using the latest versions of the tools, we have to migrate and make a few changes and run a substantial set of tests. This will take [time] and cost [money]. After we've done it, we should be good for at least another 5 years. In addition to being more secure, it will also be a little faster, and it will be easier to recruit and retain developers since we're using the latest tooling.

Explanations like these are entirely different from what you would use developer-to-developer. You have to focus on the big picture, the costs and benefits, and so on. People who want to drill in will drill in. You generally don't talk about precise probabilities, but instead say "should", "quite likely", "good chance" and so on. You consider intangibles like the happiness of your customers, suppliers, and staff, as well as your reputation and everyone's ability to sleep at night. You draw conclusions and let people ask for details, unlike a typical technical briefing where you give details details details and expect your peers to draw the conclusion.

The advice you've been given about length and format is good. But if you follow that advice while providing "key technical information" your briefing isn't going to work.

Answer 3

In the mid-70s, George H. Heilmeier who was a director at DARPA formulated a set of questions for this precise situation - with technical people having to communicate solutions to leadership teams. It has been used at NASA and many, many other places. The questions are not always formulated like this, but can differ a bit.

• What are you trying to do? Articulate your objectives using absolutely no jargon.
• How is it done today, and what are the limits of current practice?
• What is new in your approach and why do you think it will be successful?
• Who cares? If you are successful, what difference will it make?
• What are the risks?
• How much will it cost?
• How long will it take?
• What are the mid-term and final “exams” to check for success?

Source: https://www.darpa.mil/work-with-us/heilmeier-catechism

Answer 4

Firstly, it does depend on your CEO - however the majority that I've interacted with tend to want the following:

1. The Big Picture
2. Brief technical bullet points
3. Cost/Benefit

So, let's say I was pitching to change our Web-facing shop to a scale-out infrastructure model, so that new nodes can be added quickly to face increased demand coming up to the Christmas shopping spree.

"Hey Boss, last year we did $X volume of transactions through this platform, we had a failure rate of 5%, which cost an estimated $Y in lost revenue."

This is the Big Picture - the reason why I'm bothering them, I'm pointing to something that is real and happened, also prepping the Cost/Benefit analysis

"Looking at our competitors and similar market leaders, they do XYZ to avoid this issue. We plan to upgrade our system to align with XYZ"

Still big picture, but now we've entered the Technical Realm.

"To do so, we need $XX funds, which will be split between new Hardware (approx $...) - which is new servers, a new rack switch and a new fibre connection at the DC to handle additional traffic (approx $...)"

Now, I've given them the Bullet points, the CEO is buying some new physical hardware (that they can touch, see and talk to - CEO's like to 'see' where their money is going...) and more bandwidth.

"Based on the issues we saw last year, this should lead to a higher sales completion rate which will offset the cost of the new hardware - we are estimating an addition $xxxx in revenue"

Now I've given them a Cost/Benefit analysis.

A Good CEO may then press me on the figures I used or ask about alternatives or how we came to the figures etc. And it really helps if you know these inside out and back-to-front.

Think of it not as 'dumbing down' - think of it in terms of respecting their Time. They are paying you to understand all the intricate detail, so that you can present them with options that have been abstracted from the detail to provide an overview:

"We can do this - this is the benefit, this is the cost or this which has less benefit but less cost" - and then the CEO decides where they will get the greatest value.

Answer 5

Although I asked in a comment, "who is your audience?", I'm going to pivot into a different answer.

At the CEO/Board level, regardless of the technical background of the people in those roles, their focus should be about the money aspect of your proposals, the "Why is this going to save us money?/increase productivity?/make us rich?", and not you saying "I need to buy a XYZ Super computer, and only an XYZ brand, because it has the nicely colored blinking lights that everyone finds appealing". So, the technical details should be secondary to the benefits at this level, and are only needed to support the business needs.

Thus, "dumbing" down the technical details is not really an issue per se, as long as you can justify the project in terms that are meaningful to the CEO/board. And that ties into David R's answer about what being condescending actually means.

However, if these people do have a technical background, they may be interested in details behind what you have presented. And hopefully you have at your finger tips the research need to back up your recommendations.

Answer 6

I am working doing various technical tasks for a company, which often involves explaining said highly technical details to members of the board or the CEO so I can get them to spend 10s of thousands of pounds on things that will help.

You shouldn't be communicating highly technical details. You are hired to handle those, not the board members or CEO. Instead, you need to communicate what the board members/CEO care about. Projected deadline, incurred costs, consequences of changes to the budget, ...

Taking a simple example here, I used to communicate to my boss that I would need 2 days to develop a solution and 1 day to write tests for it. They'd argue that it can therefore be done in two days "because there are higher priorities than testing". This caused a cycle of technical debt and brought the development team to its knees.

No matter how much I explained the benefits of testing and how it saves money, time and effort in the long run, it would always be in vain. This happened at a dozen companies, it was not an isolated incident.

Today, I will tell my boss that it takes 3 days of development. I no longer offer the details on how much time I spend developing the solution and how much time I spend writing tests, because they're a package deal.

How I develop software is my expertise, not my boss' expertise, and it's partly my fault for previously trying to make someone who is not technical make a decision that heavily impact the technical workload.

Talk to them about the topics that they care about. Tell them what you need from them, and what will happen (to the things they care about) if they don't give it. That's it. Anything else is just fluff that's going to cause more confusion and disinterest.

Answer 7

A business decision must address one or more of:

• How x will help increase sales
• How x will reduce costs
• How x will reduce risk

The key is to state the goal to the top management with a simple but clear path to one or more of these.

Example: By updating the XYZ system our internal support costs are expected to be slightly lower while drastically reducing our cyber-security risk. This is accomplished by partnering with vendor xyz and will be completed in 18 months.

It helps to include (keep this high level):

• Where you are currently
• What is the goal you are attempting to achieve
• Any known impediments that you are aware of

Answer 8

It might feel condescending to you to explain things in simple terms to your boss's boss's boss, but if you don't explain it that way then he might not understand. Therefore, it doesn't feel condescending to him, it feels like you're explaining things.

Don't explain very simple things in excruciating detail. For example, everyone uses a computer. So when you say "We need new computers", don't say, "you know, those little magic boxes on our desk that pop up those fancy graphics and have that button-board that you can write letters on". That's condescending, everyone knows what a computer is. But if it's something that the audience legitimately doesn't know about, then you can explain it in detail.

As an example of something that isn't condescending, people tend to like to meme about the "series of tubes" comment in the US Senate from years ago (they were explaining what the internet is and the concept of how bandwidth works in terms of data traffic). That analogy actually makes a lot of sense, in the context of the discussion, with the given audience. These people are Senators, they make laws for a living. They don't need to know the electrical engineering details for how data goes down the wire; they simply need to know that the more data there is, the more difficult it is to get that data to the place it needs to go, like balls running down a tube. That comment was appropriate for the time and context in which it was made. Say things like that and you'll be fine.

Side note: As for pictures, visual aides are useful to help someone understand a difficult concept. As they say, a picture is worth 1000 words. But make sure your pictures are relevant, don't just throw random clip-art on your slides to make it colorful or whatever, just to make a quota. Use visual aides that are actually useful.

Answer 9

Condescending happens when we do not respect the other person. When we respect their position and what skills they bring to the situation, then we are not condescending when we communicate at a level they understand. It is our respect for them that counts not the words we use.

Answer 10

Justify your simple explanation by pointing out how valuable the time of your audience is. Tell them you keep it simple so you don't waste their time. They will appreciate this!

Next, focus on the main benefits or effects of your solution. Skip the technical explanation but focus on what is in for them. Make a list of Pros and Cons, but keep it brief: No more than three per item.

If you want to illustrate how the technology works: Try analogies to demonstrate the effects. One sentence is enough. If you want, tell them you will be available if they want to dive in deeper, but don't be disappointed if they politely decline.

Answer 11

In addition to who is your audience question, it can be asked what is country. Different cultures may approach the same topic in slightly different ways. According to Erin Meyer's "The Culture Map", US tend to have application-first reasoning where you would begin a presentation with how it's applicable/executive summary and then explain the conclusion in a practical manner. In principle-first reasoning country like Germany, would present theoretical concept, methodology for analyzing your data, how did you get there and just then a conclusion.