Integration Stalls on Engineering Capacity the Plan Didn’t Count

In a software buy-and-build, integration is typically treated as a matter of post-close execution. Most of the time, though, it doesn’t get done during the hold period. An EY-Parthenon analysis of 180 software companies assessed during diligence between June 2020 and March 2022 found that 75% of them lacked a cohesive, integrated product portfolio, including a majority of those that had made an acquisition in the prior three years.¹ In 19 years leading engineering teams, I’ve watched integration stall because the plan counted on engineering capacity that was already spoken for. Technical due diligence can measure that shortfall before the deal is underwritten.

Integration plans estimate the integration work. They rarely account for everything else the team has to deliver. Much of this work is committed, and can’t simply be deferred since the base case depends on it. I’ve repeatedly seen engineers double-counted between feature work and integrations.

The most visible commitments include features promised to customers, retention initiatives, compliance obligations, and work in flight. In addition, a portion of engineering bandwidth must go to keep-the-lights-on work, such as addressing bugs, support escalations, security issues, and software updates. This is the less visible subset of work, which often lives in work tickets rather than a product roadmap.

Integration ultimately gets the bandwidth that remains after commitments and maintenance — which is frequently none.

Worse yet, the deferral cost compounds over time. Engineers end up building and maintaining duplicate features across products, using bandwidth that the integration needed in the first place. Every add-on adds another set of duplicates to build and maintain. The features get prioritized because they’re small enough to fit into a short-term plan. The integration gets deferred because it requires more people, time, and tradeoffs against other priorities.

The team’s delivery record is the test

How can you tell whether the team can support the integration, and when? First, ask for a view that shows all anticipated engineering work, the total required engineering time per initiative, and the allocated headcount by team and time period. I’ve rarely seen companies produce a realistic, unified view of the engineering allocations.

If management can lay out the work in this manner, the next step is to validate it against how those teams have actually delivered in the past. The evidence sits in documents such as project trackers, slides from past board decks, and release notes, as well as in the CTO’s own account of what last year’s roadmap promised and what actually shipped. If past work has frequently run behind schedule, the size of those overruns becomes the adjustment factor for the plan’s timelines.

New capacity arrives later than the plan assumes

If the integration work can’t be slotted into the existing plan in an acceptable timeframe after cutting any projects that don’t fit the new strategy, one option is additional hiring. I’ve seen value creation plans oversimplify this approach. The key omissions are typically the time to recruit and hire qualified candidates and the time to onboard them once they’re in seat. You can project the team’s realistic growth from the company’s hiring history, the size of its recruiting team, and the number of positions to fill.

Onboarding costs more than the time it takes for a new engineer to become productive. The factor I’ve seen missed in nearly every case is that experienced engineers spend time training new hires, so the team slows down before it speeds up.

Changing how the team works with AI is another way to add capacity, and for a team without mature practices it’s a real opportunity. Like hiring, though, it pays off on a schedule. Gains the team has already realized show up in its delivery record. Gains from new practices arrive later, after investment and a ramp, and that’s when the plan should start counting them.

Without the guardrails of a full accounting of engineering capacity, an integration timeline is little more than guesswork. A full engineering forecast, covering feature, maintenance, and integration work along with the time to hire and help new engineers become productive, has been one of my most valuable tools as an engineering leader. Before close, it’s what shows a buyer the real timeline and cost of the integration.

I now build that forecast for software acquirers as part of technical due diligence.