Presenting to management is different than presenting to other technical staff. However, it shares a lot in common with good writing: Keep the audience in mind, keep your key points in mind, and focus on communicating them succinctly. Presenting to management is about realizing that you have a busy audience that wants to know the impact, cost, and risk of the plan, not every detail of it (knowing and taking care of those details is what they pay you for). Management wants to know that you thought this plan out, considered alternatives, and did the research (even though management doesn’t want to know all the details).

So, what does that mean in practice? Here is a tutorial for developers and engineers to present successfully to managers.

Who is management, anyhow?

Before deciding whether you’re giving a presentation to “management,” you may first need to understand who management actually is.

This may sound controversial but not everyone with “manager” or even “director” in their title is actually management. If you’re in the technical organization of a bank or financial institution, not everyone with “vice president” in their title is actually management. There are even C-level titles (CEO, CFO, ...) titles that aren’t even really management. That’s because titles have often inflated to the point of near meaninglessness.

For the purposes of this article, “management” is the people authorized to allocate funds. Sometimes, there may be an intermediary (lower or middle management) who isn’t directly authorized but functions that way for all intents and purposes. If you’re giving a presentation to management, it is because a financial or business strategy decision has to be made.

Why you are presenting to management

First, understand why you’re presenting to management:

• You (or your boss) are asking for resources, and management wants to understand the cost/benefit and risk of pursuing this direction.
• A project or service of business-critical function has gone off track or over budget, and management wants to understand why, how this could happen, whether the people involved are able to handle it, and how it will be avoided in the future.
• Management is considering a major change in strategy or organizational structure and is looking for input before making a decision. Maybe they want to understand more about the structure or projects or the people working for them. Maybe they need to understand some part of the business or product better. This is the more difficult presentation to give.

That’s mainly it. Everything else isn’t a presentation to management, even if management is there. If a lot of other people are in the room, it isn’t a presentation to management. Management is largely in those meetings to wave the flag, or add importance to an all-hands meeting.

What management actually cares about

When presenting to management, keep it to what management cares about. Avoid giving a long intro to something or getting into the weeds of technical detail.

Management cares about:

• What the (generally financial) benefits are of something to the company.
• What the risks are to the company.
• How the change will affect the organization.
• Whether it has the right people in place to make this happen.

Management does not care about:

• Your web framework, computer language, or other technical minutiae.
• How clever you think you are.
• Technical details that can’t be easily explained for business advantage.

In some IT organizations, “no” is phrased as “what is the business case for this?” Then you come up with some nonsense that is the business case for using some particular test framework or doing unit tests at all. But that isn’t actually a business case—management doesn’t care about that. If this were a factory, a test framework decision would be a thing that was presented to a line manager. Line managers aren’t authorized to sign or anything, though they might ask management for a budget. They would not present a business case of “doing unit tests.” It would be buried as a line item under “focus more on quality control measures” with a goal of decreasing outages by 30 percent, which will result in $500,000 savings caused by last year’s production outages.

Don’t make the mistake that the IT organization’s “business cases” are actual business cases. They’re organizational politics.

Structuring a management presentation

Every presentation to management should follow roughly this structure:

Who you are and why management should listen to you

Generally, this isn’t answered directly but covered in the introduction. It’s best to give more than your title. But don’t give you résumé or some long bio, but do casually mention a success that qualifies you in this situation.

For example, if I’m asking for resources for my day job and upper management didn’t already know me, I might say something like: “Hi. I’m Andrew Oliver. I’m the technical engagement manager for Lucidworks. I work on our content marketing strategy as well as produce and write a lot of the content. Before coming to Lucidworks I worked for various Fortune 500 companies and startups. One of which was JBoss, where in the early days of the web, I convinced them to invest in blogs, wikis, and other early social media. After that I ran a big-data consulting company.”

In that bio I explained: who I am, where I am in the organization, what I do for the organization, and what qualifies me to make this request.

What the problem is or what is being asked for

This needs to be stated as succinctly as possible. Context may be required, but start with the statement. In general, avoid the long-form storytelling approach when defining the problem. You can use customer stories or other facts as evidence after you define the problem. This should be one slide if possible.

Start with a simple statement that defines the problem. Examples: “We want to replace all of the CPUs in the datacenter. We believe this will resolve the issues we’ve had with hackers from Russia stealing our data” or “We’d like to move our entire product into the cloud.”

How much this will cost

You know how sales people like to hold the cost until the very end? You know how that makes you not really listen to what they are saying until the answer that? You’re actually a salesperson in this case. You’re selling something to management, so if you put the cost at the end, management will know it’s being “built up” for something.

You should explain the cost of what you’re asking for early on in the presentation and provide enough detail on how you arrived at that cost so it’s clear you didn’t pull it out of the air. No one wants to read an accounting statement, but show your work, as your elementary math teacher demanded.

What the business/strategic benefit is

A business benefit is either financial or in market segments. For example, if adding AI to your product makes you the only AI-navigated aerial assault drone and you can demonstrate that there might be demand for that, allowing you to edge out the competition—lead with that. Also explain the downside to inaction.

If the project has gone off the rails due to some unforeseen issue with the latest Intel chips, explain that. For example:”There is a security flaw that allowed hackers to use our cloud platform, deploy their code, and through the flaw access other people’s code. And that although this isn’t supposed to be possible, the flaw made it possible. Replacing these chips will let us prevent this problem and any damage. It will also let us advertise as having fixed this issue to our customers and differentiate ourselves for now from the rest of our competitors that haven’t fixed this problem. If we do not fix this problem, our competitors will beat us to it, giving them a window to capture our customers. Also, our customers may believe we aren’t focused on security. It is difficult to project, but a customer survey shows we could lose 20 percent of our customers for an impact of $6 million this year.”

The risks and how you are going to mitigate them

There is always a risk, even if it is minor. When you drove to work, there was a chance you would wreck your car and die. With each breath you draw, you could inhale toxins from the air that might give you cancer. Everything involves risk. Admit them.

For example: “There is a risk of an outage while we take systems offline to replace their CPUs. Additionally, some of our customers could experience performance issues.”

The alternatives you considered

If you only considered one thing and didn’t think of any other solutions or drawbacks, good management will be incredulous about your plan. You should be too. You haven’t done enough—and that’s just bad engineering.

For example: “There is a software patch but it involves a significant (20 to 40 percent) decrease in performance. We think this would disappoint customers and cause a large number to leave. We also considered waiting to see how this rolls out, but by jumping on this first we think we can leverage this against our competitors and benefit from upgraded performance.”

Dos and don’ts of presenting to management

Don’t fill your slide with a wall of text. Don’t do that to anyone, but especially not to management. Put your key points on a slide and ideally through a visualization. Talk through the rest.

Don’t talk needlessly. Management wants to know the meat of the issue, not the whole history of your thought process and research into the problem. Focus on that meat.

Save some for the Q&A. It is the nature of all people to want to get their input in. This is also a way to stay out of the weeds. In this article’s examples, I alluded to the Meltdown and Spectre Intel bugs. However, note that the explanation was very basic. I didn’t say “virtualization” or “Docker” or “container” or any of the things you might explain to a technical audience. This is almost certainly to prompt questions. Questions are good.

Have your research done and ready. You’re not going to present a lot of research, but you still need to be prepared. Maybe you don’t include your whole cost/benefit analysis in the slides, but you’re prepared to show it or send it as a handout to anyone who cares.

Don’t like PowerPoint? Too bad. I once unleashed a totally different, experimental slideless presentation style on a local conference and bombed. This isn’t a time to give a Ted talk. And save your crusade against Death by PowerPoint for your fellow geeks. Sometimes you have to meet people’s expectations even if you don’t like the ritual.