How to read an engineering organization before an acquisition: a tech-DD guide for M&A teams
“Once the conversation turns technical, I lose the thread.” “When the CTO presents, I cannot tell whether what I’m hearing is the truth.” These are common, candid admissions from M&A deal teams and corporate-development professionals. The good news is that even without deep technical chops, once you can frame the right questions, you can read a target company’s engineering organization with confidence.
Why non-engineers can evaluate engineering
Technical quality shows up less in the elegance of the code than in patterns of decision-making. Strong engineering organizations can clearly articulate “why we chose this.” Dangerous ones default to “we just did,” “it was popular at the time.”
Put differently, evaluating engineering is not about judging whether the answer is correct — it is about whether the thinking process is sound. That lens does not require technical knowledge.
Three quantitative metrics to check before the meeting
Evaluation begins before the first interview. The following are objective data points you can confirm without hearing a single verbal explanation.
1. Deployment frequency
Deployment is the act of releasing the code an engineer has written so that it actually runs in the user-facing service. It happens every time the team ships a new feature or fixes a bug.
Look at deployment along three dimensions, in order.
(1) The deployment lifecycle (what process the change goes through)
Look at the path a change takes from commit to production. The presence of automated tests, code review, and structured approval reflects organizational maturity. Heavy manual steps that only certain individuals can perform are a strong signal of key-person risk.
(2) Lead time (from code change to production)
How long it takes a single change to travel from an engineer’s machine to actual users.
| Lead time | Assessment |
|---|---|
| Hours to one day | Excellent. Strong automation in place |
| Two to three days | Acceptable. Review process is functioning |
| More than a week | Caution. Suggests approval bottlenecks or heavy manual work |
| Multiple weeks | Red flag. The process is broken |
(3) Deployment frequency (how often releases happen)
Read this together with lead time. Short lead times combined with high frequency are the ideal pattern. Note that appropriate cadence differs between B2C consumer services and B2B enterprise products, so always interpret in context with the business model.
| Frequency | Assessment |
|---|---|
| Daily to several times a week | Healthy. Continuous improvement loop is working |
| Weekly | Acceptable. Reasonable for a growth-stage company |
| Once a month or less | Caution. Likely fear of deploying |
| Only “big-bang releases” | Red flag. Suggests significant accumulated technical debt |
When an organization is afraid to deploy, it is telling you that the team lacks confidence in code quality and cannot reason about the blast radius of changes.
2. Engineer attrition
Ask how many engineers have left over the last two years. Industry data generally puts engineer attrition in the IT and software sector around 15–20% annually (see, for instance, the U.S. Bureau of Labor Statistics’ Job Openings and Labor Turnover Survey and Japan’s IPA DX White Paper, among other industry surveys). Sustained rates well above this — over 30% per year — suggest structural problems in the engineering organization. That said, the right benchmark depends on company stage, size, and hiring strategy, so always pair the number with the qualitative reasons for departures.
Common reasons engineers leave:
- Too much technical debt makes them unproductive (“I want to fix it but I cannot”)
- Opaque decision-making and a lack of technical autonomy
- Misalignment with the CTO’s direction
3. Hiring channels and offer-acceptance rate
Look at the share of candidates who accept offers. The best engineering organizations are the ones that strong engineers choose. Reputation inside the engineering community is invisible from the outside, but you can read it indirectly through “where they hire from” — particularly the share of referrals.
Four lenses to use during the interview
In the interview, look for a healthy thought process rather than the “right” answer. Are technical decisions grounded in reasons? Can the leader honestly admit uncertainty? Do they have a concrete grasp of the issues? These are observable without technical knowledge. Use the four lenses below to organize what you hear.
Lens 1: Quality of technical decisions
Judge along three dimensions: technology choices, pivots, and awareness of current problems.
- Reasoning behind technology choices: Are the chosen technologies and tools tied to a business problem? “Because it was popular” or “because I like it” tends to become debt as the organization grows.
- Experience with pivots: Can the leader discuss past failures and major direction changes concretely? A CTO who only says “everything is going well” either does not see the issues or is not being honest.
- Awareness of current problems: Can they name “the things I want to fix right now” on the spot? “Nothing in particular” is a sign of weak situational awareness.
Lens 2: Organizational and process maturity
Examine how the engineering team operates day to day.
- Onboarding speed: How many days does it take a new engineer to ship code to production for the first time? One to two weeks is the benchmark; longer than a month suggests gaps in documentation or process.
- Incident response: How does the team detect and address serious outages? “We don’t have outages” needs scrutiny — is that plausible at the company’s scale? Whether incidents are recorded and reviewed (post-mortems) reflects organizational maturity.
- Surfacing technical risk to the executive team: Is there a path for engineers to escalate technical concerns to leadership? “The CTO decides everything” tends to mean ground-level risks never reach the top.
Lens 3: Readiness for scale
Assess whether the technology can keep up with business growth.
- Awareness of bottlenecks: If users or transactions grew 10x today, where would the system break first? “We’ll be fine” without specifics is far less credible than “this is the bottleneck and here is the plan.”
- Third-party risk: Do they understand the dependence on external services for payments, authentication, and infrastructure, and the impact if any one of them goes down? Over-reliance on a single provider is a direct continuity risk.
Lens 4: Future investment posture
Look at how the engineering organization will function during growth.
- Allocation of technical investment: After acquisition, how does the team plan to split investment between infrastructure improvement and feature work? Organizations that perpetually defer infrastructure work see velocity decay as they grow.
- Concreteness of organizational scaling: Can they describe next year’s hiring plan, organizational structure, and stack changes as one connected picture? Strong CTOs don’t separate these three.
Translating findings into the deal decision and PMI
After assessing the four lenses, the next step is to synthesize the findings into action.
The right unit of judgment is the pattern, not any single answer
Don’t decide on the basis of one response. Read the pattern that emerges across all four lenses. What matters most is not “what they know” but how accurately the organization understands its own current state.
Engineering organizations that can articulate both strengths and weaknesses concretely have actionable plans. Conversely, when every lens produces only optimistic answers, the team either lacks awareness of the issues or is unable to speak about them with accountability. Either case makes post-acquisition integration harder.
What the gaps tell you about PMI design
Gaps revealed in the evaluation can become reasons to walk away or material for price negotiation, but they are also clues for designing post-acquisition integration.
Treating technical evaluation as a pure go/no-go decision misses much of its value. Reframing the question as “how do we support this organization so that it grows?” ties directly into post-PMI value creation. Below are concrete plays and case examples by lens.
When there is a gap in decision quality
Key plays
- Engage a fractional CTO one to two days a week to co-design a process for structuring the rationale behind technical decisions.
- Introduce a habit of recording technical decisions, such as Architecture Decision Records (ADRs).
- Set up a monthly cadence in which the target shares “the major technical decisions and the reasoning behind them” with the buyer’s team.
Example
In an interview, the CTO could only justify the technology stack as “everyone uses it.” After close, weekly 1-on-1s were set up with an external technical advisor. Within six months, 30 ADRs had been recorded, and the rationale for technology choices could be explained in PMI reviews.
When there is a gap in organizational process
Key plays
- Make the hiring of an engineering manager a PMI condition within 90 days of close.
- Build out onboarding documentation as a defined milestone.
- Introduce incident response templates (post-mortems) as part of PMI support.
Example
New engineer onboarding averaged 45 days, with all the load resting on a single lead engineer. Hiring an EM was set as a PMI condition, and the onboarding process was redesigned after that hire. Within three months onboarding dropped to an average of 10 days, freeing the lead engineer to return to feature work.
When there is a gap in scalability readiness
Key plays
- Run an external architecture review before close.
- Model infrastructure cost across user and transaction growth scenarios and share at the board level.
- Set scaling bottlenecks and remediation status as a recurring PMI agenda item.
Example
Asked about a 10x user scenario, the team only said “we’ll be fine,” with no specifics. As supplemental DD, an external technical expert ran an architecture review and surfaced an N+1 query problem in the database. Performance improvements were added as a milestone in the closing conditions.
When there is a gap in future investment posture
Key plays
- Negotiate the share of post-acquisition technical investment allocated to infrastructure improvement as a deal term.
- Add the technology roadmap to quarterly board reviews.
- Run a technical debt visibility exercise (such as a scorecard) every six months and track velocity changes.
Example
The post-close technical investment plan allocated 100% to feature development. After board discussion, a milestone was set to direct 20% to refactoring legacy code. Twelve months later, deployment frequency had improved from once a month to three times a week.
Wrap-up
Even without specialist technical knowledge, you can evaluate a target’s engineering organization if you have a structured way to frame the questions. To recap:
- Start with quantitative metrics — deployment lead time, frequency, attrition, and offer acceptance rates are observable before any interview.
- Organize the discussion around four lenses — decision quality, organizational process, scalability, and future investment posture.
- Watch the thinking process more than the content of the answer — does the leader admit uncertainty, do they reason from evidence?
- Bring in outside expertise when self-assessment hits its limits — when technology is at the core of competitive advantage or the system is complex, external technical DD is well worth the investment.
Get in touch to discuss specific evaluation approaches.