Business relies on routines.
Things that happen day in and day out.
No, correction. Successful, long-term businesses rely on routines.
Unsuccessful ones don’t need routines.
Routines
A routine is just a series of steps that are taken to accomplish a result. They can be as simple as how you start the coffee in the morning to as complex as how you acquire a new business.
Much of the success and failure of a business can be attributed to its routines. Both good and bad.
Good routines improve the business. While bad routines either keep the business still or weaken it.
As humans, we’ll create routines as we work. It’s in our nature. If you doubt it, ask anyone with a young baby about how important routines are for the baby to have a good day.
When we first start a business we’re trying to build routines while we learn.
“Should I check email first to show that I have fast customer service or should I make progress on a long-term project?”
Converting a routine to a business system
Over time these routines are adjusted and optimized until we don’t notice them anymore. How many times have you had to actively think about your check email routine this week?
Once a routine becomes the standard way you work, it’s time to convert it into a system.
Systems can be large, drawn out documents. Think MBA-speak and flowcharts.
I’ve created a few systems like this in the past when I wanted to change my routines. I still use the systems but they are so complex I’m only using about 25% of them.
(At the time I just finished reading a systems theory book and I wanted to apply what I learned. This helped me learn a bunch but now I have the wisdom of knowing that I could have done 1/3 of the effort and gotten the same benefits.)
When creating a system, the core aspect is to take the routine you’ve built up and document it. At a minimum you need a few parts.
- What is the goal? A strong goal will tie the system to your business and prove why this system is needed. A weak goal means that this system might be a bad one and is up for elimination.
- What are the steps? With a routine you probably automatically did some of the steps so you need to be careful to write down everything. Watch your assumptions.
- What triggers the system? Are there are events that cause the system to start? Write them down. It could be as simple as “a new email arrives” or “in the morning when I step into the office”.
- What resources are needed to run the system? Do you need something from someone or something else to run the system from beginning to end? E.g. a “process a client payment” system will require a payment (check, electronic receipt) and an invoice number.
- What does the system produce? This can be both at the end as well as while it runs. You might have a system to lookup a client and their outstanding invoices, which produces the client information as a result (which can then be used in the “process a client payment” one above)
- What are the related systems? Systems can work in isolation but most of the time they connect to other systems or routines. Making a list will make it easier when you want to change this system or related systems.
In my experience, documenting those six parts will give you most of the benefits of a system.
What did I do wrong in my system documentation?
I following the systems theory a bit closer and defined feedback loops and sinks. While this can be useful in some cases, it was overkill for my solo operation.
When documenting a system, you need to think about why you’re putting in the work. Perhaps you’ve had mistakes or missteps which a plan can prevent. Or maybe you want to refine and optimize it. Or maybe you’re hiring some help and need clear instructions.
I’ll be writing about some of the systems I’ve created in future posts.
Eric Davis