Integrating Engineering Teams After an Acquisition

I'm Tom Lang — I've built and scaled engineering organizations for three decades, from startups to 250-plus engineers and through multiple acquisitions, and I work as a fractional and interim CTO for growth-stage companies, with particular depth in regulated and integration-heavy environments.

When you run engineering for an M&A integration, the instinct is to immediately start merging databases and consolidating cloud providers to show the board some cost savings. That instinct destroys value. It's also the default, which is why so many technical integrations quietly fail.

Here's what most people get wrong: mergers don't fail because of incompatible tech stacks. They fail because of mass attrition and severed context — the people who understood the acquired system walk out the door, and the knowledge goes with them. I've run these integrations across multiple acquisitions, including at Videology as we absorbed companies across nine offices. Here's how I actually do it.

Day zero: find the load-bearing walls

The moment the deal closes and I own both sides, I do not look at the codebase. I look for the load-bearing walls — human and technical — because those are what a careless integration knocks out.

• The bus-factor audit. I immediately identify the three to five engineers in the acquired company who actually hold the system together. Who knows how the billing cron job really works? Who manages the database migrations? I secure those people first — often fighting for retention bonuses before anyone talks about org charts. Lose them and you've bought a codebase nobody can operate.
• The revenue plumbing. I map exactly how a customer transaction flows — from their front end, through their system, into the bank. I don't touch a thing until I know precisely where the money moves, because the fastest way to destroy the value you just paid for is to break the revenue path in week one.
• The security perimeter. I audit their cloud IAM roles, their exposed S3 buckets, their third-party dependencies. If they have a breach on day two, it's now my breach — I inherited their security posture the moment the deal closed, whether I've looked at it or not.

Integrate the experience, isolate the risk

Here's the rule that separates a pro from an amateur. Amateurs try to merge everything into one monolithic codebase to achieve "architectural purity." Pros merge the experience and isolate the risk.

My rule: unify the customer experience, unify the data, but isolate the execution environments.

What I aggressively integrate: single sign-on, so the customer has one login. The BI and data warehouse, so the CEO gets one dashboard instead of two. Security tooling, auth, and billing. These are the things that make two companies feel like one — to the customer and to the executive team.

What I deliberately leave alone: the core product stacks. If we bought a company running a Ruby monolith and we're a Go microservices shop, I do not force a rewrite. That's a multi-year death march that produces nothing customers can see. Instead we leave their application running exactly as it is, wrap it in an API gateway, and let the two systems talk over a clean network boundary. (That's the same wrap-and-interoperate move I use for legacy modernization — you don't have to merge two systems to make them work as one.)

The 90-day sequence

I run this as a strict, phased sequence — and the counterintuitive part is that everyone rushes the code merge, which I deliberately slow down, while I speed up the cultural integration.

Days 1–30 — secure and stabilize. No new features. We lock down security, audit the infrastructure costs, secure the key personnel, and freeze major architectural changes. The goal of month one is simply: don't break anything, and don't lose anyone.

Days 30–60 — the "one company" facade. We build the API bridges. We unify the login with SSO, consolidate the customer-support tooling, and — this matters more than it sounds — merge the Slack workspaces so the two teams can actually talk to each other. Communication first, code later.

Days 60–90 — process harmonization. Only now do we start aligning sprint schedules and deployment cadences, and only where it genuinely makes sense. Not everything needs to match.

The cultural landmines — where integrations actually die

The fastest way to sink an integration is to treat the acquired team like a conquered province. If you walk in on day one and say "we're moving you off GitHub to GitLab, you'll use our Jira templates, and by the way your codebase is a mess," your best engineers will resign inside 30 days — and they're the ones you can least afford to lose. (Remember the bus-factor audit.)

Two moves prevent that:

The reverse-adoption move. To kill the "us versus them" mentality, I actively hunt for one thing the acquired company does better than we do — and I force the parent company to adopt it. If their incident-response playbook is sharper than ours, it becomes the standard for the whole org. Nothing proves "this is a merger, not an occupation" faster than the acquirer changing its ways to match the acquired team's.

Protecting autonomy. I tell the acquired engineering leaders plainly: "You still own your roadmap and your deployment pipeline. I'm here to integrate the perimeters, not to micromanage your commits." That's the same autonomy principle I design teams around — and it's what keeps good people from feeling demoted overnight.

The scar that taught me the rule

I learned this the hard way, early. Years ago — I was a lead engineer at the time, not the one running it — a company I worked for acquired a smaller competitor to capture their enterprise client list. The mandate from the board was to fully merge their legacy monolith into our modern stack within 90 days, to "eliminate redundancy."

We tried to run a dual-track sprint: build new features while migrating the old ones. It was a disaster. The acquired team felt insulted by our engineers nitpicking their code; our engineers hated working in the legacy system. Velocity dropped to zero. Two key senior developers on the acquired side quit in the same week — exactly the people who understood the system we were trying to migrate.

Eventually we had to halt the migration and admit the strategy was wrong. We rolled it back, wrapped their app in a secure services layer, and simply maintained it for two years until it was naturally deprecated — which is exactly what we should have done on day one.

The lesson I've carried ever since: never rewrite a working, revenue-generating system just because the acquiring engineers don't like the technology stack. (It's the same lesson whether the system came from an acquisition or was already yours.)

The honest goal

So that's how I actually run an integration: secure the people and the revenue path before anything else, merge the experience while isolating the risk, slow the code and speed the culture, and treat the acquired team like partners you were lucky to get. Do that and the acquisition delivers the value you paid for. Skip it and you'll spend two years and a lot of goodwill discovering that the tech was never the hard part.

If you've just acquired a company — or you're about to — and you want someone who's actually integrated engineering orgs before rather than learning on your deal, that's exactly the kind of work I do. Book a call and we'll map it out before day zero.