The Delegation Trap

SPEAKER_00 0:00

Delegation should not create more work, but unfortunately, for a lot of founders, it does. You hand something off, it comes back wrong, it comes back half done, or not just how you imagined it. So you fix it. What has happened is that you have ended up doing two jobs. The original task that you thought you had delegated and the cleanup after the mess. And I get it, it's not that you want to be a control freak. It's just that you've tried delegating and you've been burned before, and you're tired of paying that rework tax. So you tell yourself, I'll just do it myself next time. And this is how you become the bottleneck in your business yet again. In this episode, I'm going to show you how to delegate in a way that actually sticks so you can hand off tasks and stop taking them back. Welcome to the Systemized Business Podcast. I'm BK, a business manager and a workflow specialist who just loves all things systems and process improvement. And this episode is for the founder who wants the support but keeps taking tasks back. Maybe you've hired an assistant, maybe you've you're working with a contractor, or maybe you have a small team. You could still be solo, but occasionally ask one or two people to assist you with one or two things in your business, but you cannot keep scaling like this. By the end of this episode, you will know why delegation fails, even though you have good people on your team. You will know the exact handoff package you need to delegate without rework, and you will have two approval rules that protect your time and quality. And then I'll give you a simple challenge: one task, one page, one SOP. Let's get into it. Let's first get to the heart of why delegation fails. Um, and I have identified four main reasons. Most delegation problems are not people problems, they are handoff problems. And as I go through these, see if you can recognize where things have gone wrong for you, and later I'll give you some ways to fix them. More often than not, we don't need a better assistant, we actually need a better system for transferring the outcomes we are looking for. Okay, so the first reason that delegation fails is because there is no definition of done. We say things like, can you post this? Can you handle my emails? Can you update the website? Can you help me with onboarding? In your head, you know exactly what that means. But in their head, they're guessing. And people can't hit a target if you don't explicitly define it, right? This is why, as founders, we end up disappointed because the expectation lives in your brain, it never made it into the brief and it was never clearly communicated. Delegation without a definition of done is basically a setup for failure. The second reason that delegation fails is because there's no SOP, standard operating procedure. Or there is an SOP, but it is so long and so complicated that nobody actually uses it. A lot of founders will say, but I explained it in a voice note. Okay, well fine. Voice notes are great for relationships, but they are not a reliable process. A voice note is not an SOP. A scattered message thread is not an SOP. The goal of an SOP isn't to write a novel either. The goal is usability. Something someone can follow while they are doing the task. No SOP, unfortunately, um, it fails. The third reason delegation fails is because there are no checkpoints. So let me explain this. So you hand off a task and then that's it. You disappear, you don't see anything until the end. Only to find that it's either wrong or it is late or it's not even what you wanted. How about the other extreme? You uh hand off the task and then you check every five minutes, which means now you're micromanaging. So you are still doing the work mentally and frustrating the person the person that you have handed the task to. So the the solution here is not to delegate and forget, delegate it and forget it with zero checkpoints or the other extreme, the constant looking over the shoulder. It's to set up milestone checkpoints to give you the opportunity to give feedback to the person doing the work. And the last reason, reason number four, that delegation fails, and this one is is is not quite as obvious, is um is because you are delegating the wrong task first. If you delegate something that is high judgment, high risk, or brand sensitive before your delegation process is stable, it is likely going to feel and be a complete disaster. So the best first delegation tasks are repeatable and predictable. By and delegation doesn't mean that we're just dumping tasks that we don't want to do onto somebody else. What we are really doing by delegating is transferring outcomes, and so this needs to be done with as much clarity as we can. So, okay, we know now why delegation fails. So, how can we prevent that from happening? And that's why we need a simple handoff package, and every delegated task needs a handoff package, and it doesn't have to be complicated, it uh we're not creating a long document or a cumbersome process. All we need is something that makes the outcome clear, and I call it a package because it has four parts. Part one is the outcome and success criteria. This answers the question: when this task is done, what is true? Let me give you an example. Let's say you're delegating a social media post. Now, the outcome is not post on Instagram. The outcome is post is created, caption matches brand voice, it includes a clear call to action, and it is scheduled for the correct date and time. That's the outcome. Then we want to add success criteria. So these are three to five bullets. For example, the the uh caption is conversational but professional, it uses our tone guidelines, it includes a call to action, it uses correct hashtags, it's uh and it is scheduled inside whatever tool that we use. So that is how we measure that it's successful. The success criteria matters because it turns feedback from emotional to objective instead of this doesn't feel right. You can say, does it meet the criteria? Yes or no, and then go through the three bullets, three, five bullets and see if it does. Just these two steps can reduce rework immediately. Do you see that? Part two of our handover package is constraints. Constraints are the boundaries that protect the brand and protect the business. This is where you clarify things like your brand tone and your brand voice, the do's, the don'ts, the budget limits, the tools to use, uh, the access and permissions. And here's an example of simple constraints that really can save you a headache later. For example, no emojis on LinkedIn posts. Keep them conversational but corporate. Use Canva templates in this folder only, or keep captions under 150 words, or no refund language unless I approve. So constraints are putting the rules, the boundaries in place so that micromanagement is avoided. They give additional clarity, and clarity is what makes delegation feel safe for you delegating and safe for the person who the work is delegated to. Part three of the package is giving an example of good or what a finished version version looks like. And this just might be the magic ingredient. This is an example of what a good finished version looks like. So this can be in the form of a link to a post that performed really well, or a screenshot, or a loom video, a template, or a gold standard folder with examples. If you show somebody what good looks like, they can match it. But if you don't, they're kind of just guessing, and guessing can create rework in the future. And then finally, part four is uh deadline and check-in points. So we're the final part of the package is the deadline, the check-in points. Deadline is uh is obvious, but check-in points are what prevents surprises, right? So you don't need um to be checking constantly. Remember, we don't want to be micromanagers, um, but we want to check at milestones. For example, if you have dedicated a blog blog post, indicate that, for example, the outline should be due uh Tuesday at 2 p.m. First draft can be due Thursday, 12 p.m. And then final edits Friday, 10 a.m. That is clear, those are milestones that you give feedback at every milestone. If you're delegating a batch of content, you can request send me three caption drafts first. Once approved, create the rest, and then final review before scheduling. Doing this protects your quality, uh your quality, and it also protects your time. And one thing about um about approvals, because some this can also be where people can get stuck and spend a lot more time than necessary uh approving things. You can approve things all day. And I actually advise my clients to batch approvals, and the way this looks like is instead of a message coming in, you respond, a draft coming in, you check it, a question coming in, you answer. Uh um this being asked for approval, you you know, like I said, this can take all day, and your day ends up being just a series of reactive micro approvals. Instead, I suggest having an approval window. For example, I do approvals once per day at 3 p.m. Or approvals happen Tuesdays and Thursdays. And this is how we can protect our deep work blocks. Remember, your team can still move forward, but you don't have to be interrupted 20 times a day. Another approval rule actually goes back to the checkpoints. Remember, one of the examples I gave was uh send me three drafts and when I approve, send the rest, something like that. Well, this can be an approval stage. Show me the outline first, send me two options, complete one example first, then replicate. Another example uh would be if you are delegating, let's say, your podcast show notes, don't say do all these 12 episodes, rather say do one, let me approve the format, then you can do the rest. And so that's how we can prevent rework at scale. So what we are not um we don't we it's not that we're chasing perfection, by the way. The goal is to be confident that the outcome we are looking for is clearly communicated. So now you might still be wondering what to delegate first, because that was one of the things at the top of this episode that we talked about delegating the wrong thing. So you might be wondering: okay, so what do I delegate first? Um, we want to delegate repeatable tasks before judgment-heavy tasks. For example, you can delegate things like scheduling and calendar management, formatting and um scheduling content, repurposing a post into multiple formats, client onboarding steps, you know, the folders, the templates, the welcome emails, file organization, things like that that have a repeatable process. The things I do not recommend delegating at first would be high-stakes strategy decisions, sensitive client escalations, or anything that you have never consistently done yourself yet. So you start with what repeats because that's what makes systemizing it easy. Let me take a quick break and let you know that if you have support, if you have an assistant or a small team, but you find that work keeps coming back to you, you, as this episode has um hopefully communicated that you don't need more help, you need clearer processes. So I'm offering a free clarity call where we will identify what is breaking in your handoffs, your roles, and in your workflows. And I'll recommend for you the next best step. For a lot of founders, tightening role clarity and building those standard operating procedures and checklists and templates so tasks can be owned end-to-end, is exactly what they are looking for and what they need. So if that is intriguing to you, if you need that kind of uh support, the link is in the show notes. Alright, so here is your action step for this week. Plan one task that you redo every week and create a one-page SOP for it. One page, just one page, and here's the simple structure, the purpose. What is this SOP for and when do you use it? The tools and the access, what tools are used, and where do these files live? And then the steps, try to keep it to five to ten bulleted steps, step by step of what happens throughout the process, and then the definition of done, which is it might be a checklist. What must be true when this task is finished? If you need to add a section that notes what the common mistakes can be, what usually goes wrong, or what can go wrong, how do you avoid it? And then give an example link or screenshot what good looks like. And that's it. We want to create SOPs that are simple and usable, and once you have one SOP, delegation gets so much easier, and then you do the next one. And if you want the template of either the handoff package or the SOP template, you can download those in the show notes below. If this episode hit home, if you found it useful, I'd love for you to give us a subscribe or a follow so you don't miss future episodes. Uh, go ahead and share it with somebody who might need a little bit of guidance when it comes to delegating and encouraging and encourage them to subscribe as well or follow the show. Why not? Thank you for your time today. Thank you for listening. I'll talk to you in the next one. Bye for now.