Monday, February 13, 2017

How to organize a meetup

I've organized a few DDDBE meetups in the past, and always succeed in forgetting something. Either someone points it out well in advance, or I end up stressing last minute. This post partly serves as a checklist for myself, but it would be a welcome side effect to also see it encourage others to help out organizing future meetups. Organizing a meetup is not rocket science, having a list of what to take care of is a good start.

Finding a speaker

One of the crucial ingredients of an interesting evening is the speaker and the content he or she brings. My strategy is to use Twitter to keep a tab on people that produce content that's of interest to me. A meetup is a great excuse to meet in person and to hear them out. When it's someone who isn't local, I keep an eye on whether they will be attending any conferences nearby in the future.

Contacting a speaker

The medium you use doesn't matter that much, whether it's through Twitter, email, Slack or in person, as long as you give them enough context to work with.

Things to mention when contacting someone:

  •  Introduce yourself and the user group.
  • Tell them why you think he or she would make a great guest. Which was the talk, tweet or blog that piqued your interest? What is it that makes the content so relevant to your audience?
  • Tell them about the expected composition of the audience. Will there be 20 people or 100? Should most of them be quite familiar with the topic, or do you think an introductory talk would work better?
  • Propose a date or a small set of dates from the get-go. Even if none of those dates work, you might settle on an alternative date instead which allows you to move forward and start planning.
  • To avoid awkward situations, mention up front whether expenses can be covered or not. Not having a budget normally isn't an issue when speakers are local or when they're around for a conference or customer. When they have to get on a plane, it's another matter.
Gathering speaker requirements

Ask the speaker what he needs, to be able to do his session:
  •  A projector
  • A whiteboard
  • Modelling space
  • Markers and sticky notes
  •  ...
Selecting a location sponsor

With those requirements in mind, you can start looking for a location sponsor to host the meetup.

It's a luxury to have a pool of location sponsors. Depending on the speaker and format of the session, you can make a selection on what would be the best fit. When the speaker is a big name in the community, try to find a location that fits a lot of people. A large auditorium perhaps. When it's a workshop, make sure there's plenty of modelling space. An open space with lots of walls or windows you can use to your advantage. If you think the interest in a certain topic will be rather limited, aim for something a bit smaller and more cozy, which could benefit the quality of interactions between the speaker and the audience.

Once you've come up with a short list of ideal locations, you should be aware of the type of relationship your community has with the sponsor. Even if they don't get much out of it, they might not mind doing you a favor once in a while, but hosting a weekly meetup might be a bit much. I like to order them in a way that makes a best attempt at a round-robin distribution. This also benefits attendees and avoids over concentrated geographical communities. Not everyone's up to drive half way across the country on a weekday for a one hour talk.

Contacting a location sponsor

Keep a list of location sponsors and the people you need to contact, and who inside your community knows them best. You have a higher chance of getting a positive response if you have someone that knows them well contact them. You can send an email, but there's a high risk that it ends up in a low priority queue somewhere - nobody likes sending out those reminder emails. It's more efficient to just call them, to ping them on Slack or to send them a direct message on Twitter - in that particular order.

Prepare a list of things the location sponsor needs to know:
  • The date
  • The name of the speaker and the subject
  • The speaker requirements
  • The amount of people you're expecting
  • Expectations towards food: sandwiches, pizzas, soda, beers?
I try to contact location sponsors one after the other. This avoids broadcasting the request, to have to turn it down later on. This has never been a problem, as long as response times are low. If you have to wait weeks to get a reply, you're going to end up stressing out once the deadline approaches.

Meetup.com

You can schedule a meetup as soon as the speaker and the date are confirmed.

Opening the RSVP's is best done after the location is also confirmed and not more than one month in advance. You want to avoid people reserving their seat to eventually not show up.

Details you want to include when making the announcement:
  • The date
  • The location and the maximum number of attendees
  • The speaker and the abstract of the session
  • Where to park your car
  • Whether food is provided or not. Include what to expect if possible, so that people with a specific diet can make the necessary arrangements.
  • The agenda of the evening: doors open, start of the session, debriefing
Not all these details need to be present when you schedule the meetup, you can still enrich later on. My own experience tells me I mostly care about the speaker, date and location. I only look at the specifics one week up front.

When you have people on the waiting list, it's a good idea to send a personal reminder one week in advance, asking people to update their RSPV's in case they can't make it. These seem to be more effective than the auto generated ones.

Even with those reminders, you will often find a percentage of people not showing up. Many factors influence the no-show rate. Count the empty chairs, and allow for some overbooking once you get a feel for it. The worst thing that can happen is that the organizers have to watch the session standing up.

Speaker gift

Like Christmas gifts, you also want to think of a speaker gift up front. This doesn't have to be something super expensive, a small token of appreciation will do. I'm going to guess this is a culture thing. In Belgium people often end up gifting each other beers or wine. This isn't always appropriate or practical. Not everyone likes to drink and when you're travelling it's quite literally a burden on your shoulders. I'm actually thinking that something small, like a book with a personal note might be a better idea.

Recordings

Before recording a session, there are a few things you need to consider.

Does the speaker mind being recorded? Some bring experimental content that's rough around the edges which isn't necessarily something they're ready to show to a large audience. Others see it as a perfect opportunity to be able to pitch a conference talk for later on, or to spread their content.

When you announce that the talk will be recorded up front, more people tend to stay at home. They can catch the video later on, but eventually often end up never doing so. Even when they do, they've missed out on the best bits: the interactions before and after the talk.

Day of the meetup

Make sure you set aside enough time in your agenda. You don't want to be stressing out last minute, or God forbid, be late.

Your job is to make the speaker as comfortable as can be, and to think fast when something falls apart last minute.

If the speaker has been travelling, go get him at the station or at the airport. Travel is tiring. Reassure him he can just relax from now on, you will take care of anything he needs. The basics first: is he thirsty, hungry, does he need to use the toilet, an internet connection? You will also help him set up his laptop and put a bottle of water nearby before the session starts.

Arrive at the venue in time, at least 20 minutes up front. Say hi to the host and quick check whether all requirements are met.

Once the first people start pouring in, say hi, point them in the right direction and make some small talk. Once a small crowd has found its way to sandwiches and the social area, you can focus on ensuring the room and speaker are ready to go. The next batch of people to come in will be able to find their way on their own.

Once people are well fed and settled, take the stage and do a short introduction:
  • Community announcements: scheduled meetups, oncoming befriended conferences...
  • Sponsor raffles: software licenses, conference tickets...
  •  Mention the types of sponsoring the community is still looking for: locations, markers, budget...
  • Thank the sponsor(s) and allow them to say a few words if they like to
  • The agenda for the night
  • The speaker(s)
Now the session is well on its way, you can mostly just sit back and relax. Pay attention though. In case nobody wants to go first during QA, you should lead by example and have a question ready.

Once questions dry up, or people are thirsty, thank the speaker and don't forget to hand off your speaker gift.

After the session, the location sponsor usually has a fridge with beverages you're free to plunder. Out of courtesy, you don't want to make it too late and see yourself out in time. Ask the host what time that should be. Usually 30% of the people leave right after the talk, the rest sticks around for one or two drinks. When the time comes to leave, not everyone wants to head home right away. As part of your prep, find a bar that's nearby and easily accessible, where you can gather afterwards in case not everyone has had enough.

Give thanks

Whew, congratulations, you made it! The only thing left to do is to thank the speaker and the location sponsor once more. Give them a shout out in public, and send them a personal thank you note through a more personal medium.

Thanks to the whole DDDBE community for the inspiration and the platform. Thanks to Mathias, Yves, Stijn, GienAntonios in particular for reviewing.

Friday, January 13, 2017

Everyone has to serve somebody, but software has to serve more than one

When people get paid to write software, we very often find some form of friction between the people that build the software and those that pay to have it built.

The company I joined three years ago was no exception. When I joined, they had just launched three months ago, weren't seeing any return on investment and prospects weren't too bright either.

I won't lie, that first year was quite stressful. The business model sucked, the code was even worse. That first year, I wouldn't have been too surprised if the whole team had been let go. In that situation, I could have played it safe, but to be fair, there was something quite exciting about actually having skin in the game and trying to make something out of nothing.

The best thing to come out of this situation, is that each and every engineer acquired a high sense of ownership. When you're a team of only a few people, you have to carry your weight and make an impact. And the only impact that mattered was coming up with changes that would make customers return to us instead of to our competitors. A product without customers, isn't a product at all.

Being extremely customer-focussed, we did set aside many of our own concerns. Both from a personal and technical perspective. We spent too much time at the office, putting in more hours than ideal. We were lucky to have a young team, that didn't have a large day-to-day personal workload though. Since we were also the ones running the operational side of things in the early days, the tooling that was built covered the bare minimum, in a very crude way. On the technical side of things, we played the hand we were dealt. We tried not to make things worse - like treating a slowly healing wound. Improving things when constraints allowed it, still taking the rare short cut when our hand was forced. I still believe today that had we invested in the large technical overhaul the code base deserved - putting ourselves in a position where we would have shipped less features and changes - we would have found ourselves completely pushed out of the market and without a job six months later.

Once things started to turn around for the better, we acquired more and more return customers, but we also acquired a set of customers we didn't anticipate.

When we were still small, we would handle customer tickets ourselves. The owners didn't think the workload warranted another hire. After we threw away the homegrown, not very inviting to use, ticket system, we switched to an off-the-shelf live chat system. This gave us a lot more customer feedback - more than we could manage. Where tickets can be processed in batch, chats are expected to be replied to in real time. Nothing you can juggle in-between programming work, giving us a good reason to hire extra people. For these people to be productive, and actually able to help customers, they also needed access to those crude tools we built earlier. Turns out, those tools didn't really cut it. We needed to listen to their feedback and work towards building tooling that's obvious and easy to use. And there you have it, an extra type of "customer" we needed to satisfy.

But it didn't stop right there. Like a scurry of squirrels after a bird feeder, there was more and more pressure from within the organization to provide more sophisticated tools for the expanding operational needs, like invoicing, content management, customer segmentation, localization and so much more.

So far, we had always put the end customer above all. We had always been very conservative with our technical budgets. We did refactor aggressively, but only changing the inside doesn't always cut it. Larger structural, organizational changes require you to move mountains. Well, more like small hills. We knew the domain and its characteristics well enough to have a pretty good idea where we wanted to go, but the clock had always kept us from making big technical leaps forward.

One could ask: if we have been able to postpone these changes for so long, are they necessary at all? If you would ask non-technical stakeholders, they would probably prioritize the next "one more feature". Hell, they would probably only start caring when the system comes down crashing every few days. Who we should really be asking however is those maintaining the system. If they feel as if they're operating a system that's headed toward needing life support, we should probably pay attention. Eventually something has to give. Eventually you might see your software become a serious liability, or you might see people jump ship even before the tipping point. Engineers are just as much of a customer as your end customer - code is a product too. Engineers also have certain needs you want to satisfy to turn them into happy return customers, who like spending their time, energy and creativity on your product.

It might sound backwards, but even the people you're paying at the end of the month, are very much customers of your product. A monthly pay check might buy you a higher pain barrier, but it's not unbounded either. You might even see some of the most passionate people succumb early on. People on the payroll are as much a vital part of the ecosystem as the end customer. If they don't like being a customer, chances are, your end customer won't either. Highly contagious. While the end customer is still King in this story, to build something truly sustainable for the future, you need to reckon with each and every entity that interacts with the software.