Your monolith might be doing more for your business than you think
A monolith acts as an implicit anvil of alignment: a self-contained set of code, tests, data models, and ci/cd pipelines all wrapped up in a single deployable unit. This conceptual “box” of functionality is easy to hold in our minds as systems thinkers, and suggesting carving it into smaller “boxes” seems easy at first. In practice — across many clients we’ve advised — it is fraught with hidden complexity.
This challenge is not purely technical. It’s an organizational problem wearing a technical disguise. When you split a monolith, you’re not just dividing code; you’re dividing knowledge, ownership, and the informal communication patterns quietly formed around a shared codebase. That developer who always caught security issues in code review? They now only see 1/10th of the changes. The architect who understood the system’s performance characteristics? They are now juggling dozens of black boxes, each with its own operational mysteries.
Consider what actually happens in organizations that successfully operate microservices at scale: they don’t eliminate coordination costs — they formalize them. They invest heavily in platform teams, service mesh infrastructure, distributed tracing, centralized logging, and entire departments dedicated to maintaining what the monolith gave them for free: a shared understanding of how the system works. Companies like Netflix, Amazon, and Spotify didn’t succeed with microservices because they eliminated complexity; they succeeded because they could afford to manage it.
Your monolith might be frustrating. It might feel “slow”. It might even be genuinely hitting technical limits. But it's also doing invisible work that won't reveal itself until it's gone.
In the sections that follow, we'll explore exactly what that invisible work entails, why the costs of losing it are so often underestimated, and most importantly, how to determine whether your organization is truly ready to replace the implicit alignment of a monolith with something more deliberate. We'll examine the middle ground that many overlook, and provide a framework for leaders to navigate this critical architectural decision—one that has as much to do with your org chart as it does with your system design.
The monolith isn't just code. It's an organizational alloy. And before you dissolve it, you'd better understand what's been holding you together.
The monolith as a forcing function for alignment
Our team started calling this phenomenon the anvil of alignment thanks to Joel Helbling, who observed that “a healthy monolith behaves like a failing test for organizational cohesion — nothing ships until disagreements are resolved.”
In a monolithic system, all components — data model, deployment mechanisms, operational code — are deployed as a single unit. The system’s state is assumed to be atomic, indivisible. This inherent unity creates what we at Test Double have come to recognize as “constructive friction”: disagreements and misalignments within the organization — whether about terminology, abstractions, or fundamental concepts — must be resolved for anything to ship. The code simply won’t run unless you do.
Joel’s insight emerged from watching teams struggle with decomposition efforts — not because they lacked skill, but because they underestimated what their monolith was quietly accomplishing.
This resolution often happens implicitly, almost invisibly, as developers translate between different domain languages to make the system cohere. That moment when the payments team and the inventory team realize they’re using “Order” to mean different things? In a monolith, they have to hash it out. That architectural debate about whether “User” preferences belong in the user service or the settings services? The monolith makes it moot — it all deploys together anyway.
The monolith, therefore, acts as an unexpected organizational asset: it enforces human communication and alignment that might otherwise be overlooked. It’s a forcing function that operates at compile time, at code review, at deployment — continuously pushing teams toward shared understanding.
Just as code won’t compile with syntax errors, teams can’t ship with conceptual misalignments. The monolith enforces organizational “type checking” — ensuring that when the payments team’s “Order” meets the inventory team’s “Order”, they’re actually compatible types, not just similar-sounding abstractions.
When you move to microservices, you lose this forcing function. Teams can now maintain their own definitions of “Order” in their respective services. They can deploy independently, iterate in isolation, and build their own perfect little kingdoms of code. This feels like freedom — and it is, to a degree — but it is also the freedom to drift apart.
We’ve seen this pattern repeatedly in practice:
- Domain drift begins: teams embrace microservices and each develops slightly different interpretations of domain objects
- Translation layers proliferate: domain drift creates friction of the wrong kind — instead of forcing alignment, it forces translation layers between services
- Service ownership emerges: teams compensate by creating clear “service owners”, but this increases bus factor and creates information silos that may not have previously existed
- Knowledge walks out the door: when those owners inevitably leave the organization, they take their understanding with them, leaving gaps in knowledge
- Coordination costs compound: the result is further increased collaboration costs required to maintain any shared understanding
What begins as an effort to reduce coordination overhead becomes a Byzantine network of service contracts, translation layers, and tribal knowledge.
So why does this keep happening?
"We didn't really address the root cause of how we got into that messy situation in the first place. This looks like a technical decision that is really very much a people decision and we can't divorce the two."
– Steve Jackson
Steve’s experience echoes what we see time and again: teams focus on the technical mechanics of splitting services while missing the human dynamics that created their problems. The monolith wasn’t the source of organizational dysfunction — it was the structure that was compensating for it. Remove the monolith without addressing the underlying organizational issues, and you’ve simply distributed your dysfunction across a network of services.
That said, monoliths aren’t magic. The same forcing function that drives alignment can also create bottlenecks, political battles over shared resources, and the dreaded “merge hell” that keeps developers up at night. But here’s what we’ve observed across dozens of decomposition efforts: organizations rarely appreciate what the monolith was doing for them until they’ve lost it.
The irony is striking (pun intended): we break apart monoliths to give teams autonomy, then spend enormous effort building processes, tools, and governance structures to coordinate those autonomous teams. We trade implicit alignment for explicit orchestration — and often find ourselves longing for the simplicity we left behind.
So if monoliths provide this valuable organizational alignment, why do so many companies rush to dismantle them? The answer lies in a fundamental misunderstanding of what problems microservices actually solve — and more critically, what new problems they create.
To be clear: microservices can be the right choice when you have genuinely different scaling needs, clear domain boundaries, and the organizational maturity to manage distributed complexity. Amazon’s transformation offers the canonical example of getting this right. Jeff Bezos mandated that every internal service be built as if it were a public-facing product that could be sold externally. This mission—building services good enough to sell—became their new forcing function for alignment, replacing what the monolith had provided. Every team had to think beyond their immediate needs to consider how their service would work for external customers.
However, most teams aren’t working at Amazon Scale and are frequently lacking a mission strong enough to replace the anvil. Without that replacement forcing function, the results look very different:
“One Fortune 500 company I worked with was moving from a monolith to microservices. They had failed to do this 3 times, finally bringing in outside help after they fired the latest CTO over it. It was an absolute beast to accomplish and left many senior leaders in the dust.”
– Jonathon Baugh
Three attempts. Three failures. A CTO’s career. This isn’t an outlier story either — it’s disturbingly common. The hidden costs of dismantling your monolith go far beyond the technical complexity of the migration itself. They strike at the very heart of how your organization functions, communicates, and delivers value.
Let’s examine what actually happens when you remove the anvil.
The hidden costs of dismantling your monolith
The loss of implicit alignment
When you break apart a monolith, you lose this natural forcing function for organizational cohesion. Without a single codebase that must compile and deploy together, disagreements can proliferate across services unchecked. Teams that once had to resolve their differences before shipping can now paper over them with API contracts and translation layers.
That “some other way” rarely materializes organically. The monolith was, in fact, a governance model disguised as an architecture — it ensured continuity and acted as a de facto managing body, keeping everything copacetic without anyone having to think about it. Remove it, and suddenly you need explicit processes, committees, standards bodies, and architecture review boards. You’ve traded one form of complexity for another, much more bureaucratic one.
The human and organizational toll of shifting to microservices
The journey from monolith to microservices exacts a steep organizational price that goes beyond technical challenges. Organizations often start this journey considering only the technology, overlooking the cascade of changes required: governance models need restructuring, reporting hierarchies (which may not have even existed) need to be created or realigned, recruiting strategies need updating (suddenly, you need distributed systems experts), cost allocation becomes cryptic, and most critically, delivery schedules extend far beyond initial estimates.
When organizations embark on microservices migrations without understanding these ripple effects, the pattern is predictable: multiple false starts, leadership turnover, and years of disruption. The technical debt isn’t just in the code — it’s in the organizational trauma, lost institutional knowledge, and eroded trust between engineering and business stakeholders.
"Shipping your org chart" (Conway's Law)
I’ve watched this happen repeatedly: companies don’t create microservices, they create architectural portraits of their dysfunctions. Every organizational silo becomes a service, every communication breakdown becomes an API boundary. They’re not solving problems— they’re cementing them in code.
Conway's Law tells us that organizations design systems which mirror their communication structures. Without first addressing organizational dysfunction, microservices simply codify existing problems into architecture. The awkward handoffs between teams become network boundaries. The unresolved disagreements become incompatible data models. What were once awkward conversations become failed API calls and pager-duty alerts at 3 AM.
"I’ve seen a multi-billion dollar business running on core software maintained with eight people. How? They could write a stored procedure that updated everything in one go. If they ‘modernized’ to microservices, their development costs would increase by orders of magnitude — 10x to 100x."
– Steve Jackson
Eight people. Multi-billion dollar business. Every change is immediately applied everywhere. The simplicity is almost beautiful — and completely incompatible with the microservices dream.
Increased operational complexity & the debugging tax
While a monolith’s operational complexity grows predictably with size, microservices introduce non-linear complexity from day one. Debugging in a monolith means looking at one codebase, one set of logs, one deployment. Debugging microservices involves correlating logs across many services, understanding retry logic and circuit breakers, and often coordinating communications with multiple teams just to trace a single request.
"Introducing the network boundary adds a lot of problems. They're all solvable problems, but I find that it is rarely fully accounted for ahead of time... I see lots of data duplication across microservices being like, 'oh, eventually it'll be the source of truth.' But then years later, it's like it never quite got across the finish line."
– Patrick Brown
The phrase — “eventually it’ll be the source of truth” — should send chills down any architect’s spine. It’s the distributed systems equivalent of “we’ll refactor it later”.
The compounding maintenance burden
This one tends to sneak up on most organizations: maintenance doesn’t distribute, it multiplies.
"A library upgrade affects 18 services as opposed to one... One person can hold the pager on a monolith, but once you have 30, 40, 50 services, you probably need more than one person holding the pager. And all of a sudden you're paying engineers to be available at three o'clock in the morning that you didn't have to pay before."
– Steve Jackson
This isn’t just about money either—though the on-call costs alone can be staggering. It’s about cognitive load. Every service needs monitoring, alerting, documentation, and runbooks. Every service interaction needs error handling, retry logic, timeout configuration. The surface area for failure expands exponentially.
The broken promise of velocity
Perhaps the cruelest cost is the betrayal of expectations. Engineering teams often sell microservices with promises of quicker feature delivery and improved agility.
But that agility often does not materialize. Instead, teams find themselves rebuilding functionality that worked fine in the monolith, untangling shared dependencies, and discovering that the “cleanly separated” services share more business logic than anyone anticipated. The promised land of independent deployments becomes a minefield of coordinated releases.
These hidden costs compound over time, creating a weight that many organizations suddenly find unbearable. So how do you navigate this treacherous terrain? How do you know if your organization is truly ready to remove the anvil? Let’s explore the wisdom gathered from those who’ve made the journey — both successfully and otherwise.
Navigating the architectural divide: Wisdom for leaders
For senior technical leaders, the decision to re-architect is strategic, not merely technical. Our collective experience highlights several key considerations:
Why breaking up your monolith is a business decision, not a technical one
Before considering how to break up a monolith, thoroughly explore the why from a business perspective. Too often starting with the how leads to a focus on the technical aspects, turning it into a purely technical exercise that delivers no real business value.
Architectural decisions are business decisions with technical constraints and ramifications, not the other way around. The most compelling technical architecture means nothing if it doesn't serve business needs. When organizations cite recruiting or team engagement as drivers for microservices adoption, they're often treating symptoms rather than causes. If your architecture makes it hard to attract or retain talent, that's a signal to examine what's creating friction—not a mandate to rebuild your entire system.
Understand your organizational readiness to break up a monolith
A move to microservices requires a fundamentally different kind of company — one with new communication structures, cultural norms, and operational maturity. Before you start drawing service boundaries, assess whether your organization is prepared for this cultural shift.
"When resolution and alignment now must be mediated through new forms, structures, regulations, policies, permissions from other parts of the organization … this will be experienced by people within the organization as a significant shift, and could even be perceived as a change in the company’s culture.”
– Joel Helbling
The informal hallway conversations that resolved conflicts in your monolithic world? They become formal API contracts. The quick slack message to coordinate a deployment? Now it is a service mesh configuration that requires careful orchestration across teams. If your organization thrives on informality and rapid pivots, microservices might feel like putting training wheels on a racing bike.
Explore the middle ground
Full microservices aren't the only answer. Before you commit to complete decomposition, consider modularization within your monolith. Tools like Packwerk can help define clear boundaries and code ownership without the operational overhead of distributed systems, but we also need to have an awareness of the impact of modularity.
The boundaries that make sense for code organization rarely align with the boundaries that make sense for service decomposition. Use modularization as a learning exercise, not a blueprint.
Start with marketable slices
If decomposition is justified, start small and take an incremental approach. A new, independent product that you could actually sell provides natural forcing functions for clear boundaries. It’s far easier to avoid coupling when you’re building something genuinely new rather than trying to extract something deeply embedded in existing systems. If you can’t identify a marketable slice that stands alone, that’s often a signal that your services won’t be as independent as you think.
Consider the irreversibility
Once you’ve distributed your system, your data, and most importantly your teams, there’s rarely a path back. The organizational muscle memory of working with a monolith atrophies quickly. The shared context dissipates. The tribal knowledge scatters. This is an irreversible decision that may seem attractive today but you’ll have to live with for years—organizations can’t afford to swap architectural approaches every couple of years.
If you’re small enough to easily coordinate, you probably don’t need microservices. If you’re large enough to need them, the migration itself might be beyond your capacity.
The mission is your new anvil
If you remove the monolith as your forcing function for alignment, you need something equally powerful to replace it. The most successful transformations we’ve seen replace architectural alignment with missional alignment.
As with Amazon’s approach mentioned earlier, a sufficiently strong mission can become your new anvil. But we should take note of what made it work: the mission had teeth. “Build it as if you could sell it externally” wasn’t aspirational—it was a mandate with a measurable outcome. Teams couldn’t hide behind internal excuses or take shortcuts because the standard was external-market-ready quality.
Most organizations attempt microservices without establishing any replacement forcing function. They remove architectural constraints (shared deployment) without introducing an organizational constraint (a shared mission). The result? Teams drift apart, each optimizing locally while the system degrades globally.
Without that mission, you’re not transforming your architecture — you’re just scattering it.
Understanding your organizational alloy
Your codebase — monolithic or distributed — is the crystallized knowledge of every decision, compromise, and hard-won lesson your organization has learned. It knows why that weird validation exists (because of that one customer incident in 2019). It knows why those two seemingly unrelated modules talk to each other (because of an acquisition in 2021). It embodies institutional memory that no documentation captures and no single person fully understands.
The choice between monolith and microservices isn’t just about technology — it’s about understanding what holds your organization together. Your monolith may be doing more invisible work than you realize, quietly enforcing the collaboration and shared understanding that makes your business function.
Before dismantling your monolith, ask yourself:
- Do we have a mission strong enough to replace our monolith’s implicit alignment? Without the forcing function of shared deployment, what will drive teams to resolve their differences?
- Are we solving a business problem or running from technical debt? Desire to decompose the monolith is often a signal that you are avoiding things that deserve attention.
- Do we have the operational maturity to manage 10x the complexity? Distributed systems require distributed thinking, and not every organization is ready for that cognitive leap.
- What is the cost of this transformation? Is your organization resilient enough to absorb the kind of disruption that emerges?
The irony of our industry’s march toward microservices is that we’re often solving the wrong problem. We break apart systems to give teams autonomy, then spend millions trying to coordinate those autonomous teams. We distribute our architecture to increase velocity, then watch our delivery slow to a crawl under the weight of the orchestration overhead.
The monolith isn’t your enemy — confusion about what it’s doing for you is.
While the appeal of a modern microservices architecture is strong (and valid), the most successful transformations we’ve observed have leaders who take a thoughtful, human-centric approach that respects the monolith’s role as the anvil of alignment. They consider the full spectrum of costs — technical, organizational, and human — before making irreversible architecture decisions.
Your mission, should you choose to accept it, is to understand the unique alloy that binds your organization together and ensure that whatever architecture you choose — monolithic, microservices, or something in between — strengthens rather than weakens those critical bonds.
The anvil of alignment doesn’t have to be your monolith. But before you remove it from your organization's forge, make sure you have something equally solid to replace it. Because without that anvil, you’re not shaping your future — you’re just hammering in the dark.
This article reflects lessons learned from many migrations our team has led. Special thanks to Joel Helbling (anvil framing), Steve Jackson (ops & pager calculus), Patrick Brown (duplication patterns), and Jonathon Baugh (business strategy alignment & organizational readiness).
