In organising the upcoming Scale Summit unconference, I’ve been reflecting on the history of Scale Camp, and what the purpose and point of running these events was to me.
Velocity Conference starts it all
Scale Camp was born out of a pair of frustrations. As a new developer, I was introduced to the Velocity Conference by Paul Nasrat, one of the Guardian’s system adminstrators. We watched a video by John Allspaw and Paul Hammond about 10+ deploys a day at Flickr.
Many of the velocity teachings were directly applicable to what we wanted to do at the Guardian, so I made a request to attend the conference to the management team.
My request was denied, the cost of the conference ticket, the airflight and the conference hotel would make it just too expensive to send a mere developer. I was also challenged about exactly how much I would really learn there.
That was frustration number one, I wasn’t able to attend Velocity over in California.
One of the issues was that although the velocity conference was aimed at devops staff, and there was a lot I’d learn, there would also be a lot of introductory material. Many conference talks suffer from the same problem, because you cannot be sure about the ability of the audience, you have to assume no more than a basic understanding of your topic. This makes most conference talks into essentially either a 101 level introduction, or in some cases an extremely narrow deep dive.
Frustration number two was the lack of good deep conference material
After being turned down for attending velocity, one of my coworkers, Simon Willison, suggested that I could try running my own event, a London based replacement for Velocity. A few conversations with some london based geeks indicated that there would be interest, so I asked the Guardian to help me run the event. I got to work with Alex Hazell, an amazing event coordinator, and we looked at how to run an unconference style event about operations and performance that allowed experts to have deep technical conversations easily.
The invite system
One of the issues that we saw in the unconference community was that there was a dedicated group of unconference enthusiasts. When a recent BarCamp London released their tickets, they all sold in about 5 minutes. We wanted to ensure that the conference had the right mix of people, and we were worried that tickets selling out in 5 minutes would go to the existing unconference fans, rather than the operations and performance crowd that we wanted.
We talked about different ways of ensuring that the right people would be present to have the right conversations. We decided the best way was to make the unconference invite only. We sourced contacts from everyone that we knew, and opened up a public request for invitations, asking people to give us some background as to their suitability for the scale camp event.
With that list of nearly 200 people, we got together some developers from the Guardian, and we went through the list, putting people into roughly three buckets:
- Known or demonstrable experience of scaling systems
- Experience of small scale, and desire to learn more
- No experience (students, other categories)
We had to ask people to justify why they wanted to come because we didn’t know everyone, and therefore we had to judge purely on their submissions.
We kept a rough 70/20/10 rule, allocating 70% of the tickets to the first bucket, 20% to the second bucket and 10% to the third bucket.
That meant that we would have a strong core of experience people able to lead and initiate conversations, and a smaller group of people who may have stuff to contribute, but will also learn from the event.
On the day
On the day itself, we had a larger than expected turnout, most people estimate that free unconference events have somewhere between a 30% and 50% dropout rate, we had more people turn up on the day than had booked, or had room to fit!
This photo, taken by Adewale, to me summed up the event, instead of a room full of people on their laptops with an expert at the front talking, you can see a a group of people gathered around talking together about a topic. Some of the faces might be familiar, some wont be, but everyone is paying attention and everybody is engaged.
The feedback we got was brilliant, lots of people commented on what a good event it was, and the most common negative feedback was that there was too many good sessions that people felt they missed out on far too much by not being able to attend all of the sessions. In my opinion, almost none of the “greatness” of the event came from my organisation or the event skeleton itself, but because we carefully curated a list of people who didn’t know each other well, had enough experience to engage well in discussion, and who were all experienced enough to learn from each other.
So the next step is to think about the process for the upcoming Scale Summit. Due to sponsor requirements, we ran the last Scale Camp without the invite system, and the feedback for the event was still great, but feedback on the invite system was mixed. Not needing invites makes it easier for people to apply (Justifying yourself puts off great people who suffer from imposter syndrome), but it meant that great people that I would have invited didn’t get to make it because they missed the announcement of tickets.
I’ve thought about using a mixed system, with an invite system followed by an open purchase for a small set of tickets. That would allow for the strong core of community, but also ensure that people can apply. It’s a tricky line to walk, somewhere between being completely elitist and open to allegations of cronyism, and not actually creating a good event.
I think that in my mind, if somebody doesn’t like the way that the invite system works, or thinks that the wrong people are in the room, then I would encourage them to run their own event, and organise it around the people that they would like to see at such an event.
If you have any ideas on how best to get the right mix of people at an event like this, then comments and thoughts are very welcome.