Presenting to executives

A while back I talked about presenting status updates to fellow engineers. That talk ended on an ominous phrase:

A customer meeting and an exec presentation have complete different audience and focus. 

The moment has arrived to lift the veil of mystery, but firstly let me throw in a

Disclaimer

I was lucky enough to work for execs who had strong understanding of market and technology, and did not favour personal gain over company success. So, when you visualise an exec throughout this article, banish the image of PHB or Dilbert's egg-headed CEO. Rather, think of someone whose job equally depends on the merit and success of what you are presenting, and who understands the business at least as well as you do.

Different from status updates

The first step in every successful presentation is figuring what the audience cares about, and shaping the material accordingly.

Of course, saying that all leaders have the same motives and interests would be disingenuous. Everyone has their own perspective, and people who have been in the industry a while and risen high up even more so. However, there are a few common questions that usually hover in the air:

• Does the team know what they are doing? I.e. how easy is it for me to poke holes in the approach? Are they the right guys for the job?
• Can this ricochet into other departments? Have they missed any dependency on others (e.g. marketing campaign, documentation, supportability)? Is there a wide enough grasp on the project?
• Will this go/over under budget? Am I happy with the effort and money invested? Is this justified compared to the other projects on the radar?

• When and how will we monetise this? Is there a sound commercial foothold? Does the team understand the business side of what they are working on? Do they have the right understanding of the market when making project decisions?
• How does this fit into the company concept and strategy? 

Again, there may well be more questions involved, but I'm yet to present to an executive who did not care about these. A bit further down, I'll take a sample status update and have a look at how we can pre-answer these points, but beforehand:

What to avoid?

Here is my personal taboo list:

• Long, 30+ slide presentations. Time is money. For a VIP, time is a lot of money. Most sane people dislike death by PowerPoint (yours truly included), but your bosses can convert dislike into actions. Don't do it.
• Complex project and dependency charts. The exec is not there to do a thorough review of your plan. Showing a huge chart or complex dependencies is akin to saying: "please do my job for me", which is one of the worst messages that can be conveyed. It's good to be able to show that you're in a full control of the situation, which is why this type of information should be cast into the backup slide dungeon.
• Low-level requirement breakdown. Same as above, for the same reasons and with the same resolution.

• Emphasis on technology. In general, technical terms are not out of bounds, especially if the C- on the other side is followed by TO. But, it's important to show that acronyms is not all you care about (see how will we monetise this in the list above).
• Self promotion. The word "I" is great in general (though I already overused it by this point). Just try and minimise it when presenting. 
• Internal politics. Even a slight smell of those can trigger an alarm. Recall one of the questions above "Do they know what they are doing?". If they don't work as a team in the first place, then this question goes to a totally different plane with a potential aftermath to follow. 

• Typos and visual inaccuracies. It's important to show that you treat this occasion seriously. Typos and misspellings might be ok in many situations, but not when you have stakeholders on the line.

What are the signs of a good presentation?

Many questions with quick and acceptable answers usually signal the path to success. Vice versa, if you rattle through slides accompanied by funeral silence, then something is going wrong. In many presentations having an 80/20 split between talk and questions is ok, but not here.

As a rule, I usually strive for at least 50/50 talk-to-listen split when presenting, and if this ratio seems to be far off, try and ask for opinion before jumping to the next slide. Remember, your goal is not to display all the slides, but to address the execs' questions. One of the first signs that slides do not match the agenda is silence - and one of the first actions to fix that is to discover said agenda by asking questions.

This also implies another point: interruptions are good. If you get stopped mid-phrase, great. This is not a poetry recital, and the job at hand is not getting through the PPT, but instilling confidence.

Sample presentation

Let's pull out my one slider from a previous blog post. This is what fellow engineers would see about our achievements from the past fortnight:

And, this is exactly what I'm not going to show to an exec. Rather we need to explain why we've done widget A, what is the commercial benefit of refactoring module B, which customers we expect to bring with feature C, and which business we retained by resolving defect D.

A speech may go like this:

<Slide 1: Screenshot of customisable skin engine, i.e. widget A>

We have been getting more and more customers requests for co-branding, and other modifications of our visual interface. We have prospects X and Y that depend on this capability, and there is anecdotal evidence, especially in the APAC market, of this being critical to remain competitive.
We have done the first steps there, and here how they look. Over the next few sprints we are going to expand in this direction.

<Slide 2: Mock-ups of future customisation>

<Slide 3: Statistics on recent logging issues, and list of escalations>

We had to invest some effort in refreshing our logging implementation. Unfortunately what we had created in 2012 has not scaled with the added demands in the past 3 years, and we had to deal with Z critical escalations diverting people from new features. For this reason, we decided to pay the refactoring price upfront: by spending 5 person-weeks, we expect to avoid customer calls in the future and reduce maintenance effort.

<Slide 4: High-level deployment schedule for telemetry, i.e. feature C>

For the past 3 months, we have been working across several teams on the new telemetry capabilities; this would help us in getting a better understanding of what users are doing and shaping future roadmap. This was a collaborative efforts between back-end, UI and middleware teams, and now we are getting it out to production. We had a small hiccup during deployment, but we're confident that it will be out by the end of this month. If you're interested in what specific telemetry we've created and how we'll use it for roadmap, I'm happy to go over a couple of extra slides.

How was this tailored to the audience?

1. Strong emphasis on the commercial side, next steps and collaboration.
2. Serial delivery without jumping across topics (as opposed to technical presentations to peers). With this type of presentation it's better to be predictable.
3. Meaningful numbers. However, note that they should be the type of figures people will care about. The guys in the audience will recognise a meaningless stat when they see it.

4. No mentioning of technology buzzwords (e.g. Docker). In some circumstances I might slip them in, but this will highly depend on who's present, and what I know of their current interests.
5. Triggering dialogue and seeking feedback (see the last sentence in slide 3). This both shows that you are not over-confident, and gives proactive options on what your listeners would like to zoom in.

Summary

All in all, honesty, business understanding, good, well-prepared answers grounded on a "short-but-to-the-point" approach usually make the day.
Try and avoid slides for slides' sake, and do trigger opinions at key junctions. This type of presentation is an opportunity and the better you understand the agenda and what/why you are talking about, the less chances are there to go wrong.