Transcription
If your team hears SOP and thinks soul-crushing paperwork, you're not broken, your process is. Welcome back to the operator hotline.
If that sounds like you, don't worry, because in this video, I'm going to show you how to change your perspective, or your team's perspective, around standard operating procedures so you can create ones that actually work and you actually enjoy using. Yes, enjoy. I did use that word.
But before we get into it, let's listen to the question that inspired this week's episode from Kip.
I've got a myth for you to bust, Ila. It seems to me that a lot of people, especially employees, have a lot of negative thoughts around standard operating procedures. They think if I write down a policy or a procedure, it's going to dehumanize the workplace; it's going to kill creativity; it's going to be nothing but soul-sucking awfulness. So, there's no upside for the employee at all. How do you change this mindset?
To really break down these assumptions when it comes to SOPs, we need to first appreciate, from my perspective, where are they coming from? Because by itself, if we just break down all the connotations and we look at the thing SOP, it stands for standard operating procedure. And really, in practical terms, it's a recipe for how to do something. And you would never fear that I'm taking over your world if I gave you a recipe for cookies. You wouldn't be like, "Oh gosh, don't give me a recipe for bread; that ruins my creative process." So why is it that when we get a recipe for a work activity, all these associations come up?
For the small business owners I work with, and I can only imagine for their employees as well, when we think of systems and processes, we have an overwhelmingly negative perception because what do we think of? We think of the headlines of Amazon workers peeing in bottles. We think of waiting at the DMV and filling out piles of paperwork only to wait in line for hours more. We think about movies like Office Space, where you're arguing over TPS reports or catching whole buildings on fire because you were mad about your stapler. We think about bureaucracy, inefficiency, and stifling of creativity. Because of these associations and experiences, that's what we think systems and processes are. And you know, you can't fault us for thinking that. That's all of the input most of us have.
But despite all this, recipes themselves aren't inherently negative. Again, like if I just gave you grandma's cookie recipe, you wouldn't be pissed off.
So, what we need to do if we're going to introduce SOPs to a team, especially those who have these negative connotations, like most of us do, is we need to fill the gaps. We can't just leave blank space and assumptions. Because if we just give someone an SOP, they're going to assume all sorts of things about what that's going to mean. Instead, if we want to start introducing recipes into our business, we also need to introduce some cultural change. We need to communicate: what do these SOPs mean? How do we use them? Who updates them? Who's in charge of them? We need to answer these unasked questions before they get answered by people in their own head and, you know, answered in a pretty negative way.
So, how do we do that? There's a bunch of stuff we cover inside the process foundations program for clients who go through this process with us, but I'm going to give you a quick summary of the three biggest impact things so you can steal them today.
The first tip I have for you is to make sure you communicate that SOPs are tools by and for your team. So, your team is creating them as helpful guides and references for their future selves or for their colleagues. Note that in order for this whole thing to work, you need to have your team feel agency and control over those SOPs. That means giving them editing access and ideally having them write them, which for most business owners who don't like writing SOPs, that's a two-for-one.
The most common mistake, bar none, that I have seen when it comes to SOP rollouts in small companies is when we have either the business owner or specialized consultants who write SOPs for your team. Now, I get it. Your team's busy. You don't want them spending a lot of time writing procedures. But here is the danger of outsourcing. Whether it's to the owner or to another party, you get this expert of whatever kind to write all these policies and procedures. They write up a hundred documents. They pass them over to your team. Put yourself in the position of the team at that point in time. A professional SOP writer or your boss just wrote all these instructions. They gave them to you, and now you're supposed to treat them like working drafts that you're in charge of. No, it's not going to happen. You're going to look at this document. You're going to feel intimidated. You're going to feel you just got handed the Mona Lisa and a paintbrush and told, "Hey, touch it up when it needs to be fixed." And you're not going to do it. When you go this route of outsourcing, you're going to see SOPs ignored. You're going to see intimidation. You're going to see rejection. You're going to see struggles with adoption. All of this because rather than making SOPs by and for your team, you are treating SOPs like a prescription by an outside person who doesn't do the work every day, telling the people who do do the work every day, here's how you do it.
Now, there are some exceptions to this, like if you have a very junior team, and I cover that in this video up here. It shows about how you can create SOPs collaboratively, but ideally most of your SOP work is going to be done by most of the people who will be working the SOPs, which should be the day-to-day workers.
Now, this whole conversation around adoption really ties into the second tip I have for you today, which is to make sure when you're introducing SOPs that you pick a venue, a software, a tool, a spot that is conducive to collaboration. And I know it sounds so obvious, but the number of people I have seen spend hours and hours and hours writing SOPs in a tool that only two people can edit and then be surprised when no one else edits it is shocking. SOPs do not require some dedicated piece of software. They don't require being locked behind keys and permissions and passwords. SOPs are tools by the worker for the worker. If someone wants to update it because something is out of date, don't make them jump through 30 hoops of permissions in order to do it. Let them change it and have the revision history if you need it.
I have heard many horror stories of teams where they roll out SOPs and they're blatantly ignored and rejected and never happen. But I'll tell you what, I have yet to hear one horror story of a team where people are editing the SOPs too much, where they are adding notes too often, where they're changing steps with too high of a frequency. I have yet to see that in seven years. And so for that reason, when it comes to this second category of tools selection and venue, if you want to make this a collaborative experience, which you do, make sure you're picking a venue that your team has access to, that's convenient, that's centralized, and has all the securities you need without locking things under a padlock virtually or otherwise. If you're looking for specific recommendations as to which software you should use to start writing your SOPs or if you want to do something offline, I have a whole video up here about where you should put your SOPs that'll walk you through that. But that is my second tip for you here.
Now, that brings us to our third tip, which kind of gets back to the original questions uh concerned about soul-sucking. Namely, if I do SOPs, will I be killing creativity and the human spirit and all that stuff? Not if you follow this third tip, which is to make sure when you create SOPs, you only do so when it helps. It's that simple. If I gave you a recipe for cookies, that'd be great, right? That'd be helpful. It would show you something you may not already know. If I gave you a recipe for a cup of water, would that be helpful? If I gave you a recipe for how to make macaroni and cheese, which is exactly the same as the instructions on the back of the box, would that be helpful? No.
It sounds so obvious with these examples, but I've seen far too many teams start to feel like SOPs are a waste of time because they lose sight of this core goal. The purpose of a recipe, a business recipe in this case, is to make whatever you need to do easier to do perfectly, to make success easier, to make perfect easier, to make workload lighter. Creating a recipe for how to talk on a YouTube video is not that helpful to me. But creating a recipe for all of the things I need to do to prepare to film, to like make sure the lights are on, that is helpful.
If you are a team that has creative components, things that require the human touch, and that's really the genius, it's the fluidity. It's the making it up every time. It's me right now completely improving this entire video. If that is helpful to you and part of your process, you don't need an SOP for that. However, I bet the creative acts that you have in your business are surrounded by borders of boring. I don't know what else to call them. For me here, before I film, there's all this stuff I have to do. I have to turn on lights. I have to like clean my glasses, which I usually forget to do, you know, XYZ, all this stuff. And then after I film, I have to process the file. I have to put it in this thing. I got to upload it to Drive. Like, there's these bits of boring on both sides of my creative process. And so when it comes to SOPs, where am I creating the SOP? It's not for the creative part. It's for the two bits of boring on either side.
And I think too many people get confused when it comes to SOPs. They think, "Ah, well, SOPs are what I do for anything important." And so I should really focus on this middle part, my creative process. I should systemize. And I respectfully disagree. Your creative process has so many permutations that it will be the most difficult thing in the world of all the stuff you do to systemize, and it's probably not going to change much whether or not it has an SOP. You're still improving this video. The goal of SOPs is not to make the creative work mindless. It's to make the mindless work truly mindless. So, for example, you know, if I didn't have a checklist for the things I had to do before the video, I'd be thinking about it. It would take energy and willpower to remember, oh yeah, the lights are off. Oh yeah, I got to open the window. Oh yeah, all of that stuff is draining the energy away from the creative process. Whereas when I have the checklist of all right, here's the 10 things you have to do before you hit record. Boop boop boop boop boop boop boop, go through the procedure, it's helping me protect the creativity for the work that actually needs it instead of wasting my creativity on how I turn on a light.
When you start to combine these principles together, when you introduce SOPs as something by and for the team, something that's collaborative in both where it's formatted and how it's used, and something that protects creativity rather than taking away from it, this whole association of processes being these restrictive negative things goes to the wayside, and we start to think of work recipes just like grandma's cookie recipe. It's a positive, delightful thing that makes a sweet treat at the end. Until we give our team or our leaders or whoever we're trying to convince this alternative narrative, we can't be surprised if we say SOP, but they hear PITA. You know, it's just a different experience, and we have the ability to write it.
Thanks for listening to the operator hotline. To get your question featured, check the video description. If this was helpful, share this video with a friend or your email list. Don't forget to comment hotline below to vote for more episodes in this series.