on meetup talks
I recently gave a talk at London Microservices User Group meetup - video here.
These are some rules I tried to live by:
- who’s the audience?
- what’s your story?
- what’s the learning?
- get feedback.
- don’t be scared to not know.
- don’t be scared to share what you know.
who’s the audience?
Know who you are talking to. Whatever the subject of the talk, make sure it’s appropriate for the venue and group that you are talking too. Go along to a few of the meetings, watch some videos from previous events, find out everything you can in advance.
If this means that you have to do a little more (or less) explaining of core concepts then go for it! Your audience can so easily switch off if you go too fast, or too slow. Developers and audience members can be rude - don’t take it personally if they all appear to be on laptops, they are probably tweeting how awesome you are!
There will be a mix of knowledge, but ensure you pitch it right and you’re setting your self up for a win.
what’s your story?
Some of the best talks I’ve seen have a story, they are about experiences. Add a story to your talk, a flow that leads segments into each other. This becomes easier if you throw in personal experience; mine was about the introducing a new language where I work, and the things involved in that - making sure not to skip over the gotchas!
what’s the learning?
Who’s learning from your talk? Ultimately you are trying to share something that you know, something interesting to your audience, something they might not necessarily know. Some of the best go talks, the ones that you see at big conferences like gophercon talk about really simple concepts, but in ways that you might not have seen them before. Innovative ways to use functions, or errors, or nil that you might not have come across before.
Whether you’re on the core Google Golang team, or not; you’ve got something interesting to share about your technologies and practices! The last point on learning is that the learning is not just for the audience members, two of the best ways of learning something are:
- trying to teach it to someone else
- revisiting the basics
Covering the basics, and breaking down the topics in your head to deliver in byte sized chunks is a useful experience alone!
feedback
Feedback is so important, and it shouldn’t just come after the event. Get the thoughts of others before; if you are talking about a work related subject, get the thoughts of your colleagues.
No one expects you to be able to produce the perfect slides and talk right off the bat. Find out what your peers think and iterate and improve based on that. Treat this like every other peer code review
I have a great team who were able to give really good points on areas we could improve in the slides and presentation. Find your version of that.
you don’t need to know everything
Don’t be scared to not know. There are always people that know more on a topic than you do (and those that you know more about than they), embrace this. You are talking about a subject you know, an experience you had. This is your home ground, but you aren’t going to know everything, and that’s fine. There will be people in any audience who know more than you about something. Everyone knows more about something than you. That’s a great thing. If you can always surround yourself with people that know more than you, you’ll always be learning. Take advantage of the people who are willing to share with you what they know.
you know a lot
You might not know everything, but you are on your terms, your subject, your area. Don’t be afraid to share what you know, talk about your experiences, and they don’t all have to be positive.
Positive and negative experiences are both valuable. Doing things right is awesome, woo go team 🎉! But doing things wrong can be more formative. Talking about what went wrong makes it real. It also makes you relatable. If you can tell others where they might trip up before they do, that’s useful!