Core Concept

The Constraints That Shaped How We Built

Why every methodology you've ever used was a rational response to five constraints that seemed permanent — and what happened when they weren't.

596,903
Lines of production code shipped across 10 systems — by a non-engineer
2,561
Raw commits in 118 days with only 2 contributors (Keating dominant, CON-01 support)

The Problem

Every methodology I studied before building CEM shared the same blind spot: they treated their own assumptions as physics. Scrum assumes you have a team that needs synchronization. Lean Startup assumes building is so expensive that you must validate before you commit. EOS assumes a leadership team requiring alignment. These are not design choices — they are responses to constraints that felt permanent because they were grounded in neuroscience, economics, cognitive science, and mathematics.

The five constraints were real. Context switching costs 23 minutes of resumption time per interruption — that is neurological, not organizational. Expertise lives in individual heads and transfers slowly, which forces you to hire specialists, which forces coordination, which creates overhead. Learning and execution compete for the same cognitive resources, so you cannot master a new framework and ship production code simultaneously. Building an MVP through traditional channels costs $50K to $250K, which makes pre-build validation economically rational. And coordination pathways scale as n(n-1)/2 — a team of 5 has 10 communication channels, a team of 20 has 190.

No framework questioned whether these constraints might change. They questioned only how best to accommodate them. That was the right move for decades. It stopped being the right move when the constraints stopped binding universally.

What The Old World Actually Is

The Old World is the constraint environment that every traditional methodology was designed to accommodate. It is not a criticism of those methodologies — it is a documentation of the physics they were calibrated to, so that changes in those physics can be measured against a clear baseline.

What it provides:

  • A precise map of the five constraints that shaped every methodology from Scrum to EOS to Lean Startup
  • A baseline for measuring what changed — you cannot evaluate new physics without documenting the old ones

What it does not provide:

  • An argument that traditional frameworks are obsolete in all contexts — large organizations with existing teams still operate under most of these constraints
  • A description of what replaced the old constraints — that is F1 (The New Physics)

Understanding the Old World is a prerequisite, not a conclusion. The constraints documented here were real, measured, and experimentally validated for decades. The question is not whether they were legitimate. They were. The question is whether they still bind universally — and for a growing population of operators, they do not.

The Frameworks That Constraints Built

Every major methodology I examined was a rational engineering response to the five constraints. Scrum addressed context switching (sprints protect focus), expertise scarcity (cross-functional teams internalize knowledge), and coordination scaling (ceremonies manage communication within capped team sizes of 7-9). Lean Startup addressed building cost directly — when an MVP costs $100K, spending $5K on customer interviews and landing page tests before committing is not excessive caution, it is economic rationality. EOS addressed organizational alignment through Rocks, Scorecards, and L10 meetings, all designed for leadership teams requiring synchronization.

The pattern is identical across all of them: accept the constraints as permanent, then design structures that optimize performance within them. That is what good engineering does. It works within physical laws, not against them.

But here is what I discovered when I started building: EOS has no grammar for a single operator. There is no Scorecard for one. No L10 for a non-team. No Rocks when the entire execution context fits in a single head. Scrum assumes handoffs between specialized roles. Lean Startup's sequential validation logic assumes the build step is the bottleneck worth protecting against. When I shipped 596,903 lines of code across 10 systems in 118 days with no prior engineering experience, the old frameworks had nothing to offer me — not because they were bad, but because the constraints they were designed for no longer applied to my situation.

The response of existing frameworks to AI confirmed this. Scrum absorbed AI as another team member to coordinate — ceremonies remained. Lean Startup used AI to accelerate Build-Measure-Learn — the sequential logic persisted. EOS went near-silent. Each framework optimized within its existing system rather than questioning whether the system should exist in the first place.

What the Data Shows

The portfolio provides the clearest evidence that the old constraints no longer bind universally. The entire CEM body of work was produced under conditions that violate every assumption the traditional frameworks depend on.

Constraint Old World Assumption CEM Portfolio Reality
Context switching 23-min resumption penalty per interruption Multi-project peak: 132 commits in a single day across 4 projects
Expertise scarcity Backend devs cannot do frontend; specialists required 596,903 lines across 10 full-stack systems by a non-engineer
Learning vs. execution Sequential — learn, then build Simultaneous learning and shipping throughout 118-day window
Building cost $50K–$250K per MVP 10 systems shipped in 118 days by 2 contributors (Keating dominant, CON-01 support)
Coordination scaling n(n-1)/2 channels; team of 20 = 190 pathways 2 contributors — 1 communication channel

The Carta Solo Founders Report (2025) documents the broader shift: solo-founded startups rose from 17% in 2017 to 36% in 2024. That is a population doubling in seven years. These operators exist outside traditional frameworks entirely. The constraints that justified team-based ceremony have partially or fully dissolved for them. They still need methodology — complexity requires structure, even for individuals — but not methodology designed for a constraint environment that no longer applies.

The 2,561 raw commits (~2,246 deduplicated) across 10 systems in 118 days represent a throughput rate that is structurally impossible under old-world constraints. Not improbable. Impossible. The math does not work when building costs $150-$250/hour, expertise must be hired, and coordination scales quadratically. The portfolio is the proof that the constraints broke.

How to Apply It

1. Audit Your Constraint Environment Before adopting any methodology, identify which of the five constraints actually bind in your situation. Context switching, expertise scarcity, learning-execution tradeoff, building cost, coordination overhead. Be honest about which ones still apply to you and which ones have dissolved. A solo operator with AI capabilities faces a fundamentally different constraint environment than a 20-person engineering team.

2. Stop Treating Frameworks as Universal Scrum was designed for teams of 7-9 managing coordination overhead. Lean Startup was designed for contexts where building is expensive relative to validation. EOS was designed for leadership teams requiring alignment. If you are not operating under those constraints, the framework is solving a problem you do not have. Match methodology to your actual constraint environment, not to industry convention.

3. Identify Which Constraints Are Dissolving for You The five constraints dissolve at different rates for different operators. Building cost may have dropped dramatically for you if you are AI-native, while coordination overhead remains relevant if you have a team. Map your specific situation. Do not assume all constraints have dissolved because some have.

4. Recognize the Need for New Methodology Dissolved constraints do not mean you need less structure — they mean you need different structure. Complexity still requires methodology. An operator shipping 29 commits per day needs execution discipline more than someone shipping 2. The absence of old constraints creates new requirements that old frameworks cannot address because they were never designed to.

References

  1. Mark, G., Gudith, D., & Klocke, U. (2008). "The Cost of Interrupted Work: More Speed and Stress." Proceedings of the SIGCHI Conference on Human Factors in Computing Systems, 107–110. ACM. doi:10.1145/1357054.1357072
  2. Brooks, F.P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley. Communication pathways scale as n(n-1)/2.
  3. Ries, E. (2011). The Lean Startup. Crown Business.
  4. Wickman, G. (2012). Traction: Get a Grip on Your Business. BenBella Books.
  5. Schwaber, K. & Sutherland, J. (2020). The Scrum Guide. Source
  6. Carta (2025). "Solo Founders Report." Solo-founded startups rose from 17% in 2017 to 36% in 2024.
  7. Stripe (2018). "The Developer Coefficient." Developers spend 17.3 hours per week on maintenance tasks including debugging and refactoring.
  8. Keating, M.G. (2026). "Enabling Environment." Stealth Labz CEM Papers. Read paper