The Call for Papers (CFP) for Kafka Summit London is now open, so I’m here to encourage you to consider sharing your Apache Kafka® expertise with the wider community.
The process of submitting an abstract and crafting a technical talk can be intimidating, but it doesn’t have to be. Whether you’re new to delivering technical talks and have no idea where to start or you’re a seasoned conference speaker with a bit of writer’s block, know that finding content to speak on at Kafka Summit only takes a few easy steps.
You may be asking yourself, “What would I even talk about?” Well, Kafka probably, but what specifically? A Kafka-related technical talk can cover so many things from a wide variety of perspectives, including (but not limited to):
There is no shortage of things to talk about, and it all starts with what you know. Regardless of where you are on your personal learning journey with Kafka, each project and experience is an opportunity for you to impart some worthwhile sage wisdom to the community.
Revisit a recent project you’ve put together using Kafka. Think about the last time you spent some time diving into a specific aspect of the codebase. Look at the journey you took from a complete beginner to where you are now. And after all of that, ask yourself what you achieved and if there was anything you wish you’d known going into it.
Whatever you decide to talk about, when you sit down to describe your experience, make sure you go back to the beginning. Take time to clarify the why behind your presentation. Cover your motivation behind the project, when you decided to look into that KIP, or how you got into using that specific tool. Discuss the hiccups, the challenges, and how your audience can avoid making any mistakes you might have made.
With an idea of what you want to talk about in hand, you can begin to write your conference abstract.
Great talks (and ones that are likely to be accepted for conferences) are ones that tell a story, and stories have a structure. A good technical story will engage the audience from the beginning, and the beginning is usually the “why?” Why did we need to do this? What was the problem being experienced that we wanted to solve?
Then they introduce some drama or challenge that makes the storyline interesting; the unfolding drama is usually the “how?” How is the solution implemented? How can you do this yourself? Finally, they offer a resolution that the audience cares about, and that’s usually the “what next?” What can we do now that we have this knowledge?
And on the subject of gaining knowledge…
Remember, the overall goal of a technical conference talk is to impart knowledge. The story that you tell as part of your talk isn’t enough on its own; attendees need to get something out of the talk and feel that the content relates to them.
Your experience migrating from a monolith to a Kafka Streams application within your company’s legacy system isn’t particularly useful unless you make it applicable to folks outside of your company. Are you open-sourcing the tool you needed? Great. If not, can you summarize your journey with a list of tips and gotchas that apply to anyone starting on a similar project?
Outlining a KIP that you found interesting is good, but boiling it down into how the KIP will change how attendees use Kafka is far better.
Describing the tools in the Kafka ecosystem might be helpful. Explaining when you’ll need them and how they’ll solve attendees problems guarantees it.
The best way to ensure that your talk is relatable is by reaching out for feedback. Colleagues are a great place to start; ask them if your abstract covers the key highlights of your project. Check in with members of the community and ask them their thoughts. And finally, search out and attend conference-hosted office hours to make sure your content is in line with what the program committee expects for the conference.
Let’s not lose sight of the idea that sharing your technical knowledge should be fun. After all, this is your opportunity to share your story with the wider community. It’s your chance to be on stage, to engage your audience, and inspire and encourage them to use the technology.
Conferences are meant to be a net positive, enjoyable experience for everyone involved. You’ll feel a sense of accomplishment for what you’ve created, session attendees will benefit from your shared knowledge, and at the same time everyone will have the opportunity to connect and build out their networks.
If you haven’t presented at a technical conference before, the process of distilling experiences down into a technical talk can be intimidating. But every great conference talk starts with an experience––a project, a deep dive, or a new way of doing something.
Get out there and write what you know. Tell a story. Give people a chance to learn.
And if you need any assistance….