You have two engineering organizations. Different tech stacks, different deployment rhythms, different cultures, different assumptions about how decisions get made. One of them built what you acquired, or what you merged with, and they have complicated feelings about what’s happening. Your job is to combine these teams without losing the people you need most and without creating a bureaucratic mess that slows down both organizations for the next two years.
Here’s what consistently goes wrong, and how to get ahead of it.
The First Thing That Goes Wrong: Too Much Ambiguity, Too Long
Engineers tolerate a lot. They’ll work through messy codebases, unclear product direction, and tooling that doesn’t quite work. What they will not tolerate indefinitely is not knowing whether they have a job and who they report to.
When a merger or acquisition is announced, every engineer on both sides immediately starts doing the math. They know that combined organizations rarely need two of everything. They start asking: is my role redundant? Is my manager’s job safe? Is my team’s technology the one that survives?
If those questions don’t get answered within 30 to 45 days, the people with the most options — which are exactly the people you most want to keep — start exploring those options. You will lose them before the integration plan is finished, and you will lose them to offers that come in while they’re emotionally uncertain rather than while they’re engaged and committed.
Speed here is not about rushing bad decisions. It is about recognizing that silence is a decision, and it is almost always the worst one.
The Technology Decision That Can’t Wait
Every dual-stack integration eventually resolves to one of three outcomes: one stack wins, both stacks merge into a new third thing, or the teams stay separate but are called merged. The third option is not a real option. It creates permanent organizational debt.
The decision about which technology direction to pursue has to be made by someone with the technical credibility to make it and the organizational authority to enforce it. If it gets made by committee or by whoever argues loudest, you will spend the next 18 months relitigating it while engineers on the losing side disengage and engineers on the winning side resent not being allowed to just get on with it.
The technology decision is also not purely a technology decision. It’s a culture decision. If you acquire a company and then tell their engineering team that their entire stack is being deprecated, you’ve told them that what they built doesn’t matter. Some of them will accept this professionally. Some will leave. The ones who leave will often be the ones who had the strongest sense of ownership in what they built — which is frequently a proxy for engineering quality.
The right framing is: which platform does the combined company build on, and who gets to be part of building it? That second question matters as much as the first.
The Reporting Structure Question
Who reports to whom is not an HR question. It is the most important signal you can send about how the two organizations will relate to each other.
If you put all of one company’s engineers under a VP from the other company without explanation, you’ve created a first-class and second-class structure even if that wasn’t the intent. People are very good at reading these signals, and they will act on what they read.
A few things that work:
Give both sides early wins in leadership. If the acquiring company’s CTO is clearly running the combined organization, that’s fine — but put leaders from the acquired company into real roles with real authority quickly. Not symbolic roles. Roles where they can make decisions that matter.
Map people to problems, not to org charts. The most effective integrations take the best engineering talent from both sides and form them into teams around specific problems the combined company needs to solve. This creates cross-company working relationships before the merger dynamics have calcified.
Tell people their fate before they ask. If someone’s role is redundant, have that conversation proactively. The conversation is hard, but it is better than the alternative — which is that person spending six weeks doing half-work while they wait for the other shoe to drop, spreading anxiety to their colleagues in the process.
What Loses the Best Engineers
The pattern I see most often: the acquisition closes, there’s a lot of optimism and talk about synergies, and then six months of indecision follow. Stack decisions get delayed. Reporting structures remain provisional. Two separate planning processes run in parallel because nobody wants to force the conversation about consolidation.
In that six-month window, the engineers who had good performance reviews, who could get a new job in two weeks if they decided to, quietly decide to get new jobs. They don’t announce it dramatically. They just leave, one at a time, for the next thing.
By the time the integration team realizes the talent drain is happening, the institutional knowledge is already out the door.
The antidote is not speed for its own sake. It is a concrete 90-day integration plan that answers the questions people are actually asking — who do I report to, what stack are we building on, is my job here — and communicates it clearly and early.
The Metric Nobody Tracks
Track voluntary attrition by month from the acquisition announcement date, separately for each legacy organization. This is the leading indicator that tells you whether the integration is going well or whether you have a quiet crisis developing.
Most companies don’t track this. They track retention at the end of year one. By then it’s too late to do much about what the numbers reveal.
If you’re in the middle of an engineering org merger — or about to be — and you’re not sure you have a plan that will keep the people you need, a 15-minute call with Christopher can help you identify the highest-risk decisions you’re facing and what sequence to address them in. He has navigated engineering integration across multiple acquisitions and knows where the surprises tend to come from.