Delegate or die: the self-employed trap

http://www.sivers.org/delegate/

by DanielRibeiro • 14 years ago

262 61 14 years ago

Sodaware• 14 years ago

"The E-Myth Revisited" is a great book that deals with this problem (amongst other things).

maayank• 14 years ago

I see it's from 1995. Is there something more updated? With the prominence of programming life-style businesses I'd imagine there are new things to be taught.

davidw3• 14 years ago

It's still a pretty valid book:

"Work on your business, not in your business"

the problems are the same - technology can help you solve them, but fundamentally it's an issue of how to scale up in terms of people. Here's another one:

http://www.amazon.com/dp/B004IYISQW/?tag=dedasys-20

with a cute story, but the concepts are pretty similar.

Rob Walling also covers this, briefly and more to the point in Start Small, Stay Small:

http://www.amazon.com/dp/B003YH9MMI/?tag=dedasys-20

Which is also full of real, practical advice for people doing small software businesses.

j458• 14 years ago

Some of the best books in any subject are often timeless.

The book lays out a systemic formula for making your business grow and run more and more with out you so you can work on your business, instead of your business.

Also this book has been updated I believe from time to time. It's not worth worrying about in this case because it's not opinion based advice, or based on current trends.

ngsayjoe2• 14 years ago

I finished E-Myth Revisited years back ... I'm now on E-Myth Mastery ... many of the concepts of his books requires practical experience, otherwise you might struggle to visualize his concepts ...

Following his concepts in the first book i had successfully created a small and profitable company now with about 8 employees ... i'm hoping to learn the skills required to bring my company to the next level! IPO, MNC, Big Corp, etc.

arkitaip2• 14 years ago

I've heard so much good about E-Myth Revisited but I'm not fully convinced that it's any different from all the other biz management literature I've read. Would love to hear what your major take aways are.

shreyas056• 14 years ago

reading this felt like reading an Aesop's Fables :). Very useful

heretohelp• 14 years ago

Sivers is one of the few writers on the subject of business/startups that is reliably good.

A few reasons this is the case:

1. He's not some professional blogger pontificating on things he doesn't know about. He started a real business and his posts are from his experiences starting and scaling up a successful business. He's not the usual mountebank type you get here.

2. His real business involved selling actual products that made people happy, he wasn't agglomerating eyeballs for wholesale to the advertising industry. The value proposition is very explicit.

3. He thinks like an engineer and applies the rational processes normally demanded of programmers/engineers/etc. to the business. It's not Six-Sigma certification lessons, it's him analyzing and responding to discrete business, engineering, and product problems.

You could just bundle up a dump of every post he's made about programming, products, and businesses and sell it as a book and be distributing something far more useful than 99% of what exists on the business advice book market or what gets posted to HN day to day. Toss in a bonus pack of Patrick's advice on business, SEO, A-B testing, statistics, marketing, etc and you've got a great batch of material to start with.

The stuff is timeless (relative to the internet) in a way that Norvig's post on his sudoku solver for demonstrating dynamic programming and constraint solving was.

kenmck• 14 years ago

Agreed. Actually there is a Sivers book, it's called "Anything you want"

unreal37• 14 years ago

And he has a (pricey) video course on AppSumo.

patio11• 14 years ago

A few of my savvier (small-ish) software buddies use this system:

1) We have an onboarding Google Doc for everyone at the company. It is grouped into headings. One heading might be, e.g., "Common Customer Support Questions" followed by "Query: A customer complains they can't log into the software. Common phrasings for this: X, Y, Z." Research: "Go to page X in the dashboard [detailed in Internal Tools]. Search for... . If you find the customer, use the password reset tool, then copy/paste the following response to the customer, adding in their first name if you can reasonably guess it. If the tool reports no results, forward email to foo@bar.com and send no response."

2) Every time the proprietor gets tired of a genre of emails, they improve either the internal tools or the business rules to optimize themselves out of that workflow.

3) There is frequently a catch-all rule saying something like "If you have a novel situation and think you can handle it for under $100, do so [see: Getting Access To A Company Card], and fill in why the situation was novel, how you handled it, and what you spent on your weekly report Google doc. Don't worry, we trust you to use your judgement." (This is probably among the best pieces of actionable advice Tim Ferris ever gave.)

4) Capturing this state machine as a Google doc means the business has a memory longer than the individual workers, which is particularly important in a virtual-company sort of situation where you're dealing with VAs/freelancers who a) will often not pan out and b) when they do pan out have an expected lifetime tenure with the company of 6 ~ 24 months only.

Poiesis• 14 years ago

Another solution for this is a wiki instead of a Google doc. I've seen it work well. But the important part is to make it easy to use, easy to search, and easy to update. Then just make sure as many questions as possible are answerable by the wiki. About to type an email with an answer? It better have the link to the wiki in it.

larrys3• 14 years ago

Agree. I also use a personal wiki (twiki) to keep track of all the answers and processes that I have figured out and need to use over time. Started many years ago it's close to 1900 pages at this point.

philwelch4• 14 years ago

I've also seen wikis that just turn into gigantic repositories of stale data that just sit around while tribal knowledge is passed around by word of mouth. This seems to be the default state of the company wiki, really.

Legion• 14 years ago

At my company, we've switched from a wiki to Google Drive to lower the barrier of contributing.

As a programmer, wiki syntax seemed pretty obvious to me. But it was a block for some of the non-coders.

ConstantineXVI• 14 years ago

Besides no easy internal linking, Google Docs isn't that far off from a wiki. And as a bonus, non-technical people just see it as an ordinary word processor and don't have to understand the concept any further.

caseysoftware• 14 years ago

"Every time the proprietor gets tired of a genre of emails, they improve either the internal tools or the business rules to optimize themselves out of that workflow."

I really like this point.. I always think of the FAQ as a bug list. If a question comes up repeatedly enough that people have to start searching for a solution, odds are there are a way more people not asking and you're losing conversions.

wikwocket• 14 years ago

This is sometimes phrased as "fix every problem twice," ie solve the immediate problem, and then figure out what to do so this problem doesn't happen again.

This can be done via tweaking your funnel or workflow, adding an FAQ entry, adding tooltips, restructuring your UI to make things intuitive, solving a technical glitch, etc.

Joel Spoksky has a great article covering this here: http://www.joelonsoftware.com/articles/customerservice.html

saurik• 14 years ago

A subtle and yet key thing from this article: the guy delegated writing the answer into the manual; irritatingly, I know that that is a step I would have missed (leaving me now in charge of formatting a manual).

mixmax2• 14 years ago

This is excellent advice, so often you see great capable people buckling from stress and worse because they don't know how to delegate.

The way I prefer to do it is to give everyone a piece of the project that they own. I don't want to know how or when they do their part, I just want to know that it gets done, works and that it plays well with what other people on the project are doing.

Recently I was in charge of a live webcast from a rocket launch in the middle of the Baltic Sea. A hard problem for several reasons. It involved high-speed Wi-fi over a 40 kilometer distance by having a parabolic antenna on land that tracks its counterpart at sea; using software written in C to control a videomixer in the middle of the ocean from the Internet, getting the right camera angles, mounting cameras, etc.; setting up a live studio on land where technicians could control videofeeds and move the cameras at sea, webcasting to thousands of users, making sure there was a competent speaker, creating filler videos, getting the logistics about everything right and much more. Also, since this is an opensource project there was no money, and I had to find the crew myself.

It isn't really that hard, if only you accept a few things.

1) You're not the smartest guy. There's someone smarter than you that can do whatever part of the project you have trouble with.

2) Let people take ownership of a part of their project and don't tell them what to do. Tell them what the goal is and let them do it however they want.

2) When they do awesome stuff make sure you tell them. People are capable of much more than they think it only they're motivated to so so.

3) Make sure it's fun.

4) Your job as a project manager is to make sure that the awesome stuff people do plays well with the awesome stuff other people do. You're in charge of the interfaces between people.

5) Your job as a project manager is to make sure people can do their job well. That means moving obstacles in the form of meetings, budgets, politics, etc.

5) Don't take credit for what you didn't do.

DanielRibeiro• 14 years ago

Related, and very good, post from swombat's:

Making all the decisions yourself[1]

[1] http://swombat.com/2011/7/13/taylor-drucker

dhimes• 14 years ago

number 2 and number 2 are golden.

(yes I mean this to be funny, but it's also true. Especially the first #2.)

mixmax2• 14 years ago

ah sorry about that, and thanks for taking it in good stride :-)

wpietri3• 14 years ago

Fantastic list. The only thing I'd add to this is: rehearse, rehearse, rehearse.

I've worked on a couple of projects that had all of that, but didn't come together at the end. People did what they thought was right, but until we tried putting it all together we didn't see the gaps. And then we had no time to recover.

Without rehearsals (or alpha pushes or dry runs or whatever else forces iteration) it's the job of the guy on top to figure out everything that might go wrong and then bug people about it. But if you try it all together and something doesn't work, everybody sees the problem and jumps on fixing it.

I learned this from watching a theater director friend put together a play. Day 1, she got everybody on stage, had them open their scripts to the first page, and they started reading it through. When they got to the end, they went to the beginning and started over. They gradually added motion and props and inflections and pauses and scenery and music, tweaking and tweaking. Opening night was just version 71, and it got rave reviews.

patrickg• 14 years ago

More comments from one year ago: http://news.ycombinator.com/item?id=2132591

pestaa• 14 years ago

If you read Dune from Frank Herbert, you might recall Paul observing his father's soldiers doing their jobs in silence due to Leto (the father) giving little to no orders to them.

"If you command something once, you'll have to command it again all the time." (Paraphrased as I didn't read the English version.)

Apparently, Derek "uncommanded his soldiers."

casca• 14 years ago

There is a fine balance to be achieved here. If you've read more of Derek's (excellent) posts, you'll know that his complete hands-off style led to the company almost collapsing. Delegating like this is a great step, but a leader's responsibility is to lead, not hide away.

j458• 14 years ago

Management by abdication is one thing, but being able to drive the direction of the company is a key differentiator.

There is not much out there that is truly passive income. Reasonably passive income? Much more realistic.

j_baker• 14 years ago

If you've read more of Derek's (excellent) posts, you'll know that his complete hands-off style led to the company almost collapsing.

I would like to see these posts. Could you link them?

rahoulb2• 14 years ago

http://sivers.org/trust-but-verify

In his book there's also a story about how, when asked which profit share scheme the company should use, he said "you decide" - 6 months later his accountant rang and said all the profits were being shared amongst the employees - so scrapped the scheme and never spoke to them again. I can't find the post on his site though.

lachlanj• 14 years ago

Thanks for reminding me to step back and look at my business (and read the e-myth again). Read the e-myth many years ago but it's time for another read

chmars• 14 years ago

Delegation is important but you need the financial capacity to afford it. As a consequence, outsourcing some tasks such as accounting is usually more feasible at the beginning since hiring comes with its own many costs and risks – especially in countries with a more restrictive labor law than in the US.

larrys3• 14 years ago

"The next day, as soon as I walked in the door, someone asked, “Derek, someone whose CDs"

To me interruptions are the thing I hate the most. What has worked for me in the past is to insist (despite "open door philosophy") that all questions are queued and asked at a single time, as practical. Sure the person asking wants immediate relief, but there is no reason you need to answer questions according to their schedule, unless it is urgent, if they can be combined with other questions they (or others) have.

That's actually one of the benefits of email vs. a telephone call. You can handle it w/o getting interrupted or knocked out of a zone.

adrianhoward2• 14 years ago

I've done that to... but you do need to be careful that you're optimising the right thing.

I hate being interrupted - but being interrupted often is often a sign that I'm being the bottleneck in one or more processes. If I force people to queue questions into a single time/place I can end up blocking a whole bunch of peoples work. I might be better off - but the system as a whole slows down... and "urgent" can be a hard thing for people to figure out.

Like the article - I find using interruptions as a sign that there's a process problem that needs fixing to be a excellent strategy.

wpietri3• 14 years ago

I hate interruptions as well, but if you're going to be a manager, I think you have to learn to live with them.

Managers exist to support the managed. Front-line employees are the ones doing the actual work, and I think the actual work should always have the highest priority.

As Derek demonstrates, the way to reduce interruptive employee questions isn't to hide them by driving people away. (If you do that, people will just make shit up or dither, and both are terrible habits.) It's to keep improving things until they don't need to ask.

j458• 14 years ago

My experiences:

Learn why: Figure out why you do things the way you do. Write it down, make screen casts, whatever.

Teach why: The how can always be evolving and updated. Store it in a wiki. Google docs aren't searchable.

Don't prematurely automate: Be sure to systemize your business before automating it. If you automate a process that isn't reasonably mature manually, you will have lots of pains.

adrianhoward2• 14 years ago

The step before this one also seems to be hard for many small organisations that I've worked with. Before you can delegate - you have to have somebody to delegate to.

I've lost count of the number of folk who slog themselves to the bone long after the time when it would have been sensible to grow the company with a few extra people. For some people having other people in the company, let alone actually letting them make decisions, seems to be a chasm they find it hard to cross.

petercooper• 14 years ago

This remains still great stuff, but it leaps from the "doing everything yourself" dilemma straight to handling several employees asking you questions, skipping the "first employee" problem. The gap between those two situations remains vast and more reading on going from being time stressed and doing everything to having that first employee would be awesome.

Delegate or die: the self-employed trap

Related Stories