Engineering Due Diligence: Evaluating the Team, Not Just the Stack

What Engineering Due Diligence Covers

In most software acquisitions, the asset isn't the code. It's the organization's ability to change the code. Engineering due diligence assesses that ability: the team, the delivery process, and the distribution of knowledge that together determine whether the roadmap in the deal case will actually ship.

It's a different exercise from architecture review. Stack choices (which framework, which cloud, which database) matter at the margins. They rarely predict post-close outcomes. A company on a fashionable stack with monthly deploys and one indispensable engineer is a worse technology asset than a company on a dated stack that ships daily with knowledge spread across the team. The stack can be modernized. A dysfunctional delivery organization is far harder to buy your way out of.

This page covers the people side of technology due diligence: reading a team's real delivery capability from evidence rather than testimony.

Delivery Metrics: Is the Team Actually Shipping?

Delivery evidence beats delivery narrative. Four measures, all recoverable from systems the team already uses:

• Deploy frequency. How often code reaches production. The DORA research program (DevOps Research and Assessment) has published delivery benchmarks for years: elite teams deploy on demand, often several times a day, while low performers ship monthly or less. For a SaaS business, below once a week suggests heavy process or fear of breakage. Below once a month, releases have become organizational events, and every roadmap estimate should be treated with suspicion.
• Review turnaround. The time a proposed change waits for review and merge. Under 48 hours is a reasonable working bar. Week-long queues mean either too few reviewers or a culture reluctant to approve anything, and both slow every future initiative.
• Sprint completion. The share of planned work finished in its planned window. Teams in good shape land 70 to 85 percent. Persistent completion under half signals chronic over-commitment or blocked execution. The trend is more telling than any single number.
• Unplanned work share. The fraction of capacity consumed by firefighting: urgent fixes, escalations, ad hoc requests. Past roughly 40 percent, the team is running to stand still, and strategic work is structurally crowded out.

Knowledge Concentration: The Bus Factor Test

The bus factor of a system is the number of people who would have to leave before it becomes unmaintainable. For any revenue-critical system, a bus factor of one is unhedged risk that no retention bonus fully covers.

Concentration is measurable. Contributor distribution per module shows whether one engineer authored more than about 30 percent of the codebase, or is the only person who has ever touched the billing pipeline, the data layer, or the deployment tooling. Runbook authorship and on-call rotas tell the same story from the operations side.

Why it matters most at close: acquisitions trigger reassessment. New owners, new priorities, new managers. If the one engineer who understands revenue processing decides this is the moment to move on, the company can't bill until someone reverse-engineers their work. The diligence output here is concrete: a named list of concentration points, each with a retention plan or a knowledge-transfer plan, priced into the first hundred days.

The Engineering-Product Seam

Roadmaps are written at the seam between product and engineering. If the two functions barely talk, the roadmap describes a negotiation that hasn't happened yet.

The seam is observable without reading anyone's messages. Interaction records show whether engineers and product managers work together continuously or meet only at sprint boundaries: who talks to whom, in which channels, at what cadence. Patterns, not content. When the only contact is a planning ceremony every two weeks, the functions are operating in parallel. Engineers build to spec without context. Product specifies without understanding constraints. The output is rework, missed expectations, and a roadmap that reflects neither customer need nor technical reality.

In interviews, test the seam directly. Ask a product manager what the engineering team is worried about. Ask an engineering lead what the top customer complaint is. Fast, specific answers indicate a working seam. Blank looks are a finding.

What the Repository Records Reveal

A handful of further signals, all structural:

• Commit distribution. Healthy teams show many contributors committing steadily. Warning signs: two or three people producing most of the output (concentration), long quiet periods ending in frantic pushes (planning failure), or a slow decline in overall activity (overhead or disengagement).
• Pull request dynamics. One or two reviewers, substantive comments, merges within a day or two: collaboration working as designed. Five reviewers, style debates, week-long stalls: process theater.
• Pipeline health. Build success below about 85 percent points to fragile tests or unstable infrastructure. Rollbacks above 5 percent of deploys point to weak pre-release quality control. Build times lengthening quarter over quarter are debt accruing in the pipeline itself. For the deeper liability read, see technical debt assessment.
• Time to first deploy. How long a new engineer takes to land a first production change. Around two weeks is strong. Past six weeks, expect undocumented systems, difficult development environments, or a culture that gates junior contribution. All three depress future hiring returns.

Questions That Get Honest Answers

Evidence changes the quality of interviews. Generic questions ('how does the team collaborate?') produce rehearsed answers. Questions anchored to the target's own records produce real ones.

• 'Deploy frequency halved over the last two quarters. What changed?'
• 'These four files are touched in nearly every release. What lives there?'
• 'Reviews sat a median of six days last quarter. Where's the bottleneck?'
• 'Your last three hires took two months to first deploy. What's in the way?'

Management teams answer differently when they know the questioner has already read the evidence. Not because anyone intended to mislead, but because specific questions license specific answers. The interview stops being a performance and becomes a diagnosis.