How AI helped me give a better talk

Here’s how I used AI to give a much better talk than I usually do.

AI is really good at structuring your work and editing it. It is also a great partner for helping pull your ideas out of your head. It really sucks at the content though. It doesn’t capture your voice, or novel ideas, or even what “your taste” is. You need to refine your own talk yourself. This is done through you writing your own content, and having AI structure and edit it.

I have been public speaking for most of my career in engineering. I initially started by just giving a weekly “hackernews summary” at our company townhall. I then started to figure out what developers like to hear and how to keep an audience. I found that often, it was just quick slides and just moving through things quickly to keep interest.Take questions at the end. I’d never really dug into a better way to public speak. I knew there was Toastmasters and other forums for it, but it only really came up when I wanted to train engineers or keep them informed. I didn’t need it outside of that. Now that AI is here, and I haven’t done any public speaking in ages, I thought it would be a good time to brush up on new techniques.

The ask

I was asked to do a talk at the SRE meetup in Sydney. The SRE meetup was mainly about digging into really interesting findings within the SRE space and cool bugs and outages that people have had. I came up with a list of possible talks I could give on short notice:

how to spot the difference between a bad SRE and a good one
how to market yourself as a platform engineer
how AI affects being a platform engineer
how to use AI agents effectively with IaC
why platform engineers make great leaders
the lost art of troubleshooting

The organiser recommended I go with “the lost art of troubleshooting”.

The brain dump

Once I got this idea sorted, I wrote a short overview of what I would cover that looked like this:

“Lost Art”: Only platform engineers tend to put the time into troubleshooting

“Why you should troubleshoot more”: Troubleshooting adds up. The amount of random tidbits of knowledge that allow me to do my job more effectively compounds. Sometimes you don’t know why it’s a good idea to know that when you make a change to the way you attach images to your blog post, it will break your newsletter and stop it sending.

[…]

The end.

It has a lot of ideas and is just “write immediately and get shit out” kinda vibe.

Applying Winston’s method

I then prompted Claude to apply Patrick Winston’s “How to Speak” method to this to get a good structure I could use from this wall of writing. I came across Patrick Winston’s method on Instagram and thought “why not apply it here” so I could make this talk more interesting than my usual.

Me: I’m writing a funny talk called “The Lost Art of Troubleshooting”. It’s for a room of platform engineers. It’s a talk that only lasts 15 minutes. I’ve written out some basic mess, and I’d like to organise it and structure it. I want the talk to be easy, full of memes, and entertaining. I want to use the main method of Patrick Winston’s How to Speak when writing this talk. Can you help me structure it well so that it follows the method and also is funny for platform engineers?

Claude gave me a structure like this:

Claude: The rules we’re writing to:

1. Empowerment promise. Open with what the audience will walk away with. Not a joke, not biography.
2. Cycle on the idea. State the big idea three times across the talk, in roughly the same words. People drift in and out.
3. Build a fence. Distinguish your idea from things people will confuse it with.
4. Verbal punctuation. Number things out loud (“step one… step two…”) so people who drifted off can rejoin.
5. Ask a question. A non-obvious one. Pulls the room in.
6. Examples and stories. Stick where claims don’t.
7. Strong start. No jokes cold. No apologies.
8. Strong finish. No “thank you.” No “any questions.” Salute, vision, or call to action.

The thing is, Claude actually picked out that the core idea in my paragraph above was:

Claude: “The big idea: Troubleshooting is a compounding skill. Software engineers debug their code. Platform engineers debug the world their code runs in. The payoff doesn’t land today, it lands in five years, and AI didn’t kill it, it made it better.”

This wasn’t any good.

Picking the big idea

I then asked Claude to pull back and actually just give me the structure. I would need to delve into my paragraph with Claude to get the actual content.

Me: I think you added too much. Let’s pair it back heaps. I think just put his method at the top, and I’ll help write the actual memes and the creative parts. Keep my reference and we can work through things together.

Me: alright. Let’s start with the big idea. Based on my reference material, what could it be? Please suggest 5-7 different ones.

Ideas it suggested were:

Claude:

1. The compounding bet. Troubleshooting is the highest-compounding skill in your career. The payoff doesn’t land today. It lands in five years, at 2am, when you’re the only person in the room who knows. Angle: time horizon. Why you should do unprofitable-looking work now.

2. The job description. Software engineers debug their code. Platform engineers debug the world their code runs in. That’s the entire job description. Angle: identity. The cleanest fence between platform engineers and everyone else. Sticks well because it’s binary.

3. Method, not magic. There is no such thing as “just knowing the system.” There is only old troubleshooting, billed back to you as intuition. The art is the method, and the method is teachable. Angle: demystification. Good if the talk leans heavily on the 3-step method in section 6.

4. Defend the time. Rewriting is always faster than understanding. That’s exactly why you should understand. The engineer who rewrites learns nothing. The engineer who troubleshoots becomes the one they call. Angle: resistance to the shortcut. This one fights the loudest enemy directly (your PM, your impatience, AI).

5. The weird knowledge warehouse. Your most valuable asset as a platform engineer is the warehouse of weird, useless-looking facts you’ve collected about your system. It looks useless. Until the day it isn’t. Then it’s everything. Angle: the asset being built. Leans on your blog-newsletter story and the “5 to 30 second” Postgres fact.

6. Lost, not dead. Troubleshooting is a lost art, not a dead one. AI made the easy steps free. It made the hard step, proving you understand, more valuable, not less. Angle: AI head-on. Justifies the “Lost” in your title. Probably the most contemporary framing.

7. Sleep at night. You don’t troubleshoot to fix the bug. You troubleshoot to sleep at night. The fix is a side effect of knowing. Angle: personal motivation, not career ROI. Closest to your closing line. Smallest claim, most emotionally true.

If I had to pick: #2 has the strongest hook for repetition (it’s binary and short, ideal for cycling three times), but #1 is the most defensible thesis for a 15-min talk because it does the most work for you. #6 has the best title-payoff since it explains why it’s a lost art.

Mix-and-match is fine too. Pick a primary and we’ll see which secondary it pulls in.

I picked the “weird knowledge warehouse” as the main idea because I agree with that one and have seen it myself in my old team.

Going section by section

I had to prompt Claude to properly write the main idea and go section by section in the presentation:

Me: I actually think the big idea is that the warehouse isn’t useless and the method to stocking it compounds to being a 10x engineer. As you add things to the warehouse, you get better at the ability to add more random shit to your knowledge of the system

I then went through each section:

1. Promise
2. Hook Question
3. Big idea, cycle 1
4. Fence
5. What’s on the shelves
6. The method
7. Compounding Payoff
8. Close

Each section I got Claude to suggest possible ways to write it, and then I would be in editor mode:

Me: I think i’d like to go with the one sentence save but it seems quite obvious. What’s something non-obvious?

Me: These aren’t great. I think a non-obvious question could be:

• When’s the last time you’ve come into a new company and been able to solve their issue without even knowing their system?

• How many of you know an engineer who cowboys changes to main, and it actually improves the codebase?

I feel like non-obvious stuff for platform engineers are around: when does reliability not matter? when do you move to a simpler system? when does the security feature fix the realibility issue? When does putting more gates in CI cause the team to ship faster? When does a software engineer come to you to ask about customer problems instead of production issues?

Me: I think people will confuse the warehouse with “debugging tips”, domain knowledge, systems design. They may also wonder why you don’t write down or fix the issues you encounter instead of just “storing” it in the warehouse.

Me: Alright, let’s make the warehouse concrete. I think the most obvious story at top of mind is the ffmpeg codec bug but I don’t actually remember it that well. I was digging deep into ones I know are cool, but I don’t have any specifics because the warehouse is inherently hard to remember.

I even used Claude to dig into my other chats to get a better idea of what I was currently debugging.

Me: It doesn’t quite hit. Once Dale says yes and it correlates, you ship a potential fix if it’s an incident, but then in the post mortem is where you do the actual digging and you reproduce the error. That’s where the real troubleshooting happens.

After all that back-and-forth, section by section, Claude landed on a Promise like this:

Claude, after the back-and-forth:

“There’s a reason some platform engineers look like 10x engineers, and the rest of us call them magic. They’re not magic. They have a warehouse. It’s full of weird facts about their system, and every fact they add makes them faster at finding the next one.

In the next fifteen minutes you’ll walk out with three things. What’s in the warehouse. The method to stock yours. And the argument you need to defend the time when your PM says ‘can’t we just rewrite it’.”

It wrote one of these for all eight sections, each with delivery notes and slide ideas.

Writing my own cards

By now Claude had the ideas right, we’d hammered them out together, but the words still read like Claude, not like me saying them out loud. So I rewrote every section into cards in my own voice, and added beats it never would have, like “they predict them, that’s the 10x move”: Section 1 (The promise):

• Some 10x platform engineers look like they are doing magic. They aren’t.
• They just have a warehouse full of weird facts about their system.
• Every new fact they add makes them faster at finding the next fact.
• And once that warehouse is big enough, they stop finding bugs at all, they predict them. That’s the 10x move.
• I’m going to walk you through 3 things:
  • What is in that warehouse
  • The method to stock it
  • The argument for defending the time it takes to build it

I wrote my own version of every section like this.

This became my actual speaker notes. The whole talk, speaker notes and all, is live here: The Lost Art of Troubleshooting.

The slides

Then it came time to do my slides. I won’t go into detail about using Claude to do your slides, but what I’ll say is this: Don’t do it. Just make your own. It can’t find good images, or how to space them well, or what to put on them.

I will say that I did get Claude to write out Patrick Winston’s method for doing slides so at least I could use that for doing my own slides:

Claude:

Slide rules (Winston)

1. Slides are for the audience, not you. Not speaker notes. Use a card in your hand if you need notes.
2. Too many words and you’ve lost them. Reading and listening compete. Dense slide = silent room reading ahead = you’re talking to yourself.
3. Never read your slides aloud. They’ll read ahead, you’ll be the slow one in the room.
4. One idea per slide. Don’t compress two thoughts onto one frame.
5. No condiments. No logos, slide numbers, decorative frames, footers, watermarks. If it isn’t carrying information, it’s carrying distraction.
6. Big fonts. People in the back row aren’t optional.
7. No laser pointer. Turns you away from the audience. Point with your hand or pre-annotate the slide.
8. Empty slides are allowed. When the words matter most, kill the slide. Black screen pulls attention back to you.
9. Last slide is not “Thank you” or “Questions?” It’s a contributions slide or a call to action.

So what

Overall, I think the talk went well! I think it wasn’t quite as deep as the other talks at the meetup, but it held its own because it was entertaining.

This is my method for writing talks, and yes, I’ll be refining it in the future as I do more public speaking, but overall, this greatly improved the quality of my talk, and if you are keen to get better at public speaking, use AI to help you follow Patrick Winston’s method. I used to just do quick slides and take questions at the end, but now I’ve got a method I can use and a better way to structure talks in the future.

Winston’s method is proven to work well and I can see it in TED Talks and other great public speaking bits. I think it’s what made my talk entertaining. Don’t get me wrong, don’t use it for everything, but when you want to deliver a great talk, “Steal Like an Artist” and use the damn method. You’ll figure out how it applies to you and you’ll deliver something way better than what you might think.