What I learned from organizing a developer conference

At the end of 2014 I had been toying with the idea to organize a conference for the developer group I work with. At the time I had two basic goals:

  • Provide a platform for the devs to have a talk about the cool stuff they are working on
  • Get all the devs together (again)

Now the second bullet might seem a bit odd to put there as us nerds have the unique ability to recognize others on sight, but we've had so many projects move through the building and people moving in and out of teams that it got a bit difficult to figure out who works where. Also knowing your fellow devs makes it a lot easier to solve problems by asking someone you know, to find a sparring partner or rubber duck.

As far as the first goal is concerned, I believe that in our dev group there are a lot of smart people that do interesting stuff on their projects, but also have fiddled with new libraries or tools that could help us build better software. At the regular dev meetings it's always a bit of a challenge to find people who want to talk about these topics, so how was I going to get them to speak at a conference? But more on that later.

The experience I usually have when I get a new idea is that I get really enthusiastic and full of energy you know, that conquer-the-world feeling. Having seen many ideas die a quick and messy death for various reasons I really wanted to avoid that this time around. So one of the first things I did was to pitch my idea to other devs and see if it was something people would like to see, a bit of market research if you will.

I think that from pitching my idea I learned the first lesson: get feedback early

Organizing something all by yourself can be very rewarding if you pull it off but it also means that you need to be careful that you don't suffer from tunnel vision and create something that you might find useful but others might not. One suggestion I got was to join the GoForIt days, our innovation challenge and to gather a group of people to help me hammer out the details of the conference.

Going for it

During the 24 hours of innovation (or: GoForIt day) I worked with a bunch of people (hi Jim, Michael & Henk!) to determine what the conference would look like, how it should be called, how many sessions etc. We had a lot of discussion about how large we should make it, just our dev group? Invite all devs? Do we invite only devs or should we try to get testers (QA engineers) and BA's to join us as well?

I think these questions led to lesson no 2: keep it real.

At first I wanted to aim big: get as many people as we can. 100+ attendees? Yes, please! However as this was the first time this conference is held we decided to manage our own expectations and scaled it down a bit and figured that if we could get about 60 people to show up that would be great.

But getting people to show up, that means having great sessions and that means getting speakers for those sessions. Which leads us to...

Volunteering Inviting speakers

Within any organization there are always the usual suspects who will show up to meet-ups and tech sessions and a number of those will jump to any chance to do a demo or presentation about something. So to make sure I got enough speakers to fill all the slots I had a talk to a couple of likely candidates and pitched the conference idea. Luckily for me the reactions I got were all positive so filling up the slots actually went pretty smoothly...

... until I got a cancellation.

Cue third lesson: always have a backup.

It's a sensible idea to have backups of your data but I think this also applies to basically anything else. Always have a plan B. Think about what could go wrong with plan A, it helps you identify problems that may occur later and to come up with alternatives for when that happens.
I'm not saying that you always (all right, yes I did say always) have to have a plan B but what helped me is that when the shit hits the fan I can think: all right, bad things happen but let's move on.

Luckily I was able to quickly find another speaker who was able to put together a presentation on very short notice.

Timing (and getting people to join)

One thing I haven't talked about so far is the actual set-up of the conference. During the GoForIt we had quite some discussion on how long the individual sessions should be and what the overall conference schedule would be like.

We decided to plan the conference on an afternoon instead of a full day as we thought it more likely for people to show up if it doesn't take up their whole day. We often face quite some pressure within projects that make it difficult for people to join these types of events.

Deciding on the length of a session is always a bit difficult, as a speaker it's easy to fill an hour or maybe even two on your particular topic and I've frequently found myself needing to trim a session to fit a time slot. For the conference we wanted to have enough time for both the presentation and a discussion, we wanted to make sure that the sessions were not just one-way sending of information. We thought that by making every time slot 1 hour that would work out nicely, 45 minutes of presentation and 15 minutes discussion.

Did that work? Yes, I think so. From my own session and the others that I've seen there was plenty time available for people to ask questions which is what we wanted. I did get feedback from a couple of the speakers that filling a 1 hour slot was too much and that it might prevent other people from hosting a session. It's definitely something we need to think on.

Having said that, one problem however was that we tried to cram too many sessions in one afternoon.

When we planned the conference we wanted to have enough sessions and I think we might have gone a bit overboard with that. The conference schedule ended up like this:

Session 1 - Room 1Session 1 - Room 2
Session 2 - Room 1Session 2 - Room 2
Session 3 - Room 1Session 3 - Room 2
Starting at 13:00 and every session taking an hour, plus a break between each session meant that we finished at 17:45. Obviously we didn't think this was a problem but we ended the last sessions with about 5 people in either room... *ouch!*

So I think the lesson here is: plan carefully!

It's easy with a project like this to focus too much on the content of the sessions because that is one of the things you obviously know and care about. But organizing an event is about so much more than just that. I remember speaking to someone from Microsoft a couple of years ago about the TechEd and TechDays events and one of the remarks was that they had to worry even about the temperature of the rooms! Wish I had remembered that particular conversation when I was doing the planning and not now when I'm writing this blog.

The thing we ran in to was that apparently Wednesday is a popular day to work at home or have a day off within our company. So it's likely we would have had more people join if we'd only have planned the conference on, say, a Thursday.

Also I think that most people just found 17:45 too late to stay around, starting earlier on the day would, in hindsight, have been better.

Communication, communication, communication

How do you announce an event like this? We figured that the newsletters that get e-mailed around every month would serve as a starting point, however we have seen that a lot of people just don't read them. To make sure we got enough exposure we decided to print posters and bring the event to everyones attention that way. Also we've got these nice tv-screens in our company restaurant on which we were able to put a promotional video.

The effect of all this? Not a whole lot.

It turned out that when I spoke to people before the conference a lot actually hadn't heard about it, despite our efforts at reaching as many people as we could. I think that we should have communicated the date and the general theme of the conference a lot sooner than the couple of weeks before we did.

I think that we also could have used the various team managers and lead developers more to promote the event and to encourage other people to join as well.


The question that kept running through my head during the conference and afterwards at the drinks was: can I call the conference a success?

I think I can safely say yes. We had great sessions, people actually turned up to watch them and the overall feel was great!

Would I do this again? Oh yes! It has been a great experience for me and I think I've learned a couple of valuable lessons in organizing the conference.


All right, this isn't an award ceremony but I would like to thank a couple of people, Michael & Jim for the brainstorms and pulling this off, Henk for the reality checks, Wouter for being our fairy godfather and all the speakers for their enthusiasm.