# Your Brain Is the Monolith *You've built a system whose only point of failure is your own brain. Refactor it.* # Your Brain Is the Monolith *You've built a system whose only point of failure is your own brain. Refactor it.* ![[HERO] Your Brain Is the Monolith](https://cdn.marblism.com/6KliEt3bVOR.webp) In software engineering, a monolith is a system where every part of the application — the database access, the business logic, the user interface, the auth, the email service — runs in one big bundle. It's easy to build at first because everything is in one place. It runs fast because it doesn't have to cross network boundaries. The first 18 months feel productive. Then it stops feeling productive. A bug in the email service crashes the checkout. An update to the user profile page requires you to redeploy the entire application. The team grows from four engineers to twelve, and now half of them are stepping on each other's code at the same time. The monolith is no longer fast. The monolith is also no longer reliable, because the failure modes have grown faster than the system's ability to absorb them. By month 30, the team is shipping less than they did at month 12. You are not running a monolithic codebase. You are running a monolithic *operation*. Your brain is the monolith. Every decision routes through it. Every fix is on its back. Every clarification is its job. The new hire pings you at 11pm because the documentation is in your head. The vendor decision waits until you have time. The strategic question your VP asked in March is still on your list because nobody else has the context to answer it. The pattern is identical to what software teams figured out the hard way over the last fifteen years. The fix is also identical. Refactor. ## What Sam Newman has been documenting since 2014 Sam Newman is a British software engineer who, since 2014, has written the canonical books on what software architects call microservices. His first book, *Building Microservices*, was published in 2015 and immediately became the standard reference. The second edition came out in 2021. The argument is short. A monolith is fine when the system is small. The monolith breaks when one of three things happens. The team grows past about six engineers. The system needs to scale parts of itself differently than other parts. The pace of change exceeds what one big deploy can absorb. When any of those three thresholds is crossed, the monolith stops being efficient and starts being a liability. Every change becomes a risk to every other part of the system. Every team becomes blocked on every other team. Every deploy becomes a heroic event. The fix Newman documents in detail is to break the monolith into smaller, independent services. Each service owns one bounded responsibility. Each service has its own data, its own deploy cycle, its own ability to fail without bringing down everything else. The team that owns the service is the team that ships the service. Coordination across teams happens through stable interfaces, not through a shared codebase. Newman is explicit that microservices are not always better. They are better only past the threshold where the monolith starts costing more than the coordination overhead of microservices does. The cost is real. You don't refactor for free. The reason teams do it anyway is that the cost of *not* refactoring eventually exceeds the cost of refactoring, and the people who refused to refactor end up burned out, behind, or replaced. You crossed the threshold a long time ago. You haven't refactored. The cost has been showing up as your tiredness. ## What Conway's Law explained in 1968 Mel Conway's 1968 observation, which I covered in [the AI post](https://www.unstuckwithmolly.com/writing/ai-wont-fix-structural-rot), applies twice over here. "Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization's communication structure." The shape of your software mirrors the shape of your team. If your team is a monolith — one person making every decision — your software will be a monolith, by Conway's Law, even if you tried to architect it otherwise. If your team is composed of small, autonomous units with clear interfaces, your software will move toward microservices on its own. This is the part senior operators usually miss. You can't refactor your codebase to microservices while still running your operation as a monolith. The codebase will fight you. The team will fight you. The org chart will fight you. The architecture will pull back toward the shape of the org, every quarter, until the org changes. The implication is uncomfortable. Refactoring your operation is the upstream move. Your engineering org has been trying to ship microservices on a monolithic management structure. They've been losing because Conway told them in 1968 that they would. You are the load-bearing wall. ![Founder intent decaying into chaos through a communication bottleneck.](https://cdn.marblism.com/7Ohab5MJumB.webp) ## What John Gall warned in 1975 In 1975 a pediatrician named John Gall published an unusual little book called *Systemantics: How Systems Work and Especially How They Fail*. The book is mostly out of print. The single sentence inside it has a name and is quoted in every serious book on systems engineering ever since. "A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system." That is Gall's Law. Every complex system that functions today started as a simple system that functioned. Software. Cities. Languages. Companies. Ecosystems. The pattern is universal, because complexity that wasn't earned through evolution from a simpler version doesn't have the structural integrity to hold itself together. What Gall was warning about, specifically, was top-down redesign. Senior operators love top-down redesign. They sit in a Saturday off-site, draw up the new org chart, redefine the roles, redistribute the responsibilities, and announce the new operating model on Monday. Six months later, the new operating model has not produced the promised gains. The team is more confused than before. The senior operator concludes the team is the problem. The team is not the problem. Gall's Law is the problem. The new operating model was designed from scratch and could not work, because complex working systems only evolve from simple working systems. The implication for your monolith refactor is specific. You cannot fix this with a Saturday off-site. You can only fix it by isolating one small piece of your monolithic responsibility, building a working system around just that piece, watching it work for three months, then doing the same with the next piece. Iterative refactoring. Six pieces in 18 months. Not six pieces in one quarter, in one swing. The senior operators who try to do it in one swing fail. The senior operators who do it iteratively succeed. The science is forty years old. The pattern still holds. ## Three pieces to start refactoring You don't fix this with a reorg. You fix it with three iterative moves over the next 90 days. **1. Identify the heaviest dependency on you.** Look at the last 30 days of Slack pings, escalations, and decisions that came to your inbox. Find the category that came up most often. That's the heaviest dependency. It might be pricing exceptions. It might be hiring approvals. It might be customer escalations. The category itself is the diagnostic. Most senior operators discover the heaviest dependency is something they have never tried to systemize because they are too good at it personally. **2. Build the smallest working system that absorbs it.** This is the Gall move. The system has to be simple. It has to actually work. It has to replace your involvement, not augment it. A one-page decision rubric. A weekly meeting where the decision happens without you. A delegated owner with the authority and a single page of guidance. Run it for two weeks. Watch what breaks. Fix the breakage at the system level. The first piece always takes longer than you think. The second one takes half as long. By the sixth piece, the refactor is faster than the work it's replacing. **3. Refuse to absorb regressions back into the monolith.** This is the rule senior operators break the most. The new system fails on a Tuesday. Someone pings you at 4pm asking for the override. Your reflex says yes. The system collapses back into the monolith, because the monolith was running on your reflex. The right answer is to fix the system at the system level, on Wednesday morning, instead of running the override on Tuesday afternoon. Most operators don't have the patience to hold this line. The ones who do, refactor. The ones who don't, stay tired. If you want a second voice in the room while you refactor — someone who has watched the pattern across operations and can tell you which dependency to tackle first — that's exactly what a [6-Week Build Partnership](https://www.unstuckwithmolly.com/work-with-me/build-partnership) is. ![Disassembling a monolithic business into organized microservices to fix structural bottlenecks.](https://cdn.marblism.com/JpGy7hrma8Z.webp) ## The reframe You are not a uniquely talented founder whose presence is required for the work to happen. You are the load-bearing wall in a monolithic system that you built before you knew it would scale this far, and the system has now scaled past the threshold where the monolith was efficient, and you are absorbing the cost personally because the structural cost is invisible until your body starts billing you for it. Newman has been documenting how software teams refactor this pattern since 2014. Conway named it in 1968. Gall warned us about top-down redesigns in 1975. You don't need a smarter operating model. You need an iterative, six-piece, 18-month refactor of one heavy dependency at a time, starting this quarter. Pick the heaviest dependency. Build the smallest working system. Hold the line. The monolith you built is the monolith you can refactor. It just takes the same patience refactoring software has always taken. ![Visualizing the shift from a burnt-out operator to a strategic owner through automated infrastructure.](https://cdn.marblism.com/ewligrsriIG.webp) ## Sources - [Sam Newman, *Building Microservices: Designing Fine-Grained Systems* (2nd edition, 2021)](https://www.oreilly.com/library/view/building-microservices-2nd/9781492034018/) — the canonical reference; chapters 1-3 on when monoliths break and how the refactor pattern works - [Martin Fowler & James Lewis, "Microservices" (martinfowler.com, March 2014)](https://martinfowler.com/articles/microservices.html) — the foundational article that named the pattern - [John Gall, *Systemantics: How Systems Work and Especially How They Fail* (1975)](https://www.goodreads.com/book/show/167701.Systemantics) — out of print but widely cited; the source of Gall's Law - [Mel Conway, "How Do Committees Invent?" (*Datamation*, April 1968)](https://www.melconway.com/Home/Committees_Paper.html) — the original Conway's Law paper, hosted by Conway ## About the Author Molly Shelestak is a Build Partner for Side-Project Shippers. With 20+ years in tech — from Google to Heap to Contentsquare — she helps senior tech employees stop tinkering and actually ship their side projects in 6 weeks. ## Related - [Decision Debt Is Why You're Tired](https://www.unstuckwithmolly.com/writing/decision-debt) - [Refactoring Legacy Success](https://www.unstuckwithmolly.com/writing/refactoring-legacy-success-systems) - [Systems for the Unreliable Human](https://www.unstuckwithmolly.com/writing/systems-for-unreliable-human) - [Work With Me](https://www.unstuckwithmolly.com/work-with-me)