Somewhere in the business section of every airport bookstore, there's a shelf full of books promising to free you from your own company. The covers show people on beaches. The subheadings use words like "systems" and "freedom" and "scale." And buried somewhere in chapter three, you will find some version of the same advice: stop working in the business and start working on it.
It's not bad advice. That's what makes it dangerous.
The problem isn't the idea. The problem is what most people do with it. They hear "work on the business" and they hear "stop doing the hard parts." They build a mental picture of themselves elevated above the mess, orchestrating from a distance, finally free from the operational grind. And then they hire someone to handle the toilets, metaphorically speaking, and they never think about the toilets again.
This article is about why that's a mistake. Not because the toilets are glamorous. They aren't. But because what you learn from the toilets, if you're paying attention, is exactly the kind of information you need to build a business that works without you.
There's a difference between doing the work and understanding the work. There's a difference between escaping operations and improving them. And there's a difference between a leader who delegates and a leader who disappears. This piece is going to draw those lines clearly, because a lot of businesses are suffering right now from leaders who thought they were the same thing.
The Most Misunderstood Advice in Business
Where the Phrase Comes From
The phrase "work on the business, not in the business" comes most visibly from Michael Gerber's 1986 book The E-Myth Revisited. Gerber's argument was specific and structural: most small business owners are technicians who got good at a skill, started a business around that skill, and then became trapped doing the skill forever instead of building the organization around it. His point was about entrepreneurial thinking versus technician thinking. It was about whether you're building a system or just doing a job with extra paperwork.
That's a meaningful distinction. Gerber wasn't wrong.
But the phrase escaped the book and took on a life of its own in entrepreneurial circles, on podcasts, in coaching programs, and on LinkedIn posts with stock photos of people staring thoughtfully at whiteboards. And somewhere in that journey, the nuance got stripped out.
What Most People Hear
What most people hear is permission. Permission to stop doing the things they don't enjoy. Permission to hand off the operational friction and focus on the "strategic" work that feels more important and more interesting. The phrase gets used to justify distance, to rationalize delegation without oversight, and occasionally to explain why the founder hasn't spoken to a customer in two years.
The result is a generation of business owners who are technically "working on the business" while the business quietly accumulates unresolved problems beneath them.
The thesis here is straightforward: effective leaders work both on the business and in it. The distinction isn't about which tasks are beneath you. It's about purpose. Are you doing the work to get it done, or are you doing the work to understand it well enough to improve it? That question changes everything. And the leaders who never ask it are the ones who end up surprised when the whole thing falls apart.
The Toilet Still Needs Cleaning
Every Organization Has Necessary Work
Here's a fact that no business book spends enough time on: every organization, at every stage of growth, contains work that simply needs to happen. Not because it's interesting. Not because it builds toward something. Just because if it doesn't happen, things stop working.
Phones need to be answered. Invoices need to be processed. Support tickets need responses. Shelves need restocking. Contracts need filing. And yes, toilets need cleaning. Not metaphorically. Actually, in a physical space that real people use, someone has to clean the toilets.
None of this is glamorous. None of it is what entrepreneurs dream about when they're starting out. But the organizations that pretend this work doesn't exist, or that it's someone else's problem the moment they can afford to make it someone else's problem, tend to build cultures that are quietly contemptuous of the people doing it.
The Danger of Romanticizing Elevation
There's a version of business culture that treats operational work as something to be escaped as quickly as possible. Get above it. Delegate it. Automate it. And eventually, transcend it entirely. This sounds like progress. Sometimes it is. But it also produces leaders who don't actually understand what their organization does at the ground level, and that ignorance has real costs.
The question isn't whether to do the work. The question is what you do with what the work teaches you. Every support ticket is a data point. Every invoice dispute is a signal. Every complaint that comes through the phone is a piece of information about where the system is failing. A leader who never touches that layer of the business never receives that information. And a leader who only touches it, without ever stepping back to ask what it means, is just treading water.
The goal isn't to stay in the operational weeds. It's to understand the weeds well enough to clear them systematically. That's a different thing entirely, and it requires getting your hands dirty at least some of the time.
The Trap of Operational Heroism
When Saving the Day Becomes the Problem
Every organization has one. The person who swoops in when everything is on fire. The founder who gets the call at 11pm and personally fixes the crisis. The executive who knows every system, every workaround, every exception, because they built the whole thing and never fully handed it off. These people get celebrated. They get praised in all-hands meetings. They become part of the company mythology.
They're also a symptom of something broken.
Operational heroism feels like dedication. It looks like commitment. But what it actually represents is a system that hasn't been built well enough to function without a specific person's intervention. The hero isn't solving the problem. The hero is the workaround for the problem. And as long as the hero keeps showing up, the underlying problem never gets addressed.
"Every time a hero saves the day, the organization learns one lesson: we don't need to fix this, because someone will save us."
This creates dependency. The organization cannot function without the hero present. The hero cannot take a vacation, cannot get sick, cannot leave, without something breaking. And the hero, over time, becomes trapped. Not by the organization's needs, but by the gap between how the organization actually works and how it should work.
Heroics vs. Systems
The alternative to heroism isn't indifference. It's systems. A system does what a hero does, except it does it consistently, without burning anyone out, and it works whether the hero is in the building or not.
Systems create stability. They create repeatability. They create the conditions under which a business can actually grow, because growth requires that things work at scale, not just when the right person is paying attention.
The cultural shift required here is real. It means stopping the celebration of heroics and starting the investigation of why the heroics were necessary. It means asking, every time someone saves the day, what would have prevented this from needing to be saved. That question is uncomfortable. It implies that the hero's moment of glory is also an organizational failure. But that discomfort is exactly where progress lives.
Warning Sign
If your operation breaks down when a specific person is unavailable, the operation is broken. Full stop. Not the person. The operation. The presence of an indispensable individual is not a testament to their talent. It's evidence of a system that was never properly built.
The Difference Between Chores and Progress
Completing Work vs. Improving Work
Resolving a support ticket has value. A customer got help. A problem got addressed. The queue got shorter. That's real, and it matters.
But resolving the same type of support ticket for the 400th time this quarter is not the same thing. At that point, you're not solving a problem. You're managing a symptom. The problem is somewhere upstream, in the product, the documentation, the onboarding process, or the communication. And every ticket you close without asking why it opened is a ticket you'll close again next week.
This is the distinction between completing work and improving work. Completing work keeps the lights on. Improving work changes what the lights cost. Both are necessary. But organizations that only ever complete work, that treat the queue as something to drain rather than something to understand, are running on a treadmill. They're expending energy without moving forward.
The same principle applies everywhere. Processing an invoice is completing work. Identifying why invoices consistently arrive with errors and fixing the upstream cause is improving work. Answering a phone call is completing work. Building a knowledge base that eliminates 40% of inbound call volume is improving work.
The Compounding Value of Elimination
The most underappreciated metric in operations is recurring problem reduction. Not how many tickets you closed, but how many categories of ticket no longer exist. Not how many fires you fought, but how many fire sources you eliminated.
Progress compounds in a way that chore completion never does. If you reduce a category of recurring problem by 50%, you've freed up capacity permanently. That capacity can go toward the next category of problem. And the next. Over time, the organization gets lighter, faster, and more capable, not because people are working harder, but because the work itself has been improved.
This is what "working on the business" actually means in practice. Not escaping operations. Not delegating everything and hoping for the best. It means looking at the operational layer with enough curiosity to ask why things work the way they do, and enough discipline to change the ones that shouldn't.
Controls: The Nervous System of an Organization
What Organizational Controls Actually Are
The word "controls" makes people nervous. It sounds like bureaucracy. It sounds like the kind of thing that slows organizations down, creates paperwork nobody reads, and turns simple processes into committee decisions. That's a fair reaction to bad controls. But it's the wrong reaction to controls as a concept.
Organizational controls are the mechanisms that create consistency across people, time, and circumstances. They're the reason two different employees handle the same situation the same way. They're the reason a process that works on Monday still works on Friday, and still works when the person who designed it is on vacation.
Controls come in several forms. Policies define what should happen and why. Procedures define how it should happen, step by step. Automation removes human variability from repeatable tasks entirely. Audits check whether what's supposed to happen is actually happening. Measurements quantify outcomes so you can tell whether the process is working. And accountability structures define who owns what, so that responsibility doesn't dissolve into collective ambiguity.
None of these are glamorous. All of them are necessary.
How Controls Create Measurable Outcomes
Here's the chain that most organizations miss. Controls create consistency. Consistency creates reliable data. Reliable data creates the ability to make informed decisions. And informed decisions are the only kind worth making.
If your process varies randomly depending on who's working that day, what mood they're in, and which workaround they've personally discovered, then the data you collect from that process is noise. You can't improve what you can't measure. And you can't measure what changes shape every time someone new touches it.
The Infrastructure of Learning
Controls aren't bureaucracy for its own sake. They're the infrastructure of organizational learning. Without consistent processes, you have anecdotes. With consistent processes, you have data. The difference between those two things is the difference between guessing and knowing.
This is why controls matter to leaders who are genuinely trying to build something. Not because rules are good in themselves. Not because consistency is a virtue independent of outcomes. But because an organization that operates consistently generates information about itself. That information tells you what's working, what isn't, and where the next improvement should go. Strip out the controls and you strip out the signal. You're left making decisions based on gut feel and whoever talked to you last, which is a fine way to run a very small operation and a terrible way to run anything that needs to grow.
The nervous system metaphor holds up. A body without a nervous system can still have muscles. It just can't coordinate them. Controls are how an organization coordinates itself, across departments, across time zones, across the gap between what the founder intended and what actually happens on the ground.
Data Is the Real Product of Operations
Every operation your organization runs produces two things. The first is obvious: the output. The ticket gets resolved. The order ships. The client gets onboarded. The second output is invisible, and most organizations throw it away without ever realizing what they had.
That second output is data.
Every Process Generates Information
Every time a process runs, it leaves a trail. KPIs tell you whether performance met the target. Ticket queues tell you where demand is concentrating. Defect rates tell you where quality is breaking down. Escalations tell you where frontline controls failed. Delays tell you where capacity is mismatched to load. Customer complaints tell you what your internal metrics missed entirely. Rework volumes tell you how much of your labor is being spent correcting what should have been right the first time.
Most organizations collect some version of this. Spreadsheets exist. Dashboards get built. Reports go out every Friday. The data is technically present.
Why Most Organizations Fail to Learn
Collection is not the same as learning. That distinction is where most organizations quietly fall apart.
The failure modes are predictable. Data gets siloed by department, so the customer service team never sees the defect rate data that explains why complaints are spiking. Metrics get reported but not acted on, because the reporting cadence exists to satisfy a stakeholder, not to trigger a decision. Dashboards get built for optics rather than operations, designed to look reassuring rather than to surface problems worth solving.
The result is an organization that is technically measuring everything and learning nothing. It has the raw material for improvement and no mechanism to convert it.
That mechanism is the optimization cycle. It is the bridge between data that exists and knowledge that compounds. It closes the gap between observation and change. And it is the most practical answer to the question of what "working on the business" actually requires you to do.
The Optimization Cycle
The phrase "continuous improvement" gets used so often it has lost almost all of its meaning. It shows up in mission statements and all-hands decks and means, in practice, approximately nothing. So let's replace the phrase with a structure. Seven steps. Repeating indefinitely. No finish line.
Seven Steps That Never Actually End
The cycle runs like this:
1. Perform. Execute the process as it currently exists. Do the work. Serve the customer. Ship the product. This is not optional, and it is not the problem. It is the starting point.
2. Measure. Capture what actually happened. Not what you hoped would happen. Not what the process was designed to produce. What it actually produced, at what cost, in what time, with what error rate.
3. Analyze. Look at the measurement against the expectation. Where did performance diverge from design? Where did the process behave in ways that weren't predicted? This step requires honesty, which is why many organizations skip it.
4. Identify friction. Name the specific points where the process slows, breaks, requires heroics, produces errors, or depends on a single person's memory. Friction is not a vague feeling. It is a locatable, describable event.
5. Improve controls. Design a change. A checklist. A handoff protocol. An automated trigger. A clearer ownership boundary. Something concrete that reduces the friction identified in the previous step.
6. Deploy improvement. Implement the change in the actual operating environment. Not in a pilot that never scales. Not in a document that no one reads. In the real process, with real people, under real conditions.
7. Measure again. Go back to step two. Did the change produce the expected result? Did it create new friction somewhere downstream? What does the new data say?
This Is Not a Linear Project
The optimization cycle does not end at step seven. Step seven feeds back into step one. Every improvement generates new information, which reveals new friction, which requires new controls. The loop is the point.
Why Every Improvement Reveals the Next Problem
Organizations at early maturity stages often find this cycle disorienting. They fix one thing and discover three more things that need fixing. That feeling is not evidence that the cycle is failing. It is evidence that it is working. You are now seeing problems that were always there but were invisible because the previous layer of dysfunction was obscuring them.
The goal is not a perfect process. The goal is a process that is measurably less dependent on heroics, less vulnerable to variation, and less expensive to run than it was six months ago. That is what continuous improvement actually means when it means something.
This is also the most honest definition of "working on the business." Not vision retreats. Not strategic frameworks on whiteboards. The optimization cycle, running quietly and persistently, converting operational data into organizational capability. That is the work.
Working In vs. Working On: A More Honest Map
The framing of "working in the business versus working on the business" is useful. It is also frequently weaponized to make execution feel like a trap and strategy feel like liberation. That reading is wrong, and it causes real damage to real organizations.
What Each Mode Actually Produces
Working in the business means producing output. Executing tasks. Serving customers. Resolving tickets. Shipping orders. Handling the daily operational load. This mode creates immediate value. Without it, there is no revenue, no customer relationship, no organization worth improving.
Working on the business means improving systems. Refining controls. Measuring performance against design. Eliminating problems that keep recurring. This mode compounds value. It does not create value directly. It multiplies the value that execution creates, by making execution faster, cheaper, more reliable, and less dependent on individual heroics.
Neither mode is optional. Neither is superior.
Why Neither Is Superior
An organization that is all execution with no improvement is running a treadmill. The same problems appear on Monday that appeared last Monday. The same fires get fought. The same customers escalate. The same team members burn out. Output is produced, but the organization does not get stronger. It just gets tired.
An organization that is all strategy with no operational grounding is producing documents. Vision without execution is fiction. Process design without operational reality is consulting theater. The leaders who never do the work eventually lose the ability to understand it, and their improvements stop connecting to anything real.
The Ratio Shifts. It Doesn't Flip.
Early-stage organizations may spend 90% of their capacity in execution mode and 10% on improvement. A mature organization might reach 60/40. The ratio changes as capability builds. But zero is never the right number for either side. The moment you stop executing, you stop learning. The moment you stop improving, you start decaying.
The honest map looks like this: execution is the engine, and improvement is the maintenance schedule. You need the engine running to go anywhere. You need the maintenance schedule to keep the engine running ten years from now.
The Organizational Maturity Curve
Most conversations about organizational maturity treat it like a credential. You achieve a stage, you receive the certificate, you move on. That is not how it works. Maturity is a description of how your organization currently behaves under pressure, not a title you earn once and keep forever.
Six Stages from Dependency to Culture
Stage 1: People-dependent. The organization runs because specific individuals know what to do. Remove those people and the process collapses. There are no documented procedures, no formal handoffs, no institutional memory beyond the people currently holding it. This is where every organization starts.
Stage 2: Processes emerge. Informal patterns begin to solidify. People start doing things the same way repeatedly, not because it is written down, but because it worked last time. The organization is building implicit process, but it is fragile and invisible.
Stage 3: Controls formalized. Processes get documented. Checklists appear. Ownership gets assigned. Performance starts getting measured in some form. This is a significant leap, and it is also where most organizations stop.
Stage 4: Data drives decisions. Measurement connects to action. Operational data informs resource allocation, process changes, and prioritization. Leaders make decisions based on what the numbers show, not just what they feel.
Stage 5: Optimization becomes continuous. The improvement cycle runs persistently, not as a project triggered by a crisis, but as a normal operating behavior. Problems get identified and addressed before they become emergencies.
Stage 6: Improvement becomes culture. Every person in the organization understands that their job includes making the job better. Improvement is not a department or a program. It is how the organization thinks.
Where Most Organizations Actually Are
Most small and mid-size businesses operate somewhere between Stage 1 and Stage 3. That is not a failure. It is a starting position. The maturity curve is not a judgment. It is a map.
One clarification worth making explicitly: the goal of moving up this curve is not to remove humans from operations. It is to increase what humans are capable of doing. Automation that replaces a person doing low-value repetitive work is not a threat to the organization. It is a reallocation of human capacity toward work that actually requires human judgment. Systems enable people to do higher-value work. That is the whole point.
Your Action Plan: Stop Worshipping the Status Queue
There is no virtue in being perpetually overwhelmed. Say that again, slowly, and mean it.
There is no virtue in solving the same problem for the four hundredth time. A thousand completed tasks that leave the organization exactly as fragile as it was before those tasks started is not progress. It is motion. Those are different things.
What to Do With This Starting Monday
The purpose of today's work is to learn enough from it that tomorrow's work becomes easier, faster, more reliable, or disappears entirely. That is the standard. Not volume. Not velocity. Not the length of the completed-tasks list.
"The organization that learns from its operations faster than its competitors will outlast them. Not because it works harder. Because it works differently every six months."
The biological parallel is useful here. Evolution does not optimize through effort. It optimizes through observation, variation, selection, and repetition. Organisms that adapt to their environment survive. Organisms that repeat the same behavior in a changed environment do not. Your organization is no different. Observe. Measure. Adapt. Repeat.
The Tasklist
One problem. One process. One control. Thirty days. That is the entire framework in operational form.
The optimization cycle is not a project with a finish line. It is how healthy organizations breathe. Every inhale is execution. Every exhale is improvement. Stop one, and the organization suffocates. Keep both going, and it gets stronger every single time it runs.
