Five Acquisitions, One Platform, No Authority
I worked at a company that had acquired five big competitors in two years in a roll-up strategy. My job, as a platform PM, was to get everyone onto one technology stack. I thought it was a technical problem. It turned out to be the hardest organizational change work I'd done.
We had multiple teams solving the same problems with different goals, and the result was a Frankenstein experience across the company. I had no formal change management authority, and the product depended on getting those teams to change how they worked.
I couldn't issue mandates, control budgets, or reorganize teams. What I could do was find the people in each acquired company who were frustrated by the same duplicative problems I was seeing. Those people became my coalition.
We asked each team to help build solutions and share them through a centralized module library. Each team contributed its best work, so the library belonged to them and didn't feel imposed from above. When one team's module solved a problem three other teams were struggling with, I didn't have to argue for the approach anymore.
It changed how four acquired companies worked together, and it started with finding the frustrated people and giving them something to contribute.
What I'd do again
I didn't have change management training when I took on that platform role. I didn't need much. As a PM I spent every day convincing engineers to build things, designers to iterate, and stakeholders to fund roadmaps. Reading what people care about and making a case without pulling rank turned out to be most of what organizational change requires.
The structure matters more than the training. In Prosci's research, projects with excellent change management met or exceeded their objectives 88% of the time, against 13% for projects with poor change management. Their sponsor research points the same way: 79% of projects with extremely effective executive sponsors met their objectives, against 27% with extremely ineffective ones. If you can get a strong sponsor, get one. If you can't, the coalition has to do more of that work.
What worked there has worked for me everywhere since: find the frustrated people, start small, make progress visible, and treat resistance as information.
In the platform consolidation, finding the frustrated people meant identifying the developers across all five companies who were tired of rebuilding the same components in slightly different ways. Starting small meant one shared module for one clear pain point, with the grand unified platform left for later. Making progress visible meant that when one team's module saved three other teams weeks of work, everyone heard about it. When teams pushed back on the centralized approach, I listened. Their worries about losing autonomy were legitimate, and the module library design got better because we dealt with them.
It outlasted my involvement because the teams who contributed modules became its strongest champions. They had helped build the thing, so they cared whether it worked, and nobody had to keep pushing them.