From worry lists to pipelines: 4 steps we used to design processes so we can scale

In the past 18 months since I joined Support Driven, we’ve moved from a dependency on one person’s expertise 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. Like so many things, we made it up as we went along. But we got there organically by continually focusing on “how can we set this up so it’s not dependent on us?” For anyone else moving into a new operations role, I wanted to share here how we got there.

BACKGROUND: DEFINING SUCCESS

When I joined Support Driven to help organize operations in March of 2018, we were in the middle of producing our biggest 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 we 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 do anything else for the community.

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, but Scott and I asked ourselves, “How will we know when we’ve succeeded?”

And we joked, “We’ll know we’ve succeeded when we are not required at the events.”

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 of brains and emails 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 a coordinator 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 the coordinator, I realized 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. 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, we create 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.

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 project, 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 as part of the Support Driven book club. The book made me realize how inadequate my own checklist use is, and it made 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, 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, which starts with publishing a call for proposals and includes speaker acceptance or decline for every applicant, 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 I 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 us 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.

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 we feel good about 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 their jobs better, finding folks with expertise in those areas to share their knowledge, and bringing that expertise to the Support Driven community 😍.