Lev Goncharov

Infrastructure simplifying engineer

View My GitHub Profile

How to Make a Technical Speech and Not Go Nuts

Date: 2024-08-25

I have made 100 technical speeches in English, Russian, and Spanish at international conferences, meetups, podcasts, etc. I have created the Infrastructure as Code course from scratch, pushed up DevOps school, and mentored a couple of tutors. Believe it or not, I have spotted a pattern:

roadmap

Why?

why?

Before starting, you should have a clear answer to the question: Why do I need it? There are many possible answers, and there is no silver bullet. However, it’s possible to organize them into something like Maslow’s hierarchy of needs:

There are many other possible answers:

Test

Answers are not static. Time flies, and answers can change. It is crucial to reflect on them to create a feedback loop. This allows for improvement. Moreover, the Test idea is applicable to each step on the roadmap:

Which Topic Should I Choose?

There are no out-of-the-box solutions. However, there are some clues:

Good

I am almost 100% sure that you will prepare good enough materials for:

+ / -

These topics really depend on the material quality and the author’s expertise and soft skills. One must be very accurate and patient. If you are a beginner or not confident enough, then just avoid them:

Bad

Materials

Materials

What can you see in the picture? It is a huge unsorted pile of something. It represents raw notes about your theme. Here are some examples:

The goal is to store factual information so that, when needed, you can find, organize, and present it.

Trello

There is no silver bullet for how to organize this information:

Originally, I used Trello + Google Docs. Nowadays, I use Obsidian + Git.

Abstracts

Abstracts

At this stage, you should distill the essence from your notes and prepare good abstracts from it. They will be required later for:

You might agree that mind maps can look a bit ugly and unstructured. The one shown was preparation for my first big conference. I did my best. The idea is that it should not be perfect at this stage. Moreover, nowadays I no longer create mind maps. I just write down theses, and that’s it.

Scenario

Scenario

At this stage, abstracts transform into a fully completed story. Hopefully, the vast majority of the work has been done previously. Just follow this algorithm:

As proof, I provide a link to my speech Lessons learned from testing Over 200,000 lines of Infrastructure Code and propose comparing it with the roadmap.

Requisites

Requisites

Preparing slides is as easy as pie:

Create Content

Extend the Speech via Slides

What should be presented on the slides? I recommend going through Death by PowerPoint.

Text on Slides

Bad

Slides with an enormous amount of text are not participant-friendly:

However, there are some important notes:

Good

The main goals of slides are:

My algorithm:

Screenshots

Photos and screenshots look better if they are fitted to the slide size without white margins.

Screenshots 1

It is okay to make screenshots of well-known tools/websites because participants will be in the context. Optionally, you can emphasize something with arrows or a magnifying glass.

Screenshots 2

If you present screenshots of barely known programs/websites, you might lose the audience. For example, are you familiar with galaxy.ansible.com shown on the screen?

Text on Screenshots

Screenshots 3

Text without underlying print can be hard to read.

Screenshots 4

If you colorize it, you can increase readability.

Code

Code

A huge amount of code is not readable. People need to load it into their minds and understand the context. The solution is to cut down all unimportant parts. The piece of code might be uncompilable, but it must convey the gist. To sum up:

Good:

Roadmap

roadmap

Roadmaps are a really cool way to stay on the same page with the audience. They also help to glue different parts of your story together.

5±2

There is The Magical Number Seven, Plus or Minus Two — one cannot keep too much in the head, so:

  1. Lists are our friends. The key benefit is that they are simple.
  2. Only one new thing/idea should be introduced on each slide. It is okay to highlight it with another color.
  3. One should not present more than 4-5 ideas in a speech.

Presentation as Code

In the past, I used PowerPoint for presentations. There are some problems with it:

It looks like there is a pretty cool replacement for PowerPoint that allows having Presentation as Code.

  1. Create a presentation in markdown syntax using marpit.marp.app.
  2. Draw images via the draw.io app in SVG format.
  3. Store it in git.
  4. Export the presentation as a PDF.

It can also be easily integrated with VSCode:

There are some downsides:

Slides sources example:

---
marp: true
theme: default
paginate: true
style: |
    section {
        justify-content: flex-start
    }
    h1,
    strong {
        color: #E20074;
    }
---
<style scoped>
    section {
        background-color: #E20074;
        justify-content: center;
    }
    h1,
    h3 {
        color: white;
    }
</style>
<!-- _paginate: skip !-->

## Terraform 4 VMware in XXX

lev@xxxx
xx.xx.2023

---
<!-- _paginate: hide !-->
## IaC: use cases

![bg contain](./assets/IaC_usecases.svg)

Show

There are some common types of events:

Interaction with Organizers

0. Apply

Just search for an interesting conference, prepare abstracts, and apply. Sometimes, there is a web portal for applications. Other times, it is enough to send emails to the organizing team. There is no unique way. It makes sense to attach links to your previous speeches if you have them.

1. Initial Call

Usually, a big conference’s organizing team plans a warm-up call. However, sometimes an email conversation is sufficient.

2. Demo

This is quite rare. I have only had to do this twice out of 100 speeches.

3. Acceptance

At some point, the organizing team decides whether or not to include your speech in the program. A mentor may be assigned to help you prepare the speech.

4. Dry Run

Dry-run

This is the crucial phase. The speech should be validated and tested in front of an audience. Feedback must be collected, processed, and reflected upon.

5. Show

On one hand, there is a significant difference between online and offline presentations, but on the other hand, there are some commonalities:

  1. Convert your presentation to a PDF.
  2. The presentation should be:
    • Sent to the organizing team.
    • Uploaded to a USB stick.
    • Shared on the internet.
  3. Get a bottle of water.

In the past, I had awkward experiences:

Offline

Offline

By the way, here are some notes about the presenter’s display. At big conferences, you might also find:

  1. Wireless mice to have free hands.
  2. Clickers for changing slides.
  3. Clocks somewhere at the bottom.
  4. A display in mirror mode in front of you.

However, it is possible to make a speech without all these extensions. Usually, I bring:

Let me also share some useful life hacks:

Online

Online

The biggest headache of online events is wireless technologies, so:

  1. Connect to the internet via a wired connection.
  2. Use a wired headset.
  3. Check your background.
  4. Artificial lights are better than natural because they are predictable.

The most intriguing challenge is the real-time feedback from the audience. It is really hard to feel the audience. Usually, I ask them to share some emojis.

Results

Results

The fun fact is that the speech does not end after the last slide. Just think a little bit: you’ve already put things in order, prepared the materials, created the memes, and learned the text by heart. The only thing missing is transcribing the speech to text. It is as easy as pie.

Landing

Landing

The last slide is the most valuable. Usually, participants take a picture of it. It would be nice to put on the last slide:

  1. The main idea/roadmap.
  2. Contacts, and the link to your landing page.

Where can I host my landing page?

The main problem here is that the link must exist during the speech, but the transcription can be done 2 years later. In that case, I really advise:

  1. Use GitHub Pages.
  2. Buy a domain for approximately 2€.
  3. As a benefit, you can have a useful email address and collect feedback via Google Analytics.

For example, www.goncharov.xyz is hosted as github.com/ultral/ultral.github.io. It is also reachable via github.com/ultral/ultral.github.io/blob/master/README.md:

The situation is win-win:

Writing

Writing

There is a quite good guide on how to write a good article. Let me share the gist:

Writing

It is quite similar to slide preparations:

Just start writing a draft. It can be ugly, and that is totally okay.

Writing

On the next day/week/month, reread, rephrase, rethink, and then publish.

PR

If you have free time, you can promote your article on:

From my experience, people will say thank you sooner or later.

PS

roadmap

Do not be shy. Start writing and speaking. It is a skill like driving or reading.