Two of everything

I co-designed and led the integration of two demand organizations after a large acquisition. Two demand generation platforms. Two marketing automation systems. Two analytics stacks. Two definitions of a qualified lead. Two forecast cadences. Two sets of territory logic. Two of nearly everything that mattered.

The systems were the visible half. They were also the easy half.

Systems can be chosen

A platform decision is tractable. Somebody evaluates both, somebody decides, somebody builds a migration plan, and the plan has dates on it. It is expensive and it is disruptive and people are unhappy about it for a while, but it is a project, and projects have a shape everyone recognises.

That is exactly why organizations start there. Not because it is the most important thing, but because it is the thing that can be planned. It produces a status update. It closes.

Meanwhile the things that actually determine whether the combined organization produces more growth than the two separate ones did are not on that plan, because none of them belong to anybody.

The combined number is wrong on day one

Here is the part that gets missed, and it is arithmetic rather than performance.

Two companies almost never qualify a lead the same way. One requires a scored behavioural threshold plus a fit score. The other accepts a form fill from a target account. One counts pipeline at first meeting. The other counts it at a stage with a documented next step. One measures a quarter from creation date, the other from the date it entered the forecast.

Every one of those choices was reasonable in the company that made it. None of them is wrong.

But when you combine the two organizations, somebody adds the two pipeline numbers together, because that is what the model in the deal case did. And that combined figure is not a bigger version of either number. It is a number that does not describe anything, because the two quantities being added were never measuring the same object.

Then the combined organization is held to it.

So the year opens against a baseline nobody can reproduce. When performance comes in below the model, the conversation becomes about effort, coverage, and pipeline generation, when the honest answer is that the target was assembled from two incompatible measurements and no amount of activity will reconcile them.

A combined number that is less than the sum of its parts is usually not a performance problem. It is an arithmetic problem wearing a performance problem's clothes.

The layer that gets deleted overnight

The second thing that breaks is harder to describe because it never appears in any document.

In a stable organization, the org chart explains a good deal of how work happens, but not all of it. The rest runs on accumulated relationships. Who a regional seller calls when a campaign underperforms. Which analyst a business unit leader trusts to sanity check a number before it goes into a board review. Who can approve an exception without escalating it, and who will say no on principle. Which two people have to be in a room before a decision will actually hold.

None of that is written down. All of it is load bearing.

An acquisition deletes that layer for both sides at the same time. Not gradually, and not for one population. Everybody loses their informal map in the same week, and they lose it precisely when the volume of decisions is at its highest.

What follows looks like a competence problem and is not one. Good people making slower and worse decisions, because the route they used to take no longer exists and the new route has not been built. They will rebuild it. It takes months, and during those months the organization is genuinely less capable than either half was before, which is uncomfortable to say out loud and worse to pretend is not happening.

Both sides are right about each other

The predictable next stage is that each side develops a theory about the other.

Their leads are low quality. Their process is bureaucratic. They do not understand enterprise selling. They over-engineer everything.

The frustrating thing is that these observations are usually accurate. They are accurate descriptions of a system that was optimized for something different. A company selling a high-velocity product to mid-market buyers really should qualify differently from one selling a complex platform through a partner channel. Both systems were correct for their business. Neither is correct for the combined one, and neither team can see that from the inside, because each is comparing the other against the standard that made sense where they came from.

This is the point where a lot of integrations quietly stop being integrations and become one side winning. Sometimes that is even the right answer. But it should be a decision somebody makes deliberately, with a reason, not the residue of whichever team had more seniority in the room.

Unifying the systems first can make it worse

The sequencing instinct is to consolidate the platforms first, on the reasoning that a single system will force a single way of working.

It does not, and it can leave you worse off.

If you migrate two organizations onto one platform before the definitions underneath have been reconciled, you do not eliminate the disagreement. You encode it. Both definitions get configured into the same system, usually as two fields, two report types, or two saved views that nobody outside the team knows are different.

Now you have one system producing two incompatible numbers. That is worse than two systems producing two incompatible numbers, because it looks like agreement. The tell that something is wrong has been removed while the underlying problem is still there, and it will surface later as an unexplainable variance that takes weeks to trace.

Reconcile first. Migrate second. It feels slower and it is not.

There is a deadline, and nobody names it

The last thing worth saying is about time.

Integrations run against a clock that is real but rarely stated. There is a window, usually two or three quarters, in which slower performance is understood as the cost of the transition. After that window closes, the same numbers get read as evidence that the acquisition is not working, and the conversation changes from support to scrutiny.

The organizations that come through well are not the ones that avoided the dip. Everyone has the dip. They are the ones who spent the early part of the window on the reconciliation work rather than on the migration work, so that by the time the scrutiny arrives they can explain the number, defend the baseline, and show which part of the gap is arithmetic and which part is performance.

That distinction is the whole thing. If you can make it, the conversation stays productive. If you cannot, you are arguing about effort, and that argument has no end.

What to do first

If you are inside this now, three questions get you most of the way.

Can two people from opposite sides independently produce the same pipeline number for the same period? If not, that is the first piece of work, and it is not a systems project.

Which decisions currently have no owner because the person who used to make them was on the other side of the deal? There will be more of these than anyone expects, and each one is quietly adding days to something.

What in the model assumed the two organizations were additive? Find those assumptions and check them, because they are almost certainly still in the plan you are being measured against.