Learning to Delegate, part 1 [07/23/2008 13:16:14]
I'm a do-it-yourself kind of guy. I like having things done my way.
That's probably why I work for myself and use a blog tool I wrote myself built with a web framework I wrote myself.
It's why I have a dis-assembled air filtering system on my living room floor. The motor stopped turning so I took it apart to see whether I can fix it. (The jury's still out.)
Of course I've always known it doesn't make sense to do everything by myself. There's a lot of stuff I do myself that I know other people could do better or more quickly.
But understanding the need to delegate and actually delegating are two different things.
It turns out that delegating your work is a lot of work.. In fact, delegating is a skill that has to be learned, and if it's not done well, it can cost more time and energy than it saves.
delegating RPM builds, take one
For example, one thing I really hate is compiling RPMs. RPM is the Red Hat Package manager, but it's also the extension on the packages themselves. They basically act as software installers and uninstallers for Linux, and I use them to keep all my servers up to date and in sync.
Often you can just download pre-made RPMs, but sometimes you have to package them yourself, which is often a whole lot more complicated than just compiling the program directly from source.
Building RPMs isn't something I find terribly fun, so on a couple occasions, I've tried to delegate the work.
The first guy to help me out was an RPM whiz. He built the RPM I needed and then went above and beyond, hooking me up with my own yum repository. (Yum is a third-party package manager built on top of the RPM architecture.)
Unfortunately, I have no idea what to do with a yum server or how to maintain it. When I want to update my servers, I just stick the RPM in my public rpm directory and fire off a tiny python script that tells all my servers to install it. It may not be as sophisticated or fancy as yum, but it works fine for my simple needs.
I also use Red Hat's up2date program, which keeps the core system current with the latest security patches. Turns out yum had requirements that broke he Red Hat files (in RH Enterprise Linux 3), so switching to yum basically killed up2date. The RPM guy spent a bunch of time sorting this all out and made a nice bootstrap tool that supposedly made everything work.
Anyway, to make a long story short, I never used it. I'm sure it was a fantastic system and better than my clunky little script in numerous ways, but I had no idea how to maintain his setup, so I just stuck with what I knew.
RPMs, take two
Later, I needed an RPM compiled for PHP 5. I hired someone to do it, and they went in and figured it out and gave me an RPM. He did a great job.
Then a couple months later, I needed to add some extra PHP modules to the package and I wound up having to redo his work from scratch.
trying elance
Back in October 2006, I had idea for a website that would color source code for printing.
I posted a description of the idea on elance and pretty soon I had some bids. I wound up hiring a guy from Pakistan who promptly coded up exactly what I asked for. (You can see it at ColorYourCode.com.
I know it's written in PHP and it uses GNU enscript to generate the PDF files under the hood, but I have no real idea how it's put together.
knowledge transfer
All of these are problems with knowledge transfer.
Each time, I paid for the initial creation of an asset but failed to capture the contractor's knowledge, and thus raised the cost of maintaining that asset.
extreme knowledge gap: DCD hosting
Once upon a time, I bought another hosting company. It was a single linux box running a popular commercial control panel called cPanel.
I paid several thousand dollars for it. It was a huge investment, but I ran the numbers and concluded that I'd break even in a reasonable time if I just let it sit there, and could make a decent profit if I moved the users over to my cornerhost machines.
Instead, I drove the company into the ground.
Even though it was a Red Hat Linux box, it was completely different from my cornerhost servers. It used a different mail server, different control panel. Some of the sites were running Java and talking to a PostgreSQL database. Some of the sites required obscure PHP modules I'd never heard of. And of course, cPanel has its own ideas about how to arrange things on the file system.
Even the billing setup was different. I have a nice python system that manages my billing. He had a spreadsheet with everybody's email address on it. (No names, of course, just email addresses. I had to send out a mailing to ask everyone their names.)
Integrating all that into cornerhost was a non-starter. It took me forever just to get around to billing anyone, and many of the sites turned out to be unreachable.
I had a new customer sign up at one point and had no idea how to set them up. I didn't even get an email notification that they'd signed up.
Then in a colossal screwup, the java server went down when I was out of town, and it took me several days to find out. Pretty much all the java customers left.
Several other customers closed down their sites or decided not to renew, and today I'm left with a server that loses about $200 a month on average.
I even tried to give it away at one point, but couldn't find anyone to just take it off my hands without creating a ton of work for me in the process.
(Since starting the ADD meds, I've actually gotten on top of this situation and have somebody lined up to help move the remaining customers over to cornerhost.)
abdication vs delegation
There's a great book called The E-Myth Revisited by Michael Gerber. It's is all about learning to delegate. (About 50% of the book is flowery pep talk that nearly drove me insane, but the other 50% is very practical, hands-on, how-to-do-it stuff, and it's pure gold.)
One of Gerber's points is that a lot of entrepreneurs make the rookie mistake of abdicating work instead of delegating. Abdicating basically means giving up. It's handing the problem to someone else and hoping for the best.
Basically, I took the abdication approach in each of the above cases. Even with DCD, I was abdicating my marketing role, and just paying someone to give me their clients. In each case, what I got back was good but wasn't done in a way I could easily understand or reuse.
Abdication doesn't take any work up front, but it has a very high cost if there's any maintenance in the future.
The work of true delegation is everything you do to make sure you can maintain the solution in the future.
hiring illustrators
Another mistake I know I make is jumping into things before I'm ready.
I own over 100 domain names, for example. Only a handful of them are in use.
Twice now, I've hired brilliant illustrators to create artwork for something that doesn't yet exist.
In both cases, I got some pretty amazing artwork. For example, I hired Sam Logan, creator of the Sam and Fuzzy webcomic and handed him this sketch:
He gave me this (much larger and without the text):
I couldn't have been more thrilled.
Well, crap. Firefox managed to eat the other 10 or 20 paragraphs I'd typed up without saving. It's times like these that make me glad I'm a do-it-yourself guy with my own blog tool instead of one of those lamers who got auto-saving off the shelf with their fancy AJAX interface.
I'll give it another shot later.
PS: I re-enabled comments on my blog the other day, if anyone wants to respond to the story so far...