Evolutionary architecture during M&A

During my time as a CTO in a growing med-tech start-up, I have experienced a couple of situations, which led to certain team setup and architectural decisions. I can’t say, they were all right, but I want to share my key learnings from those situations.

If you face yourself within a tough market, where your company might even want to and can acquire companies within the market for any compelling reason (market access, market share, technology access, technological synergies etc…), and build software, you’ll face a situation where your team members worked on a fancy stack A and the members of the other company worked on another fancy stack B. Both companies know, what’s good and bad about their stacks including principles, services, programming languages, frameworks, distribution, vendors and so forth. Both companies knows what to do as their daily bread and know what they had solved to make their thing a success.

An Acquisition and the following change process have to be cautiously planned, executed and monitored to make sure it will be successful.

It is critical to plan ahead, when you take the decision to merge two companies together. If you know, that you also want to create technical synergies between the two companies stacks, you’ll be confronted with ugly questions like:

• What is the plan for our software?
• Who will make the decisions?
• What will be the main programming language?
• What will the processes look like?

At this point, you rather have some proper answers in place and can put some light into the future path, as such a process always require change and alignment. Of course there will be strong voices like: “They’ll just do everything as we do and everything will be fine.” or “Just take ours, it is more advanced, we are longer on the market and you know, it is better…”. Of course, it’s never like that. Any software has its pros and cons — but trying to take from both worlds the best, should always be the way forward.

In our particular situation, we merged with a team of very knowledgeable engineers with decades of knowledge in their market niche, they were quite successful but used some very outdated tools, processes and paradigms. As you would expect, we were the “young kids from the block” within a startup, a product which was less than 2 years old, they intuitively said, we should just stop working on our product and build on top of theirs. Our software consisted at that time of a Java backend monolith grown out of a prototype as the biggest chunk, but around that, we applied many great things like Infrastructure as Code, latest orchestration tools in the cloud, continuous integration and delivery, lots of automation, react and react-native clients. Theirs was consisting of a well matured Python backend, self-hosted excellence, many run books and many customers using their software. It’s already visible that both solutions have their pros and cons.

I went for a path, which seemed like the most promising by getting into a room with our best engineers and sketching out a micro service architecture where the main puzzle pieces were about contract based API communication, deployment and automation. With this in mind, we could easily co-exist for a certain time, grow together by leveraging key functionality from each respective service to others and further harmonize future development. By taking that situation, nobody will loose their face or beloved stack and mostly continue in their way of working. Finally, with such an architecture, you’ll set the base for any upcoming organizational changes.

Check out for my other articles around start-up scaling like Hiring Strategies for scaling start-ups.