Join 15,000 others and follow Sean Hull on twitter @hullsean.
My newsletter goes out the first few days of every month. I invite everyone I’ve ever worked with, so many of my present and former colleagues & clients receive it. I often receive a few emails in the days following, with requests for help, advice & expertise.
Recently I was referred on a merger acquisition project. The project involved evaluating the technology of the target company, to understand how it would fit in with existing infrastructure, and what challenges they might face.
1. What’s your tech stack?
The scope of the project included evaluating existing application code. We looking closely at:
o What programming languages & versions were in use?
o What volume of code was there, when was it built, and how was it maintained?
o Was the code well commented & organized?
o Are those languages or technologies popular in the marketplace today?
o Are the foundation technologies still supported, either commercially or by open source communities?
2. What’s your team stack?
One of the points that came up during the discovery phase was subject matter expertise. We found that the acquiring company’s DNA was around Windows, SQL Server & IIS. Their applications had been developed mostly on C#, so their team had skills around that stack.
The target company, on the other hand was Oracle on Unix. Here the team & expertise had a different heritage.
These two stacks have very different people & cultures behind them. Those would likely introduce unique challenges were you to merge those two firms, as the former would not have skills and expertise to manage & maintain the latter. Trimming teams down, or consolidating hardware & components would likely prove challenging.
Also: A CTO must never do this
3. Where are your pain points
We also evaluated current problem areas in the target application.
o Where were team members struggling most?
o What type of performance problems existed?
o Was there data mismatch or redundancy?
o Were business units struggling in some area to report on the data they needed?
Read this: When you have to take the fall
4. Style of software development
In software development, the traditional building model is called waterfall. It involves specing out requirements, spending a long period writing code, and then releasing it all at once to be tested & deployed. Typically during development period, there isn’t a working version of the system, as it’s undergoing change.
The risk with waterfall is that what comes out the other end won’t be what feature specification teams envisioned. Worse still is when the resulting product is full of bugs, or has major performance problems. The ACA used this method to develop healthcare.gov website, resulting in a whole host of problems on launch. It’s why I’ve advocated for real techops at Healthcare.gov.
These days, the modern and arguably superior model is called agile software development. This involves writing code in much much smaller chunks, and for each releasing a small test to verify that it performs it’s function. These unit tests allow for software to be continuously deployed, perhaps multiple times per day.
Check this: How we do a performance review
5. Legacy or Open Source
A last point of evaluation is the use of legacy software components such as Oracle, versus the more nimble and open source components many internet firms use, such as Linux, Apache, MySQL & PHP or Python. These later components make the stack of many modern web facing applications, are supported by the internet community, and provide flexibility & configurability in the cloud.
Fred Wilson has advocated for Open Source in various postings on his A VC blog. Although these technologies offer great opportunity & strength, your team may not have experience bushwacking through the DIY world of open source and that would be a major consideration for a merger.
DNA and culture of the acquiring company, and the target company have a huge impact on whether those technologies will all play well together as the firm grows up.