Couchbase’s senior developer community manager Laura Czajkowski helps you narrow down your sponsorship choices, set your event goals and prepare your event presence in this practical talk from DevRelCon London 2018.
Thank you for having me here today. I’m basically just talking to you some of my experiences over the last four years as a community manager, which a lot of trade shows actually fall to my plate rather than marketing or other teams. And so, what I’ve noticed over the last couple of years is that how we’ve actually managed to grow and engage with our community came directly from engaging at specific events.
And I want to talk you through some of my experiences and best practices. It’s not always about events, it’s a lot about prep and preparation and actually post event, which has actually led to an awful lot of good conversations with our community members afterwards. So just out of curiosity, hands up here, whose sole responsibility is to run events for their teams? Okay, interesting.
How many people whose job is to go on to booth duty and have conversations? There we go. So it’s about 50/50 in the audience. That’s good. So there’s actually a lot of prep work that is required before you go onto the floor of a booth, before you go take that step or go speak at a conference and then run back to booth and do your demos, there’s so much more work involved. How you choose the events that you want to engage and what you want to actually show at those events, what you want to track to bring back into your organization.
Is it feedback or issues? Is it pull requests from talking to customers? What do you actually want to get from that event that you’ve chosen and spent, in some cases, a considerable amount of money, to bring back to your organization to show the value of actually taking part in that event? And that can be quite hard. Because what I’ve learned from four years of doing this, is that finance and sales and marketing don’t always understand why you’ve chosen that event. But by talking to them in advance and explaining the criteria you’ve chosen, it’s actually led to better buy-in.
And so, this brings me on to like life is not black and white and neither is choosing an event. You know, I looked at it there last week, there was about 400 events that I could potentially have chosen for next year. You can’t do 400 events. You can’t even do 30 events or 60 events, it’s not actually possible.
You’ll burn out. Your team will burn out. And let’s be honest, we don’t have the pot of gold at the end of the rainbow just yet. So how do you choose them? What are the criteria you need to accept? So this is where I start to create an event strategy to plan and execute. What I learned when I first started, again, when I started doing this four years ago, we did no events in our DA team.
That grew to four the following year, 20 the following year, and now currently I do 30 trade show events, on top of running my meetups, community experts and champions, the forums and community directory. So I do an awful lot. So I need these to actually run very smoothly for myself. So I needed to create an event strategy and explain that to everybody.
This is very, very clear. No matter what event you choose, you’re always, always going to get pushback. And I think that what I’ve learned from doing this is by showing how the decision is made. And guests, you’re right, we had a very good conversation on those KPIs. What do you define as the reasons why you would choose an event? And what was very evident from that discussion is that not one team, even within an organization, does the exact same.
So if it’s like for recruiting, is it for hiring? Is it for feedback? What are those decisions? And by showing it to your different stakeholders, you hope to get buy-in, but knowing full well when you don’t choose an event over another event for a sales rep, for a different team, for a different SDK, you will get pushback. But if you can show this, why you’ve chosen it, I think it kind of just softens the blow a little bit.
Homework, who doesn’t love it? So I start around this time every year for choosing my events for next year because it takes so long. As I mentioned, we didn’t do many trade shows when I first started. We did meetups. And that’s great because meetups are very useful but that gets you in front of maybe 20, 30, maybe 60 people.
You could do many, many meetups a month, but then you’re consistently on the road. If you do one event, like a large trade show, like an Oz Con or JavaOne or an AWS summit, you get in front of thousands more developers. Or some of the language specific events, you get more in front of those people over two or three days. So it’s actually better engagement in some cases.
What I learned as well was I get many, many requests. Even now, I get 20, 30 requests a quarter to sponsor the event for the coming months, for next month. So I need to kind of like have that decision made so I can also plan our activity, plan our meetups, plan our releases, but also plan downtime. What I’ve learned is don’t take vacation in May, June, September, October, now December thanks to Cube-Con.
Like there are certain months you just can’t take vacation. But if you have a plan, then you can actually like spread the love around the rest of the team so you actually get some downtime. So this is just a caveat to people who are organizing events, events that make it really difficult for me to buy in. No event on the website. No venue information. And my newest pet peeve is they will actually gate the PDF for the conference sponsorships.
If you put that there and make me have a phone call, I’m not going to sponsor it. I don’t have time to have 60, 70 phone calls a month to sponsor your event. Make it easy. Make it interesting for people to buy in to your conferences. Don’t gate that information. That’s just my small, little mini rant there. It’s because it’s bitten me this month.
So I’m not a sports person. I follow rugby, I’m from Ireland, that’s kind of what we do. I don’t play it, I love it. But what I have learned is that you need a conference playbook. And so, this was kind of our biggest step for us key to our three years was to have buy-in from the different teams. So we defined it as what we wanted to get from choosing this event.
And this was kind of a standard practice. We want to like explain our criteria for the following 12 months. So we looked at it 12 months in advance, we decided like what we needed to do to make this year successful for developer advocacy. What did we want to achieve over the coming 12 months to get in front of our community? And we worked with the different stakeholders. We wanted to show them the plan for the different territories, for the different verticals.
And how we did that was by actually like including them in the process. We try to include all the different decision makers, but also know that everybody has an opinion and there can be an awful lot of bike-shedding going on. So our team was the leader in this, which actually then put us at the forefront of showing that we are the leaders within the organization to make these decisions. And that actually helped solidify the role of the developer advocacy team, the community manager, but also the value of the community. So this was step one.
Step two was also like showing what the expected results were. So I’ve just listed some of the KPIs there. Again, what I mentioned yesterday, really one that I hadn’t thought about was recruiting. That’s a really good one because, as you mentioned today, like everybody here today is either recruiting or looking for a new role.
Perhaps we should actually look to do that in our booths going forward. How do we track that? Is it number of CVs? Is it number of submissions afterwards? I think that’s a new one that we could try and track. Is it the number of demos you want to do at the event or is it the number of lunch and learns afterwards? So defining these KPIs with these goals or objectives for the year ahead gets your team buy-in and gets the value of what the developer advocacynd the community team do for you.
So now that you’ve been chosen, I have chosen and I have selected you, and I’m doing no more for the year ahead. This is just like a bit of housekeeping, which I’ve found to be really helpful. So like I said, once October comes, decisions are made, I start reaching out to the vendors for next year. Chances are most of them already have their prospectors or they’ve asked you to do that horrible thing of resigning on the day when you haven’t even had the chance to like have a lunch break.
I take that time to actually start working for the plan for next year. Housekeeping rocks and one amazing tool that has really, really helped our team to like plan our lives and help us keep honest is the EvMan tool. So I want to thank a big shout-out to the OpenShift team and Red Hat. You are my amazing people and I love you forever.
This tool, you can just log in and create your own dashboard or you can host it yourself. I’m just giving you a showcase of like how I track my life right now. It gives you an example of all the events that you want to sign up to, that you’re taking part in. You can also track CFP dates because I often find I really wanted to submit to that conference. Oh no, I’ve missed the deadline yet again.
And this will actually track all of that information in one location for you and for your team. This just helps like plan out the timeline for you to avoid having crossover of doing six events in one month and certainly, in May and June, that’s sometimes just not actually possible. But this just helps make your life a little bit easier and shows the different stakeholders like it’s probably not the best time to ask us to then do a lunch and learn for your team.
Or it’s probably not the best time to make us jump on a call because we’re currently at an airport. I just love it and you can create your own tags and your own type of events that you want to do. I just think it’s possibly the best tool out there for me.
So to get on board with your team, and sometimes like we have the developer advocacy team do ownership of the event, we’re going to bring in different stakeholders, that’s the different product managers, or we even have some community members come into our booths. And that’s kind of been a different change over the last few years.
So if you’re having a community member or community champion come into your event, they don’t have the expectation of what to do in a booth. So we try and involve them from the start. Like, hey, you know, we’d love you to come by and talk about your experience of using Couchbase. How have you found it? Just talk to people because that’s your own advocate in the community sharing their experiences. But having all that information in one location again just makes things a bit easier and a bit smoother for tracking. So I can go back two years ago, I can go back three years ago, and see the kind of event that actually happened.
Just to make things run smoothly, we do, as I said, 30 trade shows a year. I can’t be at every single one. Otherwise I will have a failed marriage and I’ll have no dogs and nothing to come home to. So what I have to find is put all the information in one location that if I’m not there, the point of contact on the day can actually figure out what to actually do.
So it seems kind of simple and yet we hadn’t done that beforehand. So people would turn up to an event and not know where things were. So we’ve tried to put everything in one location. So everything goes into a folder, everything for that event is in one location.
So briefly with execution, which is actually if you execute and do a lot of planning, the execution should run smoothly. Touch wood. And it doesn’t always, but you have a plan B. So before we do an event, we do try and have an event briefing. And again,this is very key if we’re bringing in community members to our booth. It’s not their full time job and you want to set their expectations and understand how they can actually help. Review the booth duty rules. I kind of have some specific ones about no laptops and no food in the booth.
Because nobody’s going to disturb you if you have your laptop out and you’re reading, because I don’t want to be disturbed when I’m reading so I won’t do it to somebody else. We have found this to be very key actually, again, to reinforce like what we want to achieve from the event. Because, again, we can go back 12 months where we set those KPIs, what we wanted to achieve from these events, why they’re chosen.
So by going through an event briefing, we actually reinforce what we want to get from that event. Has there something come out recently? Is there a release you want to promote? Is there some feedback about a beta build that we want to try and promote that week? So it’s just to reinforce and get buy-in from everybody. I am very cruel and they don’t particularly like me about doing this. I do make people do an event run-through that morning.
And unfortunately, some of the events that we’re doing are 8:00 am starts, so I do make them come in at 6:00 am and 7:00 am for this. Because it’s all well and good to me, I know the booth size, I know the logistics and layouts, but not everybody on my team do. So I come with bribery and I’ve learned that coffee makes developers very happy, or donuts or just granola bars. It makes people happy.
So I do think an event run-through keeps everybody kind of knowing what they’re doing on the day. It allows for like that laptop that’s not going to work, find the connector cables that aren’t working, just come up with a few extra plans. So as I mentioned, doing the event prep is all well and good. Always have a backup plan in place but, you know, when the event is actually running, you don’t really have time for a lot of things. So just to have that information at hand makes things run smoothly.
This is kind of like the purpose of really what I actually did. The event outcomes influence future events and that’s really, really true because everybody here I’m sure has been to an event. They’ve gone, “That is amazing. We need to go back to it.” But you maybe don’t have to convey that to the rest of your team, to the stakeholders. But for sure, you know there’s an event that you’ve gone to that you do not want to go and you’re very vocal about it, and you want to track that information.
So I track everything into a debrief. We do a massive postmortem on every event that we do. We basically, you know, define like what were our goals? Were they achieved? What was the event actually about? Did it meet our expectations? What went wrong?
What could we have improved? Were there any key conversations we had? How many demos did we do? So I come from like a software testing background and support background. I now have to use tools that I’m not the best, but I can now make my peace with Salesforce. Not so much with Mercado. But these are the informations that I track.
So everything then now lives in Salesforce after the event and that helps us then run a report for next year when I want to see how the event has actually done. I can pull a report from Tableau and Salesforce on a quarterly basis, on a yearly basis, and see how the event has actually progressed. And that’s kind of key. So when we do the checklist and we do the post event, it’s just as important about the post event as it is the prep event.
It’s to get understanding. So again, if your developers aren’t over that, the events on our team, our DA team is very different from our SDK team. In other organizations it’s very different. We want to feedback into the SDK team, we want to feedback into the product managers, we want to feedback into product. How do we do this? We share that information that we’ve just achieved and learned at this event. We want to feed that back into our organization, how we can actually make a difference.
As I mentioned, you know, it goes into Salesforce. That’s really been kind of overwhelming for us to see, that six months down the line or even 10 months down the line, the event that we’ve chosen has made a difference. We’ve been able to actually have a lunch and learn from that event. They’ve done a POC from that event. Perhaps even they’ve even closed a deal from that event. That’s great because then we can show that our choices are making a difference.
We’re able to find those developers. That’s been actually really eye-opening. One of the things that we drive from our events is back to like us, our team. So we drive it back to our community directory, by driving back to our community forums, we have found future champions this way. We’ve been able to promote our community writing program. So again, try and engage more with our community members on the ground.
We can definitely see a massive increase in collaboration, and that’s actually by choosing the right events. We now have a plan in place. We know where to go find our community. Whereas, before we were kind of like “we’ll just do the generic ones that we know that are always good for developers.” But now we actually have specific data, and we can go back six months, two years back from. So it’s really made a big difference.
So after 70 trade shows over four years, I have gone grey. But I would say be very strict on your criteria. Avoid being asked to do just one more, because that one more could just break the team. It could also be a flop. And one event takes as much as many events to organize. So I’m kind of strict on that. Decide ahead of time and success. I’m still baffled by getting emails from vendors with an event four weeks away asking for sponsorship. Because for me, I’m like if you’re still looking for sponsors four weeks out, do you really know, like is your event going to be a success? I’m like nope.
It’s still evolving. Like this was stuff that we’ve learned this year. So when it comes to December and no travel, I’m very happy. I will do my updates of all the plans and what I’ve learned from the year, I’ve figured out like, you know, where are our demos working? I’ll update our conference playbook.
You know, we’ve started renting like monitors and laptops in our booth to save us using our own laptops so we know the build actually works. What’s been really evident this year is one of our success is working with our partner ecosystem. So a lot of our team are working with the different partners out there to do joint submissions and conferences, to doing joint demos on the booth.
And that’s been really eye opening to see that actually working. And the partner team then like us and we like working with the partner team, so it made really good sense. And this has led to like understanding where our community is and that’s led to a better engagement afterwards. And that’s really kind of the goal that I want to do, is to like learn where our community is. So this has really actually helped us achieve our goals and objectives and I can definitely say there’s been a big difference in the last four years.
And I can see in the last 12 months a massive dramatic because we’ve able to like have a clear, defined goal and objective and actually be able to show that six months later has been actually overwhelming. So that’s me. Thank you.
Tamao Nakahara and Baruch Sadogursky demonstrate some mistakes to avoid when engaging with developers in this session from DevRelCon San Francisco 2019.
Amanda Moran from DataStax talks through the good and bad of transitioning from engineering to dev rel in this session from DevRelCon San Francisco 2019.
Write for us