Fog Creek Software
Discussion Board




Striking Out On Your Own

So I read "Growing Your Own Business" by Paul Hawken in Joel's Striking Out On Your Own section of book reviews (http://www.joelonsoftware.com/navLinks/fog0000000262.html). Great book. I really found this one useful even though it is a little small.

But now I am thirsty for more. Could anyone recommend more books simliar to this one? They don't have to necessarily relate to the software industry, any field is fine, but growing a small business and the related tasks are what I am interested in. I am growing a small business with a partner and although it is daunting at times, knowing that others have done so successfully and are willing to share their experiences helps tremendously.

Synonymous Mallard
Thursday, April 24, 2003

I've been reading a lot on this and my favorite one so far has been:

The E-Myth Revisited: Why Most Small Businesses Don't Work and What to Do About It

by Michael E. Gerber

Daniel Shchyokin
Thursday, April 24, 2003

p.s. E stands for entrepeneur (this book was first published before e-mail or e anything became popular)

Daniel Shchyokin
Thursday, April 24, 2003

I second the E-Myth. It's an excellent book.

Tim Sullivan
Thursday, April 24, 2003

Most definately read E-myth.
You can apply the ideas to many different aspects of life.
One of my favorite books.

moses whitecotton
Thursday, April 24, 2003

Another good one is:
How to Master the Art of Selling
by Tom Hopkins

Daniel Shchyokin
Thursday, April 24, 2003

Call me cynical but "The E-Myth" gives me a pain in the ass.  Every time I've read "The E-Myth" I've developed a new inadequacy complex.

Gerber advises to "work on your business", not "in" your business. To understand what your customers want, which is usually a certain experience or intrinsic benefit, which is generally not exactly that which the owner/operator envisions their business to "be". He wants us to develop 'operations manuals' of our business and to seek to package our business as a series of activities that can be taught to "anyone".

All well and good for any food service and for most "non intellectual product" companies.  However, I do not see *any* application of Gerber's principles in SW dev or consulting, nor in a company that uses professionals to delivery a product or service. Or, maybe, I'm just too short sighted to see the innate elegance that permits this to occur.

In software development, the companies that implement a "franchise model" of interchangable bodies and "process" are in one of two camps: temp firms, and large money grubbing semi dishonest consultancies. The scum of the earth recruiting agencies treat degreed professionals like us like cattle.  Their "process" is devoted to HR and hardnosed negotiation practices, and not in any event whatsoever to providing service for value beyond delivering billed hours. As far as the consulting firms, they seek to make their Fortune 500 clients as dependent on them as a crackhead is on his next fix. That's *their* process.

In any other venue, most software developers must be hand picked from a limited pool, and the employer *has* to deal with the fact that the company can't treat a professional employee like a burger flipper. Also, in companies that create sophisticated I.P., the owners may not even *know* their own business beyond an overview level. And most owners of tech companies would run the company straight into the ground if they tried to analyze their business's activities and implement a "franchise operations manual" model. They are much better off essentially letting their employees be irreplaceable and firewalling off the activity of tech work as an indivisible "atom".

I could go on at great length. But for now, what I despise is the notion that the E-Myth is applicable for any form of business. It's NOT, particularly when it's professional services and the client won't accept anyone in my place except me. 

I'm resigned to treating my worklife as a chain of hand picked singularities. At least until I build my first resale product.

Bored Bystander
Thursday, April 24, 2003

More on this later but Gerber does not suggest hiring "burger flippers" he suggests hiring emploees with the lowest possible skill level to do the job at hand, and he doesn't suggest treating workers like cattle, he suggests that there be a system  for handling workers.

Examples of sick SW business practices that would benefit from managers reading e-myth

- Requiring  a PHD from MIT and 56 years of experience in linux kernel development for a position to write Access Reports (lowest possible skill level)


- Having an unwritten rule that leaving before the VP or Taking a vacation  WILL result in getting you fired.

Also, I've seen some of the operations manuals at "e-myth" style companies, I am currently reading one from Farmers Insurance. They are meant to be starting points, i.e. the Farmers manual does not teach you how to sell, it gives a frame-work from which to start (so you don't make a total ass of yourself) and from which you can improve and fill in the details.

Daniel Shchyokin
Thursday, April 24, 2003

Also, consider this that developers are not the only people you will be managing in a software company there will be sales, marketing, receptionists, janitors etc ...

Daniel Shchyokin
Thursday, April 24, 2003

Daniel, true observations in themselves.

But in a software company, my rhetorical question is still - how does one develop an operations manual and comprehensive procedures that cover the value-added work done by the company? Or in any brainwork type operation. I'm not saying that no "professional" will submit to any process, I'm just pointing out that brainwork jobs require that the person come in the door knowing how to do the job from his/her head already. The least common denominator in this role is basically a rocket scientist. So I'm saying that E-myth is pretty much useless in this context. But I am open to arguments how it could be employed.

This issue "pees me off" because it points to the lack of scalability of our occupation. All our business can ever be, unless we develop a killer product we release to the world, is our own labor.  It's not that we're stupidly flailing like Mr. Magoo, not seeing the forest of process for the trees of individual modules needing written (or whatever.) It's just that commoditizing technical work is more a mass financial operation relying on the odds of the marketplace, than it is a process of training anyone from scratch. The scalability happens when you have buckets of "commodity " programmers and you're accepting $300K and up payment checks.  The scalability at the level of 1 to 30 person teams simply does not exist.

And I have seen *several* would be "software tycoons" with visions of grandeur, thinking that they had the special sauce and personal magic, trying to hire roomfuls of code monkeys, "train them" trivially, and pocket 90+% of the billings. Crashing and burning right about at their second employee.

And documenting "process" for a custodian or a secretary in a SW company is next to irrelevant. It's truly unimportant because service roles like these have next to nothing to do with delivering the product or service.

Bored Bystander
Thursday, April 24, 2003

Wait. Actually, it just occurs to me how the E-myth DOES apply to SW dev in one sense.

The E-Myth philosophy simply can't "wrap" our work in a simplified operations manual.  Therefore, any sw dev company wanting to become a mass "franchise" operation *must* demote the importance of the technical work itself to a very low level that does not impact the company at all day to day.

Then, the business of the company becomes not software development, but delivering on the "promises" implied by the software or whatever else is being developed. That means that you acquire software assets as cheaply as possible, free is possible, otherwise outsourced for squat. Such a company is no place for one of us Joel types because it is basically a place that doesn't want, need or allow for the vagaries of smart people creating when they feel like it.

And you become essentially a marketing, PR and distribution company with perhaps an outreach for custom installations and per client "consulting" (non coding), through an operations manual of course.

Stage 1 ... collect software. Stage 2. ..... ..... Stage 3 - profits!

Maybe South Park should do a take off on the underpant gnomes reading "The E-Myth Revisited." ;-)

Bored Bystander
Thursday, April 24, 2003

Thank you for the replies, I actually picked up The E-myth and skimmed over it the last time I was in the book store and decided against it and instead picked up "Hemingway on Fishing" ;-) But now I have to go back and pick it up just to see for myself if there is any worth to it. I might find a good gem or two. Thanks for the other recommendation also.

Synonymous Mallard
Friday, April 25, 2003

Bored Bystander said, "All our business can ever be, unless we develop a killer product we release to the world, is our own labor. "

That's equally true of lawyers, accountants, and numerous other professionals.  Yet they have businesses that are owned by partners but where non-owners (associates) provide their own labor at a base wage or salary determined by the partners. 

The partners are not selling only their own labor; they're also selling the labor of the associates the employ, and making a profit off it.

I know there is at least some small percentage of software development houses who work in a similar way.  And the most successful one I know does have a lot of operational documentation.

So I'm thinking there may be something to what Gerber says, at least if you want to make sure that your business doesn't take over your life and run you into the ground.  There has to be something to help run your business other than just yourself.  Documentation of your "system" sounds like a good way to get that.

Herbert Sitz
Friday, April 25, 2003

Basically, the E-myth explains why "crappy" companies make lots of money, and why us quality-focused types often don't.

Haven't you ever wondered how it is that all these incompetent idiots and exploitative fools don't go out of business?  It's because what they're doing is actually profitable, most of the time.

Quality in significant excess of the customer's requirements is wasted money, because quality the customer cannot perceive will not be paid for.

Beyond a certain level of quality, only a specialist in the art (the "technician", as the E-myth calls us) can distinguish the degree of quality present.  Therefore, anything of greater quality than that, is wasted on the customer who is not a specialist in the art.  (And if they are so skilled as to discern the quality, they will be unwilling to pay because they could "do it themselves"!)

This is the true lesson of the E-myth.  It is real, but an unpleasant reality for those of us who have devoted our lives to the advancement of our arts.  Learn it and weep, ye who would profit from your skill.

You can make a living by quality work, you can be "self employed" and do quality work.  But a truly profitable business *must* make quality *secondary* to the goal of profit.  Read between Joel's lines, and you'll see that he is always saying this.

Phillip J. Eby
Friday, April 25, 2003

I would say that that is true, but quality is in the eye of the beholder, don't forget that for a lot of companies the customer is another company and "Joe Average", and so yes Gerber does imply that quality should be to the minimal level acceptable to the customer, but you can look at it in reverse where you figure out what level you can deliver at and still make a profit and still make money and then find customers that are at that level, Not everyone WILL eat at mcdonalds.

In sw development you may not be developing for desktop users, you may be developing for other companies, or professional stock traders, or NASA. For all of these you should hire workers with a minimum of skill for the job, but that minimum is a variable depending on your customer, again do you need Access Reports or Embedded Systems?

In manufacturing you have Beamers and Fords, maybe BMW workers get more training than Fords assembly line workers, but none of them are master mechanics, in fact if we had that elitist attitude, the only cars in the world would be Rolls Royces and not everyone could afford those!

Daniel Shchyokin
Friday, April 25, 2003

But you could also look to the industry as proof that low quality might be acceptable now but hurts long term performance of a software company. If a customer was not satisfied with your last effort then what will make he/she return for your next product?

Of course you have to weigh your costs related to quality assurance against the bottom line, but that doesn't mean a total lack of quality is acceptable because it leads to higher profit margins for this particular period. A company's reputation is very significant in this industry and one must put forth their best effort to assure quality in their products. Because not only can a defective product lead to an unhappy customers but also to legal liabilities and expensive court cases.

Synonymous Mallard
Monday, April 28, 2003

I think this is a good discussion to have.

It is important to distinguish between the goals of software developers as craftsmen - and of the businesses they operate within.

I'm a software engineer - software developer - programmer - have been writing software for 20 years.  I get great enjoyment from writing good code (when I have the opportunity).

So - I want to write the code my way - using my way of doing it.  My goal is to write great code.

The business has a different goal.  It wants to deliver consistent results to the customer - so it can retain that customer and get a consistent return on it's cost (me writing code, etc).

The main E-Myth idea (to me) is that a business can be successful by developing systems in which workers can be productive.  The systems developed by the business actually support the worker in delivering consistent value to the customer.

The challenge is for the leadership of the business to focus on building the business structure to do this - instead of focusing on doing the technical work of the company.

Such systems in use and discussion in software development today are RUP, Agile Development, XP, SCRUM, etc.  These are systems to support achieving consistent results across a group of average developers.

Because the system works well - workers feel supported and free to do work - managers are responsible for making sure the system delivers - and owners are responsible for making sure what the system delivers is what customer want.

The crowning key is innovation and improvement.  And everyone should participate in these two processes.

All this being said - honestly, Moore's (mine) Law says that "Reality is Messy".  People are not perfect.  So - there will be good times and bad as the people in the business work toward the goal of creating the ideal E-Myth style environment.  This will never happen of course, but as long as the company is really doing its best to get there, and the people inside the business believe that - I can't imagine that it wouldn't be a good place to be.

As a developer, it is easy to put down business systems/processes - and many of them do suck.  But we can never forget that it is the business structures that fund our efforts as developers.  And through the business structure, our work finds places to be effective and have an impact on other people.

In E-Myth-eese, Technicians are focused on doing the work of the company - not working on the company.  If the leader of the company is being a Technician, then the company is not being built - and this is as bad as throwing a bunch of developers at a problem with no lead - or design.

It's time that developers - and all technicians - develop an understanding of real world business systems and how they work - so to better support them - better build IT systems to grow them - and better pick them to participate in.

Jim Moore
Tuesday, February 03, 2004

*  Recent Topics

*  Fog Creek Home