
Delegate or die: the self-employed trap - DanielRibeiro
http://www.sivers.org/delegate/
======
patio11
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
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.

~~~
philwelch
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.

~~~
j45
Any document is only as good as it is maintained. A wiki has to be searchable,
editable for the most basic of user as well that would be modifying it.

~~~
city41
I agree, and so it always puzzles me why wikis are so hard to maintain. We use
Google Sites at my job, and I've never found them particularly fluid,
intuitive or efficient.

A markdown based wiki would be a decent start, but I still overall feel like
this is an unsolved problem.

~~~
vidarh
I think a lot of the problem is whenever you don't easily "see" all the
information. In a document you can scan it beginning to end, and get an idea
of what needs work. In a wiki you need to click through to other pages to see
whether subsidiary pages need work.

Perhaps a wiki that allows pulling in "snippets" from linked pages could help.

~~~
simonbrown
MediaWiki has a templates feature.

<https://www.mediawiki.org/wiki/Templates>

------
mixmax
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.

~~~
dhimes
number 2 and number 2 are golden.

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

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

~~~
alexqgb
FWIW, the fives are equally sound as well.

------
casca
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.

~~~
j_baker
_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?

~~~
rahoulb
<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.

~~~
lusr
Interesting. While I really enjoyed the post, something that stuck out for me
was: what if they don't apply your philosophy as you expect? Isn't this how
great companies fall down, when the founder's philosophy is lost and replaced
by internal politics? Some how you should be able to review the decisions
being made without having to waste even more time doing the review.

~~~
rahoulb
I think there's a fundamental difference between being a "manager" and being a
"doer".

If you're a "doer" (for example, a developer) your to-do list for today is
likely to have three or four items on it - each a couple of hours in length -
and context switches (interruptions, changing task) are _expensive_ (half an
hour or so).

If you're a manager, your to-do list is actually about a hundred items long -
but each item only takes a few minutes to complete (also meaning that it's
probably not written down and it's hard to enumerate what you actually did
today). And most importantly - context switches are cheap.

So reviewing someone else's work is actually only a ten minute job (it doesn't
need to be detailed - just check to see if it fits with your philosophy).

But for a developer that's ten minutes plus an hour of context switching -
making it very expensive.

For a manager that's ten minutes, plus a minute of context switching - making
it cheap.

------
pestaa
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."

------
saurik
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).

------
adrianhoward
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.

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

~~~
maayank
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.

~~~
davidw
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.

~~~
accountoftheday
were the affiliate tags really necessary?

~~~
davidw
Something I wrote about those a few days ago:

<http://news.ycombinator.com/item?id=4360330>

I took the time to recommend some books that were very specific to the thread
at hand, that I had taken the time to read and evaluate. Getting a few extra
dollars to buy more books with, that costs those clicking nothing, seems like
a mutually beneficial transaction in that it makes me more likely to read some
interesting books I can recommend in the future.

So: yes, they were. If you don't like them, don't click on them. If you think
my account is a spam account, created for the purpose of spamming HN with
affiliate links, feel free to report it to Paul Graham.

~~~
larrys
I don't have a problem at all that you put in the affiliate link and didn't
even notice it.

Otoh I think the disclaimer that you made above is good and informs people of
why you did what you did so it might be an idea to include it. If the parent
thought that, I'm sure others did as well. (Of course this might encourage
others to do the same who don't put the same effort in that you did to read
and evaluate.)

This is somewhat similar to when someone at a store makes a suggestion and
adds "I'm not on commission". Here you are saying "I am on commission but I
use this product and can vouch for it". Nothing wrong with that.

(I'd like a suggestion on a learning rails book by the way.)

~~~
sebg
Ruby:

[free] <http://ruby.bastardsbook.com/toc/> [free]
<http://ruby.learncodethehardway.org/> [free]
<http://mislav.uniqpath.com/poignant-guide/book/>

[$$$] The Well-Grounded Rubyist

Rails:

[free] <http://ruby.railstutorial.org/>

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

------
larrys
"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.

~~~
wpietri
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.

------
j45
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.

------
petercooper
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.

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

~~~
heretohelp
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
Agreed. Actually there is a Sivers book, it's called "Anything you want"

------
chmars
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.

------
lachlanj
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

