The technician trap in an AI-first world
Gerber's technician, manager, and entrepreneur personas hold up. But they no longer map to people — they map to capability layers in AI-first firms.
Part 2 of The E-Myth, revisited again
The previous article in this series ended with a claim that deserves unpacking: the technician, manager, and entrepreneur roles "no longer map cleanly to people — but still map precisely to capabilities."
That distinction matters more than it might first appear. Gerber's original framework was built around roles as internal conflicts — three personas competing for the founder's time and attention. The growth path was clear: move from technician to manager to entrepreneur, hire people to fill the roles you vacate, and build a business that operates without your constant involvement.
What AI changes is not the framework itself, but the assumption underneath it. The E-Myth took for granted that every role required a human. That constraint shaped everything: how roles were defined, how handoffs were structured, how systems were documented. Remove that constraint, and the framework doesn't collapse — it transforms.
The three personas as Gerber described them
In The E-Myth Revisited, Gerber argued that most founders are technicians suffering from an entrepreneurial seizure. They are good at doing the work — baking, coding, consulting, designing — and they assume that running a business means doing more of it. The problem is that doing the work and designing the business are fundamentally different activities.
Gerber named three internal personas. The technician wants to get things done, lives in the present, and distrusts abstraction. The manager wants order, predictability, and control. The entrepreneur wants growth, possibility, and change. Every founder contains all three, but most are dominated by the technician. They stay in the weeds because the weeds feel like real work.
The remedy was role separation. Define the technician's job as a set of procedures. Hire someone to execute them. Move yourself into the manager role. Eventually, define the manager's job, hire for that too, and step into the entrepreneur role — the person who works on the business rather than in it.
This made complete sense when every role required a body. If work meant human effort, then scaling meant adding humans. The founder's job was to design jobs that other people could fill.
Why the framework held together
The three personas were not just psychological insights. They represented fundamentally different kinds of work.
Technician work is execution. It turns inputs into outputs according to known patterns. The baker bakes. The developer codes. The consultant delivers. The quality metric is consistency: can this person produce reliable results within defined parameters?
Manager work is coordination. It ensures that technician work happens in the right sequence, at the right quality, with the right resources. The manager handles exceptions, monitors progress, enforces standards, and decides when something needs escalation. The quality metric is coherence: do the parts work together?
Entrepreneur work is design. It decides what the business should be, what trade-offs it should make, what capabilities it needs, and where it should go. The entrepreneur sets objectives, defines constraints, and holds accountability for outcomes that span the entire system. The quality metric is intent: is the business doing what it was meant to do?
Each layer requires different skills, operates on different time horizons, and fails in different ways. Gerber's insight was that most founders try to do all three simultaneously — and do none of them well.
What changes when roles don't require people
AI disrupts this framework at the level of assumption, not structure.
The three layers — execution, coordination, design — remain distinct. They still require different kinds of capability. They still fail in different ways. But they no longer require three different humans.
Consider what AI can now do reliably. It can execute pattern-based work: drafting, summarising, formatting, researching, responding to routine queries. That is technician-layer capability. It can also handle coordination within defined parameters: routing tasks, monitoring for exceptions, applying quality checks, managing workflows. That is manager-layer capability — not all of it, but a meaningful portion.
What AI cannot do, at least not yet, is set objectives worth pursuing, define constraints that reflect genuine values, or hold accountability for outcomes that span the whole business. That is entrepreneur-layer work. It remains irreducibly human.
This means the founder's job is no longer to hire people into roles. It is to design how capabilities interact — regardless of whether those capabilities are human, AI, or some hybrid of the two.
The capability reframe
The three personas can now be understood as capability layers.
The technician layer is execution capability. This is where pattern completion happens, where defined tasks get done, where consistency is the primary goal. AI excels here. It can draft the proposal, process the invoice, respond to the standard inquiry. But it needs bounded scope. Without clear inputs, defined outputs, and explicit constraints, execution capability drifts or hallucinates.
The manager layer is coordination capability. This is where execution gets orchestrated, where exceptions are handled, where quality is monitored. AI can operate here too — routing work, flagging anomalies, enforcing checklists. But it needs escalation paths. Coordination without judgment design produces systems that optimise locally while failing globally.
The entrepreneur layer is design capability. This is where objectives are set, where trade-offs are defined, where the system's intent is authored. This remains human. Not because AI couldn't theoretically do it, but because the accountability for getting it wrong cannot be delegated. Someone has to own what the business is for.
The shift for founders is significant. Instead of asking "Who should sit in this role?", the question becomes "What capability does this function require, and where should it live?"
The new failure modes
This reframe creates new ways to fail — ways that would not have made sense under the old model.
The first failure mode is treating AI as a super-technician without building the manager layer. This happens when founders hand execution to AI but do not design the coordination that makes execution coherent. The AI drafts proposals, responds to emails, and generates reports — but no one is monitoring whether the outputs align, whether exceptions are being caught, or whether the whole system is drifting. The work gets done, but the business loses coherence.
The second failure mode is automating coordination without designing escalation. Here the founder builds workflows that route, check, and process — but never specifies when a human should step in. The system hums along until it encounters something genuinely ambiguous, at which point it either stalls or makes a decision it was never qualified to make. The manager layer exists, but without the tripwires that keep it bounded.
The third failure mode is the capability gap. This is when no one — human or AI — owns a necessary function. It happens when founders assume AI is handling something it isn't, or when roles are defined so narrowly that edge cases fall through. The symptom is not failure but absence: things that should be happening, questions that should be asked, checks that should occur — none of them do. The gap is invisible until it isn't.
What this looks like in practice
To ground this, consider a small marketing agency with three people: a founder, a strategist, and a junior account manager.
In a traditional model, the founder handles new business and big-picture direction. The strategist develops campaign concepts and client recommendations. The junior handles execution — scheduling, coordination, reporting. Each person fills a role, and the system works as long as everyone stays in their lane.
Now introduce AI. The junior's execution work — scheduling posts, generating reports, compiling research — can largely be automated. The strategist's work shifts: instead of producing first drafts, they review AI-generated options, refine positioning, and focus on client relationships. The founder's work shifts too: instead of defining processes, they define policies. What should the AI never say to a client? What tone is non-negotiable? When must a human review before anything goes out?
The org chart still shows three people. But the capability map looks different. Execution capability is now mostly AI, with human spot-checks. Coordination capability is split between the junior (managing client relationships) and automated workflows (routing approvals, flagging deadlines). Design capability remains with the founder and strategist — but its surface area has expanded. They now own not just what the agency does, but how its systems think.
The interesting failure mode here is the one that sneaks up gradually. The AI handles more and more, the humans review less and less, and the policies that were supposed to govern behaviour become assumptions no one remembers to check. The agency is still functioning. The clients are still happy. But the gap between what the founder intended and what the system actually does is widening — invisibly, until a client sees something that should never have been sent.
The audit that matters
Given these shifts, how does a founder know whether their business is structured correctly?
The traditional E-Myth audit asked: which roles are documented? Which are dependent on the founder? Which could be filled by someone else? The answers pointed toward delegation and systemisation.
The capability-layer audit asks different questions. At the execution layer: what tasks require pattern completion, and are they bounded clearly enough that AI can do them reliably? At the coordination layer: what exceptions need to be caught, what quality checks must occur, and who — or what — is responsible for each? At the design layer: what objectives govern the system, what constraints are non-negotiable, and who holds accountability when they conflict?
This audit does not produce an org chart. It produces a map of where capability lives, where judgment is required, and where gaps exist. The output is not "hire for this role" but "design this boundary."
Why this matters now
The technician trap has not disappeared. It has evolved.
The modern version is the founder who is fluent in AI tools, who can wire automations, who can get results — and who therefore stays central to everything. They are still holding the logic in their head. They are still the bottleneck. The work looks strategic, but the dependency is the same.
Escaping this trap requires the same conceptual move Gerber originally prescribed: stepping back from doing the work to designing the system. But the system is no longer just procedures and people. It is capabilities, policies, and boundaries — a layer of architecture that did not exist before. It is also the goal John Warrillow sets out in Built to Sell: a business that can run, and sell, without its founder.
The next article in this series will explore what that architecture actually looks like. Org charts, it turns out, are the wrong tool. Capability maps are not.
