The manager of an acquired function raises every real complication in its integration, in writing and at every checkpoint, so the timeline slows to what the function can absorb and its control lasts longer.
Borderline: whether this move is justified depends on the situation, and only the person in it can judge.
An example
Twenty years of customer-specific pricing rules, written by the controller himself, ran the billing at a regional snack maker, including rebate terms for its three largest grocery customers. When a multinational food company bought the business and scheduled the billing integration for two quarters, he was convinced the date would misbill those customers. He documented every dependency he knew of, nineteen in all, with the dollar exposure for each, and presented them at the first checkpoint. He offered to map the rebate logic himself if the parent assigned an analyst to learn it. The integration lead moved the deadline by a quarter and assigned the analyst. The migration went live in month nine without a billing error, and the controller was asked to lead billing integration for the next acquisition.
Why it works
Raising real complications makes slowing down easy to agree to: nothing is refused, and each concern is documented and plausible. The promised synergies look worse as the timeline lengthens, and pushing ahead looks costlier, since every concern now carries a named risk to customers or revenue. The move rests on knowing things the acquirer does not, an integration team with other demands on its attention, and a deal thesis that can absorb a revised schedule. It holds only as long as the complications are real and the manager is helping to resolve them.
The thinking behind it
Jeffrey Pfeffer Power as structural position, from Power in Organizations (1981): power comes largely from control of resources, information, and the decision process. The controller's knowledge of the legacy billing rules is information nobody else has, which gives him real say over the timeline. Pfeffer's frame also predicts the acquirer's answer: assigning someone to learn the system reduces the dependence, and the power with it.
Oliver E. Williamson Asset specificity and opportunism, from The Economic Institutions of Capitalism (1985) and Markets and Hierarchies (1975): knowledge of one firm's systems is an asset that loses value outside the relationship and leaves the parties dependent on each other, and opportunism includes incomplete or distorted disclosure. Twenty years of custom billing rules are such an asset. Holding back what one knows is the opportunism that turns raising complications into a stall.
Herbert A. Simon The scarcity of attention, from Designing Organizations for an Information-Rich World (1971): information consumes the attention of those who receive it, so attention becomes the scarce resource. An integration lead running several deals cannot examine every risk list, so the manager who presents complications clearly, with stakes and fixes, shapes the decision. The same scarcity is why defenders keep a senior executive's attention fixed on a slow function.
When it fits
Managers who hold knowledge an integration depends on, and who are convinced the planned timeline will damage customers or the business, are the ones it fits. You need documentation of the risks, credibility with the integration team, and the willingness to help resolve the problems you raise.
How to use it well
Write the complications down with their stakes: which customer, how much money, what fails. A risk with a dollar figure gets a hearing that a worry does not.
- Raise everything you know at the first checkpoint, so the list doesn't seem to grow on purpose.
- Propose a fix or a test for each item.
- Offer to transfer your knowledge, and ask for someone to learn it.
- Agree to dates you believe in, and meet them.
Your credibility rests on the list being complete early and shrinking over time.
What it costs and where it backfires
Integration leaders will suspect you of protecting your turf, and the suspicion grows with each delay. A stall that costs the deal its synergies can cost you your job, if the acquirer decides to take a write-down and force the function onto its platform. The line is honesty about the list. Inventing complications, saving known ones to release one at a time, or withholding documentation so nobody else can understand the system turns caution into obstruction, and the record of the checkpoints will show it.
When it is used on you
Integration leaders facing a list that grows at every checkpoint can put someone with independent technical depth on the function, make documentation a dated deliverable, and keep a senior executive's attention on it. Real complications get resolved that way, and invented ones dissolve.