Open Tech Calendar

After your event one of the problems is knowing how you did. I say problems, because this is actually a lot harder than you think.

The problem is simple – most people will not tell you directly if there is something they didn’t like. Instead they will keep it to themselves, or bitch to thier friends, or just not come back. And then you may think everything went great simply because you didn’t hear otherwise.

So firstly, go out of your way to hear bad feedback. Ask people regularly for feedback and always think about what you could improve.

And secondly, don’t boast about how well it went unless you are really sure. There is nothing worse that seeing an event organiser tweet about how they “nailed it” when you know a bunch of attendees went to the pub afterwards and complained about certain elements.

Of course, you may listen carefully to someone’s bad feedback and decide it isn’t relevant. Maybe they want something specific and you are aiming for a different type of event, for instance. How you deal with the feedback you get is a different issue. But always do your best to listen.

ps. And also, real listening often involves a long conversation to get to the real root of the problem and will probably bring up some complex issues with several subtleties. Twitter is not a suitable medium for this. Few electronic chats are. But that’s a topic for a different post.

The topic of audience participation during a talk and the questions afterwards is a well argued one.

Some speakers welcome audience participation during talks. Some would rather talk first and then take questions at the end. It may be worth asking your speakers what they prefer and enforcing it.

Others would prefer the audience never ask questions as most of them don’t add anything. They say the audience can talk to the speaker afterwards. Well, some people will, but some won’t be able to find the speaker or will be to shy to go up and butt in on whatever the speaker is doing. And sometimes, listening in as someone else talks with the speaker can be really informative.

Some let people just shout questions, while some have questions submitted somehow and a moderator pre-approves them.

You’ll have to experiment and decide what works for your speaker and your community. (Personally, I’d happily ban questions during the talk but I think that the questions after can sometimes be the best bit.)

But whatever you do, it must be very well moderated. You need someone to set the tone, and who can then jump in and be strict if needed. The bigger your audience gets, the more important this and the suggestions that follow are.

If a meandering discussion starts that is off-topic or one person starts to dominate the discussion just politely but firmly kill it. “I’m sorry but that’s getting off-topic; why don’t we continue this discussion afterwards? Any other questions?”

If people are shouting questions, insist everyone puts their hand up and be strict about the order. This gives quiet people a chance to ask questions, and stops it becoming a free for all. Or if it’s a smaller event, say “Does anyone who hasn’t asked a question yet have one?” at some point.

Be clear about an end point at which people can leave without offending the speaker and those who choose to stay can start their own discussions.

If people are talking at the back, ask them to be quiet politely. Especially in an un-micced venue it will be hard for those around them to hear the speaker, so they are being selfish. (Also, this may be a sign that the session has gone on for to long.)

Generally speaking, this means the speaker can’t moderate their own talk. It’s possible but if your the one getting involved in a long drawn out ramble, it’s harder to gather the authority to stop it and move on. Also it’s good to have someone with an outside perspective who can see when the questions have gone on for to long.

Also, it’s a tiny courtesy, but I think the moderater has to make sure the audience are paying attention at the start. When you call for attention in a room, it might take a minute for everyone to sit down, finish the remark to their neighbour they were half way through and arrange their bags or whatever. Don’t make a speaker start over that and have to fight for the audiences attention – the moderator should do that for them. Just keep waffling an introduction for 30 seconds or so at the start until you are sure the audience is ready, and then pass over to the speaker.

The worst I’ve seen is one talk where they said strictly all questions had to come in over Twitter and a moderator would ask them during a final session. (So no questions over 140 characters then? Hmmm.) However after one question the organiser of the event started shouting questions from the audience. Because he had done so it gave everyone else a license to do so and before long a drunken guy was slurring rambled nonsense. The moderator said literally nothing after his opening question. I have no idea how it ended – I was one of a sizeable chuck of the audience who just walked out.

Audience interaction can be one of the best parts of an event if handled properly – experiment and see what works for you!

This is the one of several posts about running tech events taken from a talk I gave at OggCamp 2012. I’m not claiming this is the definitive guide on this matter,  but hopefully this will give people something to think about and start a conversation.

When running a meetup, it’s important to establish a clear line of communication with the attendees and make sure that messages are sent regularly. You never know what attendees are listening to.

I learnt this when I was the main organiser of talks for Tech Meetup Edinburgh. One month I didn’t update the website with the speakers as I was very busy and to be honest, I didn’t think it mattered. I was soon corrected by someone who asked me what was happening that night, before politely but firmly pointing out the website was not updated. I could do nothing but apologise.

Every month I email events from Open Tech Calendar to a email list. Whilst normally I email events a couple of days before the month starts, on January 2013 I emailed it on the 4th. This was partly because of the New Year holiday – it won’t matter right? (It was also partly because there was a bug I was hoping to fix before I sent the email.) At a big meetup someone came up and said “I want to report a bug!”. Me sending the email several days late had meant he had missed an event. Again I could do nothing but apologise.

Recently I went to a meetup that was usually in a set pub. Several people had turned up, but not the main people. I asked the staff, and they were confused as several people had been asking after it and they hadn’t been told anything. They knew it was a usual booking, but this month they hadn’t heard anything. They asked me to get the organisers to call them.

The meetup’s own website did not list the latest events – it was two months out of date. Eventually I found someone on the phone who told me it was in a pub across town. Arriving late, I got chatting to one of the people sometimes involved in organising it who airily said “It’s all on Twitter”. That’s clearly wasn’t adequate.

(No names. I’m trying to make a general point, not have a go at anyone.)

Once you have established several clear communication channels, be they an email list or a webpage or anything else it’s important to stick to them. People are watching.

Annnnd this is the bit of the blog post where we start telling you how Open Tech Calendar can help with this problem. We know there is a lot for event organisers to do and they often do a under-appreciated job. We want to make life as easy as possible for them.

By adding your group and adding events in just one place, attendees can get an iCal feed to add to their personal calendar, a reminder email on the morning of the event or an email every time any details change. You can get a widget to place on as many websites as you want that displays the latest events from your group only.

And even better, our open Wiki design means anyone can add events. This way attendees can help out by editing entries and ensuring they are correct for organisers.

A lot of people check us to see what events are on, so give us a try!

One of the things that I think is key to a good technical talk is to introduce concepts instead of getting bogged down in code details.

You see, most programmers are self taught. Which means that if they know something can be done and they want to do it, they’ll just sit down with Google search until they crack it.

So teach concepts instead. The idea will stick in the programmers mind and when they need it, maybe years later, it’ll pop up again.

For example, I found learning Android programming easier because I had seen a talk that explained the basic concepts of the activity life cycle and the intent system that sends messages between activities.

Or the talk about messaging systems that I saw was perfect for web developers. I think when I finally came to use a messaging system I used a different one from the one that was demoed (I used Beanstalkd and I can’t even remember for sure which one was demoed) but what was important is that the talk taught me a better way of moving the workload from the front of your web app to the back end.

So when I was finding talks for Tech Meetup, I would find talks like an introduction to user testing not because I thought all programmers should be experts in it (I wouldn’t call myself an expert) but because I thought every developer should at least know that it exists and the basic concepts.

I’m not saying you should never have any technical details in a talk; sometimes a technical detail or demo communicates the idea much more effectively than words ever will, and its usually more entertaining. But always remember to concentrate on the concept.

This is the first of several posts about running tech events taken from a talk I gave at OggCamp 2012. I’m not claiming I’m always right, but hopefully this will give people something to think about and start a conversation.

This is a repost from my personal blog,