Assessing the engineering team

The most common mistake in technical due diligence is treating it as a review of code and forgetting that the code is made by people. The code you see shows the system at one moment. The team produces the next version, and the one after that. If you are investing in a roadmap, you are investing in the team that will build it, so assessing the people is the most important part of the review.

Why is the team the real asset?

The team is the real asset because it is the only part of the company that can produce the next version of the software. A strong senior team with mediocre code is a manageable situation, because good engineers fix code. They see what is wrong, they know how to improve it, and they do. A small or junior team with excellent code is a hidden risk, because as soon as the work gets hard, or a key person leaves, progress stops.

This is why seniority matters more than headcount. A small senior team builds more than a larger junior one, because experience is what lets people move fast and avoid the mistakes that cause rework, an argument we make in full in a small senior team outbuilds a big one. So when you count the team, count the seniority too, and check that the senior people are working on the core of the product rather than working only in management, away from the code. The main guide explains why this finding matters more than any single code finding.

Reveneau's team assessment asks one question of every senior engineer it meets: explain the last decision you got wrong and what you changed afterwards, because how a team handles being wrong predicts how it will behave after close far better than how it presents itself when things are going well.

What is key-person risk, and how do you measure it?

Key-person risk is the situation where one engineer is the only person who understands the core system, so the company's most valuable knowledge can leave with two weeks' notice. The measure is the bus factor: the minimum number of team members who would have to suddenly disappear before the project stops for lack of knowledgeable people.

It is low in most software. A study by Avelino, Valente and Hora of 133 open source systems, cited on the Wikipedia entry for the term, found that 65 percent had a bus factor of two or fewer, and fewer than 10 percent had a bus factor above ten. Commercial codebases built fast around one founder-engineer are often worse, because nobody outside the founder ever needed to know how the core worked.

Question	What a healthy answer sounds like	What a risky answer sounds like
If this one person left tomorrow, what would happen?	"We would slow down on X for a month; Y and Z have both released changes there."	"We would be in trouble."
Who else has changed the most critical part of the system in the last quarter?	Two or more names, with pull requests to show it	One name, or "nobody needs to"
Where is the knowledge written down?	A design document, runbooks, a specification that is kept current	"It is all in the code" or "ask her"
Who is on call for the core service?	A rotation of three or more	One person, always
Who can deploy to production?	A documented process anyone on the team can run	One person with the access

Ask the questions directly, then check the answers against the repository: the commit history for the core service will show whether two people have changed it. This finding is serious enough that it is first on the warning signs page, because it can move a deal from "price the fix" to "reconsider the terms". At the earliest stage, where one developer is the norm, the single developer risk page in the angel guide covers what to ask instead.

Why can hiring not fix a late roadmap?

Hiring cannot fix it because of Brooks's law. Fred Brooks stated it in his 1975 book The Mythical Man-Month: adding manpower to a late software project makes it later. The reasons he gave still apply. New people take time to become productive and need the existing team to teach them, which reduces the existing team's output. The number of communication paths grows faster than the number of people. And some work cannot be divided, which Brooks illustrated with the observation that nine women cannot make a baby in one month.

This matters in diligence because the fix for a small team is often written in the deal model as "hire ten engineers in the first year". Brooks's law says that plan slows the roadmap before it speeds it up, and the why adding engineers can slow you down page in the scaling guide covers the reasons in detail. The realistic plan adds senior people slowly, in areas where the work can be divided, and expects productivity to fall for a time while it happens. Price that fall.

How do you assess seniority without running interviews?

You form a judgment from a few conversations and the artifacts, without a full hiring process. Four approaches work.

1. Ask for a hard decision, explained in plain language. Strong engineers explain the options, the choice, and the trade-off clearly. A team that answers with jargon or cannot explain its own decisions is a warning. Clear explanation comes from clear thinking, which is what you are testing.
2. Ask how they handle being wrong. What did they do the last time a plan turned out wrong mid-project? A mature team treats that as normal, catches it early, and adjusts. A team that hides problems, or argues against every change, will do the same after you invest.
3. Read the pull request history for who reviews whom. Senior engineers appear as the people whose reviews change other people's code. If nobody's review changes anything, nobody is acting as the senior engineer, whatever the titles say.
4. Ask an outside reference how the work performed over time. Someone who inherited or maintained the code will tell you whether it stayed cheap to change, which is the outcome that seniority produces. This is the same standard we apply when we measure engineers by outcomes rather than output.

For a target whose technical founder is the team, the evaluating a technical founder page covers the version of this that fits a one-hour conversation, and what to look for in a CTO hire covers the profile itself.

What does the org structure tell you about the system?

It tells you how the software will be structured. Conway's law, stated by Melvin Conway in 1968, observes that organisations that design systems are constrained to produce designs that are copies of their own communication structures. Three teams that do not communicate will produce three components that do not communicate. A single team that owns everything will produce a single system with no clear divisions.

In diligence this works in two directions. If the architecture assessment found a disorganised system, look at whether the teams are disorganised too, because the fix may be organisational rather than technical. If the deal plan splits one team into several, expect the system to split along the same lines, and check that the boundaries in the plan match boundaries that exist in the code. The structuring engineering teams page covers the organisation side.

What do tenure and turnover tell you?

They tell you whether the culture works. High turnover in engineering is a signal worth understanding, because people are leaving for reasons that will repeat after close. A team that has stayed and grown together usually means the culture works. Ask how long the key people have been there, why past engineers left, and whether any of them left in the last six months. Ask whether anyone is on notice or negotiating.

Engineering culture sounds hard to measure, but it has measurable effects. A culture that releases often, tells the truth about problems, and writes things down produces good software over time. A culture that skips necessary steps, hides bad news, and depends on a few people working extra hours to save each release produces the opposite, no matter how talented the individuals. You can judge culture from how the team answers your questions: openly and specifically, or defensively and vaguely.

How does the team work with AI, and what should you check?

Check whether the team has a method for catching what the model got wrong, because almost every team uses the tools and the risk is in the checking. Stack Overflow's 2025 survey of more than 49,000 developers found 84 percent using or planning to use AI tools, 46 percent distrusting the accuracy of the output against 33 percent trusting it, and 66 percent naming "almost right" solutions as their biggest frustration. Google's October 2024 DORA report associated a 25 percent increase in AI adoption with a 7.2 percent decrease in delivery stability.

Ask who reads the generated code before it merges, what tests or evaluations run against it, and whether the specifications the code was generated from still exist. A team that can show an evaluation suite running is a team that has solved the problem; the eval-driven development hub explains what to look for, and the assessing code quality page covers the repository-level checks. A team that says the model writes it and the team releases it, with nothing in between, has an unmeasured risk rather than a fast process.

How do you put the team finding in the deal?

Use it in two places: the confidence you have in the roadmap, and the plan for the first hundred days.

Finding	What it means for the roadmap	What goes in the plan or the terms
Senior team on the core, bus factor of three or more	The ambitious plan is believable	Retention for the people the plan depends on
Bus factor of one on the core system	One resignation could stop the roadmap	Knowledge transfer as a condition, retention terms, a second engineer on the core in ninety days
Junior team with good process	The plan works if the senior hires join	Senior hires or a partner team priced into year one
Plan depends on doubling headcount in a year	Brooks's law says the roadmap slows first	Slower hiring plan, a priced fall in productivity
Turnover in the last six months among seniors	Ask why before believing the roadmap	Exit interviews or references before close
AI-written code with no verification method	Speed claims are unmeasured	An evaluation suite in the pipeline, priced

If the plan is to grow the team after close, the scaling engineering teams guide covers how to do it without breaking what works, and the technology after the deal guide covers how the team plan becomes the hundred-day plan. The technical due diligence checklist lists the team questions in a form you can take into the meeting.