The day-to-day work of a software engineer generally involves quite a narrow field of focus. Beyond the next two iterations of development, those involved in designing or writing code have a glaring blind spot. This is not a bad thing – the purpose of management is to allow their staff to focus on the tasks which they are most productive at, while ensuring the cogs keep turning in the other “invisible” areas of the business. To generalise even further, this is usually a mutually amicable position when done correctly; Coders want someone who keeps the coffee stocked and the internet connected, Managers want productive work units expelling product as fast as the conveyor belts can carry it. (This is, of course, in the ideal world where politics, ego, and incompetence have been banned.)

Eventually, the ambitious engineer listens to the confident homunculous whispering words of encouragement in their inner ear, reaches satori, and hands in their resignation to pursue their own venture. This is the point at which many Engineers encounter difficulty. The stereotypical Engineer has a strong logical mind and great problem solving skills, but lacks the very different set of abilities required for managing a business. How do you move past these issues in order to grow this business from a one-person shop into a license to print greenbacks?

“The E-myth revisited” by Michael E. Gerber is not a book designed specificially for Software Engineers, but is generic enough that it can apply. While I have certain reservations about whether some of the principles which the author defines as preferred practice can apply to the software industry, the majority of information presented is both applicable and useful. Content aside, the book is presented in terms of a Socratic Dialogue with a young lady who is running a pie shop. While useful for expanding upon subtopics, this style gets dull quite quickly – a pointlessly emotional narrative storyline is very tiring if you’re trying to skim back through the book to summarise it.

My one-word summary of Gerber’s advice is “vision”; In order to build a behemoth company to crush the competition you need to visualise how such a company will behave, and model your current behaviour around the vision. Gerber tackles this from seven key steps:

• Primary Aim – When you have nurtured your monster company, what does it do all day? This future primary aim shapes how you initially position yourself, and allows you to place benchmarks for future progress. To be as succinct as possible, he recommends a one-word aim. (The cloying example from the book’s narrative was “caring”).
• Strategic Objective – Describe in detail the envisioned company’s revenue, staff size, suppliers, outgoings etc. Doing this allows you to picture a yearly growth.
• Organizational Strategy – This step involves creating an organizational chart for your company as it will look several years from now, creating an operations manual for each role in the organization.
• Management Strategy – This step pre-empts the growth of the company by setting out what the staff and service of your company will provide, ensuring that each staff member is fully aware of what is required for their role, and what is unacceptable.
• People Stragegy – Each person in the company should be aware of the underlying motivation for their role, and how it affects the company as a whole. Gerber describes this in terms of a process (“game”) which the staff will undertake which has associated penalties and rewards.
• Marketing Strategy – This involves the acceptance that customers make quite irrational decisions, and that the informed business owner should use demographics and psychographics to sway prospective clients.
• Systems Strategy – Systems the company uses are subdivided into passive and active systems. An example of a passive system might be a neat reception area which influences the client’s opinion favourably. Active systems involve the actual business processes and information systems that create value for the company.

My main point of dischord with Gerber’s approach has more to do with what he describes as the pinnacle of business; the ability to franchise your operation into a turn-key for others to operate. While this obviously has merit for a pie-shop owner, the applications to software engineering are not so apparent. I’m willing to conceed that the obvious connotations to McDonalds, Walmart, and Starbucks have probably influenced my judgement in this regard, but hopefully I have presented a balanced view of the authors intent.