Reading Time: 9 minutes

Occasionally, I give talks. I have collated full transcripts and video of those talks, where available, on this page for those of you who would like to revisit them.

This is a 3 part series about giving talks as a technologist (or maybe anyone, but I’ll stick to what I know).

This first part is about finding your niche as a speaker. First, I’ll share an example: I’ll tell you what my niche is, and I’ll explain why I chose it. Second, I’ll talk about some techniques that you can use to help find your niche.

My Niche

My niche choice has to do with what I find interesting, and it also has to do with the reputation that I want to build in the industry.

My talks are:

 1. Didactic: I teach a topic. I draw examples from my career, but the talk does not center me or my personal experience. I don’t talk about my journey into software development, for example.

I have a few reasons for this.

First, my life and relationships improve when I limit the degree to which I talk about myself. People don’t care about me. They care about themselves. Maybe me and my stories are interesting or useful to an individual person in a specific context, but they’re tedious for the majority of any large audience. Instead, I teach: I talk to audiences about their problems and their careers. That’s what’s interesting to them.

Second, by avoiding talking about myself, I preserve the audience’s energy so that other speakers can talk about themselves. In my experience as a speaker and an organizer, I have seen a lot of people give their first talk. The topic is almost always “My journey into tech.” Even if the title isn’t that, the talk ends up being that. And people’s stories are cool! But audiences have limited stamina for focusing on somebody else like this. People, in general, get energized by focusing on themselves.

I know that a talk like this takes energy from the crowd rather than giving energy to the crowd. The crowd only has so much energy to give like this. So I leave that energy in the crowd such that the newer speakers who follow me get a warm reception that will encourage them to keep speaking—hopefully, eventually, about topics that give energy to the crowd.

This is especially important now that I give keynotes. When I keynote, I usually speak first. The first talk absolutely must give energy to the crowd. It sets the tone for the entire conference day. If that talk takes energy from the crowd, it becomes exponentially harder for any speaker afterward to get the crowd excited. The most amazing speakers can do it, but I shouldn’t force my fellow speakers to climb out of quicksand like that.

Third, I get joy out of helping people make progress. I often do this by finding a new way to say things or a new way to show things. For about fifteen years, I’ve practiced finding the right turn of phrase, the right diagram, to clarify an otherwise murky concept. Speaking gives me the opportunity to share that with more people.

 2. Technical: I focus on things I think engineers should know (though I make sure to include something for designers and product folks, too). The examples come from application or machine learning development projects. The slides may have code samples.

I went into this field to become a skilled technologist and make a positive difference in the world by deploying those skills. I’m not a diversity orchestrator, a product manager, or a designer, but that work is asked of me so often that I have developed canned scripts to help me set boundaries against it. I am an engineer: a nuts and bolts, gearhead, build-things engineer. By sticking to technical talks, I encourage potential clients, employers, and colleagues to see me that way.

I also find that, among the plethora of technical talks I have seen (both live and on video), very few of them significantly improve the audience’s understanding of their topic. Some do an excellent job. Most relay a tidbit or two, but they don’t impart more wisdom than the typical decent StackOverflow answer. Many manage to confuse the audience, and a few even mislead the audience. I would love to see a higher standard of skill in how to impart information from speakers who cover technical topics. So I’m trying to be part of that change.

 3. Language and version agnostic: I stick to principles and approaches that remain valuable across languages, frameworks, and versions. I don’t talk about what’s new in the latest Android SDK release, for example.

A good talk—a really good talk, with well-tested and effective diagrams and turns of phrase—takes me between 60 and 100 hours to compose. That’s not a typo. A once esteemed MIT physics professor (since deposed for sexually harassing students, but that’s a separate rant) put the figure at 40 hours, and he had decades of experience teaching a topic that has been taught in universities for centuries. I don’t have decades of experience (yet), and my field has existed for about sixty years. Teaching includes a massive amount of tedious, unsexy work.

I need to maximize the return on my investment of time and effort. Most of the return on my investment goes to my audience: they get to have an easier time understanding my topic because I’m speaking about it. How do I maximize their return on my investment? First, I make the talk relevant to as many people as possible: I keep it language-agnostic so it’s useful to all programmers, not just Pythonistas or Swifties or Java programmers. (This is also why you almost never see me at language-specific meetups and conferences). Second, I don’t write talks with an expiration date under about three years. Software versions turn over much faster than that, so I don’t write talks that center software versions.

Some people enjoy the rush of popularity associated with being the only person speaking about the new-new. I love those people. When they have good speaking skills, their talks do wonders for early adoption. I’m happy to leave this task to them.

Finding Your Niche

So now you know about my niche. How do you find yours?

It’s okay if you don’t know right away what you want to talk about. I took some time to figure it out, too. A few practices helped me along in that process.

 1. I write regularly on this blog. Some blog posts fly from my fingers with little effort, and others take a lot of work and self-convincing. The ones that take more work often make better talks. I think this is because those things are harder to talk about articulately, and so fewer existing talks cover them well. Once I have a written piece, I can parlay that into an outline for a future talk, which reduces the amount of work for creating new talks. (The recurring theme of this series of posts will be how much I hate doing work).

2. I practiced in low-stakes, low-prep settings. I gave talks to coworkers, to my work lunch and learns, and to meetups. Usually these lasted only five, ten, or fifteen minutes. These created an opportunity for practice, and after each one I gauged whether I would give that talk again. If you find yourself giving a talk and sighing with relief when it’s over, that might be a useful signal to consider: why are you so glad it’s over? Would you dread doing it again? What is that telling you: is it the topic, the venue, the audience, or something else?

 3. I considered the reputation I want to build. It’s okay to start out talking about your journey into tech. The thing is, everyone in tech has a story about their journey into tech, so it’s hard to build a unique brand on that. What makes your story unique? What expertise do you bring to the table that other people are hungry for? What skills does your unique perspective allow other people to build? My answers to these questions led me to the semi-timeless, didactic, technical talks that I give now.

Conclusion

Occasionally, I give talks. For me, establishing a sustainable speaking cadence required me to find my niche as a speaker. I spent a lot of time figuring out what I did and did not want to talk about. That’s how I alighted on my niche: didactic, technical talks without an upcoming expiration date.

You can use some of the same techniques that I used to figure out what you’d like to talk about. It’s hard to know what you want to say before you start saying things to see what feels good. Before you begin speaking, you can jump-start this process by writing about a few different topics and seeing how they feel. Then, you can practice speaking in low-stakes, low-prep settings. That can include the canonical recommendation (Meetups), but it can also include lunch and learns at your office, or even chats with your coworkers.

You may also wish to consider the reputation you want to build. Everyone in tech has a story about their journey into tech, so it’s hard to build a unique brand on that. What makes your story unique? What expertise do you bring to the table that other people are hungry for? What skills does your unique perspective allow other people to build? The answers to those questions can help you carve out a type of talk that works for you.

In the next post, we discuss some tools for crafting and outlining talks.

If you liked this post, you might also like:

Some of the other posts about ‘career-building’ activities

The ‘Leveling Up’ series, which deals specifically with building technical skills

This series about persuading folks at work to be open to big changes in the code