Delegate or die: the self-employed trap
sivers.org
sivers.org
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.
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.
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.
A markdown based wiki would be a decent start, but I still overall feel like this is an unsolved problem.
Perhaps a wiki that allows pulling in "snippets" from linked pages could help.
As a programmer, wiki syntax seemed pretty obvious to me. But it was a block for some of the non-coders.
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 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
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.
Making all the decisions yourself[1]
(yes I mean this to be funny, but it's also true. Especially the first #2.)
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.
There is not much out there that is truly passive income. Reasonably passive income? Much more realistic.
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.
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 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."
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.
"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.
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.
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.)
[free] http://ruby.bastardsbook.com/toc/ [free] http://ruby.learncodethehardway.org/ [free] http://mislav.uniqpath.com/poignant-guide/book/
[$$$] The Well-Grounded Rubyist
Rails:
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.
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.
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.
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.
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 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.
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.
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.
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.