Don't Waste Time Creating SOPs the Wrong Way

Hello. Hello and welcome back for another Workflow Wednesday. This one, I'm actually not going to be pulling up the whiteboard today. So if those of you who have joined me for other workflow Wednesdays, you're probably familiar with normally, I will pull up my digital whiteboard and I'll start drafting a workflow. We're actually going to work through it together. This week is different because I had a conversation with some of you this past week that just totally shocked me about how you document your processes, or at least the burden that you feel around documenting your processes. Processes. So before I talk about that, because that's what I want to discuss today, your process for processes, let me first just introduce myself. My name is Layla. I run ProcessDriven and what I do is I help people document their SOPs and build a business instruction manual using ClickUp. And the thing I want to talk about in these workflow Wednesdays is how you should be building or I don't mean to use shoulds or prescriptives here, but I really do believe that you will have a better shot in getting value out of your technology if you build technology around your workflows rather than the other way around. Rather than saying, I love ClickUp and therefore you just chase every new feature that ClickUp prescribes to you and says, all right, I need to somehow make this feature work or docs work or whatever it is. I think that's a reactive way to build a business. And no offense to the product manager's ClickUp, but they are trying to develop a piece of software that is adaptable and what they release as features is based on a complex kind of weighing of variables of all of the people who are asking for features from them. Whereas what you need to grow your business is really a lot more constant and it's based on how your business actually functions. So in these Wednesdays, my goal is to kind of make space for that more fundamental conversation of what should your workflows actually look like and how can technology help the way your business is structured rather than just saying, here's a tool, make it work. I just don't think that's the most helpful way to go about. So if you're joining me live, just gonna do the quick courtesy audio check here because otherwise we've had some issues with audio. If you are watching right now, give me a thumbs up to confirm that you are able to hear this. I'm hoping it's coming through. This video is going to be all about process for processes and talking about Kind of a conversation I had this actual week. And hopefully. Okay, it looks like we've got audio coming through. Give me a confirmation if you can confirm. But the conversation I had. Let's just start with that. The conversation I had this week was about how long it took some fellow system service providers, some of you were in that conversation, how long it took you to actually create your SOPs, whether it was sitting down in one sitting, whether it was working over a period of time. How long did it take you to create those SOPs that you use in your business? And I was shocked when some of you said, I'm not going to out anybody here but 3, 4, 5, 6, 10 hours. And this wasn't just this group. I've had this conversation elsewhere of the amount of time people put into creating SOPs. And it seems counterintuitive that the SOP fanatic in me is telling you don't spend your time on sops, but I really do think that we do not want to be spending our time on sops. All right, there we go. Confirmed. The audio is working. Very much so. Okay. That you should be spending that much time. I do not think most businesses should. Almost any business should be spending five hours in one sitting on one sop, especially small businesses. One of the best processes and maybe one of the first processes you need to document for your business. Decide. Not even document, just decide. Sit down and say, this is how we're going to do it is your process for processes. How are you going to document your processes? I've been reading some books recently about other the gurus that tell you how to document a process. And I've been alarmed at the range of recommendations that you might see. So one of the most popular books on this is Clockwork or Clockwise Clockwork. Clockwork. Clockwork, I'm pretty sure. Oh, my gosh. And basically they talk about how you should be building a business that can run itself. It runs like clockwork. You get it. And the prescription in that book is one that I've seen all over the Internet of how you should document your processes in the lightest way possible. It's very focused on making life easy for the owner. And it basically prescribes just use this fancy technology called loom. You know how books are. Clockwork tells you to use loom, basically, and just record yourself talking through a process and then just give that to people. Now, that is probably the so basic, it's barely going to save you any time approach to documenting processes. Meanwhile, this conversation I had with these people this Past week suggested that a lot of the small businesses with not a lot of time are investing totally the opposite extreme into their system. They are dedicating five hours in one sitting for one rendition of their SOPs. Oh, that's a lot. So there is a place in between these and I want to talk about what that looks like and how you can kind of define that for yourself. I'll say that one of, like I said, this is like one of the key decisions you need to make for yourself. You can try both extremes and kind of walk your way towards the middle. You don't need to know the right answer, but it can sometimes be helpful to watch videos like this or to actually look at examples of the work product of both extremes to let you know which way is right for you. So when I'm actually working with clients, I have a few, like a library of SOPs with different levels of sophistication, like three major levels of the clockwork recommendation of one long video. Like just watch it for 30 minutes every time you need to do a five minute task kind and the super detailed like work instructions and then this place in the middle. And I usually when I'm working with clients or if we're doing group work, we're bringing all of those to the table and asking you to pick the elements of each that you like to find something in the middle. Let me explain why I have a problem with the super detailed approach. The super detailed approach to SOPs is extremely time intensive from the most important people in the organization. The expert, whether that's you, the entrepreneur that's trying to delegate for the first time, whether it's you, the founder of a large organization that's trying to get things off of your plate and onto your manager's plates. Whoever is the person trying to delegate, they're typically the expert in that topic. And it's safe to assume their time is probably more valuable than the person they're delegating to. So it's wonky to me that the entire burden of process documentation would be on the person whose time is most valuable and the person who's basically getting rid of this task. I don't know about you, but I wouldn't trust somebody who I'm about to fire to train the next person, if that makes sense. And so I wouldn't ask the person who's getting rid of the task to explain it to somebody who's totally green. It's similar thing there. Because your time is so valuable, you should not be spending all of your time 100% of the process should not be built by you. And because you're so experienced with it, your way of explaining it is going to be bonkers compared to someone who has a fresh perspective. So that's my problem with that. My second problem with the really, really intense, let's sit down for five hours and write this entire process out is how much time are you building into a process that's incorrect? So I mentioned before that the way you're going to explain it is not going to necessarily provide the info or the context that a newbie might need to do that task because you're the expert wearing the expert hat and so on. So instead of picturing us doing a five hour deep dive into our email newsletter process, you saw just last week how I documented my newsletter process in 30 minutes, 45 minutes live on air, instead of doing it in one big chunk iterate. I know that word is kind of such it's overused nowadays, but that is my biggest problem with seeing people do a huge time junk. You're doing a lot. You're wasting the wrong person's time. I do mean wasting time. And you are not going to get the correct result anyway. Rather than one five hour sitting or one three hour sitting, six 30 minute sittings are going to give you a much higher result. Plus it'll be a little bit more pomodoro friendly. So you're not sitting there just trying to get everything out of your head. I will wrap up this video with my explanation of how I think you can merge these two, but I just want to discuss that extreme first. If you are a business, less than a million dollars a year and you have anything other to do, anything else to do besides just documenting processes, there is no. I can't think of a reality where you'd want to spend three hours documenting one process, maybe three hours documenting ten processes all for it. But no, unless you're the coo, and that is your full time job, is just to start documenting processes because you've got this big exit strategy or something like that. Just no, don't do that. That is not your process for processes. That is a process for frustration. On the other extreme, let me go back to ranting about Clockwork because I love picking on the big gurus. So for the record, I love the book Clockwork. I think it's got a lot of good stuff in it besides kind of the soccer mom style, nicknames for things. But the prescription for how to document your work, which is one that I see all over the Place, which is just make a loom video is troublesome in the opposite way, especially for small teens. Now, again, if you were the big COO guy or you were the big boss man and you had a huge team, and for you, paying someone $20 an hour to watch your 30 minute video to do the five minute task every time they needed to do it, if that extra 30 minutes of labor wasn't a significant cost to you, maybe the inefficiency of making a 30 minute long video, talking through that task makes sense. For most of us, our labor is a considerable cost. Even when you're a large company, labor is a considerable cost. And while you can deal with more inefficiency when you're larger, you probably don't want to. So my problem with the loom video approach is that it is super easy for you to get out of your head. It is super difficult for it to be accessible to others. It is. I think you've all been in that, that mind space. I know I create a lot of YouTube, I watch a lot of YouTube. But there are times where you're like, I don't care about your 15 minute video. I know many people have said that to me. I don't want your long form video. Just tell me the answer and you'll see. When I create YouTube videos, I am actually pretty, I try to be pretty conscious of this. And my workaround is to create the video, working on subtitling them, but also create timestamps in the description. Basically, we're making that video easy to pick up and search. Creating a loom video does not provide that searchability, that ease of use. So you're basically taking your convenience at the cost of the end user's convenience. And that end user is going to be using that sop, hopefully day in and day out for years to come. So is that really the right investment of distributing work? Are you really wanting to put all of that burden on the person using it every day instead of just doing a little bit more work up front? I am very much opposed to the idea of people who just make loom videos and say, yeah, we have things documented. We have a loom video for everything. That is not an sop. That is a recording of an experience which could be used to basically walk someone through things. Which walking people through things is also not an sop. It is just an experience that you're able to provide. So a recorded experience is not an sop. An SOP should be there to save people time and to make things clearer. Videos can Somewhat do that, but not as more not as effectively as a mixed medium approach. My other concern with video, and this is a really big one for those of you with small teams, I have the same problem we have on the opposite side. So my big concern with the big people over here is that three hours you're going to document the wrong stuff. You're not going to be able to anticipate the needs and changes that need to be made. You're not going to get everything covered anyway. So why get so detailed over here when you're making a video? I don't know about you, but I don't really just whip open or open up a video, an MP4 file and start editing it in my editing software just because I want to change something in the process. That does not seem lightweight to me. But if we want to be good about our processes, we're going to be changing them frequently, right? So using video, which is a very fixed at this point, a very fixed form of communication, I'm going to make this video. This is going to be saved and recorded. It's going to go to you changing it or amending it or changing. What I'm saying right now is a difficult time sucking. And for processes that we want to be evolving over time, it just does not make sense to me to use video, at least in large chunks, to explain a topic. Rant over. I think rant is over. If you are watching this and you have a process in place for how you document your processes, I would love to hear it here. Not that I'm going to rip you apart. If you tend to skew towards the all in one sitting, really intense, super descriptive instructions. Go ahead and put that over there. You can just say you're super detailed. If you are someone that skews on the Loom video, I will not persecute you. I'm just curious to hear what your experience has been using that. So if you use Loom or Dub or Camtasia or Screencast, O Matic or any of those kinds of things, and use screen recordings or video walkthroughs, I would love to hear that as well. And if you totally agree with me, I'd also love to hear that. So besides just ripping apart what everyone suggests and what every YouTube video I look for that says how to create SOPs instructs you to do, what's the middle? The middle of the road is one that you need to define for yourself. For me, this includes a combination of both extremes. We include videos or preferably gifs. But only for small segments of things, things that don't change. So rather than one 30 minute video, we are looking at maybe a 2 minute video showing how to get into settings of Streamyard. Or rather than using a video at all, I use a screenshot with like an arrow over it. That would be easy to move that arrow in PowerPoint or whatever you're doing it without having to go in and rerecord an entire video, which I will never do, I will always put off. I also pull in elements of the very text heavy screenshot, crazy detailed area on the other stream. I usually create my SOPs with a set structure which I've shown here in past lives. If you haven't seen that, just let me know and I can find the right link. But build a structure for your SOPs that let you know when you're done. So maybe it includes at the top the owners. Who's in charge of this? What department does this fall under? Don't bother with things like when was it updated, when was it created? Because we're using technology, it tracks that for us. Let's not make more work than we need to. Maybe there's a few key sections and keeping these as simple as possible. Things like what's the purpose? That's my favorite header because it says not just what is this process, but why does this process matter in the the. In the context of the larger business? This is so different than the dictatorship style of process where it says do this or else. By having that purpose, we are justifying and kind of commending somebody for following the process because it's letting them know how important it is and how important they are by extension for doing things the right way. After purpose, maybe it's procedure after procedure. Maybe it's FAQs or examples of good and bad, you know, good and bad examples of what this process looks like. Three basic pieces, very simple. They can only have a few sentences each, or they could have, you know, a page each, but not much more. The main difference between myself and these two extremes, or at least what I suggest and I found helpful for clients versus these extremes, is not necessarily the end product, because believe it or not, the end product is going to look a lot like both of these extremes. But what gets done in one sitting is the real change. So rather than just recording a video and clicking Save and throwing it into airtable or throwing it into Asana or ClickUp, rather than doing that, or rather than spending three hours writing every single step in each iteration of working on a process, I believe you should only be working for about 20 minutes, maybe 30, 40. If it's a really complex thing that you really need to get out of your head. I believe you should approach processes in phases. You should do one in one sitting, then you should use the process to revise the process. Then you should delegate the process and have that person revise the process, then shut that person, give it back to you, and you should revise the process. There is a phase by phase improvement of a process before it even becomes a published sop. The amount of time that process I just described to you takes is probably less than the time of doing it in three hours. And it's going to be more accurate because you're involving more stakeholders. You're using fresh brain power each time you're using it, and just fresh eyes. And it's going to be more accessible than that loom video because you're using things in clips and chunks and you're focusing on editability rather than having one easy to brain dump information dump, which you could. To be clear, you could start out this process with a loom video, but it does not end in that state before the first or after the first draft. I've given you some kind of fuzzy stuff here, but what I want to loop this back to is you need to decide what this looks like for yourself, and you need to make this standard and incorporate other people into it so that a hundred percent of the most valuable person's brain power is not spent entirely on sitting in the armchair and documenting processes that maybe they don't even do themselves. It's just we're shooting ourselves in the foot and wasting our resources when we approach things that way. And if you're watching this and you're like, I have no idea what mine should even be, or maybe you're at one extreme or the other and you're not even sure how to divide it into the middle. One of the things that I work on with clients and I'm actually really focused on in the group program coming up, is this. Defining this for you, using standards and seeing examples and defining your process for processes is the main prerogative of the group system up that I am launching here in September. So if you're at all interested in kind of getting past that thought of just thinking about your processes and being like, yeah, I should totally document my business processes. If you're ready to move past that and actually do something about it, I would highly encourage you to reach out, like, leave a comment, shoot me a message. You see me in the group. I'm here all the time. Let's talk about this. Because if you're at either extreme, you're wasting someone's time, either your time or your team's time. If you were in the middle but not sure, like you're reinventing it every time, you're still at a fuzzy point. And if you have a solid process for processes but you're not using it, we should definitely work together on that. Because that's where the rubber hits the road is once we are able to get a clear directive as to what your processes need to look like, then it's just a matter of doing and you have people, whether it's yourself on, you know, on Monday mornings when you have your CEO day, or whether it's your contractors or whether it's your team or your employees. You have people who are able to execute once you have those cleared guide rails and clear instructions. And we just need to make sure you have those and you feel good about them so you can start building out that business instruction manual. So that's just my final call to action here. I will say if it has been helpful to you, if this video has been at all informative, if you were like, oh, I never thought about it that way, or if you've maybe been on the clockwork side of things, let me know. Because I keep reading books and so many are prescribing loom. I'm like stop. I would love to hear in the comments have a conversation with you about what you're doing and if you want to actually change anything around this or anything around the workflows we've talked about in other videos, maybe we should talk. So that is it for this workflow Wednesday. I just wanted to go on the soapbox. I didn't even bring the whiteboard today. I was like I just need to talk through this and hopefully my energy wasn't all over the place. I just needed to share a little bit about this frustration. So that is my thoughts on process versus Process or process for Processes. I would love to hear what yours is in the comments below and I will see you all next Wednesday for another hopefully less ranty Workflow Wednesday. Have a good one. If you are tired of trying to piece together YouTube videos to figure out out how to align your workflows, your processes and your ClickUp account, well, maybe it's time that we talk. I work one on one with a select group of clients every quarter to help people build out their systems and processes. Find out more at ProcessDriven Go.