How Well-Intentioned Integration Can Undermine Modern Architecture and Team Autonomy
11 min read
Having been part of numerous acquisitions and technical due diligence efforts throughout my career, I have observed familiar patterns in mergers. Leadership evaluates architecture, the technology stack, team skills, and organizational structure to assess fit and value. I have seen how integration decisions can reinforce or erode what made an acquisition valuable.
In one recent integration, however, the process risked undoing the very capabilities that had made the acquired organization successful. Its architecture and team design, once aligned for speed and autonomy, were reshaped in ways that constrained both.
A large, established technology company, which I will call LegacyTech, acquired a smaller, fast-moving company, AgileWorks. LegacyTech’s architecture is still largely monolithic, shaped by years of prioritizing control, predictability, and reliability. Its teams are large, its operating rhythm consistent, and its management approach straightforward: one engineering manager for about eight engineers, one product manager per team, and a typical structure applied across the organization. Part of this structure reflected LegacyTech’s leadership instincts, and the other part reflected the very real need to standardize roles, expectations, and career frameworks across the combined company.
AgileWorks had spent nearly a decade transforming from a monolithic system into a microservices-based organization. Its teams were small, long-lived, cross-functional, and aligned to clearly defined domains and subdomains. Each team owned its services end to end, including logic, data, deployments, and the flow of value. They operated with local decision-making, shipped independently, and continuously improved without waiting for outside coordination.
At AgileWorks, engineering managers focused on people and career development rather than directing day-to-day delivery. Delivery teams included dedicated Agile leaders, product partners, technical leads, user experience, QA, and the skills required to deliver independently.
By the time of the acquisition, AgileWorks had become the kind of organization many aspire to be: fast, autonomous, and adaptable.
The Integration Challenge
After the acquisition, LegacyTech required all teams, both legacy and newly acquired, to adopt the same structure, reporting model, and span-of-control expectations. AgileWorks’ small, domain-aligned teams were reshaped to match LegacyTech’s organization. What seemed rational and efficient on paper quickly began influencing how work flowed in practice. Structure does not simply describe how people work. It defines how they work.
When Structure Shapes the System
Conway’s Law teaches that organizations design systems that mirror their communication structures.
At AgileWorks, small teams designed, built, and deployed small services. At LegacyTech, large teams built large systems. Both structures made sense in their respective architectures.
When the two companies merged, the system began to change, not because the code changed, but because the structure changed. Teams that once released independently now had to coordinate across domains. Engineering managers balanced conflicting priorities across multiple queues. Flow slowed. The architecture itself risked drifting toward a more coupled and synchronized model.
This was not personal or political. It was mechanics.
Understanding the Architectural Misalignment
LegacyTech was not wrong. It was simply optimized for a different world.
Its monolithic architecture enabled centralized decision-making, broad responsibilities, and larger teams. In that environment, consistency and uniform structures work well.
AgileWorks’ architecture required something different. It operated within a distributed microservice architecture with bounded contexts. Each service independently owns its logic, data, and deployment lifecycle. Because the architecture was modular, the teams were modular as well. Small teams were not a stylistic preference. They were a structural capability.
Seen through LegacyTech’s perspective, AgileWorks’ structure looked unfamiliar: more teams, fewer people per team, independent decisions, separate flows. Without curiosity about architectural context, autonomy can look like fragmentation.
Why the “Too Many SKUs” Question Misses the Point
As integration continued, a recurring question arose. “Why does AgileWorks have so many SKUs?”
To LegacyTech, the number seemed excessive. An SKU is simply an internal identifier for a product, but in AgileWorks’ system, each SKU represented a bounded context, a domain or subdomain with its own architecture, team, and flow of value.
This is the natural outcome of microservices. As Martin Fowler and Dave Farley describe them, microservices are small, autonomous, independently deployable, and aligned to a single, well-defined domain boundary. That was exactly how AgileWorks structured its system. Each SKU marked a clean separation of concerns, not a proliferation of products.
Microservices reduce dependency drag by allowing teams to work in parallel, which DORA research consistently shows is a predictor of higher performance. What LegacyTech viewed as unnecessary complexity was in fact a sign of architectural maturity.
The Hidden Cost of Consistency
Consistency creates clarity and predictability. It is appealing, especially in large organizations. But when consistency is applied without understanding architectural intent, it can silently erode the strengths the acquisition sought to preserve.
Reassigning domain-aligned teams into broader groups collapses boundaries that AgileWorks had intentionally kept separate. From the outside, the structure appears aligned. On the inside, queues form, decisions slow, and delivery suffers.
What appeared efficient became regression.
Leadership Context and Legacy Mindsets
LegacyTech’s leaders emphasized consistency across the combined organization. One executive summarized it plainly: “We cannot redesign all of our teams to match the company we acquired, so we will redesign theirs to match ours.” From their perspective, this was a practical decision.
With far more teams than AgileWorks, standardizing the smaller footprint seemed simpler and more efficient. AgileWorks’ leadership understood this dynamic well; it was the same approach they had used when integrating engineering teams during their own previous acquisitions.
LegacyTech’s desire for consistency created immediate pressure to reorganize AgileWorks’ teams. To meet these expectations while minimizing disruption, the AgileWorks department head adopted a phased hybrid approach.
Instead of dismantling domain boundaries outright, he grouped related subdomain teams under individual engineering managers until each manager had an average of eight software engineers in their hierarchy. This met LegacyTech’s span-of-control rules while protecting delivery continuity for committed roadmap work. Leadership and HR at LegacyTech formally approved the plan.
Although the plan satisfied the stated requirements, it did not align with how LegacyTech leaders mentally modeled team structure. They were accustomed to a one-engineering-manager-to-one-team pattern tied to a single codebase. Seeing multiple small subdomain teams grouped under a single engineering manager did not fit that worldview.
Despite backchannel conversations, no one approached the AgileWorks leader directly to understand why the hybrid structure existed or what it was designed to protect. Over time, this misunderstanding worked against him.
The original team design misunderstanding also set the stage for deeper structural changes. To eliminate ambiguity and fully align the organizations, AgileWorks was required to adopt LegacyTech’s management model. This meant removing the Agile Leader role from each team and shifting delivery responsibility directly to engineering managers.
The shift was more than procedural. It fundamentally redefined the role of the engineering manager at AgileWorks.
Engineering managers, who had previously focused on people development and coaching, were now accountable for day-to-day delivery, performance, coordination, and practice consistency. Their span of control increased from five to eight, requiring them to support two or sometimes three small subdomain teams, since most AgileWorks teams averaged three developers.
What had once been a role centered on enabling people quickly became one centered on directing delivery. The cognitive load increased, role boundaries blurred, and the structure that once allowed AgileWorks to move rapidly and independently became increasingly challenging to maintain.
What had once enabled flow and autonomy at the subdomain-scoped team level now introduced friction and confusion. These role changes did not remain at the organizational layer; they risked influencing how the architecture behaved.
This tension over roles and structure surfaced again in how leaders interpreted AgileWorks’ team sizes and scopes.
Team Design, Domain Thinking, and the Case for Larger Scopes
Misunderstanding also surfaced around team size and scope. AgileWorks had several small teams working within the same domain, which some LegacyTech leaders interpreted as fragmentation. The issue was not fragmentation. It was a missed opportunity to ask why the structure existed in the first place.
In Transformed, Marty Cagan describes a common pitfall in product transformations. Organizations create too many narrow teams that each own a thin slice of the product. These slices are too small to deliver real outcomes independently. Handoffs increase, dependencies grow, and accountability becomes unclear.
Cagan recommends not necessarily building bigger teams. It is to give small teams a larger scope. Increase what a team owns, not the number of people on it.
AgileWorks followed this principle. Drawing from Domain-Driven Design, Separation of Concerns, microservices, and distributed systems patterns:
- Domains aligned to product portfolios
- Subdomains aligned to individual products or major capabilities
- Each team owned a full subdomain end-to-end
This structure gave every team deep domain expertise, architectural control, independent deployment capability, and clear ownership of outcomes. Small teams did not mean fragmented teams. They owned coherent, customer-facing capabilities aligned with product portfolios.
LegacyTech’s model relied on broader functional groupings within a monolithic system. Engineers were often reassigned to different teams based on capacity needs. That model works in monoliths but does not map cleanly to distributed systems where autonomy and boundary clarity matter.
Curiosity would have bridged this gap. A simple question about how AgileWorks’ teams aligned to product portfolios and subdomains might have made the structure clear and its purpose obvious.
When Experience Replaces Curiosity
A moment shared with me later captured the tension clearly. A long-tenured manager walked a LegacyTech senior leader through AgileWorks’ architecture and team structure. The leader responded, “I have been doing this for thirty years, and my playbook works. I do not understand how your organization works, nor do I care to at this point.”
This approach is a familiar leadership pattern. Playbooks shaped by years of success do not always map to new architectural contexts. One size does not fit all. Playbooks can be adjusted to match context and practices. Experience is valuable, but experience without curiosity becomes limiting. And in distributed systems, where autonomy and domain clarity matter, it can quietly become destructive.
When Naming Becomes a Surrogate for Understanding
Another unexpected friction point involved team names. Years earlier, AgileWorks allowed teams to name themselves. They chose names like Red, Blue, and Green. These names were cultural, not architectural.
Inside the organization, each team was clearly mapped to its domain, products, and value stream. Ownership was unambiguous.
Yet some LegacyTech leaders found the names confusing. Some made jokes about them. They expected teams to be self-describing, named after products. Ironically, LegacyTech’s argument contradicted itself. It also had several teams name themselves after animals, terms, and cultural references. Labels alone did not reflect product alignment on either side.
Asking a simple question, “How do these team names map to your products and domains,” would have resolved everything.
The Diligence Gap
AgileWorks’ success came not only from its code but from how its teams worked: decoupled, autonomous, and aligned with their architecture.
Ignoring that alignment risks dismantling the system that created the capability value in the first place.
You can acquire the product and organization, but if you do not understand the system that built it, changing one without respecting the other often produces unintended consequences.
When Capacity Pressure Resurrects Old Patterns
Another difference emerged in how each organization responded to capacity pressure. AgileWorks designed its teams to be long-lived. Engineers rarely moved between teams, which allowed domain expertise, trust, and ownership to develop over time.
LegacyTech worked differently. At the end of major delivery cycles, leaders reassigned engineers wherever demand was highest. Teams functioned as resource pools, flexible and frequently reshuffled. Engineers did not always have a choice, and these moves were often framed as career opportunities.
When demand exceeds supply, leaders fall back on the operating model they trust. In larger, monolithic organizations, pooling and trading engineers across teams can work because the teams themselves are large and the domains broad. But in a distributed architecture with small, domain-aligned subdomain teams of three developers, this same practice can have a significant negative impact. Removing a single engineer destabilizes the team’s knowledge base, disrupts flow, and undermines the deep domain context those teams rely on.
When people become fungible, domains may become fungible as well. When domains become fungible, ownership becomes shallow. When ownership becomes shallow, flow slows, defects rise, and quality declines.
LegacyTech was not acting in bad faith. They were relying on a model that had worked in their environment. But AgileWorks required long-lived teams because its architecture depended on them. When capacity was tight, AgileWorks moved teams to the work, not individual team members.
Why Context and Choice Determine Team Design
Modern leadership provides many frameworks to draw from: Cagan, Kersten, Team Topologies, Agile, Lean, DevOps, Value Stream Management, Product Operating Models, Scrum, XP, and Kanban. Each offers value, but none is universally correct. Their effectiveness depends entirely on the context in which they are applied.
Some leaders prefer fewer teams with broader scopes. Others prefer many small, domain aligned teams. Both approaches can succeed. Both can fail. The difference is not the model itself but the architecture, constraints, and business environment it must support.
So the question is never which team model is better. The real question is which structure fits the architecture, flow constraints, and organizational realities of this moment in time.
And even more importantly, do leaders understand why a structure existed in the first place. Most team designs are not arbitrary. They reflect hard-earned lessons about architectural boundaries, flow of work, domain ownership, operational needs, and past failures.
Curiosity is what makes these choices effective. It separates meaningful alignment from surface-level consistency. Without curiosity, even well-meaning integration decisions can erase the very patterns that made a system successful.
Closing Reflection
Through curiosity, I came to understand why LegacyTech made its choices. They were not dismissing AgileWorks’ model. They were responding to their own context, constraints, and operating history. Their decisions made sense inside the environment they knew.
This is the point.
This is not a story about who was right or wrong. It is a story about what happens when architecture and structure drift apart. When a monolithic organization acquires a microservices-driven one, success depends not only on integrating people and tools, but also on integrating understanding.
When you acquire a product, you also acquire the organizational DNA that built it. Structure, practices, team design, flow, and architecture evolve together. Change one without respecting the other, and the system will reshape itself in ways you may not expect.
Alignment is powerful when it is guided by curiosity. Curiosity turns alignment from imposition into learning. And understanding becomes the bridge between two different worlds, trying to operate as one.
Sustainable integration is not about enforcing a single model, but about recognizing the strengths each system brings and understanding how to align them without erasing what makes them effective.
Poking Holes
I invite your perspective on my posts. What are your thoughts?
Let’s talk: phil.clark@rethinkyourunderstanding.com
Influences and Further Reading
Established ideas from modern software architecture, team design, and flow-based organizational practices inform this article. The concepts discussed draw on Domain-Driven Design, microservices and distributed systems principles, Team Topologies, the Flow Framework, DevOps and Lean thinking, and contemporary product operating models.
Notable contributors to these bodies of work include Eric Evans, Martin Fowler, Dave Farley, Manuel Pais, Matthew Skelton, Marty Cagan, and Mik Kersten, as well as research from the DORA community (Accelerate). Their work has shaped much of today’s understanding of how architecture, team structure, and organizational context interact to influence delivery performance and long-term success.