Picture a storage migration plan going in front of a finance director. Slide one is a diagram of the SAN topology: LUNs, fibre channel switches, two arrays and a lot of arrows. The engineer who drew it is proud of it. About forty seconds in, the director asks whether this will cost more or less than the current setup, and when people will notice. The diagram goes away, the question gets answered, and the deck that took a full day to build turns out to be mostly beside the point. I have made a version of that mistake myself, more than once.
Sysadmins, DevOps engineers and IT managers end up in this room more often than they expect: asking for budget to replace aging hardware, explaining why the patch window needs to move, making the case for a backup overhaul after a near miss, or walking leadership through what happened during an outage. The audience is smart, busy and not interested in how the thing works. They want to know what it means for the business, what it costs, and what you need from them.
These days I treat the whole job as translation.
Start from the decision, not the system
Before opening any slide tool, answer three questions on paper:
For a server refresh, that might look like:
- Decision: approve budget for replacing 14 hosts that go out of vendor support in Q2.
- They care about: cost vs the risk of doing nothing, disruption to staff, audit findings.
- They will ask: can we wait a year, can we move it all to the cloud instead, who else has done this.
Those notes become the backbone of the deck. If a slide does not help with the decision or answer one of those questions, it goes in the appendix.
Translate every technical fact into an outcome
Engineers think in components. Stakeholders think in consequences. For each technical point you want to make, write the “so what” next to it. I keep a two-column scratch table while I prepare:
|
What I know |
What they need to hear |
|
The hypervisor hosts are out of vendor support from April |
After April, if a host fails we cannot get replacement parts quickly. One failure could take the ERP system offline for days. |
|
Backups are not tested regularly |
We believe we can restore our data, but we have not proved it recently. If we are wrong, we find out during an incident. |
|
We have 22% free storage and growth is about 2% a month |
We run out of space in under a year at the current rate. |
|
TLS 1.0 is still enabled on two legacy apps |
Two older systems would fail the security part of next year’s audit. |
The right column is what goes on the slides. The left column is your speaker notes.
Numbers like the ones above should be your real ones, and they should be numbers you can defend if someone asks where they came from. A rough estimate stated clearly (“about 2% a month, based on the last six months”) is far better than a precise-looking figure you cannot explain.
Use a structure that answers the question early
A structure that works for most IT proposals:
Notice the architecture diagram is at the end. Keep it, because someone (often the CIO, sometimes a board member with an engineering background) will want to see it. It just should not lead.
Draft the slides quickly, then spend your time on the hard part
Once you have the structure and the translation table, the slide-building itself is the least valuable part of the work, and the part that eats the most time if you do it by hand. This is where an ai presentation generator earns its place. Paste in your outline and the right-hand column of your translation table, specify the audience, and let it lay out a first version you can edit.
A prompt that gets a usable draft:
“Create an 8-slide proposal for a non-technical leadership team (CFO, COO, HR director). Topic: replacing 14 virtualisation hosts that reach end of vendor support in April. Avoid technical jargon. Use the slide titles and notes below. Maximum 3 bullets per slide, maximum 12 words per bullet. Slide 4 compares three options in a simple table. Slide 8 is an appendix placeholder for architecture diagrams.”
Then paste the outline and notes.
You will still edit. Generated slides often reintroduce jargon from your notes, overfill bullets, or add a generic summary slide. But you start with layout, titles and structure done, and your time goes into the parts no tool can do for you: checking numbers, deciding what to cut, and rehearsing.
If you work from an existing document (a change request, an incident report, a vendor proposal), uploading it as the source can save more time again. Just be careful with anything confidential, and follow your organisation’s rules on what can go into third-party tools. Internal IP ranges, hostnames and credentials should never be in a stakeholder deck anyway.
Make diagrams that tell one story
Non-technical audiences can handle diagrams. They struggle with diagrams drawn for engineers.
A few rules:
- Fewer boxes. Collapse “web tier, app tier, three database replicas, cache layer” into “the system customers use.” Collapse a rack of servers into one icon.
- Label with business names. “Payroll system,” not “PRD-HR-APP02.”
- Show only what changes. For a migration, a before/after pair with the moving parts highlighted works better than one detailed diagram.
- One diagram per slide, with a title that states the point. “Today, one failed server can stop payroll” is a title. “Current architecture” is a label.
For incident reviews, a simple timeline beats a network diagram almost every time. Time on the horizontal axis, three or four labelled events (detected, escalated, mitigated, resolved), and a line showing customer impact.
Explain risk without fear-mongering or hand-waving
Risk is where technical people tend to go wrong in one of two directions. Either everything is a catastrophe (“if this fails we lose everything”), which stakeholders learn to discount, or the risk is buried in qualifiers until nobody notices it.
A format I like for risk slides:
|
Risk |
How likely |
Impact if it happens |
What reduces it |
|
Host hardware failure after support ends |
Low per month, rising over time |
ERP down 2 to 5 days while we source parts |
Refresh before April |
|
Untested backups fail during a restore |
Unknown, which is the problem |
Data loss for affected systems |
Quarterly restore tests (low cost) |
“Unknown” is a legitimate answer. Saying so plainly is more credible than inventing a percentage.
When the presentation is about an outage
Post-incident reviews for leadership are a different animal from budget requests. The room is often tense, someone senior may already be annoyed, and the temptation is to either over-explain the technical cause or get defensive. Neither helps.
An order that keeps these meetings calm:
Keep the blameless tone you would use in an engineering postmortem, but drop the technical depth. The full timeline with log excerpts can go in the appendix or a separate document for anyone who wants it.
A common trap here is a slide titled “Root cause analysis” with seven contributing factors listed in equal-weight bullets, which reads to a non-technical audience as either evasion or chaos even when every factor is accurate and genuinely relevant. Pick the one or two that matter for preventing a repeat. Mention the rest in the appendix.
Rehearse with someone outside IT
Find one person who is not technical (someone from operations, finance or HR who will give you a straight reaction) and walk them through the deck in ten minutes. Ask them to stop you every time they hear a word they would not use themselves. You will be surprised. Words like “deprecated,” “failover,” “latency,” “endpoint” and “EOL” feel ordinary to us and are opaque to most people.
Also ask them to tell you, at the end, what you were asking for. If they cannot say it in one sentence, your first slide needs work.
Time yourself as well. Most people run long on the first rehearsal, usually on the “why now” and options slides, where the urge to explain the technical background creeps back in. Cut there first.
Common mistakes
Opening with background. “First, a bit of history about our infrastructure” loses the room. Lead with the ask.
Too many acronyms. Every acronym either goes or gets spelled out the first time. Keep a short glossary slide in the appendix if you must use several.
Presenting options you do not believe in. If option C is obviously a strawman, stakeholders notice. Make each option genuine, and be clear about which one you recommend and why.
Hiding the cost. Put the number on a slide, with what it includes and what it excludes. Finance will find the gaps if you do not.
Reading the slides. If the slides are written for reading as a pre-read, they are too dense to present from. Consider two versions: a sparse deck for the meeting and a fuller document or PDF to send afterward.
Forgetting the people impact. Leadership will ask “will staff notice?” Have a clear answer: a maintenance window on a Saturday, a 10-minute VPN reconnect, nothing at all.
Reusing the work next time
Technical teams present to leadership on a cycle: quarterly reviews, annual budget requests, post-incident reviews. Save your outlines and prompts. Next quarter, you update the translation table, adjust the outline, and generate a fresh draft. If your team presents often, an ai presentation generator that exports to PPTX or PDF fits neatly into that cycle because the structure stays similar while the content changes.
It also helps to keep a single “standard slides” file for things you explain repeatedly: what a backup policy covers, how patching works, what the on-call process looks like. Each one written once, in plain language, and reused.
Keep a log of the questions stakeholders asked after each presentation, too. A short text file is enough. After three or four meetings, patterns show up: the CFO always asks about licensing renewals, the COO always asks about weekend work. Build those answers into the standard deck so you stop getting caught out by the same question twice.
Short answers
How many slides is right? For a decision meeting of 20 to 30 minutes, six to ten main slides plus an appendix.
Should I include architecture diagrams at all? Yes, in the appendix. Someone will ask, and having it ready builds confidence.
What if a stakeholder asks a deep technical question? Answer briefly, offer to follow up in detail afterward, and bring the meeting back to the decision.
Before your next one
Take the last technical deck you presented and read only the slide titles in order. If someone from finance could follow the argument from the titles alone, you are in good shape. If not, rewrite the titles as statements first; it is usually a fifteen-minute job, and it changes how every slide underneath reads.
