Michael Gerber's "The E-Myth Revisited" has been around since 1986, but its core insight remains painfully relevant—especially in tech. The "E-Myth" (Entrepreneurial Myth) is the mistaken belief that being good at the technical work of a business means you'll be good at running a business that does that work. Being an excellent baker doesn't make you good at running a bakery. Being an excellent engineer doesn't make you good at running a software company.
I've watched this play out repeatedly—including in my own journey. The very skills that make someone an exceptional engineer can actively work against them as a founder. Understanding why requires unpacking what Gerber identified decades ago: the three personalities that exist within every business owner.
The Technician, The Manager, and The Entrepreneur
Gerber argues that every business owner contains three personalities in constant tension:
The Technician is the doer. They love the work itself—writing code, solving technical problems, building things. They live in the present, focused on getting today's work done. Left to their own devices, technicians would work on interesting problems forever.
The Manager is the pragmatist. They crave order, systems, and predictability. They think about processes, schedules, and organization. Managers live in the past—they want to preserve what works and create repeatable systems.
The Entrepreneur is the visionary. They see opportunities, imagine futures, and live for building something bigger than any individual task. Entrepreneurs live in the future, constantly asking "what if?" and "why not?"
In Gerber's framing, most small business owners are about 70% Technician, 20% Manager, and 10% Entrepreneur. They start businesses not because they wanted to build a business, but because they wanted to escape a boss and do the technical work they loved. They had what Gerber calls an "entrepreneurial seizure"—a moment where they decided that because they could do the work, they should run a business doing that work.
The Engineer's Trap
For engineers, this trap is particularly acute. Engineering culture celebrates the Technician. We hero-worship the 10x developer, the technical genius who can solve problems others can't. We tell stories of founders who coded their way to success. The implicit message: technical excellence is the path to business success.
So an excellent engineer starts a company. They can build better products than anyone they might hire. They know exactly how the code should be structured. They have opinions on every technical decision. And so they do what they know: they write code. They solve technical problems. They stay in the Technician role because that's where they're comfortable and competent.
Meanwhile, no one is selling. No one is systematizing operations. No one is building a team. No one is thinking strategically about where the company should be in five years. The company becomes dependent on the founder's technical output—which doesn't scale.
Working In vs. Working On
Gerber's most famous distinction is between working "in" your business and working "on" your business. Working in means doing the technical work—serving customers, writing code, building products. Working on means building the systems that enable the business to operate without you.
For technical founders, this is counterintuitive. Writing code feels productive. It has immediate, visible results. Thinking about business systems feels abstract, maybe even like procrastination. Why spend time documenting processes when you could be shipping features?
But the math is simple. If your business requires your technical output to operate, your business is limited by your personal capacity. There are only so many hours in a day. At some point, you become the bottleneck. And if you're the bottleneck, the business can't scale.
Worse, you've created a job, not a business. You work for your company, not the other way around. You've traded one boss for a more demanding one: your own creation.
The Turn-Key Revolution
Gerber's prescription is to build your business as if you're going to franchise it—even if you never will. Design the business so someone with reasonable skills could run it by following documented systems. Create processes for everything: hiring, onboarding, customer service, product development. Build a business that works without you in the day-to-day.
This is the "turn-key" model. The business is designed to be operated by turning a metaphorical key—following the system—rather than requiring the founder's genius. McDonald's is the canonical example: systems so well-designed that teenagers can reliably produce the same experience in any location.
For software companies, this looks like:
- Documented engineering practices: Code standards, review processes, deployment procedures that don't require the founder's involvement
- Hiring systems: Defined criteria, interview processes, and onboarding that can be executed by others
- Sales processes: Repeatable approaches to finding, qualifying, and closing customers
- Product strategy frameworks: Ways to make decisions about what to build that don't require the founder's technical judgment every time
The Identity Challenge
The hardest part isn't intellectual—it's emotional. Engineers identify with their technical abilities. Being the best coder in the room is a source of pride, even identity. Stepping back from the technical work feels like abandoning what makes you valuable.
This is the E-Myth's deepest challenge: building a business requires becoming someone different than the person who started it. The skills that got you here won't get you there. The founder who writes code all day is doing something valuable, but they're not building a company—they're doing a job.
The shift requires recognizing that building systems is its own kind of technical work. Designing a hiring process is like designing a system. Creating sales playbooks is like writing documentation. Building an organization is like architecture at a different level of abstraction.
What This Looks Like in Practice
Over the past year, I've tried to internalize these lessons. Some concrete changes:
I stopped being the default assignee. If a technical problem could be solved by someone else, even if I could solve it faster, I delegated it. Speed today at the cost of scaling tomorrow is a bad trade.
I documented everything. Every decision that might need to be made again got written down. Every process that I executed got turned into a checklist. The goal: anyone else could do what I do.
I hired for complement, not similarity. Instead of hiring people who think like me, I hired people with skills I lack. Someone who loves sales. Someone who loves operations. The goal is a team that covers the full spectrum, not a team of technicians.
I scheduled time for strategy. The Entrepreneur needs time and space. I block time weekly to think about the business rather than working in it. Where should we be in a year? What's not working? What opportunity are we missing?
The Ongoing Struggle
I'm not going to pretend I've figured this out. The pull toward technical work is constant. When things get stressful, my instinct is to write code—it's controllable, it shows immediate results, it uses skills I'm confident in.
But every time I catch myself defaulting to Technician mode, I try to ask: "Is this the highest-leverage thing I could be doing? Or am I just doing what's comfortable?"
The E-Myth's insight isn't that technical work doesn't matter—it does. It's that building a business requires balancing the Technician with the Manager and Entrepreneur. The technical founder who can't make that balance will build, at best, a successful consulting practice. The one who can will build a company.
Gerber wrote for bakeries and plumbers, but the lesson applies perfectly to startups. If you're a technical founder, the biggest risk isn't a competitor with better technology. It's your own inability to step back from the keyboard and build something bigger than your own output.