Reading Time: 15 minutes

Lately I don’t blog as often as I’d like, so in an effort to change that, I’ve waived my protocol about spicy takes. I used to reserve them for Twitter and my Patreon. Today, you’re getting one here.

My 🌶️ spicy take 🌶️: I don’t like seeing tech talks live.

Why: I get very little out of 95% of them. I much prefer online recordings, which can come vetted/recommended. Also I can bump them up to 1.5x or 2x speed, so that at least if the talk isn’t that good I waste less time on it.

I know, it’s harsh. I’m sorry.

You know what, I’m not sorry. I’m a brat, and I want better than that. More importantly, I think speakers can do better than that.

It’s not that the speakers are poor engineers. It’s not even that they’re necessarily poor speakers. I think two things are happening.

1. There’s a lot of platitudinous advice out there about how to deliver a talk. Some of it is straight up wrong. Even more of it is technically ‘fine’ but, in the context of limited time and effort, draws speakers’ attention away from more important things.
2. Speakers spend a lot of time thinking about what they want to say up there, or who they want to be in the eyes of the audience. They spend relatively little time thinking about what the audience should receive or who they want the audience to be in the eyes of themselves after the talk is over.

I’m a selfish little cuss. When I’m in the audience, I want the talk to be about me. Not the speaker.

But I’m also an empathetic little cuss. So when I’m speaking I try, first and foremost, to center the audience the way I’d like to be centered.

That’s not very helpful advice on its own, so…

…allow me to describe how I build a talk.

I suspect some of this is gonna sound counterintuitive.

I’d like to start by addressing some of that platitudinous advice about how to deliver a talk. These are things I see a lot of speakers do, that I specifically do not do.

1. I do very little self-intro.

Why: I think people forget this part unless there’s a big name drop, and I also think legitimacy by proxy is gross. People can decide from my talk if I’m worth listening to.

One legit objection: “I am from an underrepresented group, and without my credentials no one listens to me.”

Maybe so. But:

1. If they’re not listening based on that, I’m not convinced credentials will change it
2. Misogynistic homophobes are not my audience, and I don’t waste precious seconds appealing to them.
   

2. I don’t start with “why you should listen to my talk.”

Or any version of it, like “broader context for my talk” or “why my talk is important.” The people who are hearing the intro to my talk are already at my talk. I don’t have to convince anyone. If I wrote it right, the content will do the convincing.

In fact, more broadly, I think a lot of speakers could benefit from spending less time trying to convince people they’re worth listening to, and just write the talk as if it were dead f**king obvious that you’re worth listening to. Imagine you already have the rapt attention of the whole room, and think about what you would say in that situation, and write that. In many circumstances—tech conferences being one—I think that would produce much better talks.

3. I don’t do a lot of memes, gifs, puns, or cultural references.

They’re wildly inaccessible to people from different age ranges and cultures, so talks with a lot of these have a shorter shelf life and limited relevance.

These sorts of things also often get used as crutches for weak content. If I’m reaching for them, I look for the weakness I’m trying to cover up.

4. I don’t worry about eye contact.

Mostly my audience is too far away to see my eyes live. How many audience members could I momentarily lock eyes with in a room of 400? Maybe 40? If I had time? The rest can’t see my face well enough to ‘lock eyes’ with me even if I could fake it. And on Zoom I have to operate Zoom, which unfortunately hijacks most opportunities to make choices about my gaze.

5. I don’t show code, mostly.

See, 99% of the time when developers show code in a talk, it’s WAY too small for people to read and WAY too much for them to absorb. On a projector in a 4-600 person room, you can make about 3 lines legible onscreen. Everybody does more than that.

Whatever I’m trying to say about code, I figure out how to represent it with 3 lines, or I figure out how to paraphrase it with a diagram. Or I don’t talk about it. More on this later.

Those are my “counterintuitive things I don’t do.”

Now let’s talk about what I do instead.

I’ll present these things in the rough order that they show up in the talk, and as foils to the “dont’s” I shared above.

1. Instead of starting with self-intro, I consider the start of my talk to be The Hook.

From the moment I’m given the stage, I’m trying to get past self-intros and other crap and onto The Hook (the start of the talk) as fast as I can.

The Hook has one job: surprise people. That’s it.

Why: Because I give talks to auditoriums full of nerds.

Reveal to nerds that they don’t know something, and you’re done having to worry about whether they’re leaving. You’ve nerd-sniped them. They’re not leaving.

Disclaimer: I have one huge advantage with this step.

My advantage: my schtick is to take slippery concepts and install handles on them for easier handling, transport, and transfer.

A lot of ’em are concepts that people handwave because everyone is “supposed” to get them, and no one quite does, and it’s unsafe to admit it.

So my schtick has a built-in hook. I can just go up there like “Today we’re talking about tech debt. Y’all think you know what that is, but you don’t and I’ll prove it.”

Bam, now everyone’s either like “Who does this b**ch think she is” or “WHOA, I had no idea!”

Here’s an example of that: I give a talk about tech debt, and I have a slide titled “What is Technical Debt?” And then it says “Tech Debt == Bad Code,” which is a 65% accurate distillation of what a lot of engineers would tell you if you asked that question.

And yet, that part of the slide is labeled “Two Misconceptions.” Wait, so that’s wrong? And apparently there’s also another thing that’s wrong?” Yep. I start the talk with what tech debt is not, and I point out flaws in two very commonly held assumptions. You can see it here (This link starts deliberately at 126 seconds into the video):

2. Instead of providing overarching context, I explain new ideas in the form of examples.

I don’t define “empowering engineers to make design decisions.” I tell a story about a launch pad tower that was 4x harder to maintain because the damn door was on the wrong side.

Human brains can struggle to apply a general idea to a specific situation, but they’re BRILLIANT at drawing connections between stories and seeing broader patterns.

So, by explaining with stories, I can get points across in less time and cover WAY more ground in one talk.

Here’s an example of that: same video as above, but this time deliberately timestamped much later, at 2060 seconds. This is where I tell that story about the launch pad design.

Sharing examples offers another advantage: it credentials me.

The stories I tell demonstrate that I have experience with this and I know what I’m talking about. I don’t need to be like “Listen to me because I work for <Brand Name>”.

3. Instead of gifs, puns, memes, or cultural references, I stay focused on offering tools.

Funny is great, but it’s hard to do well (I’d know: I did standup), and can be harmful when done poorly. I’d rather my talk be memorable for its utility than its humor: good or bad.

I find that the best way to offer tools is flowchart-style.

1. Give folks a thing.
2. Give them three things that they can tie back to the first thing.
3. Give them spinoff things from each of THOSE things.

The body of my talk should be structured like a tree, rooted at a contrast with existing knowledge. People remember stuff best when they can relate (especially contrast) it to stuff they already know about. I take advantage of that.

This talk about leveling up exemplifies the strategy. First, I introduce the idea of leveling up actively, and I contrast it with the more common, more passive understanding of leveling up. Next, I introduce four branches: the four skills of leveling up actively that I will discuss in the talk. Each of those branches spins off into specific exercises and tactics.

4. Instead of focusing on eye contact, I invest in other stage presence concerns.

It’s not that making eye contact is bad—it just has a low return on investment relative to other stage presence things I could focus on.

For example, you’ll notice in the above examples that I move around onstage (Leveling Up talk) and on camera (Tech Debt talk).

But the biggest and most underrated stage presence concern (especially in ‘informative talk’ circles) is timing of delivery.

Timing of delivery makes an enormous impact. It can make the difference between the concept sinking into people’s brains and sliding past to be lost to the ether.

This one is hard to develop. You do, I’m afraid, have to get comfortable standing on stage doing this 🤌 (or whatever), in total silence, while you wait for your point to land. And then you also have to know when to be satisfied that it landed.

You can see some examples of me playing with timing here, 2546 seconds into a workshop that I co-facilitated with a student of mine (at the time—she is now a software engineer in good repute at Spotify). The content of this talk is unlikely to make sense unless you have watched the rest of the workshop, so I recommend focusing solely on the timing here:

I comport myself as if people are already listening to me.

I project “This is my stage. I’ll do what I want on it. You’ll watch and listen if you know what’s good for you.”

This workshop recording at 38 seconds in offers a good example of that. People still make fun of me for this when we’re out for beers at conferences:

This is, by the way, a noticeably gendered variety of stage presence. People largely reserve this for, and expect this of, masculine presences. I noticed that after I got better at doing this, a funny thing started to happen at my talks.

During Q&A, I get called “sir” pretty regularly.

In winged eyeliner and four inch heels.

(For the record: It’s okay. I don’t mind. It’s kinda fun.)

In this regard I am, again, privileged. My parents agreed on almost nothing, but they did both raise me like I’d have important things to say. And I talk a lot like my dad does. In a lot of ways I’m everything my dad wanted…in a hetero son. Oops 😂

5. Instead of showing code, I focus on talk-friendly content.

This is the maximum amount of code I’ve ever put on a slide, and it’s in the midst of several minutes of explanation where we built this code up gradually. I’ve never introduced more than about three lines of code at once in a tech talk.

But even this right here is more code than I put on a slide for a tech talk anymore. Instead, I try to keep each kind of subject matter to the medium that best suits it. So for talks, I focus on topics that convey well in audio format. I do not think code does that.

First of all, speakers put way too much code on a slide and go past it way too fast. In a room of 400-600 people, most of them are too far away to even see it—and that’s if there’s no projector glare, which there’s always projector glare. Code just doesn’t communicate well in contexts where only the audio is accessible to the whole audience.

Is it possible to convey code without visual cues? Yes. But it requires special tools like high-speed screen readers, which have a learning curve that I can’t ask my audience to scale in one talk.

So about the most the audience is gonna get out of code in a talk is something like “that code is cool.”

And if they get that out of the code in your talk, you’ll get positive feedback. But they, the audience, does not get a useful takeaway. You, the speaker, get to leave feeling like a badass, and they, the audience, might even think you’re a badass, but the audience doesn’t get to leave with any newfound badassery at their own disposal. And as far as I’m concerned, that’s a failure. If my audience doesn’t leave with their own new skills, their imaginations full of schemes for unleashing their newfound badassery on their work, then I have not taught them anything important. I have failed. And that kind of failure is not badass.

When I want to teach or explain with code, I do it in a visual format with audio options: a blog post like this or a video like this. Or I create interactive exercises like this.

In a talk, I focus on stuff that folks can quote, or make into lists, or draw in tree diagrams. I focus talks on getting people to think about their old problems with a new perspective—usually a flexible framework outfitted, like I said, with handles 😉.

Here are some examples of slides like that from various talks:

So those are specifics of my preparation. They happen in different orders depending on the talk. Sometimes, my brain makes its own progress on one of these steps when I least expect it.

Regardless of order, throughout my talk prep, I focus on one guiding principle:

What new skills do I want my audience to have, and know how to use, when they leave this room?

I don’t worry about what they’re going to think of me or my talk.

I don’t even worry about what they’re coming to my talk to get: I instead trust myself to focus on skills that tech audiences sorely need, more than what they’re asking for.

But they—or maybe more precisely, their potential as change agents in tech—are my whole focus in building a talk. And that’s what works for me.

A final P.S. that I probably shouldn’t put in here

This blog post assumes you have some speaking experience and some understanding of conference etiquette. Here are some additional things I also want to say based on things I cannot believe I have actually seen speakers, sometimes compensated ones, do onstage at tech conferences.

• Know how long your talk slot is. Do not accept a $1k honorarium and start wrapping up the workshop you clearly did not prepare at 56 minutes, only to have an attendee inform you that your slot is two hours long. No, this was not some junior speaker. It never is, in my experience.
• Do not gripe about the video, audio, or slide setup. I promise you, the A/V staff are doing the best they can, and whatever is happening during your actual talk is not the fault of the A/V staff in the room. Definitely don’t repeatedly interrupt yourself throughout the talk to do it. You sound like a Karen and no one can follow your material. Can it.
• Do not open up the floor for questions and then take an opportunity to dunk on an attendee for the question they asked. If you accidentally misworded your answer and people laughed, that’s one thing. But inviting people to be vulnerable in front of you and then popping off a zinger when they do is borderline unethical, a fast lane to my teaching doghouse, and worse than not talking at all.

Folks, I love you, but Jesus, have your basics in hand when you get onstage.

If you liked this piece, you might also like:

Critique, The Internet, and You—about critiquing things people make

The feedback series—about critiquing the things that somebody does

The listening series—the one I’d say most people think they need the least and actually need the most