I didn’t set out to write about life balance.

After my Three Gurus series — where I traced how a Victorian monk, a clinical psychologist, and a modern entrepreneur independently converged on the same principles about responsibility, sacrifice, and meaning — a few readers reached out. Not about the philosophy. About the application. “You clearly think in systems,” one message said. “So how do you actually apply systems thinking to this?”

Fair question. I’m not a philosopher. I’m not a psychologist. I’m not a business guru. I’m an enterprise architect who spends his days building reconciliation loops and compliance infrastructure in regulated banking. But I kept seeing the same structural patterns in “life management” discourse that I see in legacy enterprise systems — and the same architectural mistakes.

Then I read James Clear’s piece on the Four Burners Theory, and something clicked. Not because the theory was wrong. Because the theory was describing a monolith.

The Theory

The Four Burners Theory comes from a 2009 David Sedaris piece in The New Yorker. The metaphor: your life is a stove with four burners — Family, Friends, Health, Work. To be successful, you must cut one burner. To be really successful, you must cut two.

Clear popularized the idea with three response strategies. Outsource — delegate aspects of life (childcare, meal prep) to keep burners running without personal investment. Embrace constraints — maximize effectiveness within fixed time blocks rather than wishing for more hours. Seasons of life — dedicate different periods to different burners rather than pursuing simultaneous balance.

These are reasonable strategies. Millions of people use them. The discourse around work-life balance is built on variations of the same three ideas.

But they all accept the same underlying assumption: the four burners compete for a shared, finite resource pool, and your only option is managing how that pool gets distributed.

What if that assumption is the problem?

The Monolith Pattern

If you’ve worked in enterprise software, you recognize the Four Burners immediately. It’s a monolith.

A monolithic application runs as a single process. Every component — authentication, billing, notifications, search — shares the same memory, the same CPU, the same deployment pipeline. When the billing module gets hammered with traffic, authentication slows down. When notifications go haywire, everything degrades. One component consuming too many resources starves the others. That’s not a theory about tradeoffs — it’s the predictable behavior of a tightly coupled system.

The Four Burners theory describes exactly this pattern. One stove. Four burners. Shared gas line. Turn Work up, Health goes down. Pour energy into Family, Friends fade. The “you must cut a burner” conclusion feels like a universal law. But it’s not a law. It’s a coupling problem.

When enterprises hit this wall — when their monolith starts choking under load — they don’t accept “well, you’ll just have to turn off some features.” They decompose.

What Decomposition Actually Does

Microservices didn’t win because they’re trendy or because someone wrote a persuasive whitepaper. They won because they solve the coupling problem. Each service gets its own resources. One service crashing doesn’t take down the others. You can scale billing independently from authentication. You can deploy notifications without redeploying search.

The critical insight isn’t “more resources.” It’s blast radius containment.

When Work bleeds into Family at 11pm — when you’re answering Slack messages during your kid’s bedtime routine — that’s not a resource problem. You have the time. You have the energy. What you have is a boundary failure. Work’s blast radius is unconstrained, and it’s cascading into an adjacent service.

When Health degrades because of Work stress — when you skip the gym because a project is consuming your headspace even though the gym only takes 45 minutes — that’s not about cutting a burner. It’s about shared state leaking across service boundaries. Work’s cognitive load is contaminating Health’s execution context.

Decomposition doesn’t give you more hours in the day. It stops one domain’s problems from automatically becoming every domain’s problems.

This is the same principle behind the compliance tax I wrote about — regulated environments force you to build boundaries that unregulated environments skip. Those boundaries feel like overhead. Until the day an uncontained failure cascades through your entire system, and you realize the boundaries were load-bearing.

Drift, Not Sacrifice

Here’s what the Four Burners theory gets most wrong: it frames the problem as a conscious allocation decision. “You must cut a burner.” As if someone wakes up on a Tuesday morning, looks at their four burners, and deliberately switches one off.

That’s not how it works. Nobody cuts the Health burner. What happens is: you skip one workout. Then another. Then three months pass and you’ve gained fifteen pounds and can’t remember the last time you ran.

That’s not sacrifice. That’s drift.

If you’ve touched infrastructure-as-code, you know this pattern. Someone manually edits a security group in the AWS console. Nobody runs terraform plan for six weeks. Actual state silently diverges from desired state. By the time someone notices, the drift is extensive and the remediation is painful.

I wrote about this exact pattern in The Reconciliation Loop — how infrastructure engineers have been running desired-state reconciliation for a decade, and how AI agents introduce a new executor into that same loop. The pattern applies here with uncomfortable precision.

Your life domains don’t degrade because you made a strategic decision to sacrifice them. They degrade because drift accumulates when nobody’s running the reconciliation loop. No periodic comparison of desired state to actual state. No diff. No plan. No apply.

James Clear’s “seasons of life” approach is the closest anyone gets to addressing this — the idea of deliberately rotating which burner gets attention. But even that frames it as macro-level allocation (this year I’ll focus on Work) rather than what’s actually needed: continuous drift detection at the micro level.

Constraints Force Better Architecture

In my experience, the people who manage multiple life domains effectively aren’t the ones with the most time or energy. They’re the ones who’ve — consciously or not — decomposed the monolith.

They have hard boundaries between domains. Work ends at a specific time, and that boundary is enforced, not aspirational. Health has its own dedicated resource allocation — a morning block that doesn’t get borrowed by other services. Family has synchronous communication patterns (dinner, weekends) that take priority over Work’s asynchronous requests.

These aren’t time management hacks. They’re architectural decisions. Service boundaries. Circuit breakers. Priority queues.

The compliance tax taught me something counterintuitive: constraints force better architecture. In banking, you can’t just “move fast and break things.” Regulatory requirements force you to build approval chains, audit trails, data classification boundaries. It feels like overhead — until you realize that the overhead is actually structure, and structure is what prevents cascade failures.

The same principle applies to life. The people who build hard constraints — not “I’ll try to leave work by 6” but “my phone goes in a drawer at 6:00 and the router blocks Slack after hours” — aren’t being rigid. They’re building circuit breakers. They’re preventing the blast radius of one domain from consuming the others.

The Architecture Is Incomplete

The Four Burners theory gave us something valuable: the honest admission that tradeoffs exist. You can’t run every domain at maximum intensity simultaneously. That part is real.

But the theory’s architecture is incomplete. It’s all application layer — four services competing for resources. There’s no control plane making intelligent allocation decisions. There’s no governance layer preventing cascade failures. There’s no monitoring infrastructure detecting drift before it becomes a crisis.

It’s a stove with four burners and no thermostat. No wonder it feels impossible.

What if the Four Burners aren’t the real problem? What if the real problem is that the theory describes a system that’s missing the infrastructure layer entirely?

That’s what the judgment-execution inversion taught me about the agent era: when execution becomes cheap, the scarce resource shifts to knowing what to execute. The same inversion applies to life: managing four burners manually with willpower is the execution-heavy approach. The judgment-heavy approach is building infrastructure that makes the management systematic.

---

The Four Burners theory diagnosed the symptom — competing demands. It missed the cause: a system with no infrastructure layer. The next post explores what that infrastructure actually looks like — and why a clinical psychologist mapped it twenty years ago.

This is Post 1 of 3 in Life as Infrastructure.

Is your life running on a monolith? I’d like to hear about it. Find me on X or LinkedIn.