I hate “hand-waving” in technical articles. You know what I’m talking about. You try to learn how to build a prototype with a new framework, or use a new feature of a language, or set up the latest and greatest build system, and the tutorial says this:
- Do a couple of trivial things.
- ??? (“This is out of the scope of this tutorial…”)
- BAM finished!
That drives me NUTS! The whole reason I’m on your stupid site is to learn all the stuff in part 2!
I find the same hand-waving happens in articles about technical career advancement. They seem to always end up like this:
- I dunno, tweet some things?
- ??? (something something “hard work”)
- INTERNATIONAL SPEAKER AND STARTUP MOGUL! Enjoy your Tesla!
I’m about five years into being a “professional developer” (my 7th grade HTML didn’t pay the bills), so like you I’ve been down the road of Googling “how to become a speaker” and “how to become a better developer.” It’s so frustrating! It feels like a game is being played around you and you don’t know the rules. You’re watching other people become “successful” (or so it appears on social media) while you feel stuck.
Frankly, I’ve ended up having to rely on advice from friends, coworkers, and members of the Angular community to get help on everything from applying to conferences to contributing to open source. That’s how I’ve deduced the rules of the game for myself.
As I start to turn the corner on achieving some modicum of success, I want to write down some of these “unspoken” pieces of advice. I’ll mix in my own lessons learned as someone who is probably just a few stepping stones ahead of you. It’s more or less of a continuation of what I started with The Painfully Shy Developer's Guide to Networking for a Better Job.
I’m going to start with getting into technical speaking. I realized the other day that my first conference acceptance was just over a year ago as I’m writing this, so all of the lessons and unspoken rules are fresh on my mind. I had been speaking at local meetups for a couple of years prior to that, but I’m still new to conference speaking. Since that first conference acceptance, I’ve spoken in Copenhagen, Denver, Helsinki, London, Orlando, and Salt Lake City, with Vegas and Delhi on the calendar.
In this article, I’ll cover some strategies and tactics to help you get started with technical speaking. You’ll also notice these three themes coming up a lot in this article: empathy, persuasion, and persistence.
We’re going to get really practical here, but first I want to take a moment to reflect on why we’re doing this in the first place.
Wait — why are doing this again?
Do you feel some pressure to speak at conferences as the only way to achieve career success? With the advent of Twitter, “tech celebrity” is a real thing. It causes a lot of insecurity and career envy.
I want to give you some advice and encouragement here. The majority of talented, experienced developers never set foot on a stage. They may be terrified of public speaking, they may have better things to do like obligations to family, or they may just not want to. That is completely and totally okay. You don’t have to follow some Twitter-endorsed gilded path to career success. Do what makes you happy.
At the same time, I have talked to a lot of developers who have said to me, “I could never give a talk. I’m not good enough. I have nothing to contribute.” That is equally misguided. Let me let you in on a little secret:
The best technical speakers are not always the best engineers.
I know a lot of people who are better engineers than I am, whether due to experience, talent, or the fact that they lock themselves in a room and program for 16 hours a day (when do you sleep!?). Speaking is about story-telling, emotion, and breaking down complex concepts. You can be a walking encyclopedia of programming information, but if you can’t explain it in a way that’s relatable and interesting, it doesn’t really matter. If I stood up and read the entire ECMAScript spec to you, I’d be technically sophisticated but a terrible speaker.
Is there a level of experience needed with your subject matter? Of course. The audience can tell the difference between a junior and senior developer based on subject matter expertise. But the key is here in the framing, not in speaker capability. If you’re a beginner, don’t sign up to give a talk on how you’re an expert at something. Frame the talk as a story about something really awesome you learned or an idea you had while figuring something out. People love authenticity; they love it when a speaker is true to who they are and relatable.
It’s also a well-established truth that the farther you get from learning something, the more difficult it is for you to explain. This makes the beginner’s perspective incredibly useful. The more of an expert in something you become, the more you start to forget all of those quirks and rough edges that confused you as a beginner.
By the way, this remains true as you proceed in your career and is one of the keys to creating great technical content in any medium. You might be a beginner in JavaScript or web development today, but in five years you may be a beginner in machine learning or Swift. Maintain the “beginner’s mindset.” Approach new tech with wonder and let that wonder permeate you’re writing and speaking.
I love speaking because I love teaching. I always have, even long before I was a developer. I love breaking down complex concepts and empowering other people to be better at their jobs or advance their career. I didn’t get into speaking for fame or anything, I just have a natural affinity for it. You might not have that same affinity. Maybe you want to travel or you’re in it for the glory. That’s fine, just be honest with yourself about it.
This leads me to my next point.
Applying to Conferences is a Skill You Can Learn
Let’s get this out of the way. There are some people who do rocket to fame seemingly overnight. This is often because they’re controversial or have some magnetic level of charisma. It may also be because they’re in the right place at the right time or have some other “in” like family or friend connections. Despite the version of reality you see on Twitter, though, these people are in the minority. The vast majority of people do have to work hard and work a system (the one I’m teaching you), even when it appears they came out of nowhere.
Let me give you an example from my life.
I have a good friend who makes re-orchestrations of video game soundtracks. It’s a niche talent, but he’s fantastic at it. He released an album a few years ago based on a Zelda game and it went viral. Suddenly, tens of thousands of people were liking, listening, and buying his music. He did an AMA on Reddit and I’ll never forget one comment about how he was an overnight success. I couldn’t help but laugh, because what they didn’t know was that, years and years ago, he and I would hang out after school and compose music. We would spend hours learning audio software, trying out MIDI samples, and coming up with our own video game re-orchestrations. I had watched my friend practice his craft for over a decade before he saw any commercial success. Yet, to the general public, he “came out of nowhere” and was an overnight success.
Most of the time, it’s no different in tech, though it probably won’t take you a decade. There are outliers to this process, but you can’t use them as an excuse. Here’s the good news: applying to and speaking at conferences are skills you can learn and improve with practice over time. They’re not mystical or magical, they don’t require an amulet or spell book, and they don’t require a certain level of underlying talent.
With the philosophy laid down, let’s get into the nitty-gritty.
Crafting a CFP with Empathy
As you’re preparing your proposal for a conference, think about what the conference is looking for. Sometimes they will tell you outright on the CFP form, otherwise you can go back and look at previous talks to get a sense of their style. Do they tend to select more advanced talks? Do they select a few soft (catalytic) skills talks? You can use this information as you craft your proposal.
CFP means “Call for Papers” or “Call for Proposals.” These usually include basic biographical information, a title, and a description of the talk (often referred to as an “abstract.”
Let me give you one tip that is pretty much safe to assume for all conferences: conferences want to sell tickets. This means they want solid, educational, entertaining content from vetted speakers. Note that “vetted” doesn’t necessarily mean “experienced.” They want speakers who will be engaging, well-prepared, and not violate the code of conduct.
“But wait, how can I be vetted if I’ve never given a talk before?”
There are a number of ways you can do this. The best way is to start giving talks at local meetups and recording yourself giving them. Don’t worry about the quality. Get yourself a cheap tripod and prop your phone up. You can get as fancy as you want, but the idea is to get some recordings of you speaking that you can send to conferences in support of your proposal. You could upload them to your own YouTube channel and start building a public portfolio, or keep them unlisted and send them out to the organizers privately.
If for whatever reason you can’t record, at least start putting slides up publicly through Slides.com, SlideShare, Google Slides, GitHub, Speaker Deck (my favorite), or others. (We’re going to cover slides in depth in the next part of this series.)
Community involvement in general is also a good way to start being vetted by conference organizers. Engaging with community members and organizers in a non-creepy and helpful way will go farther you would think. Answer people’s questions on Twitter, Gitter, StackOverflow, and other forums. Promote other people’s work. Be positive and welcoming. These aren’t just mindless platitudes; they really work! Build a reputation as someone who is welcoming and helpful.
”I’m not an expert — how do I come up with a topic?”
As we’ve established, you don’t need to be an expert to speak on a topic that you’ve got experience with. But even beyond that, let me let you in on an industry secret: many great speakers submit proposals on things they want to learn about. You read that right. They will pick a topic, learn enough to write an abstract about it, and then, on acceptance, learn enough to write a talk. While preparing, the best speakers will also vet their content with subject matter experts to make sure they’re not way off base or promoting terrible practices.
You can greatly use this to your advantage. If you notice a trending topic and have an idea on how to present it, submit a talk about it.
Okay, you now know how to start thinking about your CFP. Let’s get into writing it.
Good CFPs solve problems; great CFPs tell stories.
When we first start applying to conferences, it’s natural to think of them as black-and-white, technical, and purely logical. This makes sense coming from engineers. The truth is that humans are story-driven. Good talks focus on solving problems. Great talks tell stories that change perspectives.
That being said, avoid “lessons learned” talks unless the conference specifically requests them. Literally everyone has these lessons. Usually, though, there is a germ of a good CFP in there. Take whatever the lesson was and turn that into the talk topic. Did you learn about how the shadow DOM works when you were working developing a complex UI? Change that talk from “Lessons Learned About the Shadow DOM” to “Using the Shadow DOM in Complex UIs.”
Let’s go one step further, though. Focus on tying a technical issue to a tangible result. People love to save time, save money, reduce bugs, increase sales and customers, and reduce the amount of code written or maintained.
Here are some good example titles that focus on benefits:
- How to Save Time and Money by Planning Your ngUpgrade
- How the Async Pipe Saved Us a Million Dollars
- Cut Your Bugs by 50% with TypeScript
I made up the second two, but hopefully you get the idea. These talk titles show off a specific benefit. You can also catch attention by being surprising, unexpected, or contrarian:
- You Might Not Need NgRx
- “Can you imagine a future without zones?” (Zone.js is part of Angular)
- Browser Versions Are Dead
Just don’t get click-baity or I will personally track you down and fill your car with pizza flyers (the coupons will even be expired).
The abstract is not about you.
Here’s another secret that no one tells you: your talk abstract is not about you. It’s not even about the technical details of your talk. It’s actually sales copy. Yep, you read that right. The talk description has two jobs:
- Convince the organizers that this is a talk worth picking
- Convince the audience to attend your talk at the conference (or watch it later online)
Don’t worry. You don’t have to make your abstract salesly, gimmicky, or corny. It does need to be persuasive, though. This means that your abstract should focus on the benefits of the talk and what the audience will learn. There should be a strong current of empathy running through your writing.
Let’s look at an example:
My talk is about using Jest for unit testing. I will talk about why to use Jest, define snapshot testing, and demonstrate how to set it up in both Angular and React projects. I will also show common errors to avoid when unit testing with Jest.
What do you notice about this? It’s not just dry and boring, it also uses the words “my” and “I” multiple times in just a couple of sentences. This example describes the what of the talk, but not how it impacts the audience. Take a look at this rewrite:
Do you hate writing unit tests? It’s okay, you’re not alone. There’s good news, though: Jest makes unit testing at least 30% less terrible. In this talk, you’ll learn what Jest is, why it’s awesome, and how it reduced my team’s bugs by 15% in the last year. You’ll also learn exactly how to set up Jest in a project, whether you’re using Angular, React, or something else. Finally, you’ll learn common pitfalls to avoid in snapshot testing to make sure you don’t waste time you could be using to write new features.
What’s the difference? This example has much more energy and humor. It’s also more specific about the benefits of the talk. Most importantly, it uses “you” and “you’ll learn” to talk directly to the audience.
If this feels unnatural to you, don’t stress about it. The more you write, the more you’ll start to find your voice. Keep a bank of your CFPs through GitHub, Google Docs, or an app like Ulysses so you can easily re-use phrases or entire CFPs.
Remember: it’s a numbers game.
When I was in finance, someone gave me a copy of Nick Murray’s book The Game of Numbers. This book is about financial sales, but has a fantastic thought experiment that is helpful in many areas, including speaking. Here’s my paraphrase of it:
Imagine a slot machine from a casino. It looks like any other slot machine, but this one is magic. This slot machine comes with a guarantee: after 10,000 pulls, it will (not might, will) pay out \$100,000.
How does that knowledge affect your perspective on the slot machine? You’d probably stand there for as long as it took to get to 10,000 pulls, right?
It’s uncertainty that gets us to quit. We start on a project or goal full of enthusiasm, then somewhere along the middle of the journey we lose steam. Maybe we get rejected. Maybe we’re not seeing results. We give up, usually with some excuses or rationalizations (“I’m just not meant to be a speaker.”).
Approach speaking like you would approach that slot machine. Apply to as many meetups and conferences as it takes. If you’re a generally decent person and relatively talented developer, you will get there (not might, will). And, good news: it probably won’t take you 10,000 tries.
A Short Tactical Note on Finding Where to Apply and Tracking Submissions
There are several different web sites, apps, and GitHub repositories that track conferences for various languages and frameworks, so I’m not going to reinvent the wheel here. However, I want to give you a few practical tips to help you with this process:
- Create a CFP spreadsheet to track all of your submissions. You can feel free to copy mine. I keep track of the conference dates, the submission deadlines, links to conference and CFP, and notes on what I’ve submitted. You can also use something like Trello for this. The tool isn’t important, it just has to work.
- Create a separate CFP Deadlines calendar.
- Keep your CFP abstracts in Google Docs or an app that has cloud-syncing like Bear or Ulysses. This will let you find ways of reusing and repurposing all or part of a submission. Never submit a talk only once! You can write a few solid proposals each year and submit them in various formats to multiple conferences. Sometimes, a conference will a unique talk, but they will make that clear. (These are usually the top-level conferences in each field like ng-conf for Angular.)
- Write short first person and third person biographies of yourself and keep them along with a link to a solid headshot in the same place you store all of your CFPs. You’ll also usually need links to your web site, your Twitter and GitHub accounts, and previous talks, so make a doc that contains all of your “self metadata” for easy access when submitting.
- Don’t shy away from lightning talk submissions of 5-15 minutes. These are not less important, less prestigious, or less valuable. In fact, I find shorter talks to be more difficult to write and more fun to deliver. Also, you’ve got better odds here: a lot of people skip over lightning talk submissions. They might be your ticket in the door!
Action Steps
Here are a few things you can do to get started on your path to speaking:
- Create a CFP spreadsheet and deadline calendar.
- Find three conferences to apply to in the next year and add that information into your spreadsheet and calendar.
- Contact two local meetups about giving a talk.
- Write your short biography and keep it in your app of choice.
Conclusion
I hope this guide has left you feeling empowered and inspired to tackle applying to conferences. Remember the key themes: empathy, persuasion, and persistence. Think about what the organizers are looking for and what the audience will love, show them the benefits of your unique perspective, and never give up. If any of this works for you, I’d love to hear about it!
If you're curious about developer relations or interested in becoming a developer advocate, check out my book Getting Started in Developer Relations.
Also, if you’d like to get more of this kind of thing, I’ve got an email newsletter. It’s a regular note from me where I share actionable career wisdom for developers and developer advocates. Sign up for it below. (You’ll never get spam from me. Gross.)