Mix & match to find your ideal blend of developer events

At the Developer Marketing Summit, Karen White, Senior Product Marketing Manager (Developer Platform) at Atlassian, spoke about:

The benefits of running events for developers
The dos and don’ts of running a developer event
The 5 different types of developer events
The importance of centering your events around your developer community

Check out the highlights from Karen’s talk below. 👇

Today we're going to be talking about a few of the different types of developer events that are out there and how you can mix and match and combine them to have the biggest impact.

My name is Karen White, and I currently work at Atlassian, where I do product marketing for our developer platform.

Over the years, I've worked with developers in a few different capacities. I actually started out as a developer advocate. Since then, I’ve worked with open source tools, enterprise developer tools, and then back to the partner ecosystem.

In each of the developer-focused companies I’ve worked at, we were at different places. When I was at BigCommerce as a Developer Advocate, we were a medium-sized company. We were fairly established, but it was still really early days when it came to thinking about how the developer ecosystem fit into our strategy.

And then when I was at Rasa, we were a startup, commercial open source. We had this really lovely, engaged, active developer community. But the challenge there was trying to figure out how to build an enterprise business on top of that open-source enthusiasm.

And, now, at Atlassian, we've been building products for software teams for many, many years. We also have an established ecosystem of developers that are building apps and integrations. So, the challenge that we have here is change management over time and also how you grow to the next level.

So, today we're going to be talking about five different types of developer events. I think about these events almost like a toolbox or a color palette. Each one has its own application and each one solves for different outcomes.

Which one you reach for depends on where you are in your journey with the developer audience and what kind of activity you're looking to drive. So, it's really all about picking the right tool for the job.

The benefits of running developer events

First, we’ll look at the ‘why’ behind events. I think anyone who has put on an event before knows that events can be really messy, time-consuming, and expensive to run.

But there's also nothing like that feeling at the end of an event where you've been successful, your developers are happy, people from your company are happy, and you can see the impact right away that you've had.

That's because unlike static content, events really let you have a two-way conversation with your audience. They're interactive and you can see in real-time how your message is landing.

Although this might be changing a little bit these days with digital hybrid events becoming more common, you also theoretically have your audience's undivided attention. They’ve dedicated their time to coming here and hearing what you have to say.

And then, lastly, over time, you have the ability to create an ongoing relationship with your audience.

Of course, we're not here to talk about just any marketing events. This is all about developers. But I think people can get a little hung up on that.

At the end of the day, developers aren't really so different. They like the same things that other people like when they go to events. They like to be entertained and they like to hear content that's really relevant and valuable to them.

The dos and don’ts of running a developer event

There are a few common sense things that you want to watch out for.

I think this is the first one that everyone always names: developers are especially sensitive to really lengthy signup forms.

It's funny, when you go to a marketing event and you're filling out the registration form, it's almost like you're applying for a home loan. It's questions like, ‘Are you making a purchase in the next year?’ ‘Are you the budget holder?’ ‘What's your blood type?’ With developers, you want to keep that to an absolute minimum.

The second thing on the list is that you want to be careful that you're not sending out a million emails. Developers don't like being reminded that they're being tracked and nudged along. Do send reminders, but you want to avoid overdoing it.

Lastly, make sure that your content doesn't feel salesy. What that means is that everything doesn't need to be a super technical demo, but you do want to focus on how you’re showing value instead of just talking about value or telling people that the value is there.

You should always be answering a question that's top of mind for your audience.

Let's shift gears a little bit and talk about what I like to call ‘event FOMO.’ Maybe this has happened to you before. Some well-meaning person at your company sends you a link to some super shiny developer event that just happened, and they say, "Hey, why aren't we doing events like this?"

That comparison can be a little bit discouraging sometimes, especially when you're looking at an event that costs maybe millions of dollars to produce or has a really established developer brand because that might not be where you are today.

And that's totally fine. I think everyone has this fear that what they're doing with developer events isn't enough.

But what you don't want to do is just pluck a solution off the shelf or a strategy that worked for somebody else and just drop it in, even though your situation is different.

Everyone’s going to be in a slightly different place in regard to their business and their relationship with developers. It's not about trying to recreate that perfect event that you saw someone else do. It's about being able to pick and prioritize which next step makes the most sense for you.

Let's say that you're at a foundational level, similar to where we were at BigCommerce. You might be thinking to yourself, Can we even fill this room? And if that's where you're at, you're better off focusing on building up a reputation for developer experience and supporting developers who are building with your product before you go after further investment.

Maybe you're a little bit farther along. You're seeing engagement in your developer community and you're starting to think about how you translate this into a sustainable business.

In that case, especially if you're a startup, you might be looking at events as a way to seem bigger and more mature than you are. It's more about building credibility so that you'll potentially appeal to an enterprise buyer.

Let's say that you're at the top of the pyramid and you've been doing developer marketing for a long time. At that point, you might be thinking about how to use your event strategy to really become a leader in this field.

But, no matter where you are today, you want to ask yourself what's going to help you meet your business goals, and then pick the type of event that's going to align with those goals.

Maybe that's creating community love, maybe it's influencing a purchase decision, maybe it's getting developers to roll up their sleeves and build something useful.

I think one that people forget about sometimes is feedback. Developer events are a really great opportunity to better understand your users.

The 5 different types of developer events

Hackathons

Moving into our developer events, the first one I'm going to talk about is hackathons. I think hackathons are the classic developer event, but if you haven't done one before, they can be a little bit intimidating.

So, when do you want to deploy a hackathon?

Hackathons can be really effective when you want to reach a broader audience, especially if you're able to put some budget behind your prize pool.

Hackathons are also great for your existing developer community if you want to incentivize them to build for a certain purpose. So maybe you have an experimental new feature, something that you want to drive adoption for and, at the same time, you're going to get some really useful feedback for your product team.

A little bit of a case study here. Atlassian has been running a hackathon called Codegeist since 2015. So at this point, generations of product marketers have worked on it. Over the years, we've used Codegeist to first drive app creation for our server products, then as we went to cloud, and now for our second-generation app development platform.

In the early days, it was pretty modest, but it's really grown a lot. It's now our top-performing developer marketing campaign. Our total prize pool is up to $300,000 and, last year, we had over 1,400 participants.

We have two main objectives with Codegeist. The first one is growing our reach. It's a very top-of-funnel activity for us. And then our second objective is a little bit lower down the funnel. We measure the number of apps that are produced by the campaign, especially the number of apps that actually make their way into the Atlassian marketplace where they can be installed by customers.

There are a few things that we've learned from running this campaign over the years, and I want to share a few of those tactical tips and tricks.

First off, running a hackathon is definitely a team effort. Marketing is going to need lots of support from other teams. We start working with product really early on to make sure that we're aligned on the product features that we're going to highlight, along with shared goals, and outcomes. And we also work really closely with developer advocates who provide technical support and run office hour sessions.

Secondly, I don't recommend that you rely solely on your existing marketing channels. We use Devpost, which is a platform that runs hackathons. They have their own network of users and they can help get your hackathon in front of a group of developers that fit your target profile.

Sometimes, I think people want to run a hackathon, but they have a little bit of trouble articulating what exactly they want to do with all of those apps and projects once they're created. At Atlassian, we have really clear goals that we want to get out of Codegeist.

I think you can almost basically draw a giant arrow to what you want developers to do by assigning prize categories to those activities. So, if you want more apps in the marketplace, you might have a category for ‘Best New Marketplace App.’ If you want to drive submissions from different geographic regions, you might also have region-specific prizes.

If you want developers to go out and write blog posts about their experiences, maybe you could have a storytelling category.

Virtual conferences

Next up, we have the virtual conference. And I picked virtual because over the last two years, everything went virtual. And even though things are starting to open up back in person, I think that virtual events are going to continue to be part of our event portfolio for the foreseeable future. And the reasons for that are that they're inclusive, cost-effective, and they can be really impactful when they're done right.

Like hackathons, conferences are another really great tool for awareness and driving top-of-funnel. You can broaden your reach even more by hosting an industry event that isn't necessarily specific to your product or your company.

As you're thinking about the timing for your conference, you want to be working closely with the product team to align on what the big marketing moments you want to create are going to be.

And that's something that you want to be talking about months or maybe even a year ahead to set that target if you have a product launch coming up. What's that story that you want to tell at your big event?

We recently finished hosting Developer Day. Developer Day is our yearly virtual conference at Atlassian. It's a program that was spun up during the pandemic, but since then has become a really key part of our event strategy.

This year, the event was about four and a half hours long. We had two tracks, beginner and advanced. It was completely virtual, but we did run it during European hours, which is where a lot of our developer community is based.

One thing that set this year apart was that previously a lot of the talks at Developer Day were done by speakers from Atlassian. If you were looking at the agenda page, it just said, ‘Atlassian,’ all the way down.

We wanted to break that up a little bit this year, so we did an open call for speakers and invited community members to participate directly.

We also reached out to a couple of community leaders and asked them to be part of our content committee. So they were actually involved in choosing the talks that went on, which was a really great way to make it a more two-way experience.

Now, let's dive into some tips to make virtual events successful. With some of the other event types that we'll talk about, I think there's something to be said about taking more of a scrappy approach, but I think that's far less true for virtual events.

If you're at an in-person event, there are lots of intangible things that add up to a good experience. You have the food, the conversations with people, and the space. But when you're running a virtual event, all you really have is your content. So you want to make sure that you're putting your best foot forward and really elevating that as much as you can.

Next, I want to talk about replicating that hallway track. I think that's one of the most important parts of a conference.

There are a lot of event platforms these days that have a chat that runs alongside your content, and that's definitely better than nothing for engagement. But that endless scrolling commentary can sometimes feel a little bit disjointed.

I'm a really big proponent of using Slack for events. It allows you to have more of a two-way ongoing conversation between attendees and participants. It can also be really good if you're running your Q&A sessions a little bit asynchronously; maybe your presenters and your attendees are in different time zones.

And then, finally, don't forget about the entertainment value. Not everything on your agenda needs to be highly technical or even educational. You want a few things that are just for fun, too.

One of the most popular elements at a recent Developer Day was actually the DJ that played in-between talks. We also did swag giveaways and had pub trivia during intermissions. Those are a few ideas to add a little bit of character.

If you're going big, you might hire a celebrity speaker. A big name can also be a nice draw for registrations.

Workshops

I think workshops are an interesting counterpoint to hackathons, so I want to spend a little bit of time in this section diving into when to use them.

In a nutshell, a workshop is an event where you have a small group of participants and you're guiding them through a predefined project. It's like a mini hands-on class.

Compare that to a hackathon, which is a more open-ended contest where you're providing some help. But it's really up to participants to decide what they're going to build and how they're going to build it.

So I think the really key thing with a workshop is that you’re guaranteeing the success of your participants. Your whole purpose is to get them to that ‘aha’ moment, have a really good experience with the product, and keep them on the happy path the entire time.

We did a lot of workshops at Rasa. We focused on them exclusively versus hackathons. And one reason why is that we found it was a really high-value activity for our sales motion. But we designed our workshops to take development teams that were evaluating the product and make sure that they had a really good first experience.

The number one draw for workshop attendees is getting hands-on help from engineers at your company.

That might be a little bit tricky to do unless marketing has good buy-in from R&D leadership. But assuming that developer marketing is a shared priority, you want to set your volunteers up for success by structuring things for them, telling them how much time you're expecting them to take, and making it easy for them to help you.

And it's not just one way either. I think there's also something in it for your product and engineering teams. It gives you really direct, valuable feedback, especially about where users are getting stuck.

When we were doing workshops at Rasa, we very quickly had to shift to doing them virtually during the pandemic. We had this side goal that came out of that where we thought we were going to record these virtual workshops and then package them into something that was available on demand so that we could scale this program.

It was a noble goal. I don't know that it was completely successful. I think there were definitely people that took those on demand workshops and got value from them, but we noticed a big drop off in engagement.

So really, the takeaway is that workshops really make the most difference when live, hands-on help is at the core of what you're offering.

Another common theme is that during these workshops, we used Slack very successfully. It's especially nice for workshops because you can share screenshots and the full stack trace to get help with whatever you're trying to troubleshoot.

And, finally, one way to generate some attention around your workshop is to issue an official certificate of completion. Every time we ran a workshop at Rasa, we would get this wave of LinkedIn posts afterward from people who were sharing their certificates. It's a super easy thing to do, but it makes it a lot more meaningful for folks who are taking the workshop.

Meetups

Fourth, we have the meetup. I think meetups are a bit of a wild card event because there are lots of things that can fall into this category.

You have community meetups and company-led meetups, but the one unifying feature is that it's a pretty lightweight event and you're looking at a small group of attendees.

At Atlassian, we utilize a user community events platform called Bevy. We use it for both virtual and in-person events. There are also community leaders outside of Atlassian who have access to it so that they can book their own events. And then we use it for office hours with the development team and to set up talks with different product teams.

But, really, it's about creating a casual, ongoing conversation with your community.

One of the strengths of a meetup is that you don't necessarily need to script every last minute. It's actually better if you don't. I usually like to start off with a short presentation and then leave at least half of the time for open-ended discussions.

If your meetup is in person, the best part of it honestly might be the pizza and beer afterward, so you want to leave time for those conversations.

If you’re lucky enough to have community-led events that are happening around your product, a lot of times people forget that sending a speaker from your company is highly appreciated.

So, if you have an employee who happens to be located nearby, you can sponsor their travel and help them set up a presentation. And it really does mean a lot to community organizers.

Lastly, I don't think about community meetups solely as a vehicle for sharing out information. It's also very much about feedback as well.

One thing we hear from our developer community at Atlassian, again and again, is that they want to be told early about changes and they want their feedback to be actioned and incorporated.

So, we often use meetups as a way to share out early, semi-formed plans to get that feedback before we make a more official announcement.

Roadmap webinars

Now we’ll move to our fifth and final event, which is the roadmap webinar. Roadmap webinars are the events that you want to reach for when you have an early-stage product and you're trying to communicate progress.

The audience that you're speaking to are probably existing users in your community and they're already engaged enough that they're putting aside an hour to come and hear you talk about the roadmap.

At Atlassian, we do a roadmap webinar every quarter for Forge, which is our developer platform.

For me, one takeaway from running those webinars for the last few quarters is that it's a really good ritual for PM and PMM alignment. That's because every quarter you have this set cadence of your PMs thinking about how they're communicating what they're working on, and PMMs are thinking about how we're crafting a story around the roadmap.

One critical ingredient of doing roadmap webinars is to do them live if possible. I think that can be a little difficult sometimes with teams that are globally distributed. I've definitely done a few webinars at very weird times, but the payoff is really worth it.

I think when your audience knows that there's actually a group of humans on the other end of the call, it adds authenticity and makes them more engaged.

This is an added bonus, but little mistakes are a lot more forgivable when you're live, whereas if somebody knows that they're watching a recording, every little hiccup is going to be excruciating.

Lastly, and this is really important: don't skip the Q&A. Q&As are the real reason why developers want to come to your roadmap webinar.

I think doing a live Q&A can make people a little bit nervous sometimes, but there are ways to organize it so that you can support your speakers. We use a shared Google Sheet in the background so every speaker can see the question that comes in, and they can agree if they're going to answer it before we actually read it out on the air.

Finally, let's talk about who you want to have on your roadmap webinar. At these Forge webinars, sometimes we'll have eight, nine, or even ten speakers, which is a little bit of a clown car sometimes. But there are a couple of reasons why I like to have so many speakers.

Number one, it means that the person who's presenting is the subject matter expert on what they're talking about. They're actually making the decisions and building the product.

Number two is that you have a really wide range of expertise on the call, so you can answer pretty much anything that your audience throws at you.

Center your events around your developer community

It's really easy to be swayed by what other people in the community or in the industry are doing, but everyone has their own path that they're on.

The event that makes sense for you and the event that makes sense for the person sitting next to you might look really different, but you want to think of your lineup of developer events as a set of tools that you can apply at different times to solve different challenges.

I’m going to end here with some wise words from Mary Thengvall, who I think has influenced a lot of us in the overall space.

“No matter what type of event you're putting on, you want to center your community, not your product or your company. Your community is what makes you successful. So if you listen to your community, if you build something that they love, you’ve figured out 99% of the equation already.”

Tune in to our podcast for more expert-led content!