6 Steps for a Bulletproof Process
I have a confession. Though a startup executive and aspiring full-stack CEO, I don’t have any particular love of process. Realizing this, I connected with Olga Narvskaya for mentorship.
Olga’s track record is impressive: she ran Customer Success at Dropbox, Operations at Clara Labs, and is now Head of Operations at Segment. Fond CEO Taro Fukuyama describes Olga as “the smartest person [he’s] ever met.”
One lesson that has stuck with me is how she approaches process development. I’ve applied her process to hiring, support, roadmap development, and even personal finances. Each time, Olga’s methods lead to a performant process faster.
Olga’s approach works because:
- It’s a straightforward operational model for Kaizen or OODA [observe, orient, decide, and act] loops. I preach these things, but hadn’t before distilled them to such simple steps.
- It’s logical and accessible. You’ll read Olga’s steps and say, “of course.” But, if you’re like me, you skip some of these steps and wonder why issues keep popping up.
Step 1: List Task Types, Assign Ownership
The first step in developing any process is listing out the types of tasks to do and assigning them to the person best equipped to handle them. This isn’t a groundbreaking step, but it’s worth noting the phrasing of “ownership” here.
Ownership is accountability. The very first step in process development creates a backstop of personal responsibility which may catch future mistakes.
I led the Business Development team through this exercise at Fond. A number of tasks had unclear ownership and were being dropped. This was an otherwise highly motivated and performant team, we just needed to point that motivation where the company needed it.
Step 2: Create a Zero Loss System
Once you have tasks divvied up to the right owners, you need a place to capture every task that comes in. The tool here isn’t important, a Google Sheet may suffice, the goal is to understand the flow of work and make sure nothing gets lost.
By yourself or as a team, periodically check in on the flow of work. Your assumptions of important or voluminous work from Step 1 might be incorrect. There might be a big category of work you were unaware of.
When I work with seed stage companies, they often sheepishly show me their spreadsheet of work to be done. This proto-roadmap is totally fine for their stage. It captures enough and doesn’t lock them into a plan longer than the company’s operating history.
Step 3: Avoid Premature Automation
Step 2 can lead process-minded people to create projects in Jira, assign owners and escalation paths. Others may try to fix every bug collected in Zendesk.
Take time to understand the flow of work and individual tasks before you start to automate. It could be that some tasks are so rare they don’t need much more than awareness. You may uncover critical tasks elsewhere that need immediate resolution.
Step 4: Ensure Consistency (described somewhere)
Once you know how to best handle each task, it’s time to document that process. For new employees, these documents serve as training and onboarding. Large operational organizations may use these documents for performance management.
Step 5: Make It Redundant
“If you have one, you have none. If you have two, you have one.” — US Special Forces proverb
Finally, as you scale the team handling work, you want to ensure redundancy around execution. Only one engineer knows how to bring the message queue back up? Only one Support person knows how to troubleshoot that one issue? Now is the time to cross-train and/or hire to make sure there are no single points of failure.
This is the step that’s most often missed and disastrous when skipped. Failure here looks like a critical person on vacation during a big launch, and it hits the top line quickly.
Step 6: Poke at Things
Now you’ve got this great process. You record every task and completion is redundant and consistent. When everyone’s happy with a process is when it’s time to poke and look for holes.
I love Olga’s story for this step. Dropbox Support was functioning well and everyone seemed happy with the output. Olga looked into the queue of lower priority tickets and found tickets submitted in Russian that had been misclassified by the triage system as less severe. She fed that information back through the process and improved the Support experience for all Russian speakers who experienced it in the future.
Conclusion
That’s it. Seriously, it’s that simple.
At no time did Olga say “you have to use this tool” or “sprint planning meetings happen on fortnightly Mondays.” This simplicity means that even a process hater can apply Olga’s steps, make their employees happier, and ensure better outcomes faster.
