Day 15 - Systems

You’ll perhaps notice that there is no day 13 or 14 post, which would yet again be due to the fact that it was the weekend, during which I have little motivation to write. I tend to use weekends for true rest and relaxation time so far this year, but I feel like that is (somewhat thankfully) coming to an end for me soon so I’m working to build routines into habits that will allow me to accomplish my goals. In other words, I’m building systems.

Given the above combined with the fact that I am spending a holiday authoring systems for Rytāvi Corp in Notion, it seems appropriate to write about today.

To me, systems are nothing more than a collection of standardized processes that allow you to perform the same task in the same manner repeatedly. There are however two different kinds of systems that I think about: personal systems and organizational systems. For personal systems, it’s simply enforcing (either consciously or not) specific steps to accomplish things you want to do in your life. For example we recently moved from a regular drip coffee maker to a pour over coffee pot, which required a new process for Holly & I making coffee in the morning:

1. Grind the beans the night before.
   This is because we use a burr grinder that introduces a significant amount of static electricity to the grounds. Grinding the beans the night before allows much of it to dissipate, which means our counters stay much cleaner.
   
2. Fill the kettle the night before.
3. Wash the pot and filter the night before so they’re ready in the morning.
4. The first person in the kitchen turns on the kettle and dumps the grounds into the filter.
5. Whomever is in the kitchen next pours the hot water in the filter, and the next person that comes by tops it off again. Repeat until the pot is full.

It’s a pretty straightforward process, and not really something Holly & I had to discuss much because there are only two of us, it’s a simple task we both knew how to tackle independently, and we’re both functioning adults. In a small group this is frequently all you need to end up with an organic system. Nobody specifically planned it, and it seemingly created itself because it was simple enough for two people to just fall into doing it. This is a pretty common thing to happen in small group dynamics, but it doesn’t work so well when you scale the group.

When you’re building a business, you’re working with larger groups which means you need to create written processes for everyone to follow when working through a task. If the processes are followed regularly, you’ll be able to expect the same result every time from your system.

All of the above paragraph is barring unforeseen circumstances, which is where contingencies come into play, but I’m not writing about those today.

Creating processes is not the most difficult task in the world, but I couldn’t find much useful content on the topic when I originally realized that I needed to build processes. So, appropriately enough, I created a process to build individual and team processes that accommodate larger organizational systems.

1. Determine what you’re building a process for – One thing I’ve learned here is that this is not always what I think I’m building a process for at first. I once built a system for a specific, straightforward technical task that (now) takes an average of seven minutes to complete and by the end of it I realized I was building a system to accommodate distributed scheduling instead of a process for performing the technical task. You might not realize this until the end, which is fine. In this example, I ended up documenting the technical process separately after I completed the scheduling process that allowed us to accomplish the technical process.
2. Determine the end state – What’s the end goal? What does it look like? “We need to do X” isn’t an end state. “We need to do X in a way that Jane in accounting can look at gauge Y and explain to Joe in HR how much we can stretch the budget for a promising new hire.” is an end state. Without context your processes will not work, and your systems will fail.
3. Walk yourself through the process at least once – Take detailed notes along the way with every step you take. At the end of this, go back through the notes and remove the steps that aren’t actually needed and expand on the steps that are needed with sufficient context and detail for someone to read the step 2 to 3 times and complete it themselves. Do not assume the person following the steps has any knowledge of the task.
4. Document the process in a step-by-step fashion – Include screenshots, videos, pictures, or whatever else is needed so that anyone reading this can understand exactly what they need to do next.
   
   Make sure to add explanations where context is useful. You might have noticed I explained why we grind our coffee beans the night beforehand in the above example I gave of a personal system; this is because if you’re writing processes that contribute to overall systems a team member is inevitably going to think “Why the hell do I have to grind the beans the night before? I’m tired and will do it in the morning.” Without context, this is a reasonable thought process. With context, said team member will realize that they’ll end up cleaning the counters the next morning if they don’t grind the beans the night before.
5. Do a dry run of the process – You can walk through the process yourself if you have no other option, but the best results come from finding a willing candidate who has never gone through the process before and see if they achieve the same results you do.
6. Evaluate the process as part of the overall system – Sometimes you’ll get to the end, having documented a process that works just fine and dandy but doesn’t fit nicely into your overall systems. If you end up there, you’ll have to decide whether to adjust the process you just created or whether to adjust the overall system(s) in play to accommodate it.
7. Create a way to measure outcomes – Quite simply, in order for a system to work, the processes must work and people must follow them every time. Given that people are people, you’ll want a way to measure the outcomes of both individual processes and the overall systems they collectively comprise.

That’s all I have to say on that today. Maybe one day I’ll follow my own advice and create a good system for writing blog posts.