In every acquisition, part of the value is not in systems or contracts, but in people's heads. The buyer who knows which supplier is flexible outside the agreement. The mechanic who knows which machine makes a particular sound before it jams. The account manager who knows exactly when a customer needs a phone call and when not. That knowledge is written down nowhere, and that usually hasn't been a problem as long as the person stayed. In an acquisition, that assumption changes.
People leave more often in the period around and after an acquisition than outside it. That doesn't have to be due to dissatisfaction; uncertainty about role, compensation, or future is often enough. Why do people leave in the unclear months after an acquisition explains where that unclarity comes from. The point here is sharper: if the departing person carried knowledge that is recorded nowhere else, that knowledge disappears the moment they leave, not gradually.
That is a different risk than a vacancy. You can fill a vacancy. Knowledge that has disappeared must be rebuilt, often without you knowing you've lost something until the moment someone asks about it and no one has the answer.
The question is not who the best employee is. The question is which roles carry knowledge that exists nowhere else. That is a role-based question, not a judgment about individuals. A role can be knowledge-carrying without the person in that role needing to be indispensable — that is precisely the distinction you want to make before it is too late.
When determining which roles these are, it helps to look at who actually makes decisions, who resolves escalations, and who is the only one who can explain a process without consulting documentation. Who are your key people in an acquisition explains how you identify those roles without it becoming a popularity exercise.
In an acquisition there are often two people with the same job title, and sometimes two people who effectively carry the same knowledge from different angles. That can be a basis for securing knowledge — if both remain involved until the handover is complete — or a reason for unrest if no one knows who will fill which role afterward. What you do with that depends on the situation; see what do you do if two people have the same role. Unclarity about roles accelerates departure. Clarity about who does what, even if that is temporarily duplicated, gives people a reason to stay until the handover is completed.
It backfires if you only sort out role clarity after someone has already resigned. See how do you keep roles clear across two organisations for how that clarity fits earlier in the process than most deal teams plan for.
Securing knowledge is not an HR task you add on later. It is a question that belongs to every key role: what does this person know that is recorded nowhere else, and who could take over if this person left tomorrow. For the roles where the answer is "no one", there is something you can do — documenting, shadowing, training a second person — before the need arises.
That is precisely what the integration office is for: not as an extra layer of bureaucracy, but as the place where these dependencies are made explicit and tracked, alongside the other dependencies that belong to an integration. A key role without a backup is a dependency in the same way a system without a replacement is a dependency. Both belong on the same list.
Here too, the question that belongs to every part of an integration applies: should this even be combined. Not every role that carries knowledge needs to continue existing in the new structure, and not every attempt to secure knowledge is worthwhile if the role itself becomes redundant. Sometimes the answer is that a team or process is better left functioning separately, precisely so as not to disrupt the knowledge it holds. When does integrating destroy value explains why that question should be the standard, not an exception for borderline cases.
The three generators — synergy baseline, Day 1 plan, and Day 100 plan — map key roles and their dependencies at the moment you need them, not afterward. The integration office keeps track of where knowledge sits, which roles are at risk, and what is on the decision list to merge or not merge. This is a tool that brings structure to a question that would otherwise only become visible once someone has already left. There is no completed track record we fall back on; the instrument asks the questions and provides the structure, the outcome depends on your situation. The tool is under construction; anyone who wants to work with it can join the waiting list.
Once knowledge-carrying roles are identified, the next question is often what happens to the underlying work once the organisations merge. Which part of a task is routine and transferable, and which part really depends on one person. The work scan from FTE TO AI calculates, per task, which part of the work can be taken over by AI, and in doing so also makes visible which part is precisely not transferable without that specific person — exactly the distinction that matters for securing knowledge.
Vraag maar wat er op Day 1 moet staan, of wat integreren juist kapotmaakt.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.