CoRecursive: Coding Stories - Tech Talk: Karl L Hughes on Speaking and Conference Talks

Episode Date: March 2, 2020

Tech Talks are in-depth technical discussions. Adam talks to Karl Hughes about his path to becoming a conference speaker and the work he has done to make it easier for others to follow in his footsteps. "I didn't start trying to speak at conferences until I was at least seven or eight years into my software development career. So. Just a couple of years ago and before that, I think what helped build confidence was speaking occasionally at meetups. I started talking occasionally at local code bootcamps, just kind of getting to be in front of a crowd and start to build up some like level of self-assuredness and eventually I think the next step was just obvious. I wanted to push myself to do something a little scarier and bigger, and that was like, get in front of people at a real conference. " "And so it is scary. Partly also it's that, you know, because it was my first time, I didn't really know what to expect. I had only been to a couple of tech conferences before. I didn't know what the audiences were going to be like. If there was kind of be this like big tomato throwing thing at the end, they're all just bashed me or if it was going to be like a more of a friendly conversation." Show notes: CFP Land Karl's Personal Site Washing Machine Guy Talk episode webpage

Welcome to Code Recursive, where we bring you discussions with thought leaders in the world of software development. I am Adam, your host. Hey, Carl, how's it going? Carl Hughes is a developer and conference speaker. Not everyone is comfortable talking at a meetup or a conference. That includes me. So I invited Carl on to explain how he got started speaking at conferences. Let's jump into the interview. I start by asking Carl how he decided he wanted to become a speaker. So every year I try to set a goal for myself that is to do something that I've never done before. That's a little outside of my comfort zone in some way. And so that's changed year to year. Uh, several years ago,

I stopped eating meat. That was my big goal. Uh, and then I ran a marathon a couple of years after that. That was a huge, you know, personal goal. And then I've done some professional ones as well. And one of the big ones in, I think it was 2017 was I wanted to get accepted to speak at a tech conference. And so it was really the pursuit of wanted to get accepted to speak at a tech conference. And so it was really the pursuit of that goal that started me on the journey, which is I'm just a very goal-driven person. I like to set that thing and just have something out there on the horizon to look at. So that sort of was my forcing function. And from there, what I did was I started to think about things that I knew technically that maybe were a little unique to my situation.

I've always worked at early stage startups. And so one of the advantages I've had is I've been able to help teams set up the initial infrastructure and architecture of an application. And I realized after talking to a lot of my friends who are engineers that they didn't get that greenfield opportunity very frequently. And so the opportunity to talk about how a small company makes those initial decisions and then how those decisions grow over time and change as business changes was really interesting. And that kind of got me started on a couple of topic ideas that I started pitching around. I think for me, a big sort of barrier to getting started was feeling like I didn't know enough technically to be worthy of being on stage. And I think that held me back

for a number of years. I didn't start trying to speak at conferences until I was at least seven or eight years into my software development career. So just a couple of years ago. And before that, I think what helped build confidence was speaking occasionally at meetups. I started talking occasionally at local code bootcamps, just kind of getting to be in front of the crowd and start to build up some like level of self-assuredness. And eventually, I think the next step was just obvious. I wanted to push myself to do something a little scarier and bigger. And that was like get in front of people, the sort of intensity level, what they expect. Most conferences are actually pretty laid back, especially in tech.

And so it's not as maybe as scary as I initially thought it would be. Anyway, so I was interested in the topic of testing and sort of setting architectures at small teams. I started pitching a couple of talks at conferences. I slowly figured out how you get, how you sort of apply to conferences and how you get accepted and what the acceptance rate was going to be. There's a ton of things I learned along that first year of the journey and eventually got accepted to do one. I think it was late 2017 was my first one. Oh, what conference was it? So that was API strat

and practice is what it's called. And not a huge conference. It's mostly focused on different open source tools run by the Linux foundation. And I was giving that talk on testing distributed systems. And so it was just testing modern web applications that have multiple services and things like that. And I remember, I mean, I had done a lot of public speaking up to that point. And I had been in a, everything from, I was in a band where I played in open mics in college. I did made in stage theater production at the university of Tennessee when I was there. And I did a lot of meetups and bootcamps. So I was actually pretty comfortable in front of people. But once I got up there in front of this like tech audience and I look out there and I see all these, for lack of a better term, you know,

gray beards, guys and women, both who had been doing this for clearly much longer than me, it was intimidating. I mean, it was like, these people can call me on my BS, you know, like, I can't go up there and really not know what I'm talking about. Because I was, you know, I felt like, and a lot of talk I've talked to now a number of speakers, this is not an uncommon feeling that we all feel like we don't have enough knowledge to get up there. Wow. It sounds scary though. Like, well, that specific conference, especially like, I mean, I build things that end up running on Linux, but I feel like I only vaguely know how it works. I wouldn't want to, like, did you have that fear of like, Oh God, they're going to ask me. Yeah. I was afraid they're going to ask me about the kernel and I

barely know what that is. I mean, I, uh, yeah, I'm a high level web application developer and I, I'm at this point I'm okay with and proud of that decision, but there's a lot of people that know these, these lower level components that know assembly and C and things like that, that I've never really touched in detail. And so it is scary. And partly also it's that, you know, because it was my first time, I didn't really know what to expect. I'd only been to a couple of tech conferences before. I didn't know what the audiences were going to be like, if there was going to be this like, you know, big tomato throwing thing at the end, but they were all going to just bash me or if it was going to

be like a more of a friendly conversation. Again, kind of going back to the experiences leading up to that, I think talking at meetups and bootcamps, these sort of friendly or smaller audiences was really helpful because I at least had some idea of what might get thrown at me during and after the talk. And a lot of people I've spoken to as well who are speakers, they also try to do company lunch and learns, which I think is a great way to get your talks kind of vetted and practiced. I mean, I feel like there's still something missing there. Like, what did you think this goal would get you? Yeah, that's a good question. So besides pushing myself personally, I was really, I think that giving talks has always forced me to sort of

create a story around what I'm doing. And that's helpful on a number of levels. It's helpful when I talk to my boss, our CEO, who's non-technical, but certainly interested in why we chose to build things the way we did. So if I have a better story crafted around why that is and the results and the things that I've learned in the past, it's a lot easier to convey that to her. So even just preparing those talks about these technical decisions that our teams have made, and then sort of being able to convey that to other developers has helped me convey it to people like my boss, or I haven't looked for a job since, but like, if I were looking for a job, it would be great experience for like, explaining what we built and why we built it, because that's something that always comes up in that job interview. So kind of having that, I guess it's like a professional practice

doing professional communication. It was really valuable to me too. And, and there's also these other sort of tangential benefits that are really hard to measure, like personal branding, you know? So now I'm out there as a conference speaker and maybe others come to see that. Maybe they decide to invite me to speak later, or maybe people just start to know me as a topic expert in a certain area. Around the same time I started speaking, I actually wrote a short book about PHP and Docker, which were two technologies we were using at work. And it was just kind of a getting started guide. It was really short.

It was free. But writing that and then having some conference talks about the same topic later in 2018 and 19 was really helpful for kind of establishing a little bit of my personal brand around those topics. Like I knew those topics pretty well. And so when they come up, a lot of times people end up writing the questions on the internet, which is kind of cool. So if I or somebody listening like wanted to get started, what do we do? To me, it always seems like a catch-22.

Step one, speak speak step two, become a guru. And then once I'm a guru, then I'll be able to speak at things. I don't know. Yeah, it is a catch 22. And I think that this is the thing that holds a lot of people back. And this was what I was afraid of was that because I wasn't a guru, I would get up there and people would call me out for being an imposter. And I think the reality is everybody kind of takes that first leap without being really ready. And that's okay. And so it's kind of like, I think back to getting my first job as a software developer, I didn't think I knew enough to be a software developer. And people would in the job interview in first few days, people would rattle off these acronyms that I

had never heard before. And I mean, we all go through that. And so the first step is kind of being willing to put yourself out there a little bit. And that's why I always recommend starting with things like meetups and bootcamps and places that are a little friendlier, easygoing audiences. But once you decide like, hey, look, I'm going to speak at a conference, I think it'll be beneficial for my career, or maybe it'll be a good way to meet other people in the industry that I haven't before. It's a great way to travel. Usually the conferences will cover some of your travel costs. And so you can get out there for free, which is nice. But let's say you decide

to do that. So the first thing you want to do is find a CFP, which is a call for proposals or call for papers. Everybody's used that acronym a little differently. And there's a bunch of websites out there. I run a newsletter called CFP land that, that sends out CFPs, but there are several others that you can find, or you can just Google around for tech conference CFPs or ask people in your community. If you go to conferences, you can meet other speakers and ask them about it. It's all this stuff is actually not too hard to find on the internet. Once you find a few CFPs that you think are interested in submitting to, you have to write what's called an abstract. And that is usually a, it can depend, but one to 10 sentence sort of introduction to your talk. Sometimes they ask for as much as an outline where you kind of give them bullet points on everything you're going to

cover. Sometimes it's as little as a couple of paragraphs and you're just going to explain what it is you're going to talk about, why you're the best person to talk about it. And so you'll fill out that abstract, you'll submit that, and then you'll wait. And you kind of do a lot of waiting with the conference speaking game. And what I found initially, I think the first year that I submitted that I really decided I was going to do this, I talked to some other speakers and they said, you're going to have to submit 20, 30, maybe 40 conferences before you actually get accepted because the first one is really hard and you have no idea what you're doing. And so I found, I think my acceptance rate in that first year and still is probably like 10 to 20%. So it's pretty low to be honest. And so you may have

to submit to 10, 20 conferences before you get your first acceptance. And that's okay. That's normal. It sounds insane though. Yeah. It's like job interviews. And because it's this two-sided matching, that's really hard to do. You can never fully predict what the conference is looking for. You can read their website. You can try to tailor your talk for them. But like at the end of the day, you can only sort of adjust so much and they don't exactly know what your talk is going to be. And they can't fully understand it even if you write a great abstract so it's like this imperfect knowledge on both

sides means that nobody makes perfect decisions and it's impossible to get 100 acceptance rates but isn't there it seems to me that there's like some what i'm thinking of is like saved by the bell where zach has like two dates to the prom or something, right? Where I'm going to apply to like the JS conference and then the Rust conference and they'll both applied or another conference. And so it's perfectly okay to decline. They know there's certain percentage of the speakers they invite will decline. That's kind of part of the whole thing. There are some people that speak at dozens of conferences a year. And for them, it's a whole scheduling challenge to just figure out where they should go and when, and who's going to invite me to what. So anyway, it can be actually a pretty challenge, but in your first year or two, if you're submitting 10 or 20 conferences

and you're getting a couple of acceptances, there's probably not going to be a ton of overlap to worry about. How soon do you find out? Like I'm still imagining my scheduling being hard. Yeah, it is. And so usually what the way I've handled this is like, I sort of will apply to a conference and I'll sort of have their, the date of what that conference is written down somewhere, either a spreadsheet or I use CFP lands tool for this, but like you can just kind of keep track of that event date. So, you know, you don't have too many you've applied for in the same weekend maybe. And then I don't go as far as blocking it off my calendar until I get accepted, to be honest, because there's such a

low chance of actually being accepted, but they'll usually start sending out acceptances anywhere between two and six months before the conference happens. So usually you have quite a bit of lead time. Usually it's more like four, five months of time. And that's plenty of time for you to decide like, is this really going to happen? Or am I really going to do it? Or do I need to book a flight? Or is this not going to happen for me? Are you prepared to do the talk before you're accepted? Usually not. Now this is normal. So this is another thing that I've, last year I interviewed about 35 different conference speakers just asking a lot of these questions like, you know, how do you prepare? How do you submit? Like what are your tips for this? And I found that most of them don't have the talks already before they submit. Now, the nice thing is you can reuse talks.

So in your first year and my first year, I think I had two talks that I was submitting. So I was submitting both of them to every conference every time. And they weren't always always both right for every conference. So I'm sure I was wasting some time there, but it was just easier to kind of try to tweak it a little and make it seem okay, and then submit to. And then once those started getting accepted, it was like, I only had to prepare two actual talks. So I did think six or seven conferences in that after that first year. And they were all like, I basically just only had to prepare two real talks. And so it wasn't as much work as it sounds like. And that's usually what speakers will try to do is get the same two to five talks accepted as many places as they can so that they only have a limited number of presentations they're actively giving at any time. And then in the weeks leading up to the

presentation, you're going to get accepted. You're going to know there's four to three or four months at least before the conference itself. So you might try to submit that talk as an idea to a local meetup so that you can practice it there. Or you might try to submit that talk as an idea to a local meetup so that you can practice it there. Or you might schedule a company lunch and learn so you can practice there. And you may just schedule on your own in front of the bathroom mirror, which is what I do a lot of before you get there. What do you do in front of the mirror? Do you have your slides and you stand in front of the mirror? Yeah. So this is so nerdy and I don't really care that it is, but I like to kind of know what my body language looks like when I'm giving a talk. So if I just do it out in the middle of the living room, that's okay. But I don't really know what I'm doing with my hands and if I'm standing in a natural way. So I'll try to like do it somewhere in am I making appropriate facial expressions at appropriate times and like sort of moving around in a way that makes sense? Just awareness of my own body language before I actually get on stage and do this in front of people.

I don't know that every speaker does that, but I did find from talking to speakers that the broad majority of them practice a lot and a lot more than you would think. Anywhere between 10 and 30 times, they'll sort of practice their talk. Usually it's just to themselves in front of a conference room or in front of the mirror or going to meetups or traveling to other companies to try to give it there. And so it is important you practice. I think that's one of the things that helps lower your nervousness and make you more effective as a speaker. There's a couple of good talks and I'll send you some links. There's one by a guy named Nicholas Means. He gives a talk on what happened at Three Mile Island. And it's just this amazingly intricate and detailed engineering story about the disaster, near disaster at Three Mile Island.

And he's clearly rehearsed it a lot. Like he knows the details, but it doesn't sound like he's reading cue cards either. And hitting that balance is what I find really challenging. And I think a lot of speakers do, and it's probably something we all could work on, especially because you don't want your slides to just be a bunch of bullet points that you're reading from. You want to sort of have more of a image on the slides and you do the speaking yourself in an ideal world. So anyway, that kind of getting into the mechanics of speaking, and that's sort of a whole other topic. But I think finding a way to make yourself sound like you know what you're talking about,

and you have rehearsed this, and you're clearly knowledgeable, but also not a robot, is that challenge that we all have to face. It sounds like you have had a lot of public speaking experience before you even tried to speak at a tech conference. Like, what would you recommend for somebody who doesn't have that kind of experience? Yeah, the biggest thing is practice and just doing it, getting more comfortable doing it. Like a lot of skills, public speaking isn't, there may be some natural aptitude that some people have, but it is mostly how much you cultivate it and practice it and do it. You know, I was lucky, I guess, in a way that from the time I was a kid, I was kind of in

different church choirs and places where I was sort of up on stage and couldn't get off. So I think in a way that set me up to be like a little more open to both speaking than some people. But even if that hasn't been your background, there's no reason you can't start small with the things that are just slightly uncomfortable now, but not out of your reach. So that one, for example, whenever I hire new employees, I have them give a six week presentation where they get in front of at least a portion of the company and sort of give a quick overview, 30, 45 minutes of what they've been doing in their first six weeks, kind of what they learned, what projects they worked on,

if they fixed a little bug or they cleaned up some text somewhere, I'll have them put that in there so everybody knows that they're contributing. And it's a way for other people to get to know them, but it's also a chance for them to practice this skill of public speaking, because I think it's pretty critical that at some point as an engineer, you're probably going to do some of it, even if it's just to your team, even if it's just in a casual setting, it's still important. Yeah. Cause there's just communicating, even if you're not going to public speak, like, you know, I ended up talking to people at my company or even if it's just a singular person, but somebody very important. So it kind of gets your nerves up and then, yeah. Yeah. And then you think about job interviews. I mean, very rarely are we going to stay in the

same job for 30 years and then retire. The field seems to be moving where people change jobs pretty frequently. And so every time you go into a job interview situation, it is essentially the biggest test of public speaking that you're going to have. And I think having practiced that in other situations actually helps a lot with sort of making you ready for those those really high pressure situations. I feel like we skipped over some steps. How should I think about choosing a topic? Yeah. So there's a number of ways to do this and different people sort of think about this differently. So from talking to a lot of speakers, some considerations you should put into your mix. Does it fit the conference? So if you're going to apply to a Ruby conference, don't submit a bunch of Python talks. It's just not going to work. You know, more than that, sometimes you'll find the conferences have a

specific agenda or theme for the year. So look at the CFP page, read it, see if your talk actually makes some sense for it. And that'll avoid you submitting a lot that don't make sense or preparing a talk that doesn't make sense for the audience. You want to think about whether the talk itself will get you excited and is something that you're like actually interested in talking about. Because like I said, you're going to spend a lot of time practicing and reading about this topic and learning it because you don't want to get up on stage and look like you don't know what you're talking about. And So a lot of the speakers I talked to last year were very passionate about their topics, whether it's something very technical, like writing Java plugins, or it's something very non-technical and have a softer skill like building business off of their, you know,

whatever technology they're using. And so whatever it is, you should sort of shape your talks around something you care about. You obviously want to pick something you know well or think you can learn pretty well. And that can mean a lot of different things. Different conferences are going to have different thresholds of how technically difficult they want the talks to be. So this kind of goes back to that first point, which is make sure you know if the conference only wants senior level talks that you don't submit a bunch of introduction to X or Y. But think about that and think about if you're the right person to give that level of difficulty. The good news is that most conferences want a variety of experience levels to be represented.

Because the truth is the audience is going to be a mix of junior, senior, mid-level, and managers probably. So whatever you pick, you can definitely give an entry-level talk. There's nothing wrong with that, but just know what level you're shooting for. I have a sense that like people don't do enough beginner or intermediate talks. Maybe this is just my skill level, but it's like when I go to a conference, there seems to be more things where I'm like, I'm not quite sure what they're talking about than things where I'm like, this is too basic for me. Do you think that's true? Or that's just me? Well, I think everyone's knowledge is spiky. And what I mean by that is some people, it's like,

maybe I know the front end really well, but I don't know much about back end. So I may be a senior level front end person with a junior level back end knowledge or a entry level database knowledge, because I've never had to deal with those technologies. So just because a talk is, it sounds entry level or whatever, it doesn't mean it is for everybody. And the same with senior level talks, like you can be a senior engineer who knows nothing about like we were talking about the Linux kernel, but you know, our field is just so broad that and everyone's knowledge is a little spiky that the levels are a little arbitrary, I feel like. And it sort of simplifies the problem to call this a senior level versus a junior level talk. It's not that simple, but I will say that I would generally agree that there's plenty of space in conferences to have junior level talks. A lot

of conferences are, I think, becoming more aware of this and starting to try to find speakers who are new to speaking because they tend to be on the more early end of their career. And I think that that's something I've seen more in CFPs as I've looked at them over the last few years is they want, say they want a certain percentage of their talks to be from first-time speakers. And that's a great way to get people up there who haven't been giving talks and maybe they are giving their earlier in their career, or maybe they're from an underrepresented audience group and want to be on stage and sharing what they know too. So there's a lot of advantages to that, I think. Yeah. If I want to speak at something, like step one is like build something really cool.

So like spend three years building a new database or something, right? And then try to tell people about it. So you haven't mentioned that at all. Like you haven't mentioned creating something or, I don't know, be the creator of some huge open source project or et cetera. Yeah, there are certainly people who are, but not many of them. I mean, you know, when you think about the millions of software engineers that are out there and the tiny percentage who make an open source library that is used by more than a thousand people, the reality is there's just not many of them. And most of them are busy people who have jobs and careers outside of speaking. And so they can't just go to every conference and talk about

it. Somebody was saying that there's this fear that, you know, you're going to submit a talk about react, let's say, and then the creator of react is going to submit a talk about react. And you're like, well, I'm definitely, you're going to lose that one if it happens. But it's very unlikely that that's going to happen. You know, I don't know who it is that created it. I don't remember the name, but they cannot be everywhere at once. And so the great thing is, there's a lot of conferences that are sort of focused on specific technologies in maybe even regional areas. So for example, if you look for JavaScript conferences, you're going to find local to city JavaScript conferences.

So I think there's like a New York JavaScript kind of conference. There's even a New York Node conference that's a little different. And so there's just so many little niches of conferences that there's no reason you can't be the person in your tiny little area that is pretty knowledgeable about that topic. Should you be afraid of if I'm like, Hey, there's this cool library. I have some certain fear that like, Oh, the, the creators in the audience and he's like, actually, I stopped using that. It's no good.

I've done this and in not the best way. So I gave like a talk at a meetup about this node framework called nest. It's uses TypeScript. I really liked it. So I gave this talk and somebody started asking questions about whether you should use it with serverless. And I'm like, honestly, I have no idea. And, you know, I'm like, I don't, you know, can't imagine it would be the best for that. And then the next week, somebody from the nest team messaged me on Twitter. And it's like, you know, we actually do support that, that serverless thing that that guy was asking about. And I'm like, so of course I'm, you know, get called out after after. I don't know, I think that people know you're trying your best to admit you don't know things, that's fine. You know, nobody's going to be mad at you about that. And as long as your talk

description is clear, sort of what you're going to cover, there shouldn't be a surprise. So if, in other words, you say you're going to cover building your first React component, and someone asks you about some really obscure, small part of React that had nothing to do with what your talk was, I wouldn't expect you to know that necessarily. That goes back to the whole, like, throw it to the audience and see if they have any ideas or have dealt with that problem because you can't be an expert in every single thing. Yeah. I feel like there's a certain talk persona and maybe it's just in my head of like the very polished expert who's here to tell everybody how things work. And I don't feel that that's me, right? I mean,

I have this podcast where it's basically me asking smart people stupid questions, like the persona of like, Hey, I'm the expert. How do you approach that? Yeah. So there's a couple of ways that I think people do a good job of addressing that problem. And you're right, like coming off as I am the guru of X technology is really hard to do legitimately. So I think a better way to approach that would be to sort of take a personal story of your use case for a certain technology and tell the audience your honest story. So for example, I used to do a talk a couple of years ago about microservices and it's kind of a microservice slash service oriented architecture for small startups. And the sort of trajectory was we started off, we had this huge monolith. We had no idea,

you know, what we were doing. It was kind of like, and here's how we started breaking it up and making the pieces more digestible and learning to test it. And it wasn't like, I'm an expert on microservices and I know how to do it. It was more like, here's the things we tried and what did work and didn't work and the tech stacks we were using. But like, it's great because I give that talk and then immediately people in the audience have, they sort of like have their own experience to throw in there. And so it really invites a lot of participation and people sort of being okay with just kind of chiming in because nobody in that room

is necessarily setting themselves up as the expert who knows everything. I'm not telling you this is the way to do microservices. I'm giving you one story about how I did them once. And there's lots of room for improving and changing. Yeah, I like that. It's a case study or something like this isn't Carl's rules for microservices. Right. The older I get, maybe the less I believe there's an absolute truth and way to do everything. Yeah. The other distinction that I perceive, it seems easier to give a talk about something that is a hard piece of tech than like career advice for developers or something that could be very valuable, but it's less specific. It's harder to evaluate. I feel like soft talks are like for the

keynote speaker who's famous. So these talks that are not heavily technical, maybe more about people skills, team management and things like that, that are fuzzier, they are harder to give. I, I would agree with that. Maybe it's just because I'm an engineer and that's like, my brain goes to engineering things. It likes absolutes and it likes black and white, right, wrong. And, you know, my brain goes to engineering things. It likes absolutes and it likes black and white, right, wrong. And, you know, evaluating decisions with data and all this stuff that is really, really hard to do when you are talking about something like team management or feelings or performance reviews with team members, like all that stuff is very hard.

So I agree with you. Now that said, I kind of like the speakers who bring it back to a personal story again, because I think that is really a powerful way to convey that these things I'm telling you are not absolutes. They are just one experience. And we kind of, we form ideas about things based on all the data we have. And that data might just be a lot of stories because those top 10 lists, they kind of flow in your brain and write out because there's nothing really memorable to dive in there. But the more you can tell stories that like link it into something that's memorable, that I think the more your audience will receive and sort of ingest that information. It's like the sneaky soft talk

where you're like, I'm here to talk about Docker, but it's really a talk about how learning has changed my life. Yeah. I mean, that could definitely be one way to do it. And I think, again, this is like, there's sort of, I don't want to like discourage new speakers from talking because that sounds really hard to do. And because it is, I think there's sort of tiers to where people get in their speaking careers. I'm way down here in the early stages, like trying to learn it all and sucking information from as many people as I can. And I see people all the time who are in the like, the keynote stage of their career where they can give these big talks that are just so inspiring, like TED Talk level things. And to me, it's like, man, I don't even know where you start there. But I think you have to start down here. You start down in the low level, just doing what you can, and you get a little better, and you keep getting a little better. And maybe eventually you do get up to where you're given these keynote talks, and you've got these really inspiring stories to tell people. But it's about being critical've got these really inspiring stories to tell people.

But it's about being kind of critical and thinking through how you want to get there. I talked to somebody. They had applied to a lot of conferences as sort of a way to travel around. And the method that was described was to gather a bunch of buzzwords that were popular and put it in Excel. And they had some sort of like pick a random word from this row and then this row and this row, like Mad Libs. So how do talks get chosen? Yeah, it can vary quite a bit from conference to conference. Most of them have a CFP process. If they don't, then they just straight up invite the speakers they want to speak. So some conferences do that because it's simpler and they want to have control over every talk comes in.

But accepting those because you just have to be a well-known speaker to get invited, most of them will have a CFP and it'll open up and they'll either do one of a few ways they can evaluate the submissions. They could do a rolling review where every time submission comes in, they check it and they see if it meets a certain criteria. And if it is, they might accept the speaker or accept that talk and then kind of move on and evaluate the next one. In that case, it's beneficial to get your talks in as early as possible. So that's interesting. And sometimes they'll tell you they're doing that. Sometimes they won't tell you. So you sort of just have to know or learn or ask the organizers. But that's kind of a rarer thing. Usually what they do is they wait

till the end when they have gathered, say, a couple hundred submissions or more, whatever their threshold is, and then they are before the deadline. And then they'll just sit down as a committee of organizers and they'll decide which talks they want based on some predetermined criteria, usually. And usually that's things like the uniqueness of the talk, the interest level of the topic, the buzzwords included might be a criteria. I don't know. I haven't been on a conference selection committee, but I've talked to a couple of people who have organized conferences and, you know, they've told me basically what they realize their job is to sell tickets so they can keep doing the conference, but they also want to like give speakers an opportunity who are

new and from different areas to kind of just bring in new perspectives to the community, which I think is really cool too. So there's a mix of things happening and how they make that selection, but usually it's done by the organizing committee. I want to submit my abstract and I want it to get picked. So what's the key to that? I hate to cop out, but it depends is definitely the answer here. So when a conference opens up their CFP, they're usually going to include some details on the CFP website. It'll tell you like what topic areas they're looking for or what focus the conference has. So matching your talk to that focus is the first thing, but also just writing a good abstract in general is a skill in itself.

And this is kind of an interesting thing I didn't find out until I got into speaking was that there's the skill of public speaking, but then there's the skill of writing the abstract. And it's like taking a lot of information that's going to be an hour long slideshow and putting it into two paragraphs. Like that is a skill and it certainly can't be discounted. And I think that some of the best speakers or most prolific speakers, at least are very good at abstract writing. And maybe they can be average speakers, making your abstract compelling. That's a whole skill in itself. The conference organizers are also looking for a good blend of topics. So what this means is, if there are tons of people submitting about React, they aren't going to just take 10 React

talks, they're going to like, sort of vary it it up and maybe they're going to talk, have one person talk about React and they're going to have another person talk about Vue.js or Angular or whatever. So they're going to look for that. They're also going to look a little bit at the speaker's prior reputation and why this matters for is a couple of things. One is a well-known speaker will draw some audience members. So that's that's part of it. But also people who've spoken before are less likely to flake out or be unreliable or sort of blow it when they get on stage. So to be honest, conferences are trying to de-risk the fact that new speakers, there's some level of risk involved. They could also be looking at the cost of transporting you and the hotel that you're going to stay at. So in other words, local speakers might get preference in some conferences, especially if they're smaller community run conferences that don't have much budget to pay speakers. How do these costs get covered? Great question. So this is a whole nother thread that every few months, a thread on Twitter will

crop up that is people debating whether, you know, speakers should get paid, whether they should get all their their costs reimbursed, or whether these community-run conferences, it's not their obligation, maybe the company should cover it instead. So there's no right answer here, and it depends on the conference. I've seen a few things. In general, about 30 to 50 percent of conferences that I collect for CFP land have either travel or hotel or some combination of those covered for all their speakers. So it's not even half conferences cover that. And probably only three to 5% of conferences give you a stipend on top of those costs. So it's actually pretty rare to get paid anything to speak in tech conferences, but it's not that rare to get at least your travel and hotel bills covered. So that's kind of nice.

My wife took me to this like home show around here. And it's like you pay to go into an arena where people are like selling things like a hot tub or whatever. And I paid to get in there. The people selling things there, they paid to be there. So I found the whole business model like, well, it's genius, but confusing, right? Like why? And I guess conferences, they seem similar to like, what is the business model behind the conference or is there one or? Yeah, no, that's a great question. And honestly, I think a lot of speakers don't ever ask this or think this. It's kind of too bad because conference organizers most of the time are very idealistic,

good meaning people that want to make a community better. And they don't always do a great job of that. Sometimes they screw it up massively, to be honest, but I believe most of them have very good intentions. Now, the way that a conference makes money is either they sell sponsorships and, or they sell tickets. And usually conferences do both, but some conferences are only one or only the other. And it's interesting too, that every conference has a different actual business structure. So for example, a lot of the smaller conferences, local conferences might be either non-for-profits, which means that they can't make a profit at the end of the day, and nobody can make really money off this thing other than just sort of cover their

costs. Or there are actually for-profit companies that create conferences for brands or there are brands themselves that create the conference. So I'll kind of give an example like AWS throws a big conference every year. And the goal of that conference is to get a bunch of developers in one place. They can sort of teach them and sell them on AWS products. Right. So it's very clear that their goal is like this is a cost, a marketing cost for them. And so they probably subsidize the conference. I don't know how expensive it is to go, but it's probably not

as expensive as it could be because Amazon wants you there. And that's kind of one end of extreme corporate end of the conference world. On the other end are these like smaller community-based events where maybe a local meetup organizer decides they are going to try to get a couple hundred people together to do a local conference. And for those, usually they're going to have to get sponsors to help out with the cost. They're going to get, they're going to sell tickets for at least a couple hundred bucks a piece to sell to cover their costs. They have to rent the space, which is by far the biggest expense. And they'll probably have to provide some food. They may have to pay for speakers, travel and hotel lodgings. So anyway, most conference organizers at that level make very little to no money or lose

a lot of money on that effort. I've known several conference organizers. I've never known one who got wealthy off of the conference organizer game. Most of them do this as a sort of social good, goodwill sort of thing. And so keep that in mind as you're applying to speak and you're kind of peeved about the conference not covering your costs. Like they're probably not making money. That's good to know. Are there counter examples? Like, yeah, I mean, there are, and you can certainly dig into from the conference website.

You can probably figure that out. Like if it's run by a, an event organizing company that, you know, does this professionally, then maybe they do have a profitable business, but even a lot of those event organizing companies, they're not extremely profitable businesses. I mean, they're just small businesses, like a couple of people running this because they enjoy it. I've met a couple of people that do that as well. And I don't know, it doesn't feel like this big faceless corporate entity. We don't see as many of those in tech conferences right now. Yeah, no, that's very true. So once I get selected, what do I do? One of the things I found as I was speaking and getting invited to speak was that

the conference organizers may or may not tell you exactly what to expect and when as you get ready for the conference. So it's kind of on you as a speaker to figure out your timeline and what you need to have prepared. Usually I try to have like everything worked out with my employer as far as like time off and all that, at least two or three months beforehand, just so I know I'm going to have the day, the days off or, you know, be able to be remote those days. I may also double check with the organizers on the dates and location. Cause to be honest, like I said, running a conference is really hard.

And it takes coordination between places, times, and money that is actually pretty challenging to work out. And sometimes maybe a venue gets sort of like decides they can't do it that week. And so they may have to move it to another venue or they may have to change the date. So just double check on all those things, either check the website or email the organizers a couple of months ahead of time to make sure you're in a good spot. And then beyond that, you've got to do a lot of logistical things on your own, like book the flights and hotel rooms. Most of the time, conferences won't do that for you, but you can ask if they will. A lot of times, they would prefer if you just submitted receipts

to get reimbursed rather than they pay up front. It's just easier for them from a cash flow perspective. So that's something to think about. You may, in some cases, if you're going to travel internationally, you have to have like a passport and all that stuff. So make sure you have that ahead of time. It seems obvious, but well, if you're us centric, like I am, or if you're living in the U S like usually you can travel all over the U S and there's no restrictions, but like in somewhere like Europe, it may be more common that you're having some form of international ID. So just be ready for that sort of paperwork. And then there's a lot of times a speaker dinner or speaker after hours event where

you'll get to meet some of the other speakers. So try to get some details on that. Make sure you go to those. I found those to be one of the most fun and helpful sort of networking events in tech. And that's like you get to sit down with a bunch of other speakers. Most of them, I always feel like way under, I feel way outclassed by these people. Like they are way sharper than me, more experienced. And it's always fun to learn from them and to try to pick their brains. And then as you get closer to the date, you're going to, you know, hopefully

you're practicing, you got your slides going, all that good stuff. Um, there's some of the other things you want to think about are like, are you going to go to other sessions, which I would recommend that you do, but you may want to look at the schedule and see what other sessions would be fun to attend. Maybe there's other speakers, you know, things like that. You want to also think about how you actually get to the conference from wherever you're staying. So if you're not staying in the sort of conference hotel, like there's all this logistical stuff is my point that they don't necessarily give you. So be ready for it. And then once you get there, what I like to do is try to test out my laptop and presentation on the exact same equipment that I'm going to be giving it on. Because in most cases, the event venue will have, you know, projectors and all that stuff that you

can plug right into, but you want to try it ahead of time so that you're not debugging live if it doesn't work. And you have hopefully a backup plan of like, you email your slides to somebody or something like that. And then the other thing to think about here is what happens when inevitably you're giving a talk and the wifi goes down. Do you have all your slides backed up? Do you have like a video of your demo you were going to give all this stuff that like could go wrong because there's that whole, if it could go wrong, it will go wrong at some point. If you speak enough, you're going to hit one of these times. So I would just be ready for that.

I've unfortunately seen speakers who didn't have a backup plan and something went wrong and they forgot their slides or lost them or the power went out or something weird and they were just stuck. There was nowhere to go. So you can't avoid all that, but try to think about that. And then when you get there, you're leading up to your, getting up to your time is closer. Figure out what your sort of prep needs to be. So some speakers I've talked to, they have like funny little rituals they go through and you

don't have to have anything, you know, really cool. But one of my favorites is Alex Lakota. He's a Lakatos, I think is how you say his last name he uh is a speaker and he goes into the bathroom before his talk and just starts celebrating just acting like he won something and he's like it doesn't matter what i just want to get in there and get pumped up get that energy going get moving get like jacked up and he'll just beat on his chest and like that's how he gets himself hyped up so you don't have to go that far if you don't want but i think it's good to have like a lot of people have pump up songs they listen to or like they'll go you know run around the the building real quick maybe

30 minutes before just to get their blood moving i don't know i you know figure out what works for you and then um as you give your talk start thinking about well you know as you sort of wind down you have to decide if you're going to give questions time or not. And that you probably want to think about ahead of time. A lot of conferences will either say we do or don't encourage questions. But if they don't say you can kind of pick what you want to do, you can tell people either I'll take questions while I'm on stage or maybe tell them I don't take questions on stage. But afterwards, come meet me in the hallway. I'll hang out there for a few minutes.

That can be good, too, if you don't want to get yourself on the spot, which can feel a little awkward. Yeah. What's your preference on questions? I enjoy them, but I understand why people don't always. So I don't think there's a right and wrong answer. I think it's kind of what works for you. I like the ability to get the audience involved.

And so when someone asks a question, and even if I don't know it, I'm okay with pushing it off to another audience member or saying, I'll look it up and get back to you. There's always somebody at the conference who asks a question and then it's not even a question. It's like you talk and there's any questions and there's somebody who's like, that was neat. Let me tell you what something I did that was better.

Yeah, that does happen. That's probably a big part of why some speakers don't like questions because that's just very distracting and annoying. I don't know. I was looking at it. It's like, I just got my 45 minutes to talk on stage. If you want to have two minutes, I don't care. I'm not going to fight you. Nice. Now you've done it. You completed your goal. So was it everything you thought it would be to be a speaker? or attendees or other speakers or the organizers, the connections to me are the really most valuable thing because at the end of the day, you can probably go online and watch a lot of these conference talks in video form. And so the information itself is going to be available soon, but the FaceTime you get with other humans is not easy to replicate other places.

So biggest takeaway has been that I still do it because i enjoy all that side of it and so i don't think i'm gonna like stop completely but i've definitely slowed way down i'm trying to do more like two conferences a year which is seems like a nice number for me partly because i just had a family and just had a baby so added to the family and so it's uh it makes it a little harder to get away and i feel like i just I enjoy being home as well, because having a new baby is like a new, whole new experience at home. So doing less, but still, still doing some. And out of your current speaking experiences, like what was the most powerful or rewarding experience? So let's see, I probably have a good one and a bad one that were both

memorable in their own ways. And so I'll start with the time I really kind of blew it. So I was giving a talk for an audience that was mostly system administrators and like website administrators. They're more like people who work in Drupal and WordPress, other CMSs to update their college websites. And so it's a different audience than software engineers. There are certainly people with a lot of knowledge

and technical ability, but they don't have this, they don't go in and write low-level code. And so it's like basically when I'm talking to a Linux kernel administrator, I have no idea what they do, and they think I'm, you know, whatever. Anyway, so I was giving a talk on testing distributed systems to this group

that was a lot less technical than I was used to in the ways that I was used to. And so I really did not adjust that talk to the audience well at all. And I got up there, I start giving it and I look out in the audience, it's like clear, blank faces. And I felt like an idiot. I mean, it's like, that is the kind of mismatch that you do not want. Like, it's one thing if people call you out for missing a couple of facts here and there, but to like throw something at people that they don't understand at all and have no grounding in, it just makes you look, you have no idea what you're doing. And to me, that was like a biggest failure as a speaker, because afterwards, you know, I had some, a couple of people said, you know, Oh, that's really interesting, but I had no idea, you know, what you were saying, or, you know, that's way beyond me. And then a couple of people were like, Oh, that was good. I, you know, I kind kind of got it i knew more about this than other people but like yeah it was rough and i felt that's something i strive not to do again so in a way that thinks like screwing that up once has sort of like made me really conscious of who my audience is and what

their level is at different skills before i go in there. So I really try to go research, like the conference, look at prior talks, and even ask the organizers questions about what their audience makeup is before the actual talk. On the other side, I had a talk that I did this, the latest one I gave was kind of my favorite one we were talking about earlier, like the challenge of non technical talks. So I started pitching one this year called Stop Writing Code and Start Solving Problems. And the idea is that a lot of times as developers, we tend to jump first to like someone gives us a problem and we immediately think, oh yeah, that would be fun. I'm going to go write a bunch of code that solves it. And that's our engineering

brains that want to just build stuff, right? And I'm guilty of this as much as anybody, but I've learned that that is often not the best move for the company and for the sort of longevity of the project you're working on. Because oftentimes what we do is we reinvent the wheel because we thought that would be really cool to build. And we didn't stop and think about, was there an open source package that did most of this? Was there a vendor that would do this for us that we could integrate with? Or even sort of higher level is, do we go back and say, is this really necessary? Like, is this the only way to solve this problem? Or could we maybe do this instead? It's way easier and less technically challenging. And so I noticed that engineers just tend to jump right in. I wrote

this talk kind of about that or pitch this talk kind of about that. And I gave it at a local conference here in Chicago last year. And it was, I feel like I'm starting to get how to give those sort of less technical talks now. It's making me feel like encouraged to do more of that. And so I've been kind of pitching that talk and versions of that talk a little more lately, trying to get a little less technical and more story-based and things like that. So anyway, I don't know that that's super discrete success as much as that discrete failure, but like, it's feeling like I kind of am starting to crack a code that works for me in giving those sorts of talks. Do you think that talk has been impactful? Yeah. So I give it in form of stories. So we've been talking a lot about how I think that's a

good method for giving conference talks is to try to tell personal stories. And so I kind of was starting it off with how I used to work at GE appliances. And I worked on this new product that was called a smart dispense pedestal. Anyway, it's just like, it's supposed to be a whole new invention for washing machines. But the reality is, it's like, they hacked together 10 or 12 parts that were all available off the shelf and made this thing that was quote unquote, unique to GE. And it's a lot of its marketing. A lot of it is just like, the truth is that most inventions are just a product of what has come before them. That's just how it always is. We just kind of overlooked that because it's

so, I think it's just tempting to think that the, of the story of the master engineer who just knows so much that he or she can just build anything from scratch. And that is just so rarely true. You know, then you've got like Isaac Newton talks about, we're all standing on the shoulders of giants. And that's just continues to be true. And it's even more true in this world where we have open source and Wikipedia and like public knowledge base that is just massive. By telling stories, I think it does make some impact on people because everybody afterwards came up to me. I've never had people do this, come up to me and like call me something. They all said, oh, you're the washing machine guy. I love that. That's so cool. And so once you start to get known

as the washing machine guy or whatever your talk is, I think that's when you know you've made at least some impact. At least they never remembered it. This month, and every month, developers will be traveling to conferences. They will be watching talks and learning new things and getting excited. Carl went from an unknown developer to a conference speaker. From a vague yearly goal to the washing machine guy.

Thank you, Carl, for showing us how we could all become conference speakers. Alright, that was the show. Thank you so much for listening all the way through. Let me know what you thought. Until next time.