The abilities of a technician can be very valuable to a business, but especially as it begins to scale the owner/operator(s) need to adopt different mindsets in order to succeed. In short, if you don't like the idea of spending most of your time on business or marketing stuff, you should find someone who can handle those, or perhaps be a solo consultant/contractor. (I think this is a large part of why YC encourages cofounders so much.)
Exceptions certainly exist--there was a time when tech was a magical world and you could do magic things just by being an expert engineer--but increasingly I feel they are getting rarer.
That's fine if someone wants to start some kind of tech consulting business; but that's not the kind of business that I see promoted on Hacker News.
The "The E-Myth Revisited" describes how to plan a business where labor is low-cost and unskilled. With software, (and hardware, to a degree,) when you write a program, the program is done. Most of your labor goes into R&D that is not repeatable according to what "The E-Myth Revisited" advocates.
At least with hardware, the low-cost unskilled labor can go into manufacturing, but that is now mostly outsourced.
At most, "The E-Myth Revisited" can be applied to the sales and support part of running a tech business, which is what Oracle does very well.
Not by a long shot! The vast majority of the lifetime cost of software is in the maintenance (daily operations, upgrades, new features, bug fixes, integrations, rewrites, etc).
This is pretty much how you'd build out an engineering team of 50 or 500 people, too.
And within any kind of org - sales, engineering, support, whatever - eventually you're going to get large enough that you can be more efficient by sequestering simple work into simpler roles, which gets done by cheaper, junior people.
All 100% applicable to the audience here which is filled with people who are trying to found and grow companies.
Your comment implied that perhaps you think sales and support are low-skill roles, which makes me wonder if you have any experience working in those areas or managing people which perform those functions? I can assure you they take a very high level of a different kind of skill, and you would grow those teams more or less in the same way you grow an engineering team: starting with yourself, defining specific functions and duties, sequestering simpler work into lower skill roles for efficiency, and hiring people to fill those roles one by one. Exactly like Gerber describes.
save time and read an online summary of the book to cover the ideas quickly.
The engineers half-serious mock me for continually talking about money, billing, etc. But they do know that's how their salaries get paid.
There aren't many challenges we're the first to face in the history of the world, or the first to ever think about.
A lot of wasted time can can be saved from accessing the experience of others, and learning what to extract for your own journey.