Hello. You're listening to the Streaming Audio Podcast. And today, instead of talking about event streaming, we're talking about how to get you into events, specifically conference events. Because here's the thing, we've been doing a lot of work recently helping to organize two big Apache Kafka conferences, and it raises some interesting questions. Why do people want to speak at conferences? And if you're one of them, how do you actually get yourself accepted? Well, joining us to discuss it is Robin Moffatt. He's a principal developer advocate here at Confluent, and he's the chair of the program committee for two conferences this year, Kafka Summit London, which has just been and gone, and Current which is forthcoming. Along the way, he has seen hundreds of conference submissions, some good, some bad. And if you want practical advice on how to be one of the good ones, Robin's the man to get it from.
Before we get started on that, I'll tell you that Streaming Audio is brought to you by developer.confluent.io which is our site that covers everything you need to know about how to build successful systems with Kafka. There are some nitty-gritty courses that will take you through the internals of how it works. There are also some really nice high-level architectural guides that tell you how you can put things together and make the whole system work well. Those are some of my favorites. If you head there and you want to follow along with one of the tutorials you'll find, then also go to Confluent Cloud to get your own Apache Kafka cluster running. It will be up and ready in minutes and it will easily scale all the way into production. If you add the promo code PODCAST100 to your account, you'll get $100 of extra free credit to run with. And with that, our topic on the table is conferences. Why would you want to speak at them and how do get in?
My guest today is Robin Moffatt. Robin, welcome to Streaming Audio.
Thanks for having me, Kris.
Pleasure. Robin, you are a principal developer advocate here at Confluent. You've spoken at a lot of conferences. You've helped organize some behind-the-scenes. Relevant to this discussion, you were the program committee chair for Kafka Summit in London, just gone.
Yeah, I was.
And you're about to be program committee chair for the forthcoming Current conference, which is the next generation of Kafka Summit. So you have seen a lot of abstracts, you have spoken at a lot of conferences, you've written and submitted a lot of abstracts. Have you ever been turned down?
Plenty of times. Plenty of times. I was actually looking at this, so I use a tool called Airtable to actually keep track of all the conferences that I want to submit at, and then when I've submitted and then the responses, because I'm a geek and I like to know exactly where stuff's at. And I think the last year that was actually before COVID hit and I was actually traveling, I got accepted at 57% that I submitted for.
So just under half I got rejected at. So kind of spin that whichever way you want.
Glass half full kind of person.
Glass half full, absolutely. But yes, even if you do this thing as a profession, you get turned down a heck of a lot.
So it's still a numbers game, right?
Very much so. And sometimes you can write the best abstract and you just didn't get in. It's like there's no more to it. And sometimes you do a bad job of it and you can learn from it and sometimes you say, "It's just a numbers game. Submit to this one, submit to that one, submit to that one and you'll hit lucky if you've got a good abstract and it's what they're looking for.
Nice. So maybe that's the first thing we can teach people is don't get disheartened if you get rejected.
And also don't wait until you've got that particular conference that you really want to speak at. So there's all sorts of conferences for all sorts of audiences, and if you sit tight and think, "Oh, I would love to speak at Kafka Summit, I would love to speak at Current 22." And you think, "Right, now I'm going to write my first ever abstract," you're missing out on all of that practice time that you would get. It's kind of like interviewing for jobs really. If you only apply for a job that you really, really desperately want, maybe you'll get it.
But if you've done a bunch of interview prep beforehand at other companies that maybe you're interested, maybe you're not, but you've got that muscle memory of here's the motions that you go through, here's the keywords to look for, here's how to phrase it. Here's the kind of things that you forgot you even had to do when you submit for stuff. So it's just a good idea to get into the practice of it. So when you do I hit on that particular conference that you really want to speak at, you've kind of lined up all your ducks in a row.
Yeah. Meanwhile, I suppose you are also opening up opportunities you may not have even considered.
Well, absolutely. That's the thing. It's a funny thing with conferences, kind of everyone has their own perception of kind of what the top tier conferences are and whatever. But actually conferences appeal to all sorts of different audiences and some of the best ones I've been to on paper would've been not looked down on, but kind of people would be like, "Oh, no, I'd much rather go to this one here, the flashy one that everyone's like, 'Oh wow, you're speaking at this one.'" But for me conferences are about the people you speak to and the audiences and those interactions. And some of the best ones I've had of those have been at much smaller conferences or ones where you kind of wouldn't necessarily thought of applying. So it's always a good idea to kind of cast your net wide.
Yeah, yeah. Absolutely. Some of the most fun ones I've been to have been small, but have been a room of absolutely like minds and it's been a blast.
Yeah. And that's the best thing, isn't that? When you feel you're amongst your people.
Yeah, yeah. Because a big part of speaking is about community, right? Just getting in touch with people you wouldn't otherwise find and meet.
So let's start there. What do you think the top reasons are before we even write an abstract? Why submit to a conference?
Ah, that's a good one. I think there's various reasons. So I think some people just have an urge to share what kind of they've learned or an experience they've had maybe from a teaching side of things. So before I joined Confluent, I was a consultant and as part of that role, I was a trainer. And I enjoyed sitting with people and helping them learn about something and seeing that light bulb moment when they're like, "Ah, now I get it. Great. I can go and do cool things with this particular piece of software." And I think that bleeds over into conference speaking, that same kind of, "Let me take a concept and explain it to you and that's going to make your lives easier, your job's kind of more fulfilling," the rest of it. So that's one reason, just kind of sharing and helping people.
Another reason is it helps you, one, understand something better, right? You can be as super good at something, but actually explaining it to someone else in words that kind of make sense is actually quite difficult. And it makes you realize all of the assumptions you've made in your head about how something works or kind of that you're not actually quite sure how a particular thing does work. And if you're saying those words out loud, you realize, "I need to actually dig into this a bit further." And you can do that other ways. You can do it by writing a blog about something. But actually having to utter the words to explain something exposes an awful of assumptions that we make in our minds. So that's the second reason.
Another reason is actually a very selfish one, which is to further one's profile in the community, to advance one's career. You'd be surprised how many jobs are got by people having been seen at a conference. Their name become known within a community and people are looking to hire someone, an engineer, a trainer or whatever. "Oh yeah. We saw that person speak at the conference. They're really good." And there might be a bunch of other really good people. But if you've been seen at a conference, that's kind of, they know that you're good at it. There's the proof on YouTube that you can speak, that you can deliver a story. So that's another reason why people might want to do it.
Yeah. The one thing in hindsight I learned a bit too late in my career is that people don't hire the best people for the job. People hire the best people they can find and being findable is actually a big part of the game.
Yeah. And also let's not leave off that list, it can be a lot of fun. You can have a lot more fun at the conference when you speak. Right?
Yeah. But I think it's also that... And maybe it's fun and that's maybe what kind of what got me into it was going to conferences and sat in the audience and you have the fun of being amongst the audience and kind of listening to someone. But thinking, "Actually, I want to do that." I'm not quite sure. I suppose it's the fun, but also the maybe proving one's self kind of, "I want to be doing that." So it is a lot of fun and immensely rewarding as well.
Yeah. I think there are often people who... Especially at the end when you're asked questions, there are always one or two people in the audience asking questions who you can tell are just itching to be up on the stage.
And those people should definitely apply. Okay. So with the motivation in hand, where do you start? Right? If you are looking around for a topic, where do you begin on writing an abstract?
So I think it has to be something you care about, something that you can... I don't want to say passionate, that word's kind of overused and we're talking about computers, you're talking about ones and zeros. There's only so much passion one can have. But enthusiastic should we say. So it's got to be something that you don't think, "Oh gosh, I've got to go and speak about this again." It's got to be something you think, "Ah, I found this really interesting. I kind went down the rat hole on this one or I built a project around this thing and now I want to help others understand what I did or I want to show off what I did because it'll kind of inspire others or I want to inform them about this thing." But it's got to be something that you are actually interested in.
So you might have a broad range of things and kind of just take your pick. Another good place to start if you're not sure, and sometimes talks just kind of not write themselves, but the idea just kind of comes out of you've maybe just done a long project. It's gone live. It's been great. It's a new thing. Great. Well, you've got a talk that you can write around that. "Here's how we built this thing. Here's how it's relevant to other people." But if you don't have that inspiration, sometimes it can just be, "Well, I'm going to go and write an introductory talk about this particular technology." And there aren't enough introductory talks. Everyone wants to be kind the cool kid at the conference doing the deep dive thing on this or the cutting edge technology that.
But a lot of people go to conferences to learn. They don't know about the thing already. And sometimes they know a lot about it and they want to know even more. And that's where the deep dives come in. But a lot of people go to conferences because they just want to kind of have that sheep dip experience of, "Here's this amazing set of technology. I want to learn more about it." And not enough people think, "Oh no, I'm going to write an introductory talk to it." So if you're stuck for ideas, think about something you're interested in. Think about how you would explain it to someone who's new to it. So it's not a training cost. You're not going to like, "Here are my slides. Here's your exercise book." It's not that. It's you're kind of chatting with someone, having a coffee with them, having a beer with them. I'm going to spend 15 minutes, half an hour explaining this particular thing that maybe they've heard of, but they don't actually know what it is. And that can be a great basis for a talk.
Yeah. Yeah. It's funny you mentioned talking in the pub. I was in the pub a couple of weeks ago with one of our colleagues and we got onto the subject of how git works and I realized I have a deep burning need to explain the internals of git to someone.
Don't we all?
Well, yeah, absolutely. So I'm going to have to turn that into a conference talk because I think I managed to line up my thoughts on that.
But that's a great example because lots and lots of people use it. I know lots and lots of people, myself included, don't really understand it. You know the kind of set of incantations to run to kind of make it behave and do whatever. I just end up wiping the folder and just recloning it and start again. But that's a really, really good basis for a talk. And it's one of those things that's so widespread, that would make a really interesting talk to do.
Peel open the black box.
Yeah, absolutely. So, okay. So if someone's found a topic, then you go to this blank piece of paper and any writer will tell you a blank piece of paper can be the most terrifying monster in the world. How you actually turn it into an abstract that's going to get accepted?
Gosh. There's almost as many blog articles about how to write a good abstract as there are conferences or abstract themselves. It's kind of, it's a rite of passage for some speakers to kind of, you go and read them and then you get on the conference scene and you do some talks and then you go and write it yourself because there's lessons learned. The funny thing about it is that people don't necessarily read these things. People have to make these mistakes for themselves. Some people do and that's great. You kind of shortcut a whole bunch of the process. A lot of people don't and they just kind of write a thing and send off and get rejected and eventually start refining it and kind of get to this point where you realize you've got to encompass within a fairly short number of words... Hopefully not too short, I hate it when conferences give you like, "Tell me what your talks going to be in 20 words," Because you can't really do that.
But equally it can't be too verbose because that's kind of too much to read. And I think you, Kris, something you wrote recently about the abstract's like your ticket to the conference because if you do a bad job on that, it's not going anywhere. It's going on the reject pile. So when you're writing an abstract, you've got to think of two people, two audiences. You've got the audience themselves at the conference. Your talk's been accepted. Brilliant. They're looking down the agenda. Which talk should I go to? So let's assume that it's a conference with more than one track. The title of your talk is going to be the first thing they'll look at and then the abstract. And the other audience is the program committee. So most conferences build up the program based on a program committee and a chair or whatever.
And how the kind of internal machination's work, they're going to take these abstracts and they're going to look through them. Does it fit what we're looking for in the conference itself? But also are people going to be interested in seeing this talk? Are they going to understand what the abstract's about? So if the abstract is too long, people are going to skim over it. "No, far too long. Didn't read it, ignore it." If the title's really boring, they're probably going to skip over it. Sometimes a talk can be so good that kind all the worst seven sins are forgiven because you know it's going to be good. But probably, I'm not being very constructive here. I'm saying here are all the things not to do.
But the worst thing that people can do is not spend time on that abstract. It's turning in your homework. You wrote it the night before and you didn't really make much effort and you assume, "Well, people will know what I meant anyway." And they won't because unless the conference is really undersubscribed, the conference committee is going to have a lot of abstracts to review. A lot of them are going to be extremely good. So if you've not made that effort and yours is kind of middling to low in terms of quality, it's just not going to make it the cut.
So you've got to spend lots and lots of time refining the abstracts. There's tons of good resources around how to do it. And there's a lot of people in the community willing to help you with your abstract. There's a real need to get kind of fresh blood and new speakers at conferences because otherwise you're seeing all the same faces and it kind of gets really, really boring, kind of singular. So it's important to take advantage of those resources. I'm on Twitter, you are on Twitter. I'm sure both of us would be more than happy for people to contact us for help with writing abstracts.
Absolutely. Being on the program committee was really eyeopening for me. With you, I was reviewing the abstracts for Kafka Summit London. And seeing the mistakes people make and helping them get past them is really interesting. So yeah. Doors absolutely open to help with that.
Yeah. And there's also quite a lot of simple things to do. And so working in developer relations, there's the risk of becoming kind of having blinders on when thinking about... narrow minded when thinking about conferences. For us conferences are kind of our world. This is what we do. We wake up, we write abstracts, we get on planes. We go to conferences. For a lot of people, and some of the best speakers at conferences aren't developer relations professionals. They're engineers, they're architects, they're practitioners. They're kind of all of the people actually doing this stuff that we are talking about. So they're actually out there doing the things and for them, they've got their day job and they're like, "Oh gosh, this abstract I need to make sure that I've written before the deadline tomorrow."
So I don't mean to sound kind of arrogant about, "Well, just spend lots of time on it," because it's not as simple as that. But kind of the key thing is do dedicate time to making sure it's quality because you can have as great idea as you want. But if you can't articulate it within that abstract... So I've gone massively off on a tangent here. I haven't actually said how to write an abstract.
But that's the opening thing, right? That whilst it's called an abstract, you don't want to be so abstract that you've not actually put any content in it. You've got to explain what you're going to talk about in a way that makes people feel that by the time you stand up on stage, you are the person who knows interesting things and can explain it clearly to people.
Yes, definitely. And I suppose one thing that we've not pointed out here is that most conferences have a call for papers, a CFP. But this is not academia. No one wants to see your paper. You're not actually writing a paper, delivering a paper. At this stage, all you need to do is that title and the abstract. If you get accepted, then you go and write your talk. But we don't actually have to write something at that point. And the terminology is kind of bled over from one field into the other. I think the key thing with how to write an abstract is think about what is it that you've got to say that's interesting to the audience. So a good conference talk isn't just the kind of, "Aren't I wonderful? I did this thing," kind of showing off. That's what you're write in your kind of your promotion interview. "This is why I should get a promotion." That's kind of really boring for anyone at aa conference to hear.
What it should be is, "Here's this thing we did. Here's why it's interesting to you." So if it's a report about something you built, presumably other people are building similar things or trying to solve for similar problems. So what have you learned that's going to help them in what they're trying to build? So are their kind of common patterns, are their common pitfalls? What kind of stuff would you have wanted to know beforehand? So framing your abstract in that way starts to make the program committee think that you're doing something other than just showing off and that you're actually going to teach the audience something. The audience reading the abstracting is going to think, "Hey, that sounds really good. We've got that problem also. I wonder how they solved it because hopefully I'm going to have something to take away from that."
The whole thing with conferences, people go there to learn. Maybe they go to kind of just enrich themselves generally. Like, "Here's a technology I've never heard of, I'm never going to use. But now I knew a little bit more about it. I've widened my horizons." It might be, "I need to learn about this technology because it's my day job. And I want to kind of dive even deeper into it." And maybe it's just like, "Here's a silly talk," and now I know how to kind of get a cat to sing the alphabet or something. But you've learned something. And that would be a great talk by the way. S the abstract needs to articulate, what is the audience going to get from this? Not like, what have you done? How big is your company? Blah, blah, blah. That's boring. It needs to be, what's the audience going to learn from thing?
Yeah. This is a tangent, but it's almost a bit a travel guidebook. The role of a travel guidebook is to tell you places you might want to be interested in going to and tell you what to look out for while you're there so that if you ever go on that journey yourself, your journey will be more successful.
Yeah. That's a great analogy. That's really good because here's the atlas, here's just the map of the country. Off you go. That's a great idea. Another one I had was, it's kind of different, but in terms of you've been on holiday and you've taken a thousand photos. And nowadays digital devices, taking a thousand is kind of on the lower side. But instead of going home and showing your mates, "Here's my thousand photos," and wade through them, instead it's like, "Here's the five or 10 things that were great. Here's my report from my holiday. And these are the great things." And each of those photos is going to be kind of the basis around which you can kind of expound on the particular thing and what you learned about it.
So it's kind of taking that kind of approach to a talk. Like I said, some talks aren't necessarily about projects you've done. They might be much more around a particular technology, something you want to do an introductory talk on or a deep dive. But the same kind of concept, the same kind of like, "Let's pick out some highlights. Let's do a travel book for it. Let's do a holiday photo report."
Yeah. I've done a fair few conference talks by now. I've found I'm usually happiest when I've written the code, solved the problem. Then I write an abstract and then if it gets accepted, I write slides. But I begin with the concrete content, then boil it down to 200 words and only then do I worry about putting a slide deck together.
I find that less stressful than writing the abstract about the thing I'd like to build. Then you've got two months to actually make it work and write a slide deck, which can be very stressful.
And it kind of works both ways. Sometimes it can be quite good to write the abstract, to challenge yourself to then, "Now I need to go and do it." But again, it depends on kind of, what's the purpose of the talk that you're writing? Is it something I built, telling you about it? Or is it kind of like, "This would be a cool idea," or, "Here's this problem." And if it gets accepted at a conference, then presumably other people have that problem or are interested in the solution. So now it's on you to kind of go and find out the solution.
So if we get into nitty gritty, let me see if you think this is fair because I've now reviewed quite a lot of abstracts for at least one conference. And I would say about half of them go straight in the bin. And then the other half, it's genuine competition to see, are you the best, most relevant talk for this? So maybe we should spend some time on the specific pitfalls that get you straight into the half that goes in the bin.
What are some anti patterns in writing abstracts?
So negative, isn't it?
Well, no, no, you've got to see it constructively. People want to know where they're going to fall off the road.
There's some very, very easy stuff which is use line breaks. You'll be surprised at... for Kafka Summit, we used a tool called Sessionize which is brilliant. And it gives you three abstracts side by side and it uses some kind of clever chess based algorithm to kind of... You keep reviewing these triplets of abstracts and it kind of works out relative to each other what the score is. But it shows you three side by side. And if you've got one which is beautifully formatted, one which is a single paragraph, and one which is an entirely dense block of text, you are already drawn to number one which is nicely formatted. I can see they've thought about it. They've given some care to it. And whether that's fair or not, that's how the human brain works.
Maybe I'm more fallible than others, but I'm not going to be bothered to read through that block. Or probably I am, but I'm going to be skimming. I'm looking for, what are the key points here? The person who's written a single line or paragraph, do they actually know what they want to talk about? Do they actually care about this? And again, rightly or wrongly I think people will read into the effort people to put into an abstract. Well, "How fussed are they even about speaking at the " So it could be, like I say, people are going to be excellent speakers. They've just got a day job to do and they've just rushed this abstract in. But you can't help, "If this is the effort that went into the abstract, what kind of effort are they going to put into the talk?"
A talk's harder.
If I'm on a program committee and we've got kind of a hugely oversubscribed program. And there's kind of only a third of talks that get submitted are going to be accepted, then am I going to gamble on this abstract here where the author hasn't made the effort they could do? Are they going to put the effort into the talk? Should I kind of sacrifice that slot on the program? So there are lots of exceptions to that. It could be, the one that's been laid out really nicely is maybe it's a developer advocate shilling their products. And it's like, "Well, no way." Kind of like, "That's obviously a product pitch. It's not going in the bin." Oh, sorry. "It is going in the bin. So now we look at these other two and read them in more depth."
But if we assume all three are equal interest talks, that's going to factor in. And so things like how you lay it out. Things like spelling, things like grammar. And it feels really patronizing to say so, but with tools like Grammarly, and plenty of people don't have English as their first language, I don't speak any other language, I'm embarrassed when I go to conferences abroad and people from the country that I'm in are speaking about deeply technical things in English. I'm just blown away. I'm embarrassed I can't do the same. But English is often the common language. So if you're submitting an abstract, use Grammarly or a similar tool, other brands are available, to go through and it will spell check, it will grammar check. And again, it's that level of care taken on abstracts which these things kind of add up. So those are two of the things that are kind of anti patterns I would say. What else is there?
Yeah. I'd say to boil that down, it's like rule one is good writing skills.
You absolutely have to write this to say you're writing a useful document.
That's what I could have said instead of the last five minutes rambling.
I'm just summarizing the great ideas coming out of your mind. Yeah. And it's funny. I found myself when I was reviewing non-native talks... I think we are both British, right? And we are as a nation terrible at foreign languages. I think fairly forgiving, grateful even about other people speaking our language. So when you get a submission in that's not grammatically perfect from a non-native speaker, I don't think that counts against it at all. But it's worth running by a native speaker before you press submit, because it can just smooth out the paragraphs.
It's one of those things that I would love to say that I completely agree. And if you can see that they're, I don't know, from mainland Europe or wherever else and English isn't their native language, you would forgive grammatical errors. But in practice, you're challenging a lot of things here, but in practice, I think the tools are out there and Google docs will tell you your grammar and your spelling that I don't know if everyone would actually go and look, where's the speaker from? Is English their second language. Okay. Do I give them a pass on that grammatical error? And given the tools are out there, it's this game of numbers. So what are all of the things you can do to stack the odds in your favor? And this is one of them.
And bad grammar is not going to get your abstract on the reject pile, but it's not going to put it on their, "Yes, we've definitely got to have that there pile." It's going to kind leave it in the kind of like, "Okay, let's see what else they've got to offer." So you should always be thinking, "How can I basically play the odds, play the game here?" And it is a game it's very much kind of, you've got humans on the other end of the screen looking through these abstracts and a lot of the time they're judge blind anyway. So you can't even see, where's the speaker from? It's just, here's the text.
So it's kind of one of those things like it's just being pragmatic. The tools are there, use them to give yourself kind that extra edge over other speakers who aren't using them.
Yeah. Okay. To temper all this in case anyone's scared, I will say if you are reviewing all the abstracts that come in for a conference, you will get someone who submits title Stuff With Kafka Streams. And then the content of the abstract is, "I will talk about strems." And you're whatever you do, you're going to be above that guy. There is a whole slush pile you can easily climb above with some decent writing skills.
And that's a great point because I don't want to make it sound like I'm being patronizing, like the whole thing's this super intimidating thing. It's just trying to kind of get across this point that it is a game. And if you want the inside track on it, here are some of the top tips. But any good conference should be going out of its way to encourage and welcome new speakers. So for Current, for Kafka Summit, we do speaker office hours where you come along. You bring your Google Doc. "Here's my abstract idea or here are my ideas for a talk. What do you think? Give me some feedback," before it actually gets put into the submitted into the call for papers.
So that's the kind of things that Kafka Summit, that Currents are doing. Any good conference should be doing something similar to help and encourage new speakers. So it absolutely should not be a daunting thing. New speakers should always be kind of wanting to do this because it's great for them and also great for the community. But there is a game to play. So here's the kind of the inside knowledge that'll help you on that game.
Yeah. And it's worth dwelling on that because I don't think I've ever seen a conference put in as much effort on helping people with their abstracts before the submission as I've seen you organize. I've got to tip my hat to you. You've put a lot of effort into trying to give people feedback before they submit, give people feedback once they've been accepted and give them feedback if they were rejected on why it went badly. You've done a cracking job on that.
I've taken inspiration from other conferences. So I think it's Baron Schwartz on the USENIX conference, the LISA conference, did office hours and I found that really useful. I know Daniel Bryant has offered on Twitter to kind of help review abstracts for people. So there's a lot of people who follow me who have kind of set the tone for as a community, as a broad tech community, we should be encouraging people into it. So wherever I can replicate that and kind of help that happen, I'm kind of happy to do so. But other conferences, good conferences should be doing the same also.
Yeah. Okay. There's one other tip I thought we should discuss which is which I saw a lot in the submissions, which is some people are too abstract. They get too vague and you get to the end of the abstract and you don't know what they're going to talk about. And some people go too far the other way and they try and basically cram the entire talk into 200 words.
Have you seen that? And is there a sweet spot? Is there a way to find that?
We're definitely getting into... I like the kind of, the base that you set. Some people submit an abstract that is just kind of you've not even tried. You've let the cat run across the keyboard and you hit submit. So we're definitely up into kind of here's how you're going to really refine things. You've got to give enough information in the abstract that shows you know what you're talking about as in you are certainly qualified to be talking about it and that you have something concrete to offer in the talk. But it's not just going to be you stood on stage waving your hands like this for half an hour. So you've got to do that. But equally, like you say, I think I remember the last time someone actually submitted a code sample as part of their abstract. So that's probably taking things too far the other way.
Yeah. So you need to set the tone that you qualified and you thought about what's going to be in your talk. But you don't need to go into the actual code samples. So for example, someone says, "I want to talk about lessons learned from running Kafka at mega scale at ACME Corp and we're using Kubernetes, whatever. The end." And you think, "Okay, that's interesting. There's lots of other people doing that. So it's probably going to be interesting." But someone else who submits a similar talk saying, 'Okay. We're going to talk about running Kafka at mega scale, blah, blah, blah, and this other company. And we're going to talk about how we handled multi gate center replication. We're going to talk about how we handled failover. We're going to talk about how we handled blue green deployments. They're not going into kind of the nitty gritty of how they actually did these things, but they're calling out the level of topics that are like, "Okay. That's definitely interesting."
So maybe both submitters are actually speaking about running Kafka at scale at Mega Corp. But one's just saying, "We're going to talk about it." The other one's saying, "We're going to talk about it and we're going to go into these particular areas," that makes you think, "Okay, they've definitely got something to say and they've thought about it. They've not just said, 'Okay, there's this conference coming up and it would be great to go and do a talk there. We'll chuck an abstract in, and then we'll figure out what we're going to say later," because the program committee on behalf of the audience wants to know that they're actually going to do a good talk. And you're looking for all these different kind of indicators and proxies. And one of them is, have they thought about the next step beyond Kafka at scale? Just cause you're in Kafka at scale, loads of people are doing that. It needs to be more detailed as in, well what are the considerations when you are doing it at scale? What are the particular areas?
Yeah. Yeah. Just pin out pin down the topics if but without actually writing the topics.
Yeah. Yeah. Again, it's a travel guidebook. You got to pin down some specific things you'll see, but you don't list the entire contents of each museum.
Exactly. Exactly. Yeah.
Yeah. Okay. So if we move on from the abstract now, do you think there are specific things you need to know after you've been accepted and perhaps after you've been rejected? Where should you go in both of those cases?
Actually, there's one more thing I'm going to say on submitting abstracts-
Oh, sure. Yeah.
... if I just rewind ever so slightly. And that is reuse talks. When people are new to it, they think, "But I put this talk in, I did this talk last year. I can't possibly reuse it." Maybe reusing a talk for the same conference probably isn't going to be particularly interesting unless it was an absolute [inaudible 00:36:04] thing last year and they definitely want you back. But generally people don't go to lots and lots of conferences in an audience. And if they do, there's lots of tracks. They're going to watch of different one. So you put all of that effort into a crafting an abstract and you got accepted and you wrote a talk. Capitalize it, make use of that. So don't ever be afraid of resubmitting abstracts and talks. There's definitely nothing wrong with that.
Yeah. When I first got into doing this, "I thought once I've given a talk, that's it. Everybody's heard that talk so I have to bury it and put a new talk on." And now, I only dream that I give a talk and it actually gets to every developer in the world.
And the reality is nearly no one's heard you.
Yeah. And you think, "Oh, but it's on YouTube." Well, okay. Lots of stuff's on YouTube. Right? I've now watched half the things that you've put on YouTube, much as I wish I had done. So even if it was recorded, even if it was on YouTube, even if it's had 10,000 views, it's like, "Okay. There's another kind of five million developers out there who haven't seen it." So many, many, many people at conferences will not have seen your talk. So submit it. I would always reuse talks until it becomes stale and irrelevant. If you're doing a talk about, I don't know, something-
Right. Right. Absolutely. Or Haskell or something like that.
Oh my God. That's it. You're booted off the show.
Moving swiftly on.
Moving very swiftly on. Yeah. But if you believe in the topic, it's worth taking to other audiences, right? Yeah, yeah, absolutely. So with that in hand, that does take us into what you do with the talk. The world of actually, "Oh God, I've been accepted. What do I do now?" I don't think we should get into public speaking skills, but there any general conference tips you would give people?
And I'm going to shamelessly plug my blog here. I've written a bunch of articles. I'll put them in the show notes, but one's like preparing a new talk. One's all about writing abstracts for conferences and stuff like that. So we'll put those in the notes. But in general, start writing it earlier. In the same way that kind of everyone has this bravado about, "Oh, I submitted the abstract the night before it closed or I was writing my talk on the plane on their way to the conference," people do that. That's fine. Some people do really well at that. Some people, you watch them on stage and you can tell they wrote it the night before. And that's not a good thing.
So I would say start with your abstract and remember what you promised that you were going to talk about, which is what your abstract is. That's what you're promising to the program committee, to the audience. "This is what I'm going to talk about." And build it out from there. So think about kind of... Because oftentimes the gap between, "Here's this idea. I'm going to submit it for a conference," and the conference itself, maybe it's nine months out. Sometimes it's quite a long lead time and you get accepted. Maybe it's, I don't know, seven or eight months out.
By the time you think, "Oh gosh, I really do need to crack on with writing that talk," it's probably quite a long time since you had that original inspiration, "Ah, now I'm going to go and tell the world all about this amazing thing called Haskell or something that." So remember what you said you'd talk about and don't kind of do a different talk because that's going to really disappoint the audience if they rock up thinking they're going to get a talk about something and it's not. Maybe it was a really good talk, but that's not what you said you were going to do.
Yeah. Yeah. You can't bait and switch people.
Exactly. Exactly. Sometimes there's nothing wrong with a slight little stretch of what you said you were going to talk about. So let's go back to that example of Kafka at mega scale. And in your abstract, you said you're going to talk about, what did we say? Multi gate center and something. I can't remember the three examples I gave. Let's say one of those things actually, I don't know, maybe a company's not happy. You kind of talk about the details of what you did there but actually found this other thing. People in that talk are going to be interested in running Kafka at mega scale. So long as you give them brilliant Kafka at mega scale, that doesn't matter so much. But if you start saying, "Here's how we manage that Kubernetes cluster," and nothing about Kafka, that's not what you promised.
Yeah. One thing I always do with slide decks is I always put as the first slide, I put my abstract in there and then I set it so it won't export. Depending on your slide deck, your mileage may vary. But I do that because it keeps me focused and honest as I'm building out the slides.
Yeah, no, definitely. And using the abstract, and most presentation software let's you do that, it's kind of like having an outline view and you could actually take your abstract and actually split it up into different bullet points within that and then start fleshing them out. And it depends there's. And like you say, public speaking, it's a whole other podcast in itself.
We should have one on that.
We definitely should.
But, okay. So yeah, it's a lot about the slide decks. And we have disagreed about slide decks, right? Because we were having a debate about, you are quite hot on super simple, image rich, not too much text slide decks. And I agree with you. And at the same time, the slide decks I write that I'm happy with tend to have a lot of text and a lot of code samples. But you said something about that which is like, as long as you really care about the end result, that's more important, if you've invested yourself in it. Right?
Yeah. And it definitely is that. And people can read the blogs and I kind of write quite bluntly and kind of quite opinionated. But if you've read that and have thought it through and disagree with it, that's fine. Or even if you've not read it, but if you thought through, "What am I doing here?" But the reason that I end up writing those blogs is I'll have just been to a conference. I'll have finished reviewing a bunch of abstracts or something. It'll be killing me how many people repeat the same basic mistakes. It's like, "Right. I've got a blog about this."
So things like their slide is their talk. This is kind of the number one thing. And it's almost kind of trite. But if you put your slide as your talk, "Here's all this text, here's all these things. Here's all the points that I need to express," people are going to be reading that instead of listening to you. What's the point of you stood on the stage reading out your slide if they could just read your slide? So a lot of people build their slides in a way which would make brilliant takeaway pack, right? When someone says, "Can I have these slides to download later," that's what you want to share because that's brilliant because they don't actually need you on stage telling you this thing that you want to tell them. But if those are your slides on stage, there's got to be a good reason for you to even be there in the first place. Now, if you've been through that and you think, "Well, actually Robin's speaking complete codswallop because here are these great reasons why I'm going to have lots of text on my slides." Go for it. That's great.
There's always many exceptions to any particular rule. It's kind of like I'm always banging on about schema registry in Kafka. I'm like, "You've got to use schemas because schemas are super important. They're the API between your services and so on and so and so on." And someone will disagree. I say, "That's fine because you've thought about it." It's just that most people don't. They're like, "I'll use CSV or I'll use JSON something." And then it bites them later on.
But if you've got a really good reason for, "This is why we are going to use JSON. We're on the Streaming Audio Podcast. We need to talk about Kafka." So if there's a good reason to do that, fine. And it's the same thing with abstracts. It's the same thing with your presentation decks. If you've got a really good reason for doing it a particular way and it works for you and it works for the audience, go and do it. I suppose it's kind of just providing a starting point for people who are brand new to all of this. Give them something to start from and then tinker with as they want to. But it's not an absolute set of rules definitely.
Yeah. I think that's a great explanation of why programmers should be opinionated, right? Not inflexibly opinionated, but if you've really thought about something and you... Again, don't want to overuse that word passion. But if you really believe that this is the right [inaudible 00:44:13]. Because I'm going to digress now, I think one thing you see with writers and artists, they all when they're really mature as writers and artists, they end up with an opinion about how writing works or how art works. Hemingway's a really good example of someone who really had, "This is how you do writing," in his head. And he wasn't right. But he was right for him. And he'd spent a lifetime developing that way of seeing the process, the craft, the art. And I think that everybody who gets to a high end in what they do ends up with a very personalized interpretation of what this thing they do is.
So yeah. Yeah. Get to that point where you have strong opinions about how slide deck should be built. And if you're not there yet, read Robin's blog.
I suppose it's like any programmer is always looking for patterns to repeat, aren't they? Instead of reinventing the same thing each time, this is what I've done before and it's worked. So I'm going to take that. I'm going to build on it. And it's the same thing with these things. People have been through these process and learned it themselves or started from somewhere and built on it. So now let's share it with other people. But it's always a starting point from which to kind of make your own journey.
So maybe we should wrap up by teasing that public speaking podcast. If you want to leave people with one tip for what to actually do when they're on stage, what's your best tip?
Enjoy yourself. Which is really annoying, isn't it? Because it's hard to enjoy yourself if you're nervous as heck, whatever. But people in the audience want you to succeed. They want you to tell them something interesting. They want to enjoy themselves. And I found the best way to do that is to enjoy yourself. And behind that is you enjoy yourself by knowing what you're talking about back to front, by having practiced and practiced and practiced out loud. Record it on a webcam, do it in front of a mirror. Don't just read your slide deck. But actually be able to walk away from your laptop, walk around the stage, just kind of enjoy yourself. And the audience will enjoy that. And it can be an awful lot of fun.
Yeah. It can be a true source of joy for everyone involved. And that I think is both the right note to end on and one of the big reasons to do it in the first place. Right?
Cool. Well, Robin, we're going to put links to the show notes for anyone who wants to take advantage of your abstract writing clinics.
Definitely. That sounds good.
And I'll be joining in with that. So we'll have a lot of fun. Thank you very much for joining us. And we'll have you on the show again.
Kris, it's been a pleasure. Thank you.
Cheers. And that's a really nice note to end on, fun, because being part of conferences and sharing the things that interest and excite me about this technology world, they've genuinely been some of the most fun moments of my life. I know public speaking isn't for everyone, but if you are tempted, I really hope that helps you get started. And if you're already doing it, I hope it ups your batting average and you get involved more often. If you found it useful, now is an excellent time to click or thumbs up or leave a review or whatever your podcast user interface offers you by way of feedback. We'd love to hear from you. And of course you'll find Robin's Twitter handle and mine in the show notes if you want to get in touch. You're also going to find in the show notes and links to Robin's blog posts about this topic if you want even more information and more advice. He's a font of it
For more information on Kafka itself, head to developer.confluent.io, where you'll find everything from high level overviews of what Kafka does well to deep dives into the technology that makes it happen. And when you need to get Kafka up and running, take a look at confluent.cloud, which is our fully managed Apache Kafka service. You can get started in minutes. And if you add the promo code PODCAST100 to your account, you'll get $100 of extra free credit to use. And with that, it remains for me to thank Robin Moffitt for joining us and you for listening. I've been your host, Kris Jenkins, and I will catch you next time.
A well-written abstract is your ticket to conferences, but how do you write an excellent synopsis that will get accepted? As an experienced conference speaker, Robin Moffatt (Principal Developer Advocate, Confluent) often writes presentations that help the developer community to understand Apache Kafka® and its ecosystem. He is also the Program Committee Chair for Kafka Summit and Current 2022: The Next Generation of Kafka Summit. Having seen hundreds of conference submissions, Robin shares best practices for crafting abstracts that stand out, as well as tips for speaking at conferences.
So you want to answer the call for papers? Before writing your abstract, Robin and Kris recommend identifying a topic that you are enthusiastic about, or a topic that can be useful to others. Oftentimes, attendees go to conferences to learn about a given technology, which they may not have extensive knowledge of yet—so a fundamental topic is a good basis for a conference talk.
Once you’ve identified the topic you are interested in, there are key components to an effective write up:
It’s essential to spend quality time writing and refining your abstract, while keeping two audience groups in mind—the program committee and the conference attendees. Robin shares that when reviewing submissions, the program committees have a few standards in mind, such as if the topic fits into the overall conference theme, and whether attendees would be interested in the talk. Then if the abstract is accepted, the attendees themselves will decide if they’ll attend a particular session based on the agenda and the brief.
Robin and Kris also discuss why you should submit to a conference in the first place and also give tips for preparing your talk once you are accepted. If you are a new speaker or just someone interested in getting feedback on your abstract, Robin and the conference committees for Current 2022: The Next Generation of Kafka Summit will be hosting office hours to provide feedback.
If there's something you want to know about Apache Kafka, Confluent or event streaming, please send us an email with your question and we'll hope to answer it on the next episode of Ask Confluent.Email Us