Why You Need a Flowchart for Every Ops Process
When you work in operations at a startup, you are usually building a ton of processes. You need to build a process for:
Sales: from sourcing leads to scheduling a discovery call to onboarding
Billing: from reconciling service records to creating an invoice to following up on late payments
Recruiting: from sourcing candidates to interviewing to onboarding a new team member
And many more functions like supply ops (in a two- or three-sided marketplace business), finance (fundraising, bookkeeping, etc.), and so on
As you pump out a process after a process, you quickly run into a maintainability issue. What happens when a tool you use for a key step in a process goes down due to a server outage? What about when an employee who owns a process from end to end rage quits?
Without proper documentation detailing every step of the process, triaging a process issue or refining and optimizing a process becomes challenging. The process you're trying to fix or improve might be spread across multiple teams and tools. Perhaps you don't have a good grasp of the entire process and what you fix might have downstream consequences on another part of the process.
This is where a flowchart comes in handy.
What is a flowchart?
A flowchart is a type of diagram that represents a workflow or process. A flowchart can also be defined as a diagrammatic representation of an algorithm, a step-by-step approach to solving a task.
- Source: Wikipedia
A flowchart, sometimes called a process diagram, usually has shapes representing different steps in a process with arrows showing the direction and order of those steps. If you've been in ops, you've probably made some version of a flowchart in Google Slides or Lucidchart.
Here is a flowchart I created for Ops Hacks (link to zoom in here):
I created this flowchart for two primary reasons. The first was to visualize the entirety of the user onboarding process, from sign-up to joining the community. Outlining the key steps in the process in a visual way helps strengthen the mental model I have of the current process. The second was to document and keep track of all the different no-code tools I am using to build Ops Hacks. As you can see in the legend of the flowchart, the user onboarding process spans across 6 different tools. With automations happening to connect those tools, sometimes natively in the tools themselves (like Slack Workflow Builder) and sometimes via Integromat (my favourite no-code tool), I was starting to feel like the process was becoming a bit too complex to hold all the information in my head. With links to the automations and relevant tool pages included in the flowchart, it's much easier to stay on top of the process and quickly make any changes as needed.
What are key components of a startup ops flowchart?
While everyone's situation and use case is different, there are some best practices to follow when creating a flowchart in the context of startup operations.
Legend
The legend in your flowchart should act as a clear and succinct user manual. It should clearly communicate what each of the visual elements in the diagram represents, so that anyone looking at your flowchart can comprehend it simply after reviewing the legend.
There are widely accepted conventions around what each of the shapes means (see here, here, and here), but I take these as suggestions and go with my own. I find that for startup operations, some of the symbols aren't relevant. So while I use some conventions (a diamond for a decision point for example), I also invent my own (a rectangle for a user action vs. an oval for an internal action).
Links
As more and more of our work moves into the cloud and away from our physical hard drives, keeping track of where everything lives has become difficult. This is why I like to include links to the different automations and pages I'm referencing in the flowchart. If I see that an automation isn't firing correctly in the process, I can easily track down which step is causing the issue in the flowchart and have the link to the automation right there in the document.
Roles & Responsibilities
I didn't outline roles & responsibilities in my Ops Hacks flowchart, because it's currently a team of one. If you work with multiple teams and colleagues, then it's helpful to denote who or which team is responsible for which part of the process. It helps assign accountability to relevant parties. And similar to a link taking you to a relevant tool, a well-marked R&R helps foster collaboration and efficiency by surfacing who the point of contact would be for any given step in a process.
A flowchart for every ops process
Maintaining a flowchart for every key process in your operations is important for the aforementioned reasons of maintainability and optimization. In addition, it's also helpful in improving transparency across the org and making collaboration easier and more efficient. Instead of having to walk a new hire through the entire process step by step, you can just share the flowchart and field any questions they have after reviewing the diagram.
One last consideration in regards to creating a flowchart in the context of startup operations is the timing of it. You shouldn't create a flowchart before your process has had time to solidify; or else, you'll be doing a lot of revisions on your flowchart to reflect the changes in your process. On the other hand, you also don't want to wait too long - otherwise you won't reap the benefits of being able to diagnose a process and optimize it or share it with the rest of your team for increased transparency and collaboration.