After a deal is signed, two organization charts exist side by side, and they overlap messily. There are functions that occur twice, there are functions that are not properly housed in either structure, and there are functions where no one knows anymore who is actually responsible. That is not a failure of the people holding those functions. It is a consequence of two designs that were never made for each other and now have to keep working at the same time.
The question "how do you keep roles clear" is therefore not a question about individuals. It is a question about structure: which role exists where, who owns it, and what happens to the roles that remain once the organizations truly become one. Whoever approaches this question as a matter of evaluation — who is better, who gets to stay — builds unrest into the process itself. Whoever poses the question in role-based terms keeps it manageable.
In every acquisition, functions arise that literally exist twice: two CFOs, two heads of procurement, two teams that both think they manage the customer relationship. That is a problem in the role structure, and it deserves a role-structure solution: which role remains, which role gets merged, which role disappears, and which role gets a new scope. Only once those questions are answered is there something to link to individuals — and that is a separate step. What that means in concrete terms is worked out in what do you do when two people have the same role, and the complication that arises when the two organizations also work differently is covered in what do you do when two people have the same role, complicated by cultural difference.
Attention often goes to the duplicate roles, because they are visible. Less visible, and often more damaging, are the roles that fall between the cracks. A process that sat with procurement in one organization and with operations in the other sometimes ends up belonging to no one after the merger. A customer who had one point of contact suddenly has two, or none. These vacuum roles usually don't arise because someone forgets them, but because no one has laid the two organization charts side by side with the question: what did we jointly cover, and what does the new structure still cover?
Beneath the roles are people who carry more than their job title suggests: the one who maintains the most important customer relationship, the one who understands the only system still running on old code, the one in whom all the informal decisions converge. Identifying these people is not a matter of reading seniority off an organization chart. It is a matter of determining which role carries which risk if that role falls away. How you do that without it turning into a popularity exercise is described in who are your key people in an acquisition, even when the two cultures differ.
Roles that remain unclear for weeks cost something different than roles that remain unclear for days. People who don't know whether their function will continue to exist go looking for certainty, and they sometimes find that certainty outside the organization. That departure rarely happens in the first shock weeks; it happens more often in the months that follow, once the excitement of the deal has faded and the ambiguity is still there. Why that pattern occurs specifically in that phase, and how cultural difference reinforces it, you can read in why people leave in the unclear months, when the two cultures also differ. The translation to the role structure itself, including the scenario in which the two organizations are set up differently, is set out in how you keep roles clear across two organizations with different cultures.
Solving the role question is not something a generator decides for you. What tools can do: lay the two organization charts side by side, make duplications and vacuum roles visible, and link them to the Day 1 plan and the Day 100 plan so that the decision about each role gets a place and an owner instead of being made in a meeting and then forgotten. The integration office keeps track of which role decisions have been made, which are still open, and which depend on another decision that has not yet been taken. That is structure, not a judgment about who fills the role best.
And the question that needs to be asked for every role is the same question that applies to every other part of the integration: should this role actually be merged at all, or does keeping it separate preserve more value here than merging would? Not every overlap is a problem that needs to be solved by turning two roles into one.
Once you know which roles remain, which are merged, and which disappear, a different question arises that has nothing to do with the merger, but everything to do with the future of every remaining role: how much of the work in that role is routine enough to hand over to AI. That is exactly what the [work scan of FTE TO AI](https://fte-to-ai.net) is meant for: calculating per task within a role which part can be taken over by AI, so that the new role structure is not only clear about who does what, but also realistic about what will still be human work going forward.
Mergerintegration.net is under construction. Anyone wanting to use the generators and the integration office once they become available can sign up for the waiting list.
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.