Hacker News new | comments | ask | show | jobs | submit login
Delegate or die: the self-employed trap (sivers.org)
262 points by DanielRibeiro on Aug 18, 2012 | hide | past | web | favorite | 61 comments

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.

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.

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.

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.

...and there must be at least someone, somewhere in your workforce under the impression that maintaining a wiki is somehow either the most productive or the most entertaining use of their time and effort at a given moment. That's the hard part.

Totally. A company that doesn't want to pay attention to why they do things a certain way, and keep evolving it, doesn't care to grow, or stay in business.

Too often, excuses from a site like http://www.yourlogicalfallacyis.com sums up why an organization doesn't maintain enough documentation of their business and the knowledge contained with it, and it's free to just walk out the door.

Now that's a little harsh. The fact is, every company where I've seen the internal wiki go stale is also a company that is otherwise incredibly successful. Though important processes were also documented by some additional formal process, and the wiki was a lower-priority thing anyway. Or at least, important wiki pages seemed to be better maintained.

Didn't mean to be.

I've observed with clients while systemizing their businesses: In the long run in those who don't keep it a priority to document, improve and transfer their knowledge capital regularly, peak out, stall and fade.

By failing to bake into the bread of their culture that understanding and sharing the why to do things a certain way.. maintaining their competitive advantage, they inevitably are exposed to becoming less effective, productive, efficient, ultimately welcoming a culture of accepting less and less.

It's also probably worth noting that I'm not talking about creating a mistake manual, but rather a why manual that helps teach the mindset that creates the types of mindset required to make decisions to grow the business

Businesses that become institutions do so with cultivating a a 50 to 100 year mindset, but few have a 10 year mindset to take what we do today and make sure it's happening while we find the next way to grow.

I don't think we disagree. Maybe you work with smaller and younger businesses than I've been employed in, because in my experience there's always SOME means of formal documentation, with the wiki as an optional layer on top of that. Or else, a really uneven wiki with some well maintained pages (generally the ones you actually need more often) and some stale data.

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.

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.

MediaWiki has a templates feature.


I find a wiki that is less markdown based, but more ms word like seems to do well. Fogbugz is one example. You give up some and get some other stuff that just makes it a functional linker of docs

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.

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.

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.

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

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

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.

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.

number 2 and number 2 are golden.

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

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

FWIW, the fives are equally sound as well.

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

Making all the decisions yourself[1]

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

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.

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.

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?


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.

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.

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.

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

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

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.

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

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.

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.

Two ideas struck me from the book.

First, thinking like a technician is different from thinking like a manager is different from thinking like a business owner. You may have technical expertise, but that doesn't in and of itself teach you how to manage a business or how to build a business. Sometimes you have to switch hats. You'll almost certainly have to learn the difference between performing a skill, managing people, and building a business.

Second, building a sustainable business requires you to create good processes which allow you to get good results from average workers. Gerber calls this the franchise model. Even if you don't want to build a franchise, he argues that the technique works--this means getting knowledge out of the head of the one or two fantastic employees you have (the ones on whom the business relies) into documentation.

I ought to write up longer thoughts on the book. I found it frustrating to read but valuable nonetheless.

Thanks for sharing your thoughts. The second idea struck a cord because this is essentially the basis for knowledge management, which I've been studying lately and find incredible useful as a source of inspiration on how to run a business.

I read "The E-Myth" years ago. I hate business books, but loved that one. It was not because of the writing; it could well be the worst-written book I have ever bought. But the guy clearly had a ton of practical experience, and his view of business really helped me think about entrepreneurship as an activity, not a theory.

It is one of the few books I wished I had 10 years ago and would have saved me aggravation.

Other books might teach it too, but how simply he explained the battle inside each entrepreneur between 3 opposing personalities (Technician, Manager, and Entrepreneur) is really eye opening, especially once you've been on the path for a bit.

One of the major takeaway from E-Myth is that i learnt the importance of business automation, e.g. creating organization charts, business operations manuals, financial reports, business metrics, etc.

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.

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:


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:


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

were the affiliate tags really necessary?

Something I wrote about those a few days ago:


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.

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

The free Rails Guide is pretty good, actually! You could also get the Rails book with Sam Ruby as an author, but I'm less enthusiastic about it these days, mostly due to the fact that Rails has grown so much, so it covers a smaller set of the system, less comprehensively than it used to.

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.

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

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

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.

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.

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.

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.

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

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.

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

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

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.

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

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact