In a technology deal you are buying the team as much as the product, and the team is the one asset the data room cannot show you. Financials and code reviews arrive as documents; capability, key-person risk and behaviour under pressure arrive as people, and people can be staged for a visit. This post is the sequence we run instead: four artefacts to request in week one, three interviews that are hard to stage, what the Saudi regulatory picture reveals about a team, and a worked example of the findings’ effect on a term sheet.
Why the data room cannot answer the team question
The cost of getting this read wrong is not soft. Across roughly 40,000 deals over 40 years, about 70 to 75% of mergers and acquisitions fail to create value, and inadequate due diligence is cited in around 31% of those failures (Fortune, 2024). People who matter walking out after close is a quiet driver of that number, and it never appears as a line in the data room.
In our experience the team assessment is nonetheless the softest part of most processes: two founder meetings, a demo, a reference call the founders arranged. The fix is artefacts before interviews, because artefacts are produced in the normal course of work, by the whole team, not just the two people briefed for your visit.
Four artefacts that speak before the founders do
Request these in week one. Every functioning engineering organisation produces all four, and reluctance to share any of them is itself a finding.
- The commit log. A year of version control history on the core repository, author names included, laid beside the payroll. You are looking for who actually builds the thing: contribution concentrated in one or two names, blocks of work from accounts that match nobody on the org chart, or a core largely written by people who have left. The red flags in a startup’s codebase usually surface here first.
- The incident log and the on-call rota. How a team writes up outages, and who is rostered to receive them, says more about maturity than any framework. Blame-free post-mortems and a rota that genuinely rotates are the marks of a team that survives growth. An empty log is a finding either way: nothing has ever broken, or nobody writes anything down.
- The cap table read beside the org chart. Vesting schedules next to names next to systems. Anyone whose equity fully vests at close has a rational reason to leave the week after; anyone critical who holds none at all has one already. That is not cynicism, it is pricing.
- The hiring history. How long the last three engineering searches took, who interviewed, and who has left in the past two years. A team that cannot hire cannot deliver a roadmap that assumes headcount, and attrition among the strongest engineers is the earliest culture signal you get.
flowchart TD
A(["Commit log"]) --> E{"Capability present and staying?"}
B(["Incident log and rota"]) --> E
C(["Cap table beside org chart"]) --> E
D(["Hiring history"]) --> E
E -->|Yes| F(["Back the team on evidence"])
E -->|No| G(["Reprice, add lock-ins, or walk"])
Match capability to the next stage, not the last one
The artefacts settle who built what. The interviews settle whether those people can build what comes next, and the gap between the two is where most team assessments fail. You are not funding the past: selling to enterprises, winning government work or running a second region uses different muscles from launching a product, and a team that reached fifty customers on heroics may have nothing in its toolkit for five thousand.
- Ask for the story, not the claim. “Have you scaled?” gets a yes. “Walk me through the last major deployment: what broke first, and what changed afterwards?” produces detail or fog, and fog is a finding.
- Interview engineers the founders did not select. Choose three to five names from the commit log, include one junior, and keep the founders out of the room. Ask what you asked the founders: what is the worst part of the system, and what would you rebuild first. When the answers line up you have honesty at both levels; when they do not, believe the engineers.
- Call the most recent departure. The engineer who left last year will take a reference call more often than you would expect, and ten minutes with them stress-tests every story you have been told. In our experience this single call has saved and killed more deals than any pitch deck.
- Find the bottleneck dressed as a strength. A CTO who is still the best coder on the team and reviews every pull request is a single point of failure with a job title. Ask who decides architecture, who says no to sales, and what happens when those two disagree.
Read the regulator as a team signal
In the Kingdom the next stage usually brings a regulator with it, and how a team relates to that regulator is a capability read, not a compliance box. Selling into government means Etimad, whose technical requirements reward teams that have lived through a tender before; ask for the story of their last one. If the target handles personal data, full compliance with the PDPL has been required since 14 September 2024, with SDAIA as the regulator (Morgan Lewis, 2024). A named owner with a cross-border transfer assessment done is a team that runs things; “we’ll handle it after the round” is a team that does not. A fintech target should know precisely where it stands with SAMA. Vagueness about a regulator is never only about the regulator.
A worked example: what the evidence did to a term sheet
Say you are leading a growth round into a 24-person Riyadh SaaS company whose next stage is selling to banks. The numbers are made up to show the shape.
The commit log is healthy: four active authors on the core service, review comments that argue about trade-offs, and real post-mortems in the incident log. But the cap table beside the org chart shows the co-founder CTO is the only person who can safely touch the payments integration, his shares vest fully at close, and two of the three senior engineers hold no equity at all. Nobody has been through an enterprise security review. The engineers you chose, founders out of the room, describe the same weaknesses the founders do.
Without the team read this prices as a strong-founder deal at headline terms. With it, the term sheet changes in four places: a retention pool for the three named engineers, a two-year earn-out for the CTO tied to a documented handover of payments, a condition that a second engineer is trained on payments before the first tranche, and a security lead in the use of funds within six months. None of it is a reason to walk. All of it is the difference between funding the next stage and paying for the exit of the people who would have built it.
flowchart LR A(["One person can touch payments"]) --> D(["Earn-out tied to documented handover"]) B(["Two senior engineers hold no equity"]) --> E(["Retention pool, by name"]) C(["No one has faced a bank security review"]) --> F(["Security lead in the use of funds"]) D --> G(["Terms that fund the next stage"]) E --> G F --> G
Where team assessment goes wrong
- Founders get assessed while the team gets met. The founders are one interview. The people who will build the next stage are the ten engineers you were never introduced to. Talk to at least three, and choose them yourself.
- A demo stands in for a team. A demo shows what exists today, not who can maintain it or who is about to leave. A technical due diligence checklist covers the product half; it cannot answer the people question, which is why this half of the process exists.
- Retention is delegated to the lawyers. A non-compete does not keep a disengaged engineer productive. Retention is an incentive plus a reason to stay, and paperwork can only deliver the first.
- The calendar decides the depth. Middle-market deals often allow only 30 to 45 days for due diligence when 60 to 90 is advisable (Fortune, 2024). A short window is a reason to sequence tightly, not to skip the team read.
- Polish gets rewarded. The smoothest answers are not the safest team. A team that can tell you exactly where its technical debt is buried has already done half your work.
How to start when the clock is already running
Start with the key-person map: one afternoon with the commit log and the org chart, and it reframes everything else. For each critical system, the core service, the data pipeline, the payments integration, the deployment path, name who can change it safely and who gets called when it breaks overnight. Then read the four artefacts before anyone speaks. Then run the three interviews: the founders first, the engineers you selected with the founders out of the room, and the most recent departure. Write it up as a one-page risk register, each risk with its evidence and mitigation, so the deal team can turn findings into terms rather than adjectives.
For where this sits beside the code and architecture half of the work, what investors miss in technical due diligence sets out the wider process, and our technology assessment and due diligence work runs both halves together. That is how a gut feeling about a team becomes an evidenced view you can price.
Funding a team as much as a product? SDCG assesses engineering teams and leadership as part of technical due diligence for investors and acquirers in Saudi Arabia: capability, key-person risk and regulatory readiness, turned into terms you can put in a term sheet. We are independent, with no stake in the deal closing. Book a free 30-minute review.