Failure is, of course, the greatest teacher. In reflecting on my "difficult year, professionally" that followed Being Acquired, I found it valuable to walk through my struggles during that period, and consider how I might have proceeded more effectively.
The Same, But Different
One interesting aspect of the acquisition in question is that it brought together two different software development organizations of roughly the same size, who produced largely similar products, but for slightly different markets. Indeed, both orgs already used many of the same tools and technologies, and as we came together, it made total sense to combine our processes and toolchains.
For example, both the acquiring (Company A) and acquired (Company B) companies relied on JIRA for issue tracking. Great! We can easily import Company B's JIRA projects into Company A's JIRA database, and then we can easily share issues, roll up status, etc. In practice, however, things remained siloed even after merging the data. The JIRA configuration (e.g., workflows, permissions, set of issue types, etc.) was surprisingly different between the two companies. This perplexed me, because both organizations were trying to accomplish basically the same thing, and as I already knew that JIRA worked well at Company B prior to the acquisition, I couldn't see any reason for all of the little differences between the two.
The Brute Force Solution
I asked around, but couldn't find anyone else who could justify the configuration differences either. (Admittedly, JIRA configuration tends to be an arcane art touched only by a few in any organization, so the lack of deep familiarity was not that surprising.) The workflows I was familiar with at Company B were relatively simple, straightforward, and easy to understand. Since I couldn't uncover any justification for the Company A's more complicated workflows, I made the assumption that those complications were the result of historical artifacts that were no longer necessary, and had just never been cleaned up. I knew getting the various teams working together using the same workflows was important, and since I assumed the extra complications were unnecessary, I started pushing the simpler workflows onto all of the teams.
You can probably imagine how that went. I assumed that teams would welcome the simpler workflow, but instead I was met with surprising (to me) resistance. The workflows were indeed simpler and easier to understand, and some were happy with them, but they didn't quite work for the Design group, and Project Managers had all sorts of corner-case questions. I got feedback from stakeholders that I never expected to even have an opinion on JIRA workflows. Pretty quickly it was clear that pushing this any further would cause a big headache, and so I reluctantly relented and rolled everything back.
Solving A Slightly Different Problem
After puzzling over my failure for a little while, I decided to try a different tack. Instead of comparing the different workflows, which were of course just representations of the underlying software development processes, I grabbed an experienced project manager from Company A, sat down with them, and had them walk me through their entire software development process in detail, leaving nothing out. I was certainly surprised by what I learned.
I thought I already knew what Company A was doing, because I had been doing the same thing with Company B for years, but when we got into the details, it wasn't quite the same. Some of the tooling was different. Design Review entered at a different point. Staging didn't work quite the same. The workflows were different because, while both of us were solving the same class of problem, we weren't solving the exact same problem. Subtle differences in technical requirements and team culture led to necessarily different solutions.
More generally, I've seen this pattern play out all the time when there are conflicts between proposed software solutions designed by different developers. Each developer advocates for what they think the optimal solution is, and finds what they think are major flaws in the others' work. However, when investigating which solution to adopt, I quite often discover that each developer was relying on different interpretations of the given requirements, or perhaps a different weighting of the relative importance of them. In essence, while each developer claimed to be solving the same problem, they were in fact each solving a slightly different problem. Once the Product Owner clarified the requirements, and we all agreed on exactly what problem to solve (by no means trivial, but a topic for another time), the preferred solution often became obvious to everyone.
So what was the preferred solution for our JIRA workflow problem? It turns out, neither company had a ready-made solution that would work for everyone. When we sat together and designed from scratch a new workflow matching every current use case for both sets of teams, we instead found a middle ground -- something not nearly as complicated as what Company A was using, but neither was it as simplistic as Company B's. And this pattern repeated itself across different domains as the two organizations merged. Only when I took the time to step back and examine both companies' approaches from a neutral perspective -- to really understand why they were the same, but different -- was I able to chart a successful path forward.