Read Time: 23 min
A long-form executive article on why post-acquisition value is lost when leaders consolidate before they understand the work
David Carneal | Digital Efficiency Consulting Group
I've been through more than a dozen acquisitions and mergers over the course of my career. A few were quiet enough that the outside world never blinked. Others reshuffled everything: systems, people, customer relationships, the whole organizational identity of the companies involved. Three of those integrations were mine to lead end to end, and all three finished ahead of schedule while exceeding the sales targets that were set before the deal closed.
I don't bring that up to take a bow. I bring it up because repetition changes how you see things. After enough acquisitions, the same script starts playing in different buildings with different logos. The same assumptions walk in through the front door. The same mistakes follow close behind. The same promises are made. The same surprises show up right on schedule. At some point, I stopped paying close attention to the transaction itself and started paying much closer attention to what happened after the ink dried, because that's where value gets protected, built on, or quietly handed over to someone's retrospective slide deck.
The word sitting at the center of that post-closing period is almost always synergy. It's one of those terms that arrives in the room already wearing a halo. Boards expect it. Investors price it in. Executives promise it. Integration teams are assembled to manufacture it. Nobody wants to be the person who raises a hand and says "I'm not sure about this synergy thing," because in theory, the word just means the combined organization will be worth more together than apart. There's nothing wrong with that as an objective. The problem is what it becomes in practice.
In practice, synergy becomes shorthand for consolidation. It becomes permission, sometimes enthusiastic permission, to combine departments, decommission systems, eliminate vendors, standardize processes, and cut positions before anyone has done the slower, quieter, considerably less glamorous work of understanding how the acquired business actually makes money. That's where the real trouble starts. Not with bad intentions. With impatience dressed up as urgency.
Organizations routinely spend months, and sometimes years, deciding whether to make a purchase. Attorneys, bankers, accountants, analysts, consultants, and senior executives all circle the transaction. Financials get examined. Risks get modeled. Contracts get inspected. Forecasts get challenged. Strategic fit gets debated in rooms with really nice catering. Millions of dollars get spent answering one question: should we buy this company?
Then the deal closes, and suddenly that same organization that demanded rigorous analysis before writing the check becomes remarkably comfortable making fundamental operational decisions in a matter of weeks. Systems get targeted for replacement. Departments get merged. Vendors get cut. Roles get labeled redundant. Everyone is moving. And because everyone is moving, it feels like progress.
Activity and progress are not the same thing.
Activity is easy to measure. A system can be shut down. A department can be combined. A position can be eliminated. A milestone can be marked complete. These things produce visible evidence that leadership is doing something, and visible action is often treated as proof that the deal is working. Improvement is different. It requires understanding. Consolidation can be forced by authority. Improvement has to be designed.
The Question Leadership Should Ask First
Before anyone approves a single integration initiative, I want them to sit with one question: what exactly did we buy?
The obvious answers are revenue, customers, products, intellectual property, geography, talent, contracts. Those answers aren't wrong. They're just incomplete, and the gap between what they capture and what they miss is where acquisitions quietly fall apart.
Revenue is the result of something. Customer loyalty is the result of something. Fast delivery, responsive service, accurate invoicing, dependable follow-through are all outcomes. Behind the financial performance sits a collection of processes, relationships, habits, judgment calls, workarounds, exceptions, and institutional memory that made the business worth buying in the first place. That collection is the real asset. Most integration plans treat it as background noise.
When leadership rushes into synergy, it focuses on what's visible and misses what's working. Executives can see the org chart. They know what things cost. What they typically don't know is how the work actually moves. Which approvals exist for reasons that aren't written down anywhere. Which customers require exceptions and why losing those exceptions would cost the company the account. Which employees are quietly preventing problems from ever reaching anyone who would have to explain them.
They don't know where the company is fragile.
And that lack of understanding doesn't slow decisions down. If anything, it speeds them up. When leaders can't see how the work flows, they default to what they can see quickly: headcount, software costs, vendor count, surface-level overlap. Making integration calls based only on what's visible is like buying a building for its income potential and immediately removing walls before you've figured out which ones are load-bearing. You might end up with a more open floor plan. You might also end up explaining to a structural engineer why there's a crack running across your investment.
I've watched leadership teams approve changes that made complete sense in a conference room and failed almost immediately in the real world. A duplicated role looked unnecessary, until the team discovered that person was managing customer-specific exceptions that corporate's standard process couldn't handle. A legacy system looked outdated, until someone realized it contained seven years of operational history that nobody had bothered to migrate. A manual approval step looked inefficient, until the team found out it existed because one product category had a failure rate that spiked whenever it got rushed. An expensive vendor looked like an easy cut, until the team learned that vendor was the reason a critical production line hadn't gone down in four years.
None of those things were accidents. They were the result of an organization learning, over time, how to protect itself and its customers from specific, well-understood risks. Leadership didn't know about those risks because leadership hadn't asked. And because leadership hadn't asked, leadership removed the protection.
This isn't an argument for preserving everything. Some processes deserve to be eliminated. Some systems are outdated. Some positions are redundant. The point is that leadership should understand what each thing does before deciding whether it deserves to survive. You can't improve what you haven't bothered to understand. And you can't understand a business by staring at its cost structure.
The Expensive Illusion of Speed
The pressure to move quickly after an acquisition is real, and I'm not pretending otherwise. Boards want updates. Investors expect visible progress. Executives need to demonstrate they're in control of the asset they just acquired. There are also decisions that genuinely need to happen fast, especially when customers, contracts, cash flow, or key employees are at risk.
But there's a difference between decisive leadership and impatient leadership, and that difference matters more during an integration than almost anywhere else. Decisive leadership moves fast where the facts are clear and the risks are understood. Impatient leadership moves fast because motion feels more responsible than uncertainty.
Synergy feeds the impatient version. It lets impatience sound strategic. A leader can stand in front of a board and say the organization is "moving aggressively to capture synergies" and the room will receive that as evidence of mature, disciplined leadership. What it often is, underneath the language, is an organization changing the work before it understands the work. Reducing cost before identifying value. Standardizing process before determining which process is actually better.
And here's the trap that makes it worse: the early numbers often look good.
If you consolidate a department, costs go down. If you eliminate a software platform, licensing expense drops. If you reduce vendors, procurement shows savings. These outcomes land clean on a spreadsheet and arrive fast enough to satisfy the pressure for visible results. The board nods. The slide looks great.
The costs that get created by those decisions show up later, wearing different labels. Customer response times slip. Rework climbs. Managers become bottlenecks because centralized decision-making can't move at the speed the customers expected. Good employees start updating their resumes. Sales teams spend more time managing apologies than closing business. None of that appears in the original synergy calculation. None of it gets attributed back to the decisions that caused it.
This is how organizations end up spending dollars chasing pennies.
They celebrate savings that are easy to count while absorbing losses that are harder to trace. The cost of slower decisions is invisible. The erosion of customer trust is invisible. The departure of a high-performing employee who saw what was happening and made other arrangements gets filed under "personnel issue," not "integration consequence."
By the time the damage is undeniable, the original decisions have faded from memory, the leaders who made them may have moved on, and the business is left managing a residue nobody can quite explain and everyone is quietly hoping someone else will fix.
What does the organization have at the end of that journey? Fewer systems. Fewer vendors. Fewer employees. A cleaner org chart. And possibly fewer customers, weaker trust, slower execution, and an operation that looks simpler from the executive floor but works considerably worse from the inside. That isn't synergy. That's accounting theater with an operational hangover.
What This Looks Like in Practice
Several years ago, I watched a multi-billion-dollar medical device organization acquire multiple specialized businesses. On paper, the strategy made sense. The acquired companies operated in related markets, served similar customer groups, and appeared to offer meaningful operational synergies.
Leadership entered the integration with aggressive timelines and ambitious goals. What was expected to take months stretched into years.
The problem wasn't technology. It wasn't employee resistance. It wasn't a lack of effort. The problem was that leadership never invested enough time understanding how the acquired businesses created value before deciding how they would be integrated.
The acquired companies were relatively small, employing dozens rather than hundreds. Because of that, many decisions were made from a distance. Corporate leaders focused on budgets, organizational structures, system consolidation, and cost reduction. The workflows that generated customer value received far less attention.
Division leaders repeatedly raised concerns. They understood their customers, products, regulatory obligations, and operational risks. Those warnings often conflicted with integration plans that had already been approved, and many were ignored.
In one case, customers were assured that nothing would change. Anyone who has lived through an acquisition knows that promise is impossible to keep. Systems change. Processes change. Expectations change. The promise created confidence in the short term and disappointment later when reality arrived.
In another case, leadership faced a regulatory challenge involving a product line generating more than ten million dollars in annual profit. Local leadership believed the issue could be resolved through additional investment. Corporate leadership disagreed. Rather than invest approximately one million dollars to address the problem, the product line was discontinued.
Patients lost access to devices they trusted. Customers lost products they depended on. Employees lost jobs. Years of specialized expertise disappeared. The decision made sense on a spreadsheet, barely. It made far less sense to everyone affected by it.
Meanwhile, the organization continued spending heavily on consultants, technology initiatives, and system consolidation efforts. One ERP platform was selected as the future standard, on the assumption that similar businesses should operate in similar ways. Unfortunately, the acquired companies were only similar from a distance. Their products, workflows, customer requirements, and operating realities were different enough that the standard approach struggled almost immediately.
Instead of understanding the workflows first and designing requirements around them, exceptions were created. Then more exceptions. What began as a standardization effort gradually became a growing collection of division-specific rules, workarounds, and special handling procedures. The team called it the Miles effect.
The irony was hard to ignore. Leadership was reluctant to invest one million dollars to protect a highly profitable product line, yet millions were spent on integration efforts that repeatedly failed to achieve their intended outcome. Years later, the integration was still underway.
The lesson wasn't that the technology failed. The lesson was that leadership spent years attempting to optimize businesses it had never fully taken the time to understand.
The Work Is Not the Org Chart
The organizational chart is not the business. It's a picture of reporting relationships. Those relationships matter, but they tell you almost nothing about how value actually moves through an organization.
A workflow tells a completely different story. It shows how information travels. How decisions get made and at what level. How customers get served. How exceptions get handled. Where approvals create delays. Where employees have quietly built their own solutions because the official process didn't account for the real world. The workflow is where the business actually lives. The org chart is where leadership thinks the business lives.
Most integration plans start with the org chart because it's the thing leadership can understand fastest. You look at two finance departments and see obvious overlap. Two customer service teams. Two operations groups. The temptation is immediate: combine them, reduce duplication, create one structure. The problem is that visible duplication and functional duplication are not always the same thing. Two employees with similar titles might be doing completely different work. Two approval processes might look identical until you discover they exist because the risk profile is entirely different on each side.
This is why workflow analysis needs to happen before consolidation. It's slow. It's detailed. It requires talking to employees who actually do the work, not just the managers who describe the work. It requires tracing orders, invoices, escalations, and service requests from beginning to end. It requires asking why things happen the way they happen, and then actually listening to the answers.
What leadership finds in that process is often inconvenient. A process that looked inefficient turns out to be protecting the customer experience in ways that never made it into any procedure manual. A small team being considered for reduction turns out to be quietly handling the company's most complicated accounts, the ones nobody else is trained on and nobody else wants.
Those discoveries are deeply inconvenient if the integration plan has already been finalized. They are invaluable if leadership is still willing to learn something. The choice of which situation you want to be in is made well before the analysis happens.
The Acquired Company Is Not Automatically Wrong
There's an assumption I've seen operate in virtually every acquisition: the acquiring company must be the operationally superior one, because it's the one doing the acquiring. The buyer's systems survive. The buyer's processes become standard. The acquired company adapts.
Sometimes that's appropriate. Sometimes it isn't. Size and capability are not the same thing. Capital and operational wisdom are not the same thing. The ability to purchase a company doesn't mean every process inside the buyer is more effective. But many integrations proceed as if the answer is already settled before anyone looks at the evidence.
If the acquisition was justified on the belief that the acquired company brings value, capability, or market knowledge the buyer doesn't already have, then why would leadership immediately treat the acquired company's operating methods as obstacles to be removed? Why spend significant capital to acquire capability and then systematically dismantle the people and practices that built it?
The acquired company may process orders faster because it has fewer unnecessary approvals. It may communicate with customers more effectively because decisions are made closer to the customer, by people who know them. It may resolve problems faster because those employees have authority that the acquiring company removed years ago in the name of standardization. It may also have serious weaknesses that need to be addressed. The point is that leadership doesn't know which is true until it does the work of actually looking.
And employees notice when that work never happens. They know the difference between leadership genuinely trying to understand how things work and leadership collecting just enough information to justify a decision that was already made. When employees believe the outcome is predetermined, they stop contributing. They comply. They attend the meetings. They answer the questions. But they stop volunteering what they actually know.
That silence is expensive. And it is completely avoidable.
Customers Become the Testing Environment
Customers rarely care that an acquisition happened. They evaluate it through their own experience of doing business with the company. Did the order ship? Was the invoice right? Did someone answer the phone? Did the relationship get easier or harder after the deal?
That's the only scoreboard that matters to a customer.
When organizations rush integration without understanding the workflows that support customer experience, customers become the testing environment for decisions that weren't ready to be made yet. A customer discovers the new process doesn't handle the exception that's been in their contract for six years. A customer discovers that the person who knew their account, who always caught the thing before it became a problem, is gone. A customer discovers that support requests now move through a centralized queue where the context that used to travel with the request simply disappears.
Most customers don't make speeches about this. Some complain to sales. Some quietly reduce their order volume. Some begin pricing out alternatives. Some decide, when it comes time to renew, that now is a good moment to reconsider.
The organization, meanwhile, may be celebrating synergy milestones while customer confidence erodes in ways that won't show up in the revenue line until the relationship is already damaged.
Customer impact should be one of the first filters on any integration decision, not one of the last. Before consolidating a team, before changing a system, before eliminating a role, the question has to be: how does this change what the customer experiences? If those questions can't be answered, the decision isn't ready. The customer shouldn't be the test.
Employees Know More Than the Integration Plan
During integrations, employees tend to get discussed in terms of headcount, redundancy, and cost. Those things matter. But employees are also carriers of something that doesn't show up on a headcount report: operational memory.
Experienced employees know the shortcuts and the risks. They know which customers require special handling and why. They know which system behaves badly in specific situations. They know the seasonal pressures, the recurring exceptions, and the unofficial paths that work better than the official ones.
In many organizations, the real process isn't the one in the procedure manual. It's what experienced people actually do to make the business function. When leadership treats employees primarily as a cost line to be reduced, it risks eliminating that knowledge before it understands what it's worth.
I've seen organizations remove people and spend months afterward trying to figure out how a specific customer program actually worked. I've seen companies centralize responsibilities and realize too late that the local team had been preventing errors through judgment that was never written down anywhere.
Good employees don't wait for the final decision before they start reading the room. The best employees tend to have options, and when they decide the organization is no longer listening, they use them.
Hiring a replacement fills the seat. It doesn't recreate the memory.
Employee turnover during and after integrations tends to get categorized as a human resources issue. It isn't. It's an operational consequence with a very long tail. When experienced people leave, they take customer context, product knowledge, vendor history, and informal decision logic with them. The organization may believe it reduced redundancy. In reality, it may have lost the very people who could have made the integration successful.
Technology Is Usually the Wrong First Question
One of the first questions that surfaces after a deal closes is which technology platform survives. Which ERP? Which CRM? Which reporting tool? These are real questions that need real answers. The problem is when they get asked before a far more important question: what process are we actually trying to support?
Technology doesn't create good workflow. It amplifies whatever workflow it's built on top of. If the process is strong, technology makes it more consistent and scalable. If the process is weak, technology makes the weakness spread faster and touch more people. This is why system consolidation becomes so expensive when it's done in the wrong order. Organizations spend significant money moving everyone onto one platform and then discover that the platform was never the problem.
I'm not arguing against consolidating systems. There are strong reasons to reduce technology complexity after an acquisition. But sequencing matters. If leadership picks the system before designing the future workflow, the system decision becomes the process decision by default.
The business should define the work. The work should define the requirements. The requirements should guide the technology decision.
When I led integrations, we didn't start by asking which system would win. We started by asking how the business created value and what the future process needed to accomplish. Then we asked which technology best supported that outcome. Sometimes the answer was the acquiring company's system. Sometimes it was something from the acquired company. Sometimes neither system was right for what we were building, and we needed a transition period because the operational risk of forcing a change too soon was too high.
The Three Integrations That Shaped My View
The three integrations I led that finished ahead of schedule didn't succeed because I had a better framework. They succeeded because we resisted the temptation to confuse urgency with clarity.
We moved quickly where we had facts. We didn't pretend to have facts where we didn't. We mapped workflows. We talked to the people doing the actual work. We studied customer handoffs. We looked for the best-performing approach, not the politically easier one. That discipline, which felt slow at the time, changed the outcome.
In each case, we found strengths on both sides. Some of the acquiring company's processes were clearly better. Some of the acquired company's processes were stronger and got adopted more broadly. Some practices from both organizations needed to be rebuilt from scratch. That is what real integration looks like. Not a ceremony where the bigger organization imposes its habits on the smaller one. An investigation into how the combined organization can operate better than either one did separately.
Finishing ahead of schedule didn't happen because we skipped analysis. It happened because analysis prevented rework. We didn't spend months correcting avoidable mistakes. We didn't have to rebuild trust with employees who felt dismissed. We didn't have to explain to customers why service had gotten worse in the name of efficiency.
The time spent understanding the work was not a delay. It was the reason the execution was faster.
The slow-looking work at the beginning is often what makes the overall integration faster. Observation feels slow. Process mapping feels slow. But not doing those things is considerably slower when the organization has to unwind poor decisions, rebuild lost knowledge, and redesign processes that should have been understood before anyone touched them.
A Better Standard for Leadership
A better integration starts with a different standard for what leadership has to know before approving a change.
Before any consolidation is approved, leaders should be able to explain how the current process works, why it works that way, what value it creates, who depends on it, and what risks appear if it changes. If those answers aren't available, the decision isn't ready. It may feel urgent. It may be on the integration timeline. It still isn't ready.
This doesn't mean integration becomes endless analysis. There's a difference between analysis that precedes irreversible decisions and analysis that substitutes for them. Leadership can still set timelines, assign accountability, and move with discipline. But the first phase should focus on understanding both organizations, not forcing one to disappear into the other. Then design the future state from what you learned, not from what was assumed on day one.
The future state shouldn't be Company A's process or Company B's process by default. It should be the strongest process the combined organization can build. Most integrations never give themselves the chance to reach that answer because the conclusion is set before the analysis begins.
Executives also need to change what they reward during integration. Better questions produce better outcomes. How has the customer experience changed since the close? Which processes from the acquired company are outperforming ours? What knowledge did we capture before restructuring eliminated the people who had it? Where are employees building workarounds because the formal process doesn't work? Those questions don't fit as cleanly on a dashboard. They are far more likely to protect what was actually purchased.
The Final Question
After twenty-five years in operations and more than a dozen acquisitions, I'm still convinced that most integration failures don't come from technology problems, employee resistance, or the inherent complexity of the transaction. Those things matter. They're rarely the root cause.
The root cause is usually simpler and harder to admit: leadership wanted to create synergy before it understood the work. The organization started changing too soon, cutting too confidently, standardizing too broadly. And when the consequences showed up, everyone went looking for a more complicated explanation.
The business was changed before it was understood.
That's the uncomfortable truth sitting behind many integration post-mortems. Leadership bought a company because it believed that company had value. Then leadership began removing, replacing, and redesigning parts of that company before identifying which parts produced the value. Customers felt the shortcuts. Employees absorbed the confusion. Good people left. Costs moved around rather than disappearing. And at the end of a significant investment, the organization had something that looked cleaner on paper and worked worse in practice.
The objective of an acquisition isn't consolidation. It's improvement. Those words get used interchangeably, but they describe entirely different things. Consolidation is an activity. Improvement is an outcome. Consolidation can be ordered. Improvement has to be earned. Consolidation satisfies the desire to act. Improvement satisfies the reason the acquisition was made.
Before any department gets eliminated, any system gets replaced, any workflow gets standardized, or any process gets forced onto a business that built it for reasons leadership hasn't taken the time to understand, someone needs to pause and answer one question honestly: what exactly are we changing, and how certain are we that we understand it?
If the answer is unclear, the organization is not ready to change the work. It's only ready to study it.
That may feel slower in the moment. It is considerably less expensive than learning the answer after the damage is done.