As Simon Sabin (SQL Bits co-founder) pointed out recently, the 2022 SQL Bits conference is looking to get 40% of their sessions to be 20 minute talks.
He did the math for me, if you look through the thread, but I’ll repeat it here. It’s also in the speaker guidance.
- 50 minute sessions (174) – 56%
- 20 minute sessions (108) – 35%
- 5 minute Lightning Talks (30) – 10%
Those are rough percentages, but a little over a third of the sessions will be short.
Thoughts
I like shorter talks. I find a lot of fluff and wandering around in sessions when speakers aren’t quite sure what to talk about and end up covering lots of material around their central theme. Not all of them, but plenty of sessions could be tightly focused.
I’ve experimented with these, and we ran some shorter events at Redgate Software that were 20 minute talks with 10 minutes of questions. They worked well, and I had hoped we’d do more. It seems marketing really wants 40-45 minutes talks and hour webinars.
In the virtual world, I think we can all use breaks, and even in the physical world, I like having a few minutes to get up and move between sessions. 50 minutes allows this, as do 20. A little break, but not a long one as speakers change or people move from room to room.
While this is a change for speakers, I don’t think it’s too hard to shrink a 60 minute talk to 50. I’ve already had to move 75 minutes to 60, and really it was a question of focusing more on you central idea and less on filling time and space by covering lots of related information.
This also means that audiences will need to read what the talk is about and understand this isn’t teaching you something. This is about getting you to think about a topic and start further exploration.
Building a 20 Minute Talk
What does this mean for me, as someone that is submitting to Bits. First, I need to tightly scope the talk. For me, I want to talk about Git for one of my submissions, and I can’t spend time talking about what a VCS is, the history of Git, centralized v distributed, or a bunch of other stuff I covered in my Data Community Summit talk. Instead, I need to focus on a few things about Git.
Here’s my agenda for an hour:
- Who am I?
- Why use Version Control
- The basics of a versioning software
- Git introduction
- Push/Pull
- Branches
- Merges
- Pull Requests
If I want to get this to 20 minutes, then I need to cut some things out. I’d likely start to think more about an agenda like this:
- Who am I? (cut, check online)
- Why use Version Control – cut
- The basics of a versioning software (cut, this is about Git)
- Git introduction (shorten)
- Setting up a repo
- Saving Changes
- Branching and sharing
- Pull Requests
- Merging Code
I haven’t removed a lot, but I would do is remove most of the slides and spend more time showing people how I use the tool to accomplish something rather than an explanation and then showing a demo.
That might be the key. Talk about how I do things in a demo, not describe the process orally and then show a demo.
I also would look to minimize the switching between slides and demo, as each transition eats up time.
Goals
The big way that I focus down my talk is that I set up goals. A few conferences have required 3-5 goals in each submission. I liked this because it forced me to think about the things I specifically want to show. For this talk, I’d likely aim get help someone:
- set up a repo
- save changes
- share changes with others
- branch, create a pull request and merge code
That’s likely it. I haven’t completely decided, and I’d need to run through demos of these things to see if I could explain them relatively slowly in 20 minutes. I don’t want to go too fast, and I do need to allow for a few questions. What I really want is about 10 minutes of demo, a few minutes to describe what I want to show, and then a summary.
If you tightly scope sessions, I think this isn’t too hard. Twenty minutes is a good amount of time to explain something, but only that thing. Not a lot of background or side stories.
Focus is the key.
Voice of the DBA 