Last updated: October 6, 2026
By Kris Drouet, Engineering Executive, in partnership with KORE1
Post-acquisition engineering integration works when you merge how decisions get made before you merge code or org charts, which means one definition of done, one written priority list, and one named venue for cross-team calls within 100 days. The repositories can wait a year. The engineers who carry the acquired system in their heads will not wait that long.
“Nothing is going to change.”
Every acquirer says it on day one. Most of them mean it kindly. And every engineer in the acquired company hears the same thing underneath it, which is that something is going to change and nobody will tell them what or when. So they start updating their LinkedIn profiles at lunch. Not all of them. The ones you can least afford to lose, usually, because they’re the ones recruiters already call.
I’ve watched this from both chairs. Once as the leader whose team had just been bought, sitting in a town hall where the acquiring CTO put up a slide titled “One Platform” eleven days after close. Later as the person on the buying side who had to stitch two engineering orgs into one without breaking the product that justified the price. The second job is harder. Not technically. The technical part is mostly sequencing.
The hard part is that you are inheriting two operating systems at once. If you’ve read my piece on inheriting an engineering team you did not hire, the diagnosis there still applies, but an acquisition doubles it. You don’t just have a predecessor’s rules running in one org. You have two sets of rules running side by side, both of them working, both of them invisible to the people inside them, and a calendar that starts the morning the deal closes.
This piece starts where what acquirers check in technical due diligence stops. The diligence report is signed. The money moved. Now somebody has to run engineering. I’m also not covering retiring the seller’s ERP, payroll, and identity systems, which is its own discipline and has its own post-acquisition systems integration playbook. This is about the people who write the software and the rules they use to decide things.
What Post-Acquisition Engineering Integration Actually Covers
Post-acquisition engineering integration is the work of turning two engineering organizations into one that plans, decides, and ships together after a deal closes. It covers leadership, leveling, decision rights, priorities, on-call, and, last, the sequencing of any technical consolidation.
Notice what’s last. Most integration plans I’ve been handed put the stack first, because the stack is what the deal model priced and what the diligence team spent six weeks reading. Kubernetes versus ECS. Postgres versus SQL Server. Two CI systems. Two observability bills. Those decisions matter, and some of them will save real money. They’re also the easiest decisions to get right later and the most expensive ones to get wrong early.
The Research on Acquired Engineers Is Not Encouraging
Start with who leaves.
J. Daniel Kim, then at MIT Sloan, matched U.S. Census employee records across about 4,000 high-tech startup acquisitions between 1990 and 2011, roughly 350,000 workers. In the first year after the deal, 33% of acquired workers left, compared with 12% of regular hires with similar skills and experience, as MIT Sloan summarized the findings in 2019. His Census working paper points to a preference mismatch, since acquired employees never chose the new employer, and finds the ones who leave are more likely to start companies of their own, many of which look like competitive threats to the acquirer. Nearly three times the attrition. That’s your baseline before you’ve made a single mistake.
The people who stay don’t come through untouched either. Paruchuri, Nerkar, and Hambrick tracked 3,933 inventors at acquired pharmaceutical companies and found that integration generally dragged their productivity down, with the steepest drops among those who lost the most status and centrality in the combined company (Organization Science, 2006). Read that one twice if you’re about to publish a new org chart. The engineer who used to be the person everyone asked about the pricing engine, and who is now one of forty names under a director she’s never met, is exactly the profile that study describes.
Then there’s speed. Puranam, Singh, and Zollo studied technology acquisitions and found that structural integration lowered the chance of launching new products immediately after the deal, an effect that faded as the acquired firm’s innovation path matured (Academy of Management Journal, 2006). Fold them in fast and you slow them down. Probably for a while.
One more, and it’s the hopeful one. Kapoor and Lim looked at inventors at acquired semiconductor firms and found productivity held up better when the two companies had greater overlap in routines and moderate overlap in skills (Academy of Management Journal, 2007). Routines. Not tools. How work moves, who signs off, what counts as finished. That’s the part you can actually change in 100 days.
Those are academic samples, mostly pharma and chips, mostly a decade or more old. I wouldn’t bet a board deck on the exact percentages for a 60-person SaaS team. The direction, though, matches everything I’ve seen in the room.
Run the Clarity Stack on Both Orgs Before You Touch Either
The most common thing I see when I walk into a struggling engineering org isn’t a technology problem. It’s a clarity problem. I wrote up the three layers in the Clarity Stack. Nobody agrees what done means, priorities aren’t written where the team can see them, and decisions happen in hallways instead of systems. A merger takes all three layers and runs them twice, once per org, and the two copies almost never match.
So before the integration team draws a single box, I interview both sides with the same questions. Separately. Same wording. Five or six engineers from each org, picked across levels, plus each engineering leader.
| Clarity Stack layer | Ask both orgs, separately | What a mismatch usually looks like | Settle it by |
|---|---|---|---|
| Definition of done | “When you say a feature is done, where is it running, and who has used it?” | One org means in production behind a flag. The other means merged and handed to QA. | Day 30 |
| Written priorities | “Show me the list you would defend to the CEO this week.” | The acquired company has three lists, the founder’s, product’s, and the backlog, and they disagree. | Day 45 |
| Decision venues | “Who made the last architecture call, and where did it happen?” | One side has an architecture review with written records. The other side has a founder’s DMs. | Day 45 |
| Escalation (the fourth question I always add) | “At 2 a.m., when the payments service breaks, who gets paged, and who can roll back?” | Three people on the acquired side carry the whole rotation and nobody on the buying side has prod access yet. | Day 10 |
The definition-of-done row is the one that bites first. In one integration I worked on, the acquired lending team’s Jira workflow closed a ticket when the change was live for real users behind a feature flag. The parent company closed tickets at merge. Both orgs reported “done” in the first combined roadmap review. The board heard production. About two weeks of real work sat in the gap between those two meanings, across every feature on the slide, and nobody lied. Same word. Different software.
That’s why I don’t trust the integration status report until both sides have signed one definition. Show me the data, sure. But show me what the data’s counting first.
The 100 Days, Stretch by Stretch
A hundred days is arbitrary. It’s also about right. Long enough to settle the rules, short enough that people don’t stop believing there’s a plan. Here’s how I split it.
| Stretch | What you’re doing | What you’re deliberately not doing yet | Gate before moving on |
|---|---|---|---|
| Days 0 to 10 | Name one accountable engineering leader for the combined org. Hold a one-on-one with every acquired engineer who owns something nobody else understands. Give prod access and paging to at least two people on the buying side. | Titles, reporting lines, tools, repo moves. | Every key-person name has had a real conversation, logged, with a date for the next one. |
| Days 11 to 30 | Run the Clarity Stack interviews in both orgs. Agree one definition of done. Merge escalation paths for incidents, not on-call rotations. | Merging teams. Announcing a target architecture. | One written definition of done, signed by both engineering leads. |
| Days 31 to 60 | Settle leveling, one person at a time. Publish the decision map. Collapse to one priority list. | Codebase consolidation. Mandated stack changes. | Nobody learned their new level from the HR system before hearing it from a person. |
| Days 61 to 100 | Run the first joint planning cycle. Pick one or two integration seams and put a contract on them. Pick one tool per category where the two orgs duplicate each other. | “Rewrite it in our stack” projects. | A combined plan both orgs helped write and both orgs can repeat back. |
Two things in that table get skipped constantly.
The first is prod access in week one. Acquirers delay it for good reasons, mostly security review and SOC 2 scoping, and then discover at 2 a.m. on day 19 that the only people who can roll back the acquired platform are the same three engineers who are quietly interviewing elsewhere. Fix the access. Scope it tightly if you have to. But fix it.
The second is the gate column. Most 100-day plans I’ve been handed are activity lists, a column of meetings held, workshops run, and slides presented, with no line anywhere that says what has to be true before the next phase is allowed to start. I want a yes or no at the end of each stretch, and if the answer is no, the next stretch waits. No exceptions. It’s uncomfortable to tell a CEO that day 31 is starting late. It’s a lot more uncomfortable to explain on day 140 why two seniors resigned in the same week.
Leveling Is Where You Lose People
Titles look administrative. They aren’t.
A five-year-old startup and a fifteen-year-old platform company do not mean the same thing by “Senior Software Engineer.” At the startup it might mean four years of experience and owning a service end to end. At the parent it might mean eight years and a calibrated level with a promo packet behind it. So the HR integration team builds a mapping spreadsheet, applies it in bulk, and pushes it into Workday on a Friday.
I watched that happen once. Two of the acquired company’s best backend engineers logged in on Monday and saw “Software Engineer II.” No one had talked to either of them. Their pay didn’t change, which the HR lead kept pointing out, as if pay were the point. Both had offers by day 70. One of them was the only person who understood the escrow disbursement service end to end, and none of it was written down because nobody had ever needed it to be. We spent the next two quarters reverse-engineering it. It was load-bearing spaghetti, the kind nobody planned. It just grew until everything held everything else up.
That’s the Paruchuri finding playing out live. Lost status. Lost centrality. Lost engineer.
What I do now:
- Map on scope and impact, not years. What does this person own, what breaks if they leave, how many teams depend on decisions they make? A four-year engineer who owns the ledger service can be more senior than an eight-year engineer who owns a reporting page.
- Nobody sees a new level in a system before they hear it from their manager. Ever.
- If the honest mapping is a step down in title, say so out loud and explain the path back, with a date for the first review. People can take bad news. What they can’t take is finding out from a dropdown.
- Check pay against the market, not just the parent’s bands. Acquired engineers often sit below band because the startup traded salary for equity, and the deal just turned that equity into cash or into nothing. Run the roles through a salary benchmark before the conversation, not after the resignation.
- Protect the key-person list. Five to ten names, usually. Their managers check in every two weeks through day 100.
Retention bonuses help some. They buy time. That’s all. They don’t buy the reason someone stays, which is usually that they still own something that matters and the people around them still know it.
Who Decides Now? Write It Down by Day 45
This is the third layer, and it’s where merged orgs stall quietly.
Before the deal, the acquired company’s founder-CTO decided most architecture questions in about ten minutes, usually in a DM. After the deal, he’s a VP reporting to someone he hasn’t met, the parent has an architecture review that meets every other Thursday, and nobody has said which forum owns the acquired platform’s decisions. So questions go to both. Or neither. Engineers learn quickly that the safe move is to wait, and waiting looks a lot like a velocity problem from the outside. Nobody says it out loud.
The fix is boring. It works. Write the decision map. Every recurring decision type, from schema changes to vendor contracts to on-call policy, gets one owner and one venue, published where both orgs can read it. I use the two-axis version from the decision ownership diagram. Reversible, local calls stay with the team that does the work, and one-way doors go to a named person with a named forum. For a merger I add one rule on top. Until day 100, the acquired platform’s internal architecture stays with the acquired team’s lead, unless the change crosses a boundary into the parent’s systems. That one sentence has saved me more arguments than any slide.
Priorities get the same treatment. One list, written, ranked, visible to both orgs, owned by one person who can say no. If you’ve seen why engineering priorities have to live in writing, you know the argument. In a merger it’s sharper, because the acquired team’s old list still lives in a founder’s head, every engineer there knows exactly what’s on it, and some of them will keep working from it until somebody publicly retires it.
Leave the Codebases Alone Longer Than Feels Comfortable
The deal model probably assumes platform consolidation. Somebody in finance has a synergy number with “infrastructure” next to it. That pressure is real, the number may even be right eventually, and you shouldn’t pretend otherwise to the CFO, because the fastest way to lose finance as an ally is to treat their synergy line as somebody else’s problem.
But the Puranam research and my own experience point the same way. Force structural integration early and new product work slows down right when the acquirer most wants to see it. So in the first 100 days I don’t merge repositories, swap frameworks, or migrate the acquired product onto the parent’s platform. I put a contract between the two systems instead. An API with a versioned schema, or events on a shared broker. When I moved a set of tightly coupled transaction systems onto a Kafka pub/sub backbone, the decoupling alone cut downstream processing latency by 45%, and it gave both teams a seam they could work on independently. That’s the shape you want after an acquisition. Two teams, one contract, and freedom on either side of it.
Under the hood, the real question is sequencing. Which seam carries the revenue the deal was priced on? Integrate that one first, behind a contract. Leave the rest alone until the people questions are settled.
Duplicate internal tools are the exception. Two feature-flag vendors, two incident tools, two CI systems. Pick one per category by day 100, mostly on cost and migration risk, and accept that the acquired team’s choice will sometimes win. When it does, say so publicly. Loudly. It’s a cheap signal that the merger isn’t a takeover in engineering’s eyes, even when it is one on paper.
There’s one more cost hiding here. Every combined team adds coordination paths, and a merged org adds a lot of them at once. If you’ve read about the coordination tax, you already know why throwing the two orgs into shared standups on day 15 makes everyone slower.
When You Need Outside Help, and When You Don’t
Plenty of acquirers run this well with their own people. If you have a VP of Engineering with integration experience, a stable parent org, and an acquired team under 30 engineers, you probably don’t need us. Honestly.
Where it goes wrong is bandwidth. Your best leaders are already running the parent org, the acquired org’s leaders are distracted or demoralized or both, and the three engineers who hold the acquired platform together are suddenly also the only people who can answer the integration team’s questions. That’s when outside help pays for itself, usually as one of three things. A senior engineer or two embedded to absorb knowledge from the key people before anyone leaves, often through project staffing on a defined scope. An assessment bench like the one on our technical due diligence staffing page, kept on past close for the second window. Or an advisor who has run this before, through our engineering org design advisory.
KORE1 has placed engineering talent for more than 20 years, with a 92% twelve-month retention rate on placements and an average of 17 days to fill IT roles. Those numbers matter in an integration for one reason. If a key person does leave on day 70, the clock to replace their knowledge starts that afternoon.
What Acquirers Ask Me Around Day 40
Should We Merge the Two Engineering Teams Right Away?
Usually not, because merging teams before the rules are settled spreads two operating systems across every team instead of fixing either one.
Merge the rules first. Definition of done, priorities, decision venues. Then merge teams where the work actually crosses, which is rarely everywhere.
Realistically, How Long Does Post-Acquisition Engineering Integration Take?
Settling leadership, leveling, and decision rights takes about 100 days, while any meaningful technical consolidation usually runs twelve to twenty-four months.
Most of the long tail is migration work that only makes sense once the people questions are closed. If someone promises a single platform in a quarter, ask what they plan to stop shipping to get there. There’s always an answer. It’s rarely in the deck.
Theirs or Ours, Who Should Run the Combined Engineering Org?
Whoever the acquired engineers will follow and the parent’s executives will back, and if those are two different people, you have a problem to solve in week one.
Name one accountable leader anyway. Splitting authority between two co-leads is how hallway decisions come back. I’ve seen co-lead structures hold for a quarter, maybe two. Then one of them leaves, and the decision gets made for you, at the worst possible time.
Do Retention Bonuses Actually Keep Engineers From Leaving?
They delay departures more than they prevent them.
A cliff at twelve months tends to produce resignations at twelve months and one week. What keeps good engineers is ownership that survived the deal, a level that reflects what they actually do, and a manager who talks to them before the HR system does. Pay for the bonus if you need the runway. Then spend the runway on those three things.
What Do We Tell the Acquired Engineers on Day One?
Tell them what is decided, what isn’t, and the date by which each open question gets an answer.
Skip “nothing is going to change.” They know it’s false. Something like “titles stay as they are until we’ve talked to each of you individually, which happens before day 45” is specific, true, and checkable. Then hit the date. Every time.
How Will We Know the Integration Is Working by Day 100?
Look for four signals by day 100, which are zero regretted departures from the key-person list, one definition of done both orgs use without translating, a combined plan both sides helped write, and cross-org code reviews nobody scheduled.
That last one is my favorite. You can’t mandate it. It just starts happening, or it doesn’t.
Merge the Rules Before the Repos
An acquisition hands you two working engineering orgs, each with its own unwritten rules about what done means, which list wins, and who gets the last word. The code is the easy part to see and the slowest part to change. The rules are invisible and fast. Get them onto paper in the first 100 days and most of the technical integration turns into scheduling. Skip it, and you’ll spend the second year rebuilding knowledge that walked out in the first.
If you’re in the middle of one of these, or about to sign, connect with me on LinkedIn or DM me there. I’m happy to compare notes. And if the gap is people, whether that’s a bench to absorb knowledge before it leaves or senior engineers who can own a seam from week one, talk to KORE1’s engineering recruiters.
Related reading: The Three Decisions Engineering Leaders Get Wrong in Their First 90 Days, How to Tell If Your Engineering Org Is Actually Slow (vs. Just Tired), and M&A Integration Staffing for the Year After Close.
