Every recurring problem needs the right kind of system

A lot of founder-led businesses react to recurring problems the same way. Someone notices the issue, sends a reminder, pays closer attention for a week, and hopes the problem stays fixed.

Chapter 18 of The E-Myth Revisited gives a better frame. Not every recurring problem is the same kind of problem.

Some failures need a Hard System such as a template, default, automation, layout change, or tool constraint that makes the right action easier than the wrong one. Some need a Soft System such as a script, checklist, training path, onboarding flow, or benchmark sequence that helps people deliver the same promise consistently. Some need an Information System such as a scorecard, exception report, dashboard, or benchmark view that shows where the promise pipeline is stalling, leaking, or drifting.

Take one common failure: leads keep sitting too long before anyone follows up. A hard-system fix might require a next-step date before a lead can move stages. A soft-system fix might give the team a same-day follow-up script and a daily contact block. An information-system fix might flag every lead with no touch in the last 24 hours. The symptom looks the same to the owner. The missing layer is different, and so is the fix.

Diagnose the missing layer first

Ownership only takes hold if it feels lighter over time. If every recurring defect still gets solved by more founder attention, more cleanup, or more supervisory memory, then the owner is still acting as the hidden operating system.

Gerber’s taxonomy forces a better first question: what kind of system is actually missing here? If a workflow keeps slipping because inputs are malformed, the fix may be structural. A different customer experience every time points to a scripted method. When the team cannot tell where work is backing up, the fix may be instrumentation rather than exhortation. When the layer is wrong, the owner keeps carrying the problem by hand.

Stop solving design failures with strain

A lot of operational drag comes from solving system failures with human strain. It shows up as writing the same reminder again, checking the same work manually because there is no visible quality gate, or stepping in personally because the workflow gives no signal until it is already late.

Those moves can be necessary in the moment. They should not become the permanent method. A company gets healthier when repeated friction is turned into a design change that removes future owner rescue.

Use repeated friction as design input

Chapter 19 sharpens why this matters. The business is not only producing output. It is teaching everyone, including the owner, what kind of operation they are building.

If Hadto keeps falling back to rescue work, vague ownership, and unmeasured improvisation, that is evidence that the design still depends on personal intervention. The better pattern is simple: step back, classify the friction, fix the missing system, and reduce the amount of judgment the owner has to supply next time.

The standard is not better intentions. It is a business that can transfer work, maintain quality, and absorb recurring problems without pulling you back into the middle of them.

This week, take the most recent problem that has happened at least twice and classify it before assigning any effort. Does the right action need to become structurally easier than the wrong one? That is a hard-system fix. Does the team need a script, checklist, or training path to deliver it the same way each time? Soft system. Can nobody see where the work is stalling until it is late? Information system. Fix the layer you named, then watch whether the reminder you would normally send becomes unnecessary.

---

Source evidence used in this note: Michael E. Gerber, The E-Myth Revisited, Chapters 18-19, reviewed 2026-04-13. Hadto interpretation: classify recurring friction before assigning more founder effort.