The E-Myth Applied to Software Startups

In his book "The E-Myth", Michael Gerber asks why most small business don't work, and what to do about it. His main point is that people who go into business on their own tend to do so in order that they won't be working for someone else. Moreover, they tend to be the "worker" or "technician" type (not the manager, or strategist), who is good at creating the widgets/loaves of bread/furniture/other product. So they open a widget workshop/bakery/carpenter's workshop/other place as a one person venture.

So far so good. The new business probably works well, because the owner has enthusiasm and is skilled in what they do. However, the owner spends all of their waking hours attending to the work of producing the product. Gerber gives the example of a pie shop, where pies are baked early in the morning, sold throughout the day, and cleaning is done in the evening, all by the owner. The owner probably neglects areas of the business they don't know much about, such as book keeping. Neither do they get any time off. Crucially, they don't sit down and think where the business is heading (strategy).

Gerber argues that most of these people need to let their inner entrepreneur blossom. They need to own the business, rather than the technical work that goes into product manufacture. They do this by having a vision of the future of the company, and shaping the company to it, rather than shaping the future by what routine dictates. As they grow the company, they need to impart this vision to their new employees, and begin to make that vision a reality by taking on more of a managerial, and less of a technical, role. Part of this, Gerber, argues, involves documenting all the processes (e.g., how to make pies) that go on in the business, in order that the owner no longer has to check up on every step of production done by his/her employees. The result is a business that is easy to franchise.

Whilst this all makes sense for a business that produces something tangible, how can we apply it to software startups? Whilst not having a huge experience in this area, I thought I'd have a go at answering this question.

Firstly here are some of the differences I can see between the two situations:

• The capital cost of writing software is relatively small, unlike the initial investment required to rent a retail unit for a shop, or build a factory. This means that non-software businesses have to go and find funding, which normally means other people will take a look at their business plan before the business is set up. If you're spending life savings then it's different, but if you're writing software you're doing that too (just to keep food on the table)
• One doesn't tend to want to franchise software production. Outsource, possibly, and certainly bring new developers onboard. But the procedures that the startup uses won't be set in stone by the owner: they'll change as the company grows. What revision control system you use, or bug tracking software, or code format only needs to be specified at a later stage than what recipe is used for pies in a bakery.
• The cost of modifying software is very small. The cost of changing every widget that you have in stock because there's a flaw in it is at least linear in the number of widgets, so you'd better get it right first time. With software you can "plan to throw one away" (Fred Brooks; see my post The Mythical Man Month: Still Applicable Today).
• If a software product is intended for mass market, it's likely that its users will not understand how it works, and can't easily reverse engineer it to find out how. This is very different from most tangible products: most people understand vaguely how a pie is made, or have a mental model of how a car accelerates from standstill.
  

(I'm sure there are more: comment and let me know!)

I do think that technical people are as susceptible as any others when it comes to "working in their business rather than on it" (Gerber). But what exacerbates the issue is that software startups don't need initial cash, and hence owners aren't obliged to have anyone looking over their shoulders! Add to that the ease of (radically) changing their product, and suddenly the software startup is one where it's far more acceptable to have no real vision or idea of what you're doing. It's therefore very easy to waste time and then fold.

Software engineers are highly technical. In my experience, many dislike having to explain to a customer how a product works, and would hate to provide a dreaded technical support helpline. Instead, they argue that software can be made good enough that no support is needed, or those that do need support are evidently so lacking in intelligence that they don't deserve it. Yet this is crucial to getting the product sold to a mass market! Customer service is perhaps most needed in this business, and yet the software engineering stereotype is the worst-placed to provide it!

Linked to the previous point is the observation that performing market research is difficult. For a pie shop it's pretty easy: "Do you like apple pie, or would you prefer blackberry?" Software isn't as easily understood by the man on the street: "Would you like to buy my new super-fast sorting algorithm?" doesn't mean much. It requires the software engineer to divorce themselves from the beauty of the technology, and concentrate on its use by potential customers.

Another interesting issue with the low cost of modifying software is the speed at which new technologies (languages, tools, plug-in modules) become available. Unless a lone entrepreneur has a strong vision and will, it is very easy to frequently change to the newest technology, in the belief that this will create a better product. Of course, sometimes it does. But change has a time cost, which is much harder to quantify than the capital cost of buying a new piece of hardware, say.

Finally, as noted above, documentation of processes is far less important (in my opinion) for a software startup than for widget production. Gerber argues that documentation means practically anyone can read the "manual" and then achieve good results. I would argue that software is different in that it requires excellent people, as code quality can only be influenced by procedures to a small extent. In addition to good software engineers, there is a real need for one person with an overall view of what the aim and uses of the product are: they can then ensure that all the developers work in concert towards the vision of the company.