Learning about event planning -- life pro tips from Jack Molisani
Targeting an audience
With LavaCon, Jack focuses on a specific market segment: content strategy and tech comm management (you can see Jack’s video explaining his focus here). LavaCon’s attendees are senior writers/managers solving strategic content problems across the enterprise, and they often interact with upper-level execs. This is the first lesson in event planning: define a specific audience for your event. Not just “technical writers,” but “senior content strategists” or something.
With my API doc workshops, I have a specific focus — tech writers working with APIs in developer docs. Having a narrowly defined audience helps you focus content for that audience. In contrast, conferences that address tech comm in general tend to be so wide and diverse that even with 10 sessions at once (not uncommon at the STC Summit) you might find that none of them really seem relevant. With a narrower audience, you can have fewer tracks or topics and still have relevant content.
Choosing a location
Besides the narrower audience focus, another element in event planning is picking the right location. I sort of made a mistake in picking LA as a location. I thought LA had more of a tech focus, but it doesn’t. Irvine does. I should have held the workshop in Irvine (45 minutes away), but for whatever reason, I ended up steering it more towards LAX. I can’t even remember why except to accommodate those flying in since LAX is a major hub. Apparently, some years ago during a tech comm crash, many tech companies in LA moved elsewhere. It’s crazy that a one-hour flight (distance from SF to LA) can make so much difference with demographics, but it does.
On the plus side, some of the LA participants have deep experience in the tech comm industry and are really interesting people to talk to. And we had 15 people, which some feel is the perfect size for a workshop like this.
Overall, when deciding on locations, you might hear from people in an area who express interest in the topic, which might lead you to think there is wider interest in the area as well. But is there? It’s difficult to gauge interest in an area in a more data-driven way.
I asked Jack how he decides which locations to choose for his conferences, or what methods I could use to better pick locations for API doc workshops. He said it’s fairly easy: do searches on Indeed.com to see who is hiring for the skills your event/workshop focuses on, such as “API technical writer.” Look at this data to determine your locations. Where employers are looking for candidates with these skills, there will be a natural interest in events focusing on those skills. Duh! I didn’t even think about this.
Last year I did some research about locations for API doc jobs, and I wrote an article called Best locations for API documentation jobs. I tallied up technical writers employed in various areas (based on the STC Salary Database) and correlated them with hits for “API” on Indeed, and then ranked the areas. I know the approach was rudimentary, but it’s hard to pinpoint where API doc jobs are because these jobs don’t necessarily have API in the title. At any rate, the top trending states in my quick searches were California, Texas, Virginia, Massachusetts, and New York.
What about Boston? I specifically asked. Jack says that’s an expensive city, which can detract participants. If it costs several hundred dollars just to book a hotel, take that into consideration. Then again, if people are already in Boston, the hotel might not be an issue. This is one challenge with API doc workshops: locations where API skills are in demand are often major urban centers where costs are also high.
Which brings me to another point — conferences differ from workshops in significant ways. A multi-day conference can be held in an interesting, non-tech-hub city like Portland or New Orleans in part because people traveling to the area might be drawn to the area itself. You don’t see many conferences held in Des Moines or Omaha, Jack said. One-day workshops, on the other hand, aren’t multi-day getaways, and even if I held my conference in a fun, non-tech-hub location (e.g., Anaheim, Las Vegas, Miami, Missoula, Savannah), it likely wouldn’t draw people. A conference has a different dynamic at play in terms of location. Jack even holds some conferences in Hawaii.
Choosing the date
Another factor to consider is the timing. Jack told me about his experiences putting on a conference in Dublin, Ireland. It seemed like a great fit because over 1,000 high-tech companies have their European headquarters in Ireland. But he accidentally held the first conference on a federal holiday when everyone was out of town. Even the tech support for the conference was out of town.
Jack said that among different conference organizers, there can sometimes be competition with dates. Suppose a competing conference organizer aligns their event dates with your event? What then?
Since I’m only holding one-day workshops, I don’t run into this same issue of competing workshops. But I do try to avoid clashing with the same date as another tech comm conference. How do you know when all the major events are? Not just tech comm events but other events in the city (like Dreamforce) that might conflict?
Even better yet, how do you know when the best time of year is to hold an event? People travel in the summer, vacation during Christmas, relax with family during Thanksgiving, stay home with kids during spring break, etc. Mix these holidays with all the different tech comm conference dates, the different non-tech-comm event dates, and then look for dates actually available at the venues you want. Picking a date is no easy choice!
Fortunately, a one-day workshop is much less involved than a multi-day conference, so there’s not as much risk in date planning. Pick the wrong date and worst-case scenario, you end up paying the fee for the venue (usually ~$1,000) and drawing just a few people. Pick the wrong date for a conference, and you could be out thousands of dollars since the venues are often large hotels you have to book years in advance. You likely don’t have too many chances if you make mistakes with conference planning.
I’m still learning how to pick the right dates for workshops. One thing is for sure: there’s no easier way to make an enemy in this space than by planning your event on top of another event.
Surprise, planning events is fun
There’s an aspect of event planning that I didn’t expect — it’s fun. Deciding which city to go to, and which venue to pick, which content to focus on, and then announcing it is all kind of a rush. Jack is extremely good at this. In his military days, he managed a lot of contracts. Contracts are at the heart of event planning, as you have to contract with venues, speakers, exhibitors, caterers, and more.
Actually, Jack said he’s planning to write a book that contains much of what he has learned about event planning. I would be excited to read this. Jack was lively and engaged telling me all of these tips and challenges and other experiments he’s followed over the years with conferences.
I admit that I have fun browsing Peerspace for various venues. It’s not difficult to find a classroom-style meeting room that would hold about 25 people, equipped with AV equipment for presentations. There’s a whole economy shaped around different businesses renting out meeting spaces, not too unlike Airbnb.
There are a lot of details to keep track of in event planning. I mentioned location, venue, date, catering, but there are also a host of other details, such as how to foster interactions and conversations outside of instruction time, such as during lunch or post-workshop.
I don’t have ambitions to plan larger events other than workshops. Although I think a conference on API docs would certainly draw me, I know that larger event planning pretty much consumes all of your time. Jack said that planning two major conferences a year is more than double the work but is actually triple or more, as you have to constantly coordinate and separate details between the two across vendors, speakers, and other details.
I like the idea of workshops, or even bootcamps. Workshops are one-day events, convenient to participants, focused on specific skills. They fit my current lifestyle where I work a full-time job and do workshops on the side. My full-time job gives me stability, and the workshops are more of an experimental side hobby.
Synergies with complementary business streams
There are two more interesting pieces of advice, or observations really, that I gleaned from Jack. Jack not only organizes conferences but also does staffing for tech companies (see Prospring Staffing). At first, I didn’t see how the two activities related but as he explained how many people reach out to him to fill positions after attending his conferences, or how people who use his staffing agency end up attending or speaking at the conference, I could see how these two businesses build and feed off of each other. He also said that having two streams like this helps safeguard for times when one lags.
I struggled to see how my workshops could build on another business stream like this. Some have recommended that I create some kind of API writer recommendation service, but I have no desire for that, as it’s extremely hard to vouch for specific candidates without knowing and working with them. However, I do see some interactivity between API doc workshops and API tools advertising. Advertising has been fairly successful as a supplementary pocket-change type of activity. I could look to expand the way these two business activities intersect, perhaps.
When your ship comes in
As a final piece of advice, Jack mentioned a philosophy about putting yourself out there without knowing exactly what the returns will be. There’s a phrase called “when your ship comes in,” which refers to a time when people would finance an outgoing merchant ship without knowing whether it would return with traded cargo (given the dangers of high seas, pirates, and other perils). Jack’s philosophy is to constantly put himself out there, whether it involves writing articles, speaking, going to conferences, or doing other activities.
These activities involve a lot of time and effort without a guarantee of any returns. But when he does this, unexpected returns come in. For example, a big name might suddenly ask to speak at one of his upcoming conferences. Or from a video shared on Linkedin, a company might reach out to Jack to get help filling a position. You never quite know what comes of it. Either way, your ship’s not going to come in if you aren’t sending any out!
I find this philosophy interesting. When I publish a blog post, I don’t do so with any expectations. For example, I have no idea what will come back to me as a result of this blog post. Maybe nothing. But more often than not, unexpected things do happen. For me, blogging seems to align nicely with built-in marketing for the workshops. Nearly everywhere I go, people seem to know me from posts they’ve read. Whether that post reflects my current thoughts or even puts me in a positive light, I don’t know. But my life has been a constant act of putting myself out there — publishing not just blog posts, but presentations, podcasts, tweets, and other interactions. Good things usually come back in for me, in ways I don’t often expect. In this case, I learned a ton about event management from one of the top conference organizers in the industry. Hopefully, I can remember and apply some of these tips to improve and deliver on better workshop experiences.
About Tom Johnson
I'm a technical writer based in the San Francisco Bay area. In this blog, I write about topics related to technical writing and communication — such as software documentation, API documentation, visual communication, information architecture, writing techniques, plain language, tech comm careers, and more. Check out simplifying complexity and API documentation for some deep dives into these topics. If you're a technical writer and want to keep on top of the latest trends in the field, be sure to subscribe to email updates. You can also learn more about me or contact me.