The delegation yoyo

I suffer from the triple threat of ambition, perfectionism, and cheapness, which leads to something I call “the delegation yoyo”. I want to do a million things, but I try and do it all myself, because: “No one else will get it right, PLUS they want how much?? It’ll cost me $0 if I do it myself!”

As I’m trying to do too much myself, I get overwhelmed and frustrated, until I finally cave and start looking to delegate / outsource. However, this is where the other part of the yoyo comes in, because by now I’m so overwhelmed that I want to delegate all the things, so I over-hire and try and just throw everything I can think of over the wall to have someone else do it. But because I’m in overwhelmed / burnout / panic mode, I don’t really do any training for these tasks, or clearly define deliverables, or even stop to question whether this is something that should be done at all!

This process inevitably leads to me spending too much money over the course of a few months paying someone to do things poorly (not their fault), many of which shouldn’t be done at all, by anyone.

In early 2018 I finally fully realized this pattern and decided to do something about it. And I got it about half right.

I hired two people in 2018:

  1. Justin, who I hired to do design and help with Everleads
  2. Danielle, an executive assistant I hired through Worldwide101

For Justin, things have worked out really well. The truth was that I didn’t really need all that much in the way of design work after all, so I would have been paying for more time than I needed, except that the daily lead curation for Everleads ended up taking more time than expected. And I was also able to hand off customer support to him, which was awesome. So all in all, that’s turned out to be a great situation.

For Danielle, the reality is that I do need an assistant but I need less time than I was buying. More importantly, I need to focus on building systems that my assistant can run, rather than expect them to build the system themselves.

Put simply, it does NOT work very well to hand someone a general description of the problem or the outcome you’d like and then hope for the best.

Those people do exist, but they tend to be rare, expensive, and not geared towards doing the ongoing implementation of the systems they design.

As an analogy, imagine the difference between asking someone to “put together a delicious meal for tonight”, versus handing them a recipe and all the ingredients.

It’s even worse if “put together a delicious meal” actually means “I’m in the mood for Thai food and I’ll have five other people joining me and one of them is deathly allergic to peanuts”, but you don’t actually spell out those requirements in detail. Sure, you’re going to get some kind of food at the end of this. Best case: you end up with not enough food and the wrong cuisine. Worst case: you end up killing a guest 🙂

The point in this tortured analogy is that it’s a lot less work for you to just toss vague problems at someone and hope they solve them, but you’ll get much better results if you take the time to clearly define what the desired outcomes are, and detail out the process required to get there.

Which raises another point: I think it’s usually a mistake to delegate things you haven’t done yourself first.

To be clear, “delegation” is distinct from hiring a specialist who has knowledge and skills that you don’t have. You’re not really “delegating” things to your CPA, attorney, doctor, etc, unless you could do them yourself.

The problem with delegating things before you’ve done them is two-fold.

First, you aren’t able to communicate the process and outcomes very well. This naturally leads to vague requests like “make a delicious meal” rather than very specific processes like “follow this exact step-by-step recipe”.

Second, you’re not going to be able to very effectively evaluate people, either initially or on an ongoing basis. And when things change or stop working, you won’t be able to help diagnose the problem if you don’t have any real understanding of the problem space.

I’ve learned this lesson the hard way, by constantly trying to delegate things before even doing them myself:

  • bookkeeping
  • customer service
  • outreach marketing
  • social media management
  • SEO keyword research

Most of these didn’t turn out well. Once I did them myself at least a little bit, they turned out far better. By doing them for a bit I can quickly see what’s not going to work when I hand it off because it’s too vague or subjective, and then adjust the systems or processes so that everything is as clear and step-by-step as possible when handed off.

In terms of actual systems and training, I love screencasts, and then written documents in addition where it makes sense. I try and avoiding training that is live and ephemeral, like screen-sharing, video chat, etc. Not only does it not give the person you’re training something they can refer back to later if they need a refresher, but when they leave or you need to bring on new staff, you have to do that all over again.

Screencasts are awesome because they’re quick and easy to put together, and they convey a lot more information more quickly. I could spend two days writing a document telling you how to handle my bookkeeping in the software we use, or I could cover 95% of the information in a 45 minute screencast where I actually show you exactly where to click on things, explain my reasoning, etc.

The cost to the recipient is perhaps a little higher in that they have to watch a linear video instead of being able to jump around a document more quickly, but I think the ease of creating these assets is worth the tradeoff, particularly since I’d likely never get around to writing them up if screencasts were not an option.

Additionally, you can pay someone to watch your screencast training videos and turn them into an accompanying training reference document. I find having a reference document is especially helpful for long lists of things, like actions to take in particular scenarios, or how to categorize emails or something. Anything that a trainee would want to write down so they have a place to look at later for reference should also live in a document.

As Mike Michalowicz explains well in Profit First, creating systems in your business and having someone run them is not a switch you flip. It’s usually a long, slow transition. It takes time to put together the systems, find the right people, train them, and then empower them with enough authority to help you get results.

I think I’m finally getting better at this, but time will tell.


[type='submit']
[type='submit']
[type='submit']
[type='submit']
[type='submit']
[type='submit']