Lessons learned running a remote vendor conference in 2020
On the surface, nothing about running an online vendor conference feels important right now.
There are bigger problems in the world, and everyone is struggling to deal with a world flipped upside down.
But, if you’re capable, now is an extremely important time to be supportive to your peers, who may be facing uncertain futures, and in need of an extra hand.
And maybe conferences haven’t traditionally focused on that role primarily, but for a remote conference in 2020, being a place of mutual support and learning is critically important.
So how do we make an online event that builds everyone up, and makes for a great attendee experience?
Rule #1: Attention spans are limited. Make the time spent count.
In a remote conference experience, we’re not leaving our homes to escape in the ways we normally would.
Instead, we’re contending with kids, work, and the state of our local communities while “attending” remotely. As we’ve said, an online conference should feel like an insider support group. We’re all trying to balance a hundred things, and trying to do our best for the people who rely on us.
So how do we squeeze the most out of our attendee’s limited time?
For DASH, we decided to shorten the traditional talk to 30 minutes, followed by 15 minutes of Q&A from the audience, led by a technical co-host.
In our case, our global audience had many great questions, which made for an improved, more open learning experience for everyone.
Next, we made sure to build as much educational content as possible.
In the case of DASH, we had 19 (!) unique, 2.5 hour long interactive workshops for attendees to experience. Each of these touched a specific subdomain or set of problems for attendees to learn about.
We gave each workshop at multiple times (for multiple time zones), and donated all proceeds to charitable organizations.
By default, workshops were led via a Zoom with 3 teacher assistants and 80 attendees each, over the online learning platform Katacoda.
Despite the shortcomings of Zoom, by planning ahead and doing multiple dry runs, we were able to do these mostly without a hitch.
(Corporate firewalls and network rules can be wildly tricky.)
To handle the logistics of running through 19 unique workshops, we mostly built off a single, shared example project. The example project has a few built in “problems”, and each workshop offers a specific subset to diagnose and repair.
Rule #2: Admit “Marketing” to Developers is Different
Developers are famously allergic to overt marketing.
And now that the world has gone completely remote, there’s even more of a demand on developer’s time and attention.
The last thing anyone wants to hear is a vendor’s pitch.
So how does a company effectively get their ideas in front of developers, when their attention is already spread so thin?
Pre-lockdown, it’d been by giving away copious amounts of swag and goodies at conferences, along with the traditional demo booth. But with everyone locked down, the tradition of escaping away on the company’s dime is gone for a while.
So, again, how do you get your ideas in front of these people? How do you continue to build a developer focused company and products in times of “remoteness”?
At least one answer is obvious: Actively investing in the quality of life for developers.
To do this, there is a dedicated role called “developer advocacy”. Depending on the organization, this can mean different things. But having a team of people dedicated to listening and improving parts of developer’s lives, is a strategic investment, and will pay long term benefits, both in product quality and in a brand’s perceived value.
The main idea with the “developer advocacy” role is that someone is focused on building things that provide value for developers directly. The value may be delivered via talks, workshops, hanging out in forums, posting on twitter, writing blog posts, or just answering questions and providing direct feedback internally.
By continuously delivering value to these developers, a level of “trust” is built up. Fundamentally, that built trust is the currency of the role.
Regardless of the event type, or communication forum, developers have to believe that the advocates care about them first, above and beyond their current employer or immediate event outcomes.
It is from this basic level of trust that you can start to build a long term relationship. In exchange for the developer’s attention, you are promising to deliver something new, something novel, something important for them to know. And this knowledge based, learning focused marketing is much more honest and direct to a developer.
Eventually, the story becomes: “I support this vendor, because they have helped me learn more and more new things, building my value in the market, and making my job easier.
Rule #3: Online Conference Are Their Own Medium. Embrace it.
For the first time, conferences can be truly global, and no longer have their usual level of exclusivity.
We’re all able to attend, and we’re all able to learn from one another, without relying on an employer’s willingness to let us escape for a few days to a foreign locale.
For any conference, the fundamental priority will be connecting with our peers and learning. We’re there to see if everyone else is experiencing the same pains, and to see if maybe they’ve learned something new we can take back to the rest of our teams.
In watching many conferences done earlier this year, my team learned a few things, that I think fit the online medium well.
Focus on authentic stories by practitioners.
Having tangible stories and lessons learned makes for a more complete story. It also makes for an improved Q&A session, as there are inevitably trade offs made, decisions regretted, and more that are immediately transferable to attendees.
Next, build out as much interactive, experiential content as possible. For DASH, again, we did 19 instructore led workshops.
With each of these workshops, we tried to solve and diagnose real world problems. Two and a half hours seems like a lot of time to dive into a problem, but it’s really quite limited!
We also did two 3 hour long AWS Security GameDays. AWS GameDays are an experience where you are assigned real world infrastructure which is under attack, and have to rapidly discover and then repair the attack on your systems.
These GameDays have traditionally also been in person, but doing them remotely seems to have gone well.
Rather than having groups of 3 as before, this time we split people into “sessions” with a few breakout rooms for people to experience a smaller group, together. In general, we shot for around 15 people in a hangout or Zoom.
A critical part for this is having great hosts in each of the breakout teams, and leading / discussing in an informal matter. Having a great peer group to work with makes for a good experience for everyone.
Rule #4: You Are Only As Good as Your Team
In the book Debt: The First 5,000 Years, there is this idea of a web of mutual favors being owed as the basis of all communal economies.
Working with a great team of people feels a lot like that.
As we were preparing for our conference, one of my family members struggled with cancer, and was hospitalized twice.
Without a team you can trust, it’s impossible to get anything significant done in a time like that.
At multiple stages during a difficult time, both people within and outside of my team stepped in to help out and make sure things progressed. When I could, I did the same for others.
Again, having this set mutually owed favors leads to an extremely strong team. It also stresses the importance of having a diverse team, as each person can contribute their own unique set of skills to whatever problem set pops up.
Rule #5: Remember to Have Fun
Being able to speak in front of your peers is a great privilege.
But it’s also intimidating!
There is so much to know, that it can be terrifying to potentially say something wrong front of an audience.
But if anyone is going to be speaking, why can’t it be you?
We each have something to contribute to the culture of software development, and software development culture isn’t a passive thing, it’s not something that just “happens”.
Right now, developers are the stewards of human consciousness. Humanity is spending so much collective conscious time within software systems we build, that we really are the rudder directing the route for humanity.
Having a chance to improve the quality of life for the people making the rudder move is an honor. It’s also something to be enjoyed! We’re all here to make the world better, from our tiny little position.
So let’s do it.
