How Well-Intentioned Integration Can Undermine Modern Architecture and Team Autonomy
8 min read
Summary (TL;DR)
This story illustrates what happens when a company designed around microservices and autonomous teams is integrated into a larger organization built on monolithic systems and centralized management.
LegacyTech (the acquirer) operates with large, consistent teams managed through a fixed span-of-control model, with one engineering manager overseeing eight software engineers being the target.
AgileWorks (the acquired company) evolved over a decade into small, cross-functional, domain-aligned microservice teams, each independently deployable and self-managing.
During the final stages of integration, AgileWorks’ structure was eventually forced into LegacyTech’s model in the name of “consistency.” What seemed efficient on paper can lead to architectural regression, slower delivery, blurred ownership, and increased coordination overhead.
The misunderstanding, such as questioning why AgileWorks had “so many SKUs or products”, stemmed from not recognizing that each SKU or product represented a bounded context and independently deployable domain, the hallmark of microservice design.
The result: a collision between two successful systems optimized for different goals, independence vs. uniformity.
The lesson is clear:
If architecture and structure drift apart, performance can erode. You can’t integrate autonomy into hierarchy without changing both.
Before enforcing structural consistency, leaders must understand the organizational DNA that made the acquired system successful. Otherwise, the very advantages that justified the acquisition are the first to disappear.
Opening Reflection
Having been part of numerous acquisitions and technical due diligence efforts throughout my career, I’ve observed familiar patterns emerge when one company merges with another. Leadership often evaluates the architecture, technology stack, team skills, and organizational structure to assess fit and value.
Having observed these patterns across many organizations’ transformation journeys, I’ve seen how integration decisions can either reinforce or erode what made an acquisition valuable. But in a recent acquisition I observed, something different unfolded; the integration process risks undoing the very capabilities that had made the acquired organization successful. Its architecture and team design, once aligned for speed and autonomy, were being reshaped in ways that constrained both.
A large, established technology company, let’s call it LegacyTech, acquired a smaller, fast-moving company, AgileWorks.
LegacyTech is a successful and stable company with products that have stood the test of time, built on an architecture that is still largely monolithic. It has begun investing in modernization and technology transformation. However, LegacyTech’s system continued to prioritize control, reliability, and predictability.
Its teams are large, their processes consistent, and their management model straightforward: one engineering manager for every six to ten software engineers (eight being the target), one product manager per team, and one operating rhythm that keeps everything aligned.
AgileWorks, by contrast, had spent nearly a decade transforming itself. Through persistent experimentation, modernization, learning, and automation, it evolved from a monolithic architecture into a predominantly microservice-based one. Its teams were small, domain-aligned, and self-managing, each owning its own domain or set of subdomains, data, and deployments. They could move quickly, deliver independently, and continuously improve without waiting for managerial approvals.
AgileWorks maintained a span-of-control target of five direct reports per Engineering Manager. However, EMs did not oversee delivery teams or manage the engineers within them; their direct reports were distributed across multiple teams. Each delivery team instead had a dedicated Agile Leader responsible for its performance and health.
By the time the acquisition happened, AgileWorks had become everything many companies aspire to be: autonomous, modern, and fast. And that’s when LegacyTech stepped in to acquire them.
The Integration Challenge
After the acquisition, LegacyTech began integrating the smaller company’s people and processes into its larger framework. The goal was clear: consistency.
Leadership required all teams, whether legacy or newly acquired, to adhere to the same structure, reporting lines, career development framework, and management model.
So, AgileWorks’ small, autonomous domain teams were expected to merge into LegacyTech’s span-of-control structure. Each team was restructured to fit a standardized span-of-control model, regardless of its domain boundaries or architectural design.
On paper, it looked rational, efficient, uniform, and fair. But structure doesn’t just describe how people work; it shapes how people work.
When Structure Shapes the System
There’s a principle known as Conway’s Law, which says:
“Organizations design systems that mirror their communication structures.”
At AgileWorks, small, autonomous teams built and deployed small, autonomous services.
At LegacyTech, large, coordinated teams built large, coordinated systems.
When the two merged, the system began to change, not through code, but through structure. Teams that once released independently now had to coordinate across domains, with engineering managers juggling competing priorities across multiple queues.
Over time, the architecture could start to mirror the new structure, slower, more coupled, and increasingly dependent on synchronization rather than flow.
This wasn’t failure but cause and effect, the predictable outcome of two systems built to operate by different rules.
Why the “Too Many SKUs” Question Misses the Point
As integration continued, a question surfaced from LegacyTech’s leaders:
“Why does AgileWorks have so many SKUs?”
From the outside, it appeared excessive or confusing. From the inside, it reflected transformation and maturity. Each ‘SKU’ represented a bounded context, a product or domain with its own stack, team, and flow of value.
That’s the natural outcome of a microservice architecture. As Dave Farley describes it, a microservice is small, focused on one task, aligned with a bounded context, autonomous, independently deployable, and loosely coupled.
The independence of those services is the entire point. It enables small, decoupled teams to work in parallel, which DORA research repeatedly shows as a leading predictor of delivery performance:
“Smaller, autonomous teams build better software faster.”
So, what looked to LegacyTech like “too many SKUs” was actually a reflection of architectural evolution, the visible signature of independence and scale.
The Hidden Cost of Consistency
Consistency is valuable. It brings clarity, career alignment, predictability, and a sense of order that scales well.
However, when consistency overlooks architectural context, it can quietly undermine the very advantages an acquisition was intended to bring.
By restructuring domain-aligned teams under broader spans of control, LegacyTech risked recentralizing what had been purposefully decentralized.
From the outside, things still appear aligned. Inside, work begins to queue, decisions bottleneck, and delivery can erode. What seems to be an efficient integration can quietly become architectural regression.
Leadership Context and Legacy Mindsets
During integration discussions, LegacyTech’s leaders emphasized the need for consistency. One executive put it plainly:
“We can’t redesign all of our teams to look like the company we acquired, so we’ll redesign theirs to look like ours.” From their perspective, it made sense. LegacyTech had twenty or more teams; AgileWorks had eleven.
Why redesign twenty when you can standardize eleven? And the twenty monolithic teams couldn’t fit within AgileWorks’ model. LegacyTech’s teams operated on a one-to-one structure, with one engineering manager paired with one product manager, both of whom oversaw a single, unified codebase.
Under the hybrid model introduced by AgileWorks’ leader, one engineering manager now manages two or three domains, each with its own Product Manager. The design preserved domain alignment but blurred accountability and added coordination overhead.
Engineering Managers are now also held accountable for delivery and team performance as part of this shift, which removed the Agile Leader role from teams. It was a compromise, an attempt to preserve domain alignment while satisfying span-of-control requirements, with eight software engineers reporting to one manager. However, this consolidation also increased cognitive and operational load for managers, blurred accountability, and made the model harder for others to understand.
Beneath these decisions lay something deeper: a legacy mindset forged in years of success managing monolithic systems. Their definition of success came from environments where control, coordination, and uniformity produced predictability.
They hadn’t yet led in a distributed, microservices-based domain architecture, one where success depends on small, autonomous teams empowered to make local decisions and deploy independently, the very capabilities that drive speed and resilience.
It wasn’t resistance. It was familiarity. Leadership was applying what had always worked, unaware that the system underneath was fundamentally different. And that’s the real tension in most integrations: the experience that once guaranteed success can become the very thing that slows adaptation.
The Diligence Gap
This mismatch usually starts long before integration.
Traditional due diligence focuses on technology assets, the stack, scalability, and delivery practices. What it often overlooks is organizational architecture, how teams are structured to support that system.
AgileWorks’ success wasn’t just in its code. It was in how its teams worked: decoupled, autonomous, and aligned with their architecture.
When that alignment is ignored, integration can dismantle the very system that made the technology valuable in the first place.
You can acquire the product, but if you don’t understand the system that built it, you risk changing both, usually not for the better.
The Crossroads
As integration continued, the senior leader at AgileWorks consolidated software engineers by their existing domains under a single engineering manager. It was a hybrid attempt, a way to meet span-of-control targets while keeping domain boundaries intact.
Yet this structure puzzled many senior leaders, who struggled to understand how autonomy could coexist with standardization.The organization soon faced a pivotal choice:
Should it preserve the hybrid model, allowing domain teams to remain somewhat autonomous under shared leadership, or fully merge everything into one standardized structure?
Each path carried clear trade-offs. Respecting autonomy required leaders to adopt new management patterns and rethink the Engineering Manager role itself. Full consolidation simplified reporting, standardized roles, but re-coupled systems that were purposefully independent.
Whichever path they chose, one thing became clear:
The future depended not on process, but on leadership understanding.
Because structure follows mindset, and mindset follows experience.
Closing Reflection
This isn’t a story about who was right or wrong, but instead a story about what happens when architecture and structure drift apart.
When a large, monolithic company acquires a smaller, microservice-architected one, success depends not only on integrating tools and people, but also on integrating understanding.
LegacyTech didn’t fail; it followed its playbook. AgileWorks didn’t resist; it followed its principles. Both were right in their own context.
The lesson for any organization is simple: Before enforcing structural consistency, understand the architecture and operating model you’re inheriting.
Because when you acquire an architecture, you also acquire the organizational DNA that built it. Change one without understanding the other, and you may find the system changes on its own, just not in the direction you intended.
Change one without understanding the other, and you may find the system changes on its own, just not in the direction you intended.
Poking Holes
I invite your perspective on my posts. What are your thoughts?
Let’s talk: phil.clark@rethinkyourunderstanding.com