Insights

When organisations talk about product convergence following an acquisition, the conversation usually starts with technology. Which platform do we build on? Which codebase do we keep? How long will integration take? They’re reasonable questions but, in my experience, they’re not the hardest ones.

I’ve often found that products which appear remarkably similar on the surface have in fact evolved to solve subtly different problems for different customers. They’ve been shaped by different teams, different priorities and different use cases. Neither is necessarily right or wrong — they’re simply the product of different journeys. That’s usually where the interesting conversations begin.

Which product defines the future? Which features survive? Which customer roadmaps will continue to be supported? How much legacy function do you preserve before it becomes a millstone around your neck?

I’ve experienced my engineering teams being criticised because convergence wasn’t progressing quickly enough, when the technology itself was never the real constraint. The business simply hadn’t reached agreement on where it wanted to end up despite my promptings. Technology should only implement decisions. It shouldn’t make them. In fact when the former happens it is a disaster. The tail wagging the dog.

The more acquisitions I’ve been involved with, the more I’ve come to believe that successful product convergence is fundamentally about clarity. Once that exists, the technology is usually the easier part.

For most growing software businesses, architecture naturally remains an engineering concern. As long as the platform scales, customers are happy, and features keep shipping, it’s doing its job.

Then, the prospect of acquisition enters the equation. Suddenly questions that used to sit purely with the engineering team become board-level discussions. Questions about scalability, resilience and maintainability suddenly sit alongside discussions about valuation, risk and future growth.

At this point, architecture is no longer just about technology. It’s about risk. It’s about cost. It’s about the stability of your product. And, potentially, it’s about the value of your business.

I’ve seen organisations spend months, sometimes years, dealing with complexity that wasn’t fully understood before a deal completed. I’ve sat in meetings where a seemingly innocuous architectural decision made years earlier suddenly became central to discussions about integration, cost and timelines. Not because anybody wasn’t good at their job. Simply because architecture drifts while attention is focused on customers, growth and delivery.

Strong products, loyal customers and impressive growth can mask risks that only become apparent under closer scrutiny. A platform dependent on a handful of key individuals. Technical debt accumulated during years of rapid delivery. Products that looked complementary on paper present an architectural nightmare when you plan the integration.

None of these issues are necessarily deal breakers. But they can have a significant impact on the cost, complexity and timeline of what comes next. That’s why architecture eventually stops being just an engineering concern. It becomes a business concern.

With a little more time to reflect recently, I’ve been thinking about some of the more interesting challenges I’ve worked on over the years. Whether a software business is scaling organically, preparing for investment, or integrating an acquisition, many of the underlying technology challenges are surprisingly similar. At some point questions emerge around duplicated capability, platform strategy, technical debt, operating models and where future investment should be focused.

I have plenty of experience of acquisition and integration. Not the deal itself (that’s an SEP — someone else’s problem). I’m talking about the bit that comes afterwards for the technical teams involved. My experience is in bringing together products that have evolved independently, managing engineering teams with different cultures and ways of working, and dealing with architectures that solve similar problems in completely different ways.

I’ve worked through a number of these situations and I’ve noticed that many of the toughest decisions aren’t really technical. They’re product and business decisions with significant technical consequences.

Product convergence is a good example. On paper, it can look obvious. Two or more products with overlapping functionality. Rationalise them into one. Reduce cost. Simplify the portfolio. The reality is invariably messier. Customers use products in ways that nobody anticipated. Features that appear identical often aren’t. Technical shortcuts taken years ago can suddenly become critical dependencies. Convergence initiatives can move too quickly and create disruption that could have been avoided. More commonly, in my experience, organisations spend years maintaining multiple platforms because the difficult decisions are repeatedly postponed.

There are no perfect solutions. In the real world it’s usually a question of being pragmatic and making sensible trade-offs.

Over the coming weeks I’ll share a few observations from the engineering and architecture side of scaling software businesses, acquisitions and post-acquisition integration. Not because I’ve got all the answers, but because it’s an area that doesn’t seem to get discussed very often outside the organisations going through it — and sometimes inside those organisations too!