Skip to content

How to be a good conference talk audience member

I recently attended a conference and was both a speaker and audience member. It was on the smaller side; there were probably a few hundred attendees and the audiences ranged from about twenty to hundreds of attendees for the keynotes.

After one of the talks, a speaker came up and said “you were such a good audience member, thank you!”. I said the same thing to one of the attendees of the talk I gave.

I wanted to share how you can be a good audience member at a conference talk. It’s important to note that this advice is for attending in-person talks where the speaker can see the audience. This is typically when there are up to one hundred people. I’ve spoken in front of 800 people and it’s a different experience. While some of these principles apply, in general individual behavior is less important as audience size grows.

And online talks are an entirely different experience for everyone, both audience and speaker! I don’t have enough experience to give any advice for that scenario.

First, though, why would you care to be a good member of an in-person audience? After all, you are providing your time and money to the conference and the presenter. Isn’t it the speaker’s job to entertain and educate you? Why would you expend any energy to help them do so?

First, I’m a big fan of being respectful of other human beings and helping them succeed. Public speaking is a common fear and being a good audience member can reassure the speaker and reduce that fear. It’s hard up there, whether it’s your first talk or your hundredth.

The second reason is that you can make a talk better for yourself. You can learn more and you can tune their presentation to your needs. They are an expert and you can take advantage of their expertise.

So, here are my tips on how to be a great audience member:

  • First, remember that you don’t owe the speaker your time, but you do owe them respect. If you aren’t interested in the talk, if it isn’t what you thought it would be, or if you have another commitment or pressing issue to address, leave the room. Don’t make a big show of it, but get up, walk quietly to the door, open it carefully, and depart.
  • Since you’ve decided to stay, pay attention. Silence your phone. Turn off your computer. If you want to take notes using your laptop, disable wifi so you won’t be distracted.
  • When you understand and agree with something, nod and smile. This feedback provides the speaker a signal that they are reaching you.
  • If you don’t understand, frown or make a questioning face. No need to harumph, but give the presenter feedback that the topic is confusing or that they haven’t made their point clearly.
  • If you have questions, ask them. Speakers should inform you if they want to be interrupted with questions during the talk up front, but if they haven’t, a polite hand raise should be acknowledged. If it isn’t, save your questions for the end.
  • When asking questions, realize you may not get a complete, satisfactory answer. If you don’t, I’d avoid a secondary question. Instead approach the speaker after for a more in-depth discussion.
  • If you didn’t like or understand the talk, give that feedback to the speaker afterwards. No need to be rude, but saying something like “I wish you’d given more background on <X>” or “It seemed like you skipped over the complexities with <Y>” will help the speaker improve their talk.
  • If you feel moved to do so, thank the speaker afterwards. This is not required but a talk is a lot of work and any feedback is usually welcomed.

Am I always a good audience member? Nope.

I get distracted sometimes.

But when I follow my suggestions above, I learn more from the expert on the stage.

Ask for no, don’t ask for yes

I think it is important to have a bias for action. Like anything else, this is something you can make a habit of. Moving forward allows you to make progress. I don’t know about you, but I’ve frozen up in the past not knowing what the right path was for me. Moving forward, even the smallest possible step, helped break that stasis.

One habit I like is to ask for no, not yes. Note that this is based on my experience at small companies (< 200 employees) where a lot of my experience has been. I’m not sure how it’d work in a big company, non-profit, or government.

When you have something you want to do and that you feel is in scope for your position, but you want a bit of reassurance or to let the boss know what you are up to, it’s common to reach out and ask them for permission. Don’t. Don’t ask for a yes. Instead, offer a chance to say no, but with a deadline.

Let’s see how this works.

Suppose I want to set up a new GitHub action that I feel will really improve the quality of our software. This isn’t whimsy, I’ve done some research and tested it locally. I may have even asked a former colleague how they used this GitHub action.

But I’m not quite sure. I want to let my boss know that I’ll be modifying the repository.

I could say “hey, boss, can we install action X? It’ll help with the XYZ problems we’ve been having.”

If you have a busy boss (and most people do), this is going to require a bit of work on their part to say “yes”.

They’ll want to review the XYZ problem, think about how X will solve it and maybe do some thinking or prioritization about how this fits in with other work. Or maybe they’ll want you to share what you know. It may fall off their plate. You will probably have to remind them a few times to get around to saying “yes”. It might be a more pressing issue for you

Now, let’s take the alternative approach.”Hey, boss, I am going to install action X, which should solve the XYZ problems we’ve been having. Will take care of this on Monday unless I hear differently from you.”

Do you see the change in tone?

You are saying (without being explicit) that you “got it” and are going to handle this issue. The boss can still weigh in if they want to, but they don’t have to. If they forget about it or other issues pop up, you still proceed. This lets you keep moving forward and solving problems while keeping the boss informed and allowing them to add their two cents if it is important enough.

You can also use this approach with a group of people.

By the way, the deadline is critical too. Which would you respond to more quickly, if it was Jan 15, all other things being equal and assuming a response was needed?

  • “I’m going to do task X.”
  • “I’m going to do task X on Jan 17.”
  • “I’m going to do task X on Feb 15.”

I would respond to the second one, which has a deadline in the near future. I think that is the way most folks work.

Again, pursue this approach for problems you feel are in the scope of your role but that you want to inform the boss about. It’s great when you want to offer a chance for feedback, but you are confident enough in the course of action that you don’t need feedback.

Management is not leadership, leadership is not management

I’ve been a leader in one way or another through much of my career, and I’ve also been a manager of teams as well. Management is, in my experience, focused on organizational goals. It’s hierarchical. you need to manage up, but also take care of those who are below you.

Leadership, in contrast, is focused on personal goals. In some cases they may be related to the organization’s goals, and in the workplace there should be significant overlap. But when you are leading, you are walking the fine line between taking people where you want them to go and finding out from them where they want to go. You aren’t commanding anyone and if you aren’t interested in the goal, you probably aren’t leading progress toward it. Leadership is nowhere near as hierarchical as management.

Here are two examples of leadership from my career.

Perl code formatting guidelines

I worked at a consulting company in the early 2000s and we wrote a lot of perl. If you’ve heard of perl, you might know it is often called a “write-only” language because there’s more than one way to express anything. I noticed that we were not standardizing our perl code across projects, and a lot of knowledge wasn’t being shared.

I mentioned this issue to my manager and said I wanted to write some coding standards. While I was a junior engineer, I worked with my manager and perl engineers. I wrote a preliminary draft, then shopped it around and got feedback from other team members. At the end of the day, I had a working document that all teams could live with and that would help us avoid silos of perl coding idioms.

Notice what this involved:

  • seeing a problem
  • working with others to scope it
  • putting a solution together
  • getting feedback

But it didn’t involve:

  • hiring
  • firing
  • giving feedback to anyone
  • coercion

Even though this task had aspects of management, in particular the coordination and communication, it wasn’t management. Instead, it was me picking a goal (“coding guidelines to share knowledge across teams”) and working toward it with others. In other words, leadership.

Hackfests

I have written before about hackfests, but they are one of my favorite things to introduce at a new company (I’m at three and counting).

With a hackfest, I want to foster communication across departments, have fun, and offer a chance to help folks poke their heads up out of their day-to-day.

In each of these companies, I talked about hackfests to both the senior management and other employees to build support. I adjusted specifics about the hackfest (frequency, length, topics, format) based on the feedback. At most of these companies, I was one of the more senior technical employees, but I still built support for the event.

I also scheduled it and did some of the grunt work that goes along with any event, including educating folks on what the point was, emceeing the presentations, following up to get it on the calendar regularly and more. I even occasionally “rang the gong” when my bosses’ presentations ran long.

Fostering leadership

So, should you want to foster leadership within your team and organization? This seems like a no-brainer, but I still find it helpful to examine why.

Leadership, in the form of picking a goal, organizing work around it and delivering it, is critical to scaling an organization for so many reasons:

  • Lets people work together toward a goal without a “manager” around to give them instructions.
  • Is training wheels for management, but can be done by people who are not managers.
  • Can be “tried on” easily. It’s easy for someone to be a leader for one project or aspect of a problem and not others.
  • Pushes decision making closer to people confronting problems.
  • Builds a scalable culture.

You can foster leadership in your team or organization by:

  • Allowing for autonomy and space. It’s easiest to be a leader for a task you care about, but even the most passionate person can’t lead if they are overclocked in the day to day.
  • Encourage communication between teams and employees. Collaboration often offers areas for “bite-sized leadership” opportunities.
  • When someone steps up and takes a leadership role, don’t hand it off and forget. Check in and follow up. Delivery is a key part of leadership, as is accountability.

Just make sure that the projects that are chosen are at the intersection of the desire of the leader and the needs of the organization.

Options for scaling written content as a devrel team

If you are in developer relations, creating content is often a big part of your job. Written content is one of type of content, and a common one at that.

Written content scales well, is easily updated, can be consumed on readers’ schedules, is fairly accessible, and can be reused. It also can serve as a foundation for other kinds of content, such as talks, example apps, or videos.

At FusionAuth, I’m part of a team that creates a lot of written content. I wanted to talk about a couple of ways you can scale written content creation. Note this focuses on creating more content, but don’t forget to write the right content, which is more important than sheer volume. (That’s a whole other blog post, though I feel a bit like Fermat even mentioning it.) This post also assumes you can’t hire more in-house talent, either because of budget or because finding good devrel folks is really hard right now.

Re-use

First up, re-use your content. You can take pieces and use them in different ways. For instance, write a great piece of long form content. Then, pick a few of the most interesting paragraphs or sentences, and share those in Twitter or on other social media. You can also use these excerpts as fodder for comments on online communities or forums, if they answer a question someone else is asking.

Finally, you can also combine articles. For instance, I lightly edited a number of articles, wrote a few pieces of original topical content, and ended up with an ebook about outsourcing your auth which has been useful to share with readers and possible FusionAuth prospects. The effort was far far less than if I’d set out to write a full book on the same subject.

The next two options require increasing amounts of money, so if you only have your time to spend, focus on this option.

Find freelancers

The next option is to find freelancers or community members who are willing to write articles. At FusionAuth, we paid money for these posts, which is typical. Our rates were between $0.25 and $0.50 per word, typically including an example app that we would host in our GitHub organization and open source.

Thee downsides of freelancers are:

  • it is hard to find good ones. I did find a couple who delivered multiple good posts, but they are few and far between.
  • you have to manage them and their delivery. This can include extensive editing depending on skill level.
  • you have to give them an outline. While I tried to get folks to ‘pitch me’ with interesting ideas, that didn’t turn up much at all.
  • they are not going to know your product or space as well as you do.

If you are larger, you might be able to pay less because it’ll be more of a plum for authors being published and associated with you, but you should pay something. Developers know the value of good content.

You may also highlight articles written by someone on their own blog, but that isn’t your content and You won’t be able to re-purpose it. You could, I suppose, reach out and see if the authors would be okay with you licensing it. Haven’t done that myself; I prefer to keep it simpler and share whatever someone writes about FusionAuth.

Content agency

The final option is to hire a content agency. The active ones that I know of are draft.dev (disclosure, FusionAuth is a current client), Ritza, and Hit Subscribe. (I am sure there are others.) These agencies have different strengths and approaches, but they all take some of the management burden off of you. Often you can come to them with just an idea and they’ll build out a content brief (an outline), find someone to write it, and do an technical editing pass before delivering it to you.

These are great if you want technical content frequently. It is also fantastic if you want posts written about technologies that aren’t in your wheelhouse.

For example, Joomla is used across 1.7% of all sites on the internet and we wanted an article about SSO and Joomla. I didn’t want to come up to speed on the. So draft.dev found a Joomla expert who was willing to write an article for us about SSO and Joomla. If not for them, I doubt that post would ever have seen the light of day.

The downsides of these agencies include:

  • you have less control over the freelancer selected.
  • they will not know your product or space as well as you do.
  • you’ll still have to do some quality control and checking. You can’t outsource this entirely, because of the above point.
  • it’ll cost more money. You can expect to spend between $1000 and $3000 for a post (at the time I write this).

These are options that I know of that let you scale up your written content creation.

Do you want to build a community where users search or hang?

Everyone wants to build community, especially developer focused companies.

A community helps your customers and users succeed, creates content that your team doesn’t have the time to do, and builds a competitive moat.

But what type of community are you building, or looking to build? Every community is different. Which should be no surprise.

After all, offline communities aren’t identical. Neighbors are one type of offline community characterized by certain expectations and interactions. Maybe you watch their dog, wave when you see them, and get their mail for them on vacation.

Friends and family are another. You invite them for parties and see them during the holidays, discuss politics, and stay in touch through the years. Depending on family bonds, you might even lend them money or donate a kidney.

Similarly, developer communities have different levels of engagement and commitment. These can serve different audiences and needs.

A community is not a community is not a community.

One easy way to think about the community is to ask the question: are you a “Facebook” or a “Google”?

No, I’m not talking about whether you should “move fast and break democracy” or “don’t be evil” and set up a panopticon.

What I mean is: “what does your typical user want to do: hang out or get a question answered and move on?”

Facebook is where people go to hang out. It’s the dominant social media site, even if the kids are moving on to something else these days. In this type of community people chat, hang out, and get to know each other better. The technology or software solution is often the original impetus and the source of much discussion, but there are other aspects to the community. Topics range widely. In some cases, people remain members through job and role changes.

The community may even have a real life component, such as a conference or members meeting up if they are in the same area.

In contrast, Google (the search engine) is where people go to get answers. This involves searching, then leaving Google as quickly as possible. Community on Google is tenuous. It really means “people there at the same time” or perhaps “people asking the same questions”. Anonymity is fine and even valued.

The point of search engines is to send people on their way as fast as possible so they can focus on solving the problem that they are faced with. When you are looking up an error string, you don’t want to chat with someone about their hobbies, you want to get your answer and go fix the bug.

This is also a crucial, often ignored, purpose of a developer community.

What are some examples of these two types of community?

Examples of developer communities that are “Facebooks”:

  • The Rands Engineering Slack
  • The Ruby community
  • Orbit.love’s discord

Examples which are “Googles”:

  • StackOverflow (for almost all participants)
  • The Elasticsearch forum
  • Almost any other forum, for that matter

What makes a community more likely to be a Facebook or a Google?

There are many reasons why a community might tend toward a hangout or a search engine. Consider:

  • How self contained is the technology? Components or tools snapped into an existing system, such as a security framework or logging library, are more likely to be a Google-type community. Frameworks and other solutions that are bigger and more self contained lend themselves to a Facebook approach. Few folks want to hang out and discuss the intricate details of logging, but a bigger project like Haskell or Rust will have more to discuss.
  • Are there events that happen in real life around the community, such as conferences? These are likely to make the community more of a “Facebook”. There’s a feedback loop; when I meet someone in real life, I want to hang out more with them online.
  • Is the community open source? Does it have a unifying philosophy? Or is there a strong common interest such as gaming? These all make a community more likely to be a Facebook, since there’s already more to discuss than simply problem solving.
  • How do members interact with the software supporting the community? If often, there’s incentive to invest in getting to know other members. If, instead, the tool is used once in a while, then there’s less incentive. This correlates to the tool vs framework point above.
  • How big is the community? The smaller the pool of members, the more likely any interaction will be personal, and hence similar to Facebook. This is especially true if combined with a philosophy, as mentioned above.
  • How long has the community been around? Longer lived communities have, by definition, more chances for members to interact.

All other things being equal, a community where people want to stick around and chat is more valuable. It’s also harder to build, and may be impossible. And it’s only part of the picture. People hear the word “developer community” and think of IRC or discords where developers hang out, but community is so much bigger than that.

What are the ramifications of this characterization?

As a community builder, when you are starting out, you are likely building a “Google” type of community. To help it succeed, provide the most help you can in the time you have.

Help builds trust. It shows you care about your community and their success. Offering help shows you value your users time and is foundational for any other type of community endeavor. Few community members will volunteer time to help answer questions on your forum/chat if the company doesn’t seem to care enough to provide good docs about the tool or software solution.

So, your job is to help developers using your software get the answers as quickly as they can. How?

  • Well structured documentation. If possible, allow users to suggest changes to it.
  • Publicly searchable question and answer archives. I like forums, myself.
  • A clear roadmap for the product. Yes, it’ll change, sometimes rapidly, but offer as much guidance as you can.
  • Multiple channels for community feedback. GitHub, StackOverflow, hosted forum, Twitter, email, Slack, Discord, conferences. Pick some to focus on, but support as much as you can. There are plenty of tools to consolidate these disparate sources.
  • Share the changes the community has suggested that are implemented. This can be as simple as a shout out in release notes.

You can help work towards a deeper community by helping members get to know one another. This can be done in a variety of ways, including:

  • Virtual or in-person meetups
  • Profiles of community members
  • Encouraging direct communication between members, if you see people with similar interests or problems
  • Synchronous chat platforms like slack or discord

Just like it takes time for a sports team or company department to gel, it will take time for a community to do so. In fact, it will take more time, since members spend less time in your developer community than they do in others. Prepare for a long journey with missteps along the way.

Why not both?

Of course, a community can be good for hanging out and getting answers. Different users can have varying expectations and experiences within a single community.

Stackoverflow is a good example. Most people arrive there via search engines, ask or answer a question, and then leave. But there is also a lively community, meta.stackexchange.com, where users get to know each other, hang out and argue over the rules and culture of the Stack sites. It is important to design and be aware of these different needs, including lurkers.

But, in general, most communities have a clear tilt toward one mode or the other. Either you are a watering hole where folks hang out or an encyclopedia where developers come for answers. When you are helping foster a community, you’ll want to have a clear understanding of which type of community you can realistically achieve.

Thanks to Rosie Sherry for her review of this post.

Read “meaty” books

Every so often I read a book that I can’t describe with any other adjective than “meaty”. They’re large, complex and tough to get through. I read them 5-10 pages at a time. They are slow reads (and sometimes I don’t finish them) but they either change my perspective in multiple ways or introduce me to an entirely new perspective.

Some of these books:

  • Capital in the 21st Century by Thomas Piketty, which changed my thinking on how capital accumulates and what that means for societies.
  • These Truths by Jill Lepore was a re-examination of the history of the USA from perspectives I hadn’t considered.
  • The Case for Mars by Robert Zubrin is a book examining the real world possibilities for space colonization.
  • Refactoring by Martin Fowler exploded my ideas about how to modify software and gave me a new vocabulary too.

The latest book that I’ve read in this category is The Comanche Empire by Pekka Hämäläinen. This book has totally reworked my understanding of native tribes, political economy of the southwest in the 1700s-1800s, US western expansion, the wealth of Texas, social organization and more.

While it is fun to read books that don’t challenge my thinking, it is also good to read these “meaty” books periodically as well.

Ending projects

It is okay to let things end. You don’t need my permission, but I give it to you anyway.

I have let projects go in the recent and far past. It’s hard.

Tips for making it just a bit easier:

  • Sit on it for a while. Don’t make hasty decisions.
  • Give it a good shot. You, of course, get to define what that is, but you don’t want to bounce from project to project. 6 months of effort is my rule of thumb.
  • Listen to your gut. It knows what you really want.
  • Make a list of the good and the bad about this project.
  • If you can, offer to hand it off. How this works depends on the project type (an OSS project is different
  • Allow for a transition period where the project isn’t supported but isn’t quite gone.
  • Realize that changes happen and who you were when you started the project is different than who you are now. That’s okay.
  • Giving up something allows you to pursue new goals. This is a good thing.
  • Say goodbye, either privately or publicly, whatever feels right.

It’s never easy to say goodbye, especially if you have poured your efforts into something for years. I recently let a project I started in 2008 fade away. It wasn’t serving me any more and I had no enthusiasm for it. My life had moved on, and it took me a few years to acknowledge the truth–I didn’t want to maintain the project and couldn’t find anyone who did. While it was very useful for some folks for some time, it was no longer useful or fun for me.

It’s never easy to say goodbye, but it can be the right thing to do.

GitHub actions and workflows

I recently wrote my first real GitHub action workflow at work. It was to publish our website after a merge or push to our main branch.

After this experience, I think these workflows are perfect for simple automation tasks. Things like:

  • Running a linter like rubocop on your code
  • Deploying a simple application (one or a few artifacts).
  • Running unit and integration tests.

I didn’t use self hosted actions, though that seems like a nice escape valve if you want to run things within your own network or run over limit. GitHub publishes the action and workflow limits (storage, runtime) and that’s definitely worth reviewing.

You also can easily stand up a couple of different service containers (right now only postgresql and resdis) for easy integration testing. You can also abstract out your commonly used workflow segments to versioned actions.

It was really a pain to write the workflow, however. I had to push repeatedly to our mainline branch, and there were times I screwed up the YAML or didn’t have my script correct. The feedback loop was slooow. Ouch. There are solutions to run them locally, but I didn’t try it yet.

Other than that, it was a positive experience. If you are using GitHub and have automation needs, take a look at GitHub actions. I am a big fan of CircleCI and have been for years. GitHub actions covers a lot of the same ground. GitHub actions are less sophisticated, but it seems like a definite “innovators dilemma” play. So I expect to see actions to get more and more sophisticated.

The meetup opportunity

I’ve been presenting at a lot of meetups recently. With the move to virtual, if you want to spread the word about your project or company, you can speak to between five and 50 interested developers pretty easily. As a co-organizer of the Boulder Ruby Meetup, I can also tell you that I am always on the hunt for interesting speakers. Zoom makes it possible for speakers from around the world to talk to meetup attendees.

Why might you be interested in doing this? Well, if your product is aimed at developers, speaking at meetups is a great way to display that you and your company “get it” as well as get some brand awareness. It’s definitely retail rather than wholesale, but you’re still getting your name out there.

Organizers look for topics related to their meetup, from speakers who are responsive and know what they’re doing. As an organizer I’m looking for diversity and local representation, but am also happy to have folks from around the world present. We’re pretty open about the talk topic. Some of the talks are about ruby and rails, others are about generic technologies (machine learning, networking) and others are about the tech industry (ethics, interviewing).

Create a presentation

You want this to be on a topic that is technical, and related to your product, but not about your product. For FusionAuth, I present on JSON Web Tokens. If I was working for the Duckbill Group, I’d focus on the top 3 most expensive part of your AWS bill. For TimescaleDB, I’d talk about generic performance optimizations for PostgreSQL.

Do not hit the audience over their head with your product. Instead, display your awesomeness by teaching them something you’ve learned in a field adjacent to your product. Don’t worry, you’ll have your product name on every slide, and you can put in a slide or two about your company, but the focus should be on teaching something, not a pitch.

This is going to be time intensive, and the most effort, so see if you can spin off other useful artifacts. Can you make a screen cast on a similar topic? A blog post? Submit an article to Hackernoon?

You can also pitch a presentation to a meetup without fully writing it, but I’d suggest at least outlining it before reaching out to any organizers.

If possible, I like my presentation to be technology agnostic. Topics like authentication, databases, logging, etc all cut across different languages. Your presentation will be applicable to more meetups if the bulk of the explanatory slides be language agnostic. Feel free to tweak it by including a couple of slides or code examples in a particular language.

Find meetups

The meetup search tool is crap (most of the meetup UI needs some help, to be honest). I ended up creating a spreadsheet with the names of big cities in the USA in the left hand column and the names of various technologies (Ruby, JavaScript, etc) across the top. Then I built a URL searching for <city name>+<technology name>+meetup. Running this query on google was invariably better than trying to use meetup’s search tool.

Once you find a meetup, look at past events to see what kind of topics they cover, if they have online events, how big it was, and how active the meetup is. If it makes sense, send a message to the organizers. This is a good task to batch up and do weekly.

Reach out to organizers

Reach out to organizers via a meetup message. Some organizers aren’t doing meetups right now. You can scout their meetup page and see if they have online meetups. Sometimes I’ll ping an organizer even if they don’t because sometimes organizers will be interested in restarting a meetup or aren’t aware of the possibilities of remote speakers.

When you reach out, explain that you have a talk about such and such a subject and that you’re interested in doing a zoom meetup. If you’ve done it before, mention it, as that may make them more comfortable with you. Also, mention that you are interested in presenting to their meetup: “I’d like to present to the Boulder Ruby Group about JWTs”.

This serves two purposes. It shows that you aren’t a spammer because you took the time to customize the message at least a bit. And, when they reply to you (which can take days or weeks), you’ll know which meetup they run. There’s no way to go from a message to a meetup organizer to the home page of the meetup they help with. What? Yes, as mentioned, meetup has some UI flaws.

Follow up in a few weeks if they don’t respond. Messages get lost or forgotten. I also often ask if it is ok to take the conversation to email, because that’s less likely to be ignored or missed than meetup messages.

If they are interested, nail down the exact date and time (including timezone). Provide them with your bio, talk title, talk description and duration. Ask if they need anything else (pronouns, headshot, social media, the presentation for their review). I can tell you as a meetup organizer that it is quite nice to have these provided.

What you need from them is:

  • how you will connect to the meetup (zoom link, streamyard account, something else)
  • the length of the presentation
  • whether you can give anything away (electronic stuff is good, t-shirts cost a lot of money to ship but are good too)

I had one organizer want to review my talk, and a few others were happy to look at other presentations I’ve given, but other than that, the bar is pretty low. I also have a pretty extensive online presence; if you have less of one, you might need more proof that you will be a good speaker.

Remember, meetup organizers are volunteers and are looking to provide fun, useful content to their peers. Make it as easy for them as possible.

Conclusion

You won’t reach thousands of people when you do the Zoom meetup circuit, but you will get some great feedback on your presentation and help educate folks.

The largest audience I presented to was around 50 and the smallest was around five. I also got some great questions that led to additional slides and helped round out my presentation, which I was also able to submit to more traditional conferences.