The first hundred days of an integration are about decisions, not systems

01Day one is a communications event

On the day a deal closes, very little can change operationally. Systems, contracts and payroll keep running as they did the day before. What changes is what people believe will happen to them, and they form that belief within days.

The single most useful day-one document is short: what will not change in the next ninety days, what will, and when people will know more. Teams can live with uncertainty if it has a date attached. They leave when it does not.

02Decide who decides

Integration plans tend to list workstreams: finance, IT, HR, sales. What they rarely list is decisions. Which price list survives? Whose approval limits apply? Who can hire? Until those questions have owners and dates, every workstream waits.

We ask leadership to agree, in the first two weeks, a short register of the thirty or forty decisions the integration depends on, each with an owner and a deadline. It is unglamorous work, and it is the best predictor we know of whether the hundred-day plan will hold.¹

Teams can live with uncertainty if it has a date attached.

03Protect the people you paid for

Acquirers usually pay for customers, capabilities and people. Customers and capabilities stay put for a while; people do not. Competitors read the announcement too, and the best people in the acquired company are the first to be called.

Retention needs to be designed, not hoped for. Identify the people whose departure would hurt most, talk to each of them personally in the first fortnight, and resolve the questions that matter to them, such as role, pay scheme and reporting line, before anything else.

04Sequence the systems last

Systems consolidation is where most of the long-term savings sit, and where most of the risk sits too. Doing it early, before processes and decision rights are agreed, means migrating two sets of habits into one tool.

Sequence it after the operating model is clear, and limit how much any single site or team has to change at once. In our integration work, we aim for no team changing more than one major system at a time.² It is slower on paper and faster in practice.