Photo of Atual Gawande’s Checklist Manifesto from Support Driven book club

In the past 18 months since I joined Support Driven, we’ve moved from a dependency on one person’s expertise (hi Scott!) to scalable, documented processes for producing Support Driven conferences. When I signed on in an operations role, we didn’t have a plan laid out for operationalizing the conferences. We made it up as we went along. But we got there organically with a lot of community help and by continually focusing on “how can we set this up so it’s not dependent on us?” For folks in the community who are interested in what goes on behind the scenes to run Support Driven (and for those of you spinning up operations at your companies), I wanted to share here how we got to a point where we will be able to bring Support Driven conferences to more cities in 2020. We hope to make it easier and more budget-friendly for folks to get to an Expo or a Leadership Summit by making them available in more regions.

BACKGROUND: DEFINING SUCCESS

When I joined Support Driven to help organize operations in March of 2018, we were in the middle of producing SD Expo in Portland: the biggest SD conference of the year. The majority of the knowledge for how to produce a conference, and what stage this conference was currently at, was in the founder Scott’s mind or scattered across documents, emails, and tools I didn’t know where to look for. Though we were repeating production of an event SD had done before, as a newcomer it felt like starting from scratch.

Starting from scratch each time on a conference that will be reproduced repeatedly is not scalable: we might be able to produce 2-3 conferences per year that way, but we wouldn’t be able to expand to new regions. We also wouldn’t be able to do anything else for the community: just conferences.

Reproducing something repeatedly, however, is scalable. If we have documentation and processes in place, then we can multiply the conferences to expand into additional regions, making them accessible to more community members. We’d also have bandwidth for other programs for the community if we were able to operationalize conferences.

At a high level this all sounds great, right? Bit “scale conferences” is also pretty big and unshaped. Scott and I asked ourselves, “How will we know when we’ve succeeded?”

And we joked, “We’ll know we’ve succeeded when we don’t have to be at the events for them to work.”

Except we realized it wasn’t really a joke. It made sense that scaling means not being dependent on the founder’s presence to succeed. Our goal then became getting systems and processes in place that were robust enough that Support Driven could hire people to run events, and they would run well without the one of us needing to be there.

Setting that intention for success — that success looks like us not being necessary — helped us focus on what we needed to do to get there.

The big question then became how? How do you take an undefined mass of knowledge that’s mostly in someone’s head and turn it into a repeatable process you can hire someone and teach them to run? The first step was to get the knowledge out Scott’s and community members’ brains and into sharable documentation.

STEP 1: THE WORRY LIST

The worry list is exactly what it sounds like: a list of things you’re worried about. The worry list exposes not only what needs to be done, but also gives an indication of timing: if you’re worried about it, chances are it either needed to already be done, or it needs to be done soon. This is important for building timelines.

When I first joined Support Driven, and I didn’t know where I was most needed in the the whirlwind of Expo preparation, I asked Scott to make a list of things he was worried about. As I wrote about in a previous post about the worry list as an ops tool, Scott’s worry list helped me understand the work of the company right away, and how best to organize ourselves to get it done.

The first worry list became one of our central documents. Naming worries forced us to pull out of them so we could see them, allowing us to take a higher level view and piece  them together in a bigger picture. Bounding worries by words and anchoring them on “paper” made them manageable: we could prioritize them, assign them, cross them off the list.

STEP 2: PLAYBOOKS

Playbooks are documentation on how to do a particular thing. The worry list laid out a list of things that needed to done, but I didn’t know how to do them — I didn’t have instructions. For example, the worry list revealed that we needed to secure a videographer. Yet, I’d never secured a videographer, and we didn’t have documentation on what it means to secure a videographer. What do we need to know from the videographers we get quotes from? What do they need to know from us? How many quotes should we get? How many hours of footage are we talking about? How many rooms? How many days? How many angles? Do we want B rolls? Do they do editing? How long will edits take?

For each thing on the worry list we executed on, I created playbooks. The playbook template includes:

  • What
  • Why
  • Who is responsible
  • Checklist
  • Timeline
  • Resources
  • FAQ

By the end of Expo in June and then Leadership Summit in October, we had documentation on venue selection, securing hotel blocks, video management, first steps for organizers, playbooks for the talk editor program, playbooks for each volunteer role, playbooks for external and attendee communications…

For the next Expo, we hired an event coordinator, Jelena, who was not familiar with Support Driven, SD conferences, or the tools we used, and I was excited for all of this because it would really put the playbooks to the test. As soon as I started onboarding Jelena, I realized a gaping hole in the documentation: the playbooks were like taking a bunch of chapters and throwing them on the floor. There was no organization to them, no table of contents, no introduction to how to use them. Jelena was probably like, “Uh, what do I do with this pile of words?” So I created Coordinator onboarding documentation and a scorecard that included the major tasks in chronological order, along with due dates.

The playbooks continue to grow that way — if one doesn’t exist for a thing that needs to be done, an event organizer creates it when we realize we need it. Likewise, if whoever is running the playbook finds it lacking, they are encouraged to update the playbook to include the information they were looking for but did not find. The community has been great with helping refine the Talk Editor Program documentation each time new editors and coordinators sign up to help speakers with their presentations.

STEP 3: CHECKLISTS

When we started planning our next Expo event, Expo Europe in Belgrade, I was excited because we had the playbooks in place. We could test them and refine them. However, the playbooks are comprehensive, not concise. They are best used as references when you need instructions on “How to.” They are not lists for “Is it done?”

We quickly found that even with playbooks and the scorecard, we were still asking:

Did X get done?

If we had to ask that question, then our worry list and documentation were not enough. Each playbook included a checklist, but for the person overseeing the event, combing through all the various playbooks to see if things had been completed was impractical and time-consuming. We needed an easier way to see the progress of the work.

I had read The Checklist Manifesto with Lisa Hunt as part of the Support Driven book club. The book made me realize how inadequate my own checklist use is, and it made Lisa and me want to understand how to use checklists effectively. But I struggled with how to create checklists for the events. It was overwhelming. How do I condense all the material from the playbooks down to simple checklists? How do I organize the checklists? How do I share them? How do I review them?

I was taken with the way aviation checklists are constructed:

Good checklists… are precise. They are efficient, to the point, and easy to use even in the most difficult situations. They do not try to spell out everything — a checklist cannot fly a plane. Instead, they provide reminders of only the most critical and important steps.

The Checklist Manifesto by Atul Gawande

I took inspiration from those aviation checklists and started with an event “manual” of checklists. Each day-of element of the event had its own checklist that was less than a page long. All of those checklists are packaged together in a single Google doc with a table of contents for ease in navigating the manual. Want to know what’s needed for Registration? There’s a registration checklist. Want to know what supplies we need to order, or signs we need to print? There are supply and printing checklists.

In terms of determining what things required checklists, if we had to ask this question, then we probably needed a checklist:

Did X get done?

We still have plenty of checklists to make, we still have things that should be on checklists but are not, and sorting out high level checklists and granular detail checklists continues to be a challenge. However, the checklists we do have are the ones that have been repeated enough times that we know where the pain points are, where we typically forget things, and where there are repetitive tasks that don’t require a human and in fact are more prone to error if they are dependent on a person doing them.

STEP 4: PIPES

Our next step was to take those checklists for a particular process we execute repeatedly, that often require emails, or have things that are apt to slip through the cracks or are hard to keep track of, and introduce automation. An example of this is the speaker program. Even at only 1 or 2 conferences, speaker emails were slipping through the cracks: we’d forget to send a follow-up email to provide next steps after a speaker was accepted, or speakers would apply to speak and then not know when they might hear something back from us, or some speakers would receive emails but others wouldn’t because we didn’t have an official speaker submission and so they weren’t on our master spreadsheet.

Behind the scenes, the speaker program process starts with publishing a call for proposals and includes an email acknowledgement that we received the proposal, speaker acceptance or decline emails for every applicant, assigning editors, adding accepted speakers to the website, collecting slides, and sending out a post-conference speaker survey.

Scott researched process software and found Pipefy, which works similarly to Trello in that you can move cards from one end of a process to another as you complete certain steps. In Pipefy, you can also trigger certain actions when you move a card from one step to the next. For example, in the Speaker pipe, when we move a speaker from the Application phase to the Accepted phase, the speaker automatically gets an email telling them they’ve been accepted along with some details they need to know for next steps.

As our colleague Vicki described Pipefy,

It’s like Trello, but it does the thing.

The pipes not only help by adding automation, but the pipes become the checklist: moving an item through the pipe from one phase to the next shows us what has been completed and what is still left to do. The pipes give us that quick visual of progress we lacked when we only had playbooks.

The pipes help us reclaim time that we used to spend organizing all the pieces, wondering “did X get done?”, and putting out fires because X didn’t get done. This consolidation of information alone has freed up mental capacity to work on other things. When we add automation to the mix, we’re spending less time going through laborious processes of finding and tracking information in  spreadsheets to send emails, and a lot less time correcting errors: the automation helps make sure everyone gets the information they need when they need it.

WHERE WE ARE NOW

We’ve got documentation, checklists, and processes in place now for conferences. We’ve still got a lot to improve on, and checklists and pipes still to build out, but we’re at a place where it feels doable to start scaling. Support Driven recently hired Brittany Ferguson to take over as Event Director and Sonya Green to run operations via the pipes. With their help and with these systems in place, SD will be able to do more events and do them better next year.

As for me, we poured the foundation we wanted to pour for scaling conferences, and now I get to turn my focus to content: to listening to what the community wants and needs in order to do your jobs better, finding folks with expertise in those areas to share their knowledge, and bringing that expertise to the Support Driven community 😍.


Andrea Badgley organizes content at Support Driven. Prior to joining Support Driven, she was a Happiness Engineer at Automattic. She likes pastries, reading, and laughing. She lives in the Appalachian mountains of Virginia with her husband, two teenage kids, two cats, and a butterfly garden. Find her on Twitter, LinkedIn, or andreabadgley.blog.

%d bloggers like this: