NOEL:  Hello and welcome to Episode 39 of the Tech Done Right podcast, Table XI's podcast about building better software, careers, companies, and communities. I'm Noel Rappin. This is an episode I've been wanting to do for a long time. In this episode, we're going to talk about technical conferences with some of the best conference organizers I know. We're going to talk with Marty Haught who's helped organize Ruby Central's conferences for many years, Jim Remsik and Jen Remsik have organized Madison Ruby and the whole family of Madison conferences, and Leah Silber who's organized for Ruby Central and also organizes EmberConf and RustConf. 

Before we start the show, a couple of quick messages. Table XI is now offering training for developer and product teams. Topics include testing, improving legacy JavaScript, career development, and agile team process. For more information, hit our website at TableXI.com/workshops which is brand new, live as I record this. We also have a free email course and tools on improving your company's career growth and goals strategy. You can find that at StickyNote.game. And now, here's my conversation with Jen, Jim, Leah, and Marty.

This is I think the largest group we've ever done for something that wasn't a live panel on this show. And so, let me have everybody introduce themselves. I have Jim and Jen Remsik.

JIM:  Yeah, I'm Jim Remsik, with Adorable.

JEN:  Hi, I'm Jen Remsik, with Adorable.

LEAH:  That's adorable. Sorry. 

JIM:  No worries. And together we've been putting together Madison+ Ruby for the last eight years or so. Took a year off there. And then we also put together Snow*Mobile and Madison+ UX. About 13 conferences over eight years.

NOEL:  And we have Leah Silber.

LEAH:  Hi everybody. I have been working on events in tech since somewhere around 2006 I think, which makes me officially incredibly old. I'm the CEO of a company called Tilde. We build Skylight which helps with performance of Rails applications. And these days my big conferences are the annual EmberConf and RustConf. I've been doing RailsConf for the past 10 or so years. I did jQuery conferences for a number of years since the very beginning of jQuery until some point in the middle there. I don't keep track anymore of how many because there's too many. But it brings me a lot of joy to help bring people together and give communities that face to face opportunity to grow and get to know each other.

NOEL:  And I also have Marty Haught.

MARTY:  Hello. Marty Haught. I run a small consultancy called Haught Codeworks. And for organizing, I am a director of Ruby Central, one of three. And we run the RailsConf and RubyConf conferences. And I've been doing conferences since 2007 so it's been 11 years for me. And I started with Mountain West RubyConf then moved to Rocky Mountain Ruby which I ran by myself, which is not recommended. But then moved on to being a director of Ruby Central. And I will be the program chair for RubyConf in LA, in November.

NOEL:  So, that is a lot of experience in running technical conferences. So, it's always seemed to me to be a kind of a thankless job, or at least a job where you can get blamed for a lot of things. What's something that people don't notice often that you really like to get right, that you think is important to the success of a conference?

JEN:  I remember when Jim first approached me about planning our first Ruby conference. And he's like, "There are three things I want us to make sure we get right. The food, the wifi, and the programming." And I'm like, "Okay. I know how to handle making sure we have wifi and food. I need you to do the programming, since I don't know programming at all." And that's kind of how we divided up the tasks for planning our conferences. And we keep those three things in mind all the time.

LEAH:  I think the whole experience is really just an exercise in empathy. And in every step of the planning, you need to think about what you're attendee is going to be experiencing in that moment and how you can make that most efficient, most enjoyable, and most likely to be successful. And I think the difference between the conferences where you really feel like everything was together and the conferences where you feel like a whole bunch of people got sort of haphazardly thrown in a room together is how much of that the organizer does. Did they stand in line at the restroom and think about where that queues up? Did they think about, when people are walking out of this room, when people are walking out of that room, are they going to walk right into each other and cause a traffic jam? Is there enough signage? 

It's really just like a collection of all of the little things on the logistics front and then a similar collection on the people front, which is to say make sure that you have an environment that makes everybody comfortable. Make sure that you have an environment where all different kinds of people are represented. Make sure that the people that you're putting on stage are a good representation of everyone who's going to be there. So, everyone in the audience can feel like, "Oh, I'm welcome here. People like me can be successful here." And a combination of all the little things on the side of the people and all the little things on the side of the logistics really come together to form a very solid, put-together experience where people feel curated at every step along the way. 

And so, I think it's just a matter of how much bandwidth can you devote to every tiny little thing? And really, every time that you do another conference, the volume of things that you're going to be doing and the volume of things that you're going to be focusing on is going to grow and grow and grow. Because a lot of the things you have to really experience in order to understand how to handle them well and in order to iterate on the creative solutions that make people feel better and have a better time. So right now, when I think back on my first conferences, I don't want to say I'm embarrassed but I've come a very, very long way. And a lot of that was stuff that I just had to figure out for myself along the way. 

MARTY:  I can kind of riff on that because that was kind of where I was going to follow up with Leah. Because Leah provided a very, very great answer that way. Certainly with Mountain West in the beginning it was the first regional Ruby conference that came out. And we just didn't do quite as much. The bar was fairly low. We focused on certain things that were really important. And there's a lot of things that, especially with a brand new conference if you're brand new to that, you just don't know yet. And certainly when I started Rocky Mountain Ruby, I had other things that I wanted to do that we didn't have time or didn't dedicate energy to at Mountain West. And I went into that. And certainly, when I think about what we do at RailsConf and RubyConf, there's a lot more. But as we've gone along, we nailed this or we got that down. And now we can say, "Oh, great. Let's tackle childcare. Or let's tackle diversification or scholars and guides and these nice add-ons," once we've felt like we got the basics down.

LEAH:  For sure, by the way, the barrier to entry for new conferences and new organizers is higher because of how much iterating everybody else has done. So, when I first started getting into events, you were considered a successful and inclusive event where people would be like, "Wow. You care a lot," if you bothered at all to have vegetarian food. And now, fast forward 10 or 15 years, and on the food front it's like vegetarian, vegan, kosher, halal, all the possible dietary things. And then that base has expanded into considering all the needs of all the people on every level. So like, childcare which Marty mentioned is not something I would have even thought of. Like it wasn't even on the radar 15 years ago. Something like closed captioning or live sign language or just right now that every time I build a website for an event, there's of course a section that talks about accessibility and "How do you get in if you have a wheelchair?" and "What do you do if you need this?" and "Where are the all-gender restrooms?" 

All of these things, admittedly they can be a little bit intimidating for a new conference organizer so that's what I meant when I said that the bar is a little higher. There are a lot more things that people expect. But it also means that events that are put on by today's standards are really ticking off a lot more boxes and really making a lot more people happy and able to attend at all. Childcare, closed captioning, things like that are all things where for a lot of people if you don't have them you simply cannot attend. And then there's the smaller things that in theory people can attend. Like Marty mentioned the guides and scholars program. A lot of the events that we're all going to talk about today probably have some version of a program that basically makes it so new conference attendees aren't so intimidated by what's going on, whether that's pairing them up with a mentor or if you call it a guide or scholar or whether it's having a reception where they can meet people. There are people out there who would look at a conference and say, "I'm new to the industry or I'm young and new to professional environments altogether or I am some other version of new to the scene and I'm too intimidated to attend." And now you have all these programs that are like, "Okay, now that group we're tackling. Here's a way to help ease your on ramp so that you have a better experience." 

And so, I think conferences in our corner of the tech world are just much more inviting right now and inclusive. And inclusive is a word that people like to use because it's a buzzword. But on the planning side of things, it's a very tactical list of objectives that you have to figure out how to deal with. And how do we make sure that this type of person is comfortable? And how do we make sure that this type of person is comfortable? And how do we make sure that these types of people are represented? Et cetera, et cetera. And we just do so much more of that these days that I think it's a large part of the workload of running a conference. And I think it pays off. It's absolutely worth it. 

JIM:  And every time that you iterate, you wind up both making a better conference but you also signal for the future, this is what you should expect from conferences – either from this conference or other conferences that we run. And so, you wind up building up expectation for yourself as well as Leah said, other conferences around you.

LEAH:  Yeah. I'm not, not empathetic by the way to new conference organizers who see these more established events or more experienced organizers and think to themselves, "Ooh, now I don't know if I can do that." On the one hand, I want to encourage those people. On the other hand, it's really important that the art of planning a conference itself is now able to be seen as a distinct set of skills versus beforehand where it was just like, "Oh, I'm a Ruby developer and I like Ruby. So obviously, I could run a Ruby conference, right?" It was nice. And those days were really helpful to bootstrap a lot of things. But now that we're further ahead, it's also nice that it's recognized that this is an entire set of skills and logistical expertise. And that makes room for people who maybe aren't Ruby developers to have a place in our community for example, but also just encourages getting better and building it up as a skill like you would any other. 

NOEL:  How hard is it to deal with the budgetary aspect? I think that's the aspect that I probably know the least about in terms of putting on a conference. Is it something where you feel like you're constantly scrambling against a limit? How hard is that part that the attendees really, really don't see?

LEAH:  I would for sure say that that is a perfectly timed question with the last one, because the earlier you are in terms of your experience doing this, the more stressful it can be. And the further ahead you are, the less stressful it is. First of all, because you get a chance to build up a store of funds, assuming that you're able to turn some kind of profit, even if it's a small profit every year. You put it away in the bank and then you have a little bit to pay your venue deposit next year and bootstrap, like any other bootstrapping thing. But also, the more experience you have and the more history your event has, the more you know that people are going to show up and the less the risk is. So, it becomes less stressful. You also get better because you have your vendors lined up. And ideally, you have venues that you've worked with before. Everything that you can push repeat on instead of starting anew makes your life easier as an organizer. But it also makes your life safer as the financial backer of an event like this, because things are more predictable. You're less likely to have a vendor duck out at the last minute or not deliver the product that you purchased from them. So, it gets easier. 

It's also very much about organization. It's not like a haphazard collection of receipts sitting in a drawer, certainly not if you want to do it well and not have it be a tremendous financial risk. There's a lot of I think exciting but still, exciting spreadsheets and calculations involved in behind the scenes of a conference. And also, a lot of reasoning off-spreadsheet about the money for example. Like, "Well, my prices have gone up X, Y, Z. But can I actually raise the cost of the ticket? How are people going to perceive this? How is this going to make things more or less accessible to newer developers or people who can't afford a really expensive ticket or people whose employers won't pay for them?" I personally enjoy that side of things. And there should be someone in every conference team who does enjoy it, because otherwise it can suck the fun out of it for the people who are in it for the other sides of it, whether that's program planning or logistical work or all that kind of stuff. 

MARTY:  I'll add a little bit to that. Certainly it's a very different experience from say Rocky Mountain Ruby to RubyConf or RailsConf. It's an order of magnitude there, really. And certainly early on with Rocky Mountain Ruby, I was very, very cautious. I just tried to make sure I kept my costs down because there was a lot more unpredictability about how many sponsors would come on board. And would we actually sell enough tickets to not lose money? And so, it was pretty nerve-wracking in the beginning. Luckily, there was enough success and drive and interest that we never ran into any problems. But certainly it was something that I kept in mind. For RailsConf and RubyConf, they're a well-oiled machine. We know roughly what to expect in terms of ticket sales, what to expect from sponsors. The sponsors can vary. And you have to be ready and have that budget in case you don't get the sponsors you expect or if somehow there's a drop off in ticket sales, that you're still going to be okay and you're not going to lose too much money on an event.

NOEL:  Jim and Jen, you both just took your event out of its local venue with all of your local vendors. You ran Madison Ruby in Chicago. How complicated was that from an organization perspective?

JEN:  It was terrifying. [Laughs] Just like Leah said, when you can hit repeat on something, it makes things so much easier. So, I had five years' experience working with venue A and catering A. And when I told them I need coffee and a lot of coffee, they understood what I meant by 'a lot of coffee'. And they would be completely prepared. With this planning in Chicago, and I'm working with our event coordinator Shaun and I'm telling him, "Oh yeah. We need to find somebody to take care of coffee," and I'm like, "And we need a lot of coffee," he's like, oh he's thinking like five or six of those coffee joe containers that you get at Starbucks. And I'm like, "Wait a minute. Here's the invoice of how much coffee we spent when we had 200 people for 2 days at the Overture Center. And we had 40 gallons of coffee. And he's like, "Oh. Yeah, we need a lot of coffee." [Chuckles] So, explaining that, the fact that I could go back and pull up the old invoice and actually look and see how much we had, explaining that to him, making him realize what I meant by 'a lot of coffee'. 

It was also an interesting experience too, because this was the first time we were in a venue that didn't require us to use their preferred caterer. So, we were able to do a lot more experimenting and we were able to bring in other elements that we wouldn't have normally been able to bring in. so for instance, we had donuts from Doughnut Vault. When Jim and I are in Chicago, that's one thing we always do is make sure we get a doughnut at least once from Doughnut Vault. And we wanted to share that experience with our attendees. And a lot of our attendees were from Chicago. Some of them were still outside. So, that was one of the elements that we incorporate with Madison Ruby was we try and incorporate the city into the event as well. So, that was our way of doing it with having the event in Chicago. 

Jim, I think you might have had a different point of view on bringing it to Chicago. 

JIM:  Yeah. As Jen said, we've had previous attendees from Chicago and we know that community pretty well. To me, it was the venue was the big question mark. We had a venue that was selected and then approximately six weeks before show time, we lost that venue. And so, we reached out to folks in the Chicago community. And they actually, folks that run conferences in Chicago, and they actually delivered us a list of, "Here's 140 venues and all of the seats available and all the features that were important to them." And so, we wound up finding the Newberry Library which was a fantastic venue for us.  At the same time, it was so different from Madison Ruby's past, we didn't know how well it was going to go over. And so, there were a lot of unknowns and a lot of things that we weren't hitting repeat on. We actually signed a contract for Newberry without Jen or I having visited. We had sent Shaun who works with us down there. And he's like, "Two thumbs up." After we did that, we realized, "Shaun's actually never experienced Madison Ruby." But it wound up turning out well. At the end of the day, the important thing, you're in this situation. Think about how your attendees are going to have that experience in that space and just turn the dial up as much as you can and take as much into account as you can.

NOEL:  I guess for lack of a better word, the spine of a conference is the program. It's not the whole thing, obviously, but it's the thing you put on the website. It's the schedule. It's at least on paper, the function of the conference. How do you approach putting your program together? How do you approach your CFP? How do you approach your selection process? What's important for you in putting that together?

JIM:  I want to say in addition to the program, after you've done a conference for a little while, you start to build a community around that event as well. So, program is definitely the spine but we talked about Madison Ruby as it's not so much a place. We have Madison in the name. It's not so much about the place any longer. It's about this audience. 

NOEL:  Yeah. Well, I think in the specific case of Madison Ruby, it was definitely the case. There were definitely people who came from around the country because of they felt part of the Madison Ruby community and felt that it was important to them.

JIM:  As far as programming, we tried PaperCall for the first time this year. And it worked out pretty well. We did blind submissions. We were explicit and told people, asked our submitters not to include identifying information. And there are some things – either a person's given a talk before or they're just tightly associated with that topic that it's hard to completely pull them away, but we have a history of bringing in new speakers and being open to that. We have a history of bringing in topics that you might not see at technical conferences. And so, there's sort of a whisper network that gets people to submit talks that they wouldn't otherwise submit. But we do have a completely blind submission process. And we typically will grab a collection of people, different people every year, and we want them to be representative of the audience that we would like to see in the seats. And we have those people review them, upvote talks that they would like to see. And I do a final curation at the end trying to pull out duplicates and things like that. 

NOEL:  Marty, what do you like to see when you're putting together the Ruby Central conferences?

MARTY:  Yeah. I guess there's a few things to mention here. We had an established program, or at least a shape of a program that we usually stick to. We establish a program committee to help form what the new conference is going to look like. Are we going to make changes or are we going to stick to the same formula? That committee is made up, it's a rotating group and it's made up of people that are active in the community and we feel are going to be good voices, good leaders of the program. And we try to make sure it's also a pretty good representation of all the folks out there, both experience level and from a diversity standpoint, so that we can make sure voices are being heard at the conference. In terms of some of the specifics, we do primarily a call for proposals to bring in most of the program. But there are some invited content. Certainly the keynote speakers are selected by the committee. Or at least I should say we identify who we'd like to invite and go through the process – if they're available, if they're interested, and all that. Typically we have four to five keynote speakers at both conferences. 

And so, some of them are kind of standard ones. Like Matz is always going to open RubyConf and David usually opens RailsConf. So, some of that's kind of set and we rarely touch that formula. But we always talk about it. And I like to let the committee do its work. Certainly as chair for RubyConf, we're about to put together the committee and starting the program in the next month. And it'll be exciting to see where we go with that. But our process is fairly set in how we work. We have our own CFP app that Ruby Central built and put out there. It's open source. It's on GitHub. And we have a new version of it that very soon will be merged in and available to everyone to use. But we use that primarily because our flow is fairly complicated with a good 8 to 10 people involved in the selection process. And it just is a lot of steps that go into finalizing the program. 

LEAH:  Contrary to some of the stuff I said earlier where the barrier to entry is higher, I feel like on the program side of things, the barrier to entry is actually lower because there's so much canonical wisdom now about how to do it and about the mistakes to avoid. And there are also so many tools, like the CFP app that Ruby Central built, which has been out for, I don't know, four or five some years like that now. More paid tools. I think PaperCall is a paid tool. But in 2007, it was like, "Okay, let's build a brain trust of two or three people who are going to work on this. And then they're going to come back to us with a list. And then we're going to go to those people and we're going to hope that they say yes." And if we're really responsible, we'll have a list of backup people. And then at the end, ta da, you have an agenda. 

And a lot of those agendas were even decent, because hopefully you select well-qualified people to make those selections. But as we all know, that kind of a process doesn't really leave room for number one, new people to be discovered who maybe aren't well-known or well-networked yet; number two, it leaves a lot of room open for accidental biases to sneak in; and number three, it doesn't let those spontaneous creative thinking things happen, like the kind of things where your CFP is open now and a talk rolls in and you're like, "I never would have thought of that but that's going to be amazing. Let me accept that talk." So, on that front, I think things have gotten a lot easier and a lot more accessible. And a lot of the people like all the people on this call who have done it have also written blog posts and books and posts and whatnot detailing their process. So, you can sort of step into your first event on this front and be 90% of the way there in terms of all the things that took us five, six, seven, eight, ten years to really perfect. And hopefully, you can still even continue to perfect it. 

And there's still that matter of taste that will influence the final things. Almost all conferences will do their keynotes as invite, even if the entirety of the rest of the program is submitted. And so obviously, you have to make good popular and surprising and innovative decisions on that front. But it's just a much easier thing to do really, really well. 

NOEL:  It seems to me like the difference between conferences in that respect now is as much about the kind of outreach that they do to get people to submit to the CFP. Since I feel like most conferences or a lot of conferences do some form of a blind or mostly blind process. So then, the distinguishing factor is how well you get the word out as to what you're looking for and to what audiences you promote yourself to.

LEAH:  Yeah. And the fact that you're saying that is massive, because it took a long time for people to agree and acknowledge that that was correct, especially when you're thinking about how to get a more diverse program. Like, people think that you magically open it up and in some communities you just have all of the people. And they all just in a representative single-file line sign up to give their talks and you choose one from each pile and wow, we all live happily ever after. But it's really, really not like that. And especially if you're committed to having underrepresented folks represented in your program, you have to do a lot of outreach and you have to do that outreach and that investment way earlier than opening your CFP. Your CFP is going to be open for, I don't know, four to six weeks. But if you really want to tackle this, you want people thinking about it a year in advance or two years in advance. 

And that's the amazing part of what you can accomplish when you're doing an event over and over and over. Like I start EmberConf literally the day after the previous one ends. We announce the dates of our next year's conference at our previous year's conference. In Ember in particular, one of the efforts that we have is the Ember Women Helping Women program. And that's in its fourth or fifth year where we previously had women represented on the agenda but it wasn't enough. And I didn't feel like we were being true to our community and were really doing a good enough job or building not just a diverse agenda every year but a diverse leadership team in our whole community that would make that continue on in perpetuity. And so, the Ember Women Helping Women program hosts events and podcasts and hangouts and whatnot. We have an email chain list all year long. And all year long it's like, "Hey, our CFP is going to open in six months, in five months, in four months." And all year long, it's people saying things like, "I gave my first conference talk. Let me tell you about it," or, "Does anybody want to bounce ideas off of me?," or, "What can I do to do this?" or, "I'm so nervous about getting on stage. What advice can the rest of you give me?" And now five years in, we have a really, really strong community of women helping each other take that step and getting into doing conference talks at all and expanding out to other conferences as well. Like, "Oh, you want to talk at EmberConf? Why don't you start with this meetup. Why don't you start here? Why don't you start there." 

And it becomes pervasive, for all the reasons that we all know. If you show up at a place and you see someone that looks like you and you see them being successful and you see them being respected, your brain sort of knows, "I can do that, too." And then when that CFP opens you think to yourself, "Why not? I can do that, too." The stakes are also low. Like that needs to be part of the messaging. It's okay. If it doesn't get in, that's fine. And that's part of why I like the iterative process that the Ruby Central app has. Because you can give people feedback along the way. And so, a big part of the messaging for us is, "Hey, submit your conference talk. Even if it doesn't get in, we're going to help you make this better. And maybe you can take all that work that we iterated on together and submit it to another conference." And it just pays dividends forward. Every little bit that you do influences your conference and the next one and five years down the line. 

NOEL:  This is probably a good place to mention that I have spoken at and I've also been on the programming committee for the Ruby Central conferences. And I also sort of more or less openly help people with CFP, with proposals, if they ask me over Twitter or through my website. So if people are interested, I also have a pretty good success rate in helping people. 

LEAH:  The way that you said 'openly' made it sound like, "It should be a secret. But I am confessing. I will help you," which is not the case. Everybody should help everybody and that's how you do it. 

NOEL:  Yeah. That's why I do it. I feel like as a speaker, it took me many years to figure out how to craft a proposal. I was comfortable with speaking in public long, long before I was comfortable writing a proposal for my speaking. And I feel like there are some tricks there that a person can get better at that is somewhat orthogonal from the actual act of speaking at a conference.

LEAH:  They're two totally different skillsets. And that's part of why I've been really excited to see – I've never made it, so I don't know if the event is wonderful. I hope it is – but things like Write/Speak/Code which are just like, "Let's get together and work on the art of crafting a conference proposal." Because that's a skill to master. And it's not just that when you see the same people over and over at conferences, it's not even always that they're the best speakers. In a lot of cases, it's that they have cracked the nut on how to write a proposal that will get accepted. And there are a lot of things that people don't think of. Like we see a lot of conference proposals that are trying really hard to be witty or funny or to wrap some joke into the title and the abstract where because the proposer has put so much effort into that, I can't figure out what they're actually going to talk about. The content is not in there. And that's just a trick. From the surface, you see clever ones and you think, "Oh, if I write something clever, I'll get in." But once you have a little more experience, you recognize that, "Maybe I can sneak a joke or two in. But the main thing that I need to do here is actually communicate what I'm going to be saying on the stage, what people are going to be learning, things like that." And it's like learning how to write an essay in high school all over again, right? You have to learn the formula and then you can do it.

NOEL:  Yeah. The thing that I used to do for years actually was leave out the actual meat of the talk from the abstract on the theory that I didn't want to give away the surprise of attending the talk. 

LEAH:  Yes.

NOEL:  What I would wind up with were abstracts that basically said nothing and therefore nobody would pick.

LEAH:  Surprise, by the way, is overrated. People don't really need to be surprised. So just tell them the good thing they're going to learn and then they'll show up to learn it.

NOEL:  Yeah. That took me many years to figure out. So, one thing that people who attend conferences will say is that the real action takes place in the hallway. What kinds of things do you do when you're organizing a conference to encourage and enable people to interact during the conference? What can you do to make that better from a conference organizer's perspective?

JIM:  I think one of the best things that you can do is give them time. So, we  developed a cadence, which is for all practical purposes two half-hour talks followed by a half-hour break. And we occasionally get feedback that that's too much time, typically from folks that are wanting to be less extroverted and have content pushed to them. But the other thing that we do is we give a good chunk of time for lunch. And we encourage people to, in Madison and in Chicago both, we push people out of the venue to go explore the city around them. Ideally, you're going to have some local folks and you're going to have some folks from out of town that's going to give them this common chore to do together. How am I going to get food? We tend to provide options and what have you. But giving them that exercise to do together has been wildly successful. 

MARTY:  Yeah. I would say that kind of following on Jim's comment is that you have to give them space. And that's both in terms of schedule and timing and opportunity when they can actually do that, but also physical spaces that are conducive to hanging out and chatting. And we think about that when we're choosing a venue for one of our conferences and how we lay out the conference. Where you're walking, where can people gather? Will there be a bottleneck there? Will they be comfortable? We have a decorator that brings in furniture and we'll say, "Okay, we want these kinds of couches here because that will be great for hanging out here," or, "Let's have these tables or a quiet room set up over here so people can do that sort of thing." They have that option. And the other thing I would say about this that we've noticed with our conferences, because our conferences are multi-track or many tracks, you can't see all the content. It's not possible. 

And it's very different from when I ran a single-track conference where it's a joint, shared experience, it's wonderful. With something like a RailsConf or a RubyConf, there's just so much going on that it actually gives people permission to skip stuff. Because we record everything. So, you can watch the videos later on. And so, if you have a really fantastic conversation after a talk, you might skip the next talk and stay in the hallway and just chat for 30 minutes with this person that you just met at this last session. And so, I think it is very important that as you're laying out your program and as you're laying out your venue space, you think about how is that going to happen? Are you going to encourage it? What sort of events outside of the actual program are going to be part of the conference that may be conducive to that as well? 

JIM:  Back in, oh I want to say 2012 maybe-ish, I went to this conference in Colorado where they gave out a card game for people to play. 

MARTY:  Yeah. You know, I didn't factor in when I was building that game, I didn't factor in the fact that people just trade with their cards. They just give away their cards. And that ruined the challenge of it. But that's okay, because it made for a very interesting experience to how do people tell stories and use those cards for fun? 

NOEL:  One thing that you guys have done in Madison is not so much this year but sometimes in the past is do group improv or group mixer activities upfront. How do you feel about that? Do you think that that works? Is it worth considering in other venues?

JIM:  Yes. Yeah, in years past we've brought in Jessie Shternshus. She's from the Improv Effect and she's always been fantastic about finding the right collection of exercises to get everybody engaged and pumped up at the start of the conference. We weren't able to bring her to Chicago. We were having so much new going on and having questions about budget and whatnot and how much things were going to cost. We weren't able to do it. But I highly recommend doing something like that. And in years past she had done paper plane contests. She's done rock paper scissors where you basically play against the person next to you. Then the winner of that goes and plays the winner of the person next to you. And it gets everybody up. It gets the energy in the room up. And people wind up meeting that wouldn't otherwise meet. And it's been fantastic. And would highly recommend it. 

LEAH:  We do things like that as part of our mentorship program at EmberConf. And they're always wildly successful. But one of the challenges is that getting to know people is best done in a more intimate environment. I'm referring to not the room, but the volume of people in it. So, we have – our mentorship program is typically limited to 50 or so people. And we have a lot of success with various activities. Our more popular thing that we've done has been a speed friending kind of event, effectively the way speed dating works but you're meeting other community members where one side of the table is all more senior members of the community and one side of the table is more junior members of the community. So, it really helps a new person who's showing up come to conference morning already knowing 20, 30 senior people, 20, 30 junior people, and feeling like the room is already friendly to them. But the challenge for us has been that goes so well every year that we have too many people who want to do it. And in theory, I could expand it. But if I expand it, that makes it less good because you don't want to be in a room to meet 200, 300 people. 

And so, it's kind of like every year I'm struggling with, "Should I have three tracks of this going on in rooms adjacent?" And obviously the logistical complexity increases. But it is a really nice thing to be able to do to give people an opportunity to comfortably meet each other, get to know people, feel like they belong, before they get to the actual main conference itself so that then they can take full advantage of that experience when they do get there. 

JIM:  One other thing that I've noticed in the past is when we do workshops before and specifically when we do a Rails Bridge before the conference, that gives people who are new to programming this large group of people that they're introduced to. And again, they have this common goal that they're working towards. That's been really helpful and led into much more valuable experiences at the conference proper. 

LEAH:  It's kind of like your cohort in a school program or whatnot. 

JIM:  Absolutely. 

LEAH:  And that's a meaningful connection for people. A challenge that I've been struggling with a solution to on that front is when you pair something like an X Bridge – because the Rails Bridge has expanded into other communities already – when you pair something like that with a high-skilled professional conference, you end up with a weird juxtaposition of, if I need the Bridge program, that means that I don't really know enough to get value out of a lot of the conference program. And so, people aren't sure whether or not to do it. So, we'll end up sometimes with people who come to the Bridge program but don't buy a ticket to the actual conference, or people who come to the Bridge program and have a good time but then feel a little bit lost in the conference itself. And I'm not sure that there is a real answer there. Because in fact, it is pairing a super, super beginning of my career thing with a potentially super, super more later in my career thing. And it's hard. Most of the content of the conference is not expecting people who learned how to work with the technology the day before. And I'm not sure what the answer is. It doesn't lead to horror stories or anything. It just feels like it's not fully optimized yet. And I'd love to – I don't know if any of you have any good ideas for what's in the middle there to make it so you feel like you belong in both of those places and have a really good time. 

MARTY:  I think the only thing I would say there, and I don't think this is a direct answer, is that our guides and scholars program is probably the closest thing I've seen to covering that gap. And just to briefly explain guides and scholars, the idea is that people who apply to be a scholar, they get a free admission to the conference and they get support while they're here. And they're usually very, very new to the industry, to conferences in general, and probably to their programming language. I don't think any of them quite are at the, "I haven't used this technology," level. So, that's a little different. But they are brand new. And the guides are experienced conference goers and basically mentors in the space. And they allow these people that are new to have a really good experience. And some of them have, when we've collected feedback after the event is that they couldn't quite grasp all the conference. But they got enough of it. And they felt welcome and they felt encouraged. So, even though they didn't get most of the content they were happy to follow up. 

NOEL:  Yeah. Speaking as somebody who's mentored in that program a few times, one of the things that the mentor can help do there is steer the scholar towards talks that are going to be more likely to be meaningful. Because I feel like the Ruby Central conferences have a range of programming. And to occasionally sometimes say like, "Go to this one. You're not going to understand all of it. But there's going to be something there for you to think about, even if you don't understand it."

MARTY:  Definitely, definitely. 

NOEL:  Also for what it's worth, we went on to hire somebody who was not my scholar at RailsConf last year but was also in the program when I was mentoring. So, it works out in that way sometimes, too. 

MARTY:  It does. We've seen a lot of involvement of scholars getting really involved in the community and giving back. So, I'm very, very happy with the success of that program. 

LEAH:  It's good to start people off on the right foot rather than halfway through their journey into your community planting the idea that they should be giving back and that they can make a meaningful contribution. And if somebody's first interaction is something where they've been paired up with a mentor and someone has focused specifically on making sure that they have a good time and feel welcome, again that's just going to roll through the community. And after X number of years of that being the case, hopefully you end up in a place where everybody at every level of the community is behaving like that because they've started out correctly and then set the right example for the people coming behind them.

NOEL:  Cool. We're sort of coming up on time. Is there one or two other little things that you've learned, something that was much more successful than you expected? Like the one weird trick clickbait thing that you would say about running a conference?

JIM:  So, two things. I think Marty already alluded to this. Don't do it alone. A, there's no reason to do it alone. And B, if you at all possibly can, find somebody who has done it before and bring them onto the team. Bring them on as an adviser. You don't have to listen to every decision that they – you don't need to let them make all of the decisions but just soak in some of that knowledge and listen to them and hear where things have gone wrong for them before or where things have gone really, really right. There's no substitute for that experience. 

MARTY:  Yeah. I would follow up with that. Definitely ask for help. I probably am guilty of going alone too often in my past that if I'd just asked for help, it would have been easier on me. And that would have been nice to have gone that direction. So, I think that is one thing to mention. The other thing is that conferences vary quite a bit. And if you're thinking about getting into this, think about the experience you want. Why are you doing this? What are you trying to accomplish with your conference and with your program? And pay attention to what people are doing out there at other conferences and what you like. And just be very intentional about that piece. And I think that's the one thing I would say, is make sure you're following that. 

LEAH:  Yeah. I would say don't think about running a conference unless you think that it is a hard thing to do. Because the bad events tend to be the ones where people underestimate the complexity and underestimate the logistical overhead and just think, "I can throw a bunch of people together in a room and they will have a good time." Maybe they will. But you really want to do better than that. And you really have a responsibility, especially if you're going to charge people money to attend an event, you have a responsibility to give them a good time, make sure they get value for their money, make sure that nothing goes wrong. And all of that is totally doable if you do the work. And if you don't recognize the complexity, then you're not going to do the work. 

So, just know going into it that it should feel a little bit intimidating and there are a lot of moving parts. And if you pay them adequate attention, you can do a good job and you can have a really great time. And if the idea of that, if the idea of lots of spreadsheets and details and vendor relationships, if that kind of stuff doesn't appeal to you, you might not be the right person to run the conference. And maybe that means you should have a partner who can focus on that, because you're really passionate about the program or some other configuration of humans. But all of that stuff is part of the grand equation that will make it be successful. So, don't undertake it unless you are excited about all of that or have additional people who are excited about the various little parts that will all come together to make your event successful. 

JEN:  My bit of advice would be that you don't need to sell out a two [hundred] person venue right away for your first event. You can do a really great conference with just a smaller venue with 50 people. Because once you sell out an event at 50 people, you have bragging rights for the next year and say, "We sold out." And it's hard to get those bragging rights if you already aimed for the moon and you're already going for a 200-person venue. And my other bit of advice would be when you send out your feedback survey, if you get a few people that are really harping harshly about a particular element about the conference that they didn't like, invite them to be on the committee to make it better the next year. And I've done that three times. And all three times, the individuals are like, "Sure, please. I would love to help with that element for the next year." And then they did help. And they came back to me and said, "Wow, that is hard." So, it actually gets them to understand and appreciate more. But like, "Yes, I'm getting your feedback. I hear you. Please help us." And then they also then appreciate how much work does go into it. 

NOEL:  Great. Thank you all for being here. Where can people reach you if they want to continue to talk to you about conference organizing or anything else?

JIM:  I'm available on Twitter @jremsikjr. My DMs are open. 

MARTY:  Yeah. Marty Haught. Twitter's probably the best place, so @mghaught, H-A-U-G-H-T. And my DMs are open as well. 

JEN:  I prefer emails. So, jen@adorable.io. 

LEAH:  Folks can feel free to reach out to me in me email just as leah@tilde.io. I'm @wifelette on Twitter. I hesitate to mention this because I don't like the concept of shameless self-promotion but it's not really about that. I wrote a book a couple of years ago called 'Event Driven'. Haha, joke. Which is about running successful and memorable technical conferences. It's due for an update, but basically I spent a lot of time on calls with people who were like, "I want to do this. Can I ask you a bunch of questions? Can I pick your brain?" which I still do. But at that point, the volume of those calls was getting a little bit difficult. And I found myself saying the same things over and over and over again. So, I sat down in the airport lounge one day on the way back from I think the last GoGaRuCo and I just did a brain dump of all of the things. And I was anticipating writing a blog post but it ended up being like a 200-page book or whatnot. So, it's all the things that I wish I had known before my first conference and that I learned by basically messing up a time or two, or watching other people messing up a time or two. So, if it would be helpful, if you're somebody who learns well from the medium of reading, it's a PDF. It's called 'Event Driven'. You can get it on Leanpub. Thank you. It's been a long time since I even thought about it. 

NOEL:  I was going to mention it if you didn't. It really does feel exactly how you said. It feels like you just poured out all the stuff that you had learned painstakingly over the years into one PDF.

LEAH:  Yeah. So, I should update it because I've learned more, which is good. But it'll get you a large portion of the way there. And if nothing else, give you a lot to think about. Because a lot of the things are just like, "Oh, when I signed my contract I didn't realize I had to ask X, Y, Z. I didn't realize about this liability. I didn't know that if I didn't do this at this time, blah, blah, blah." And things that are hard to sort of go back and fix up later down the line in your planning. So, if that's useful to you, find it on the internet, read it. And after that, feel free to give me a call. It actually also includes a spreadsheet that I use that I think RailsConf is probably still using and I was using for a bunch of my conferences that was just a helpful Google Doc spreadsheet with 10 different tabs to set you off on the right organizational track for keeping all fo your details in order. I'm in the middle right now of creating an AirTable alternative to that, which is a little bit smarter of a spreadsheet. And I'm hoping that after I use it one more time on RustConf coming up, that I will add it to the freebies that come with the book so that it can help people plan if they want to use a more advanced tool. Hopefully, that will help some folks get over the initial humps and avoid some of the mistakes that a lot of us made ourselves. 

NOEL:  Great. Thank you all for being here. And I appreciate it. And see all of you around the community. Thank you. 

Tech Done Right is a production of Table XI and is hosted by me, Noel Rappin. I'm @NoelRap on Twitter and Table XI is @TableXI. The podcast is edited by Mandy Moore. You can reach her on Twitter at @TheRubyRep. Tech Done Right can be found at TechDoneRight.io or downloaded wherever you get your podcasts. You can send us feedback or ideas on Twitter @Tech_Done_Right. Table XI is a UX design and software development company in Chicago with a 15-year history of building websites, mobile applications, and custom digital experiences for everyone from startups to storied brands. Find us at TableXI.com where you can learn more about working with us or working for us. We'll be back in a couple of weeks with the next episode of Tech Done Right.