The Early-Team Departure Read: Benign, Explainable, or Red-Flag

This is the check I run before signing a seed or Series A term sheet. I rebuild who joined and who left the team using public profiles, date each exit, compare the pattern to a stage-matched baseline, and decide whether the founder's account of it holds up. It is written for early-stage investors, platform and talent partners, and angels. It follows one composite company from start to finish, with the queries, the counts at each step, and the two wrong turns I took along the way.

The worked example: a 46-person seed company and its founder's story

The example is a composite London B2B software company. It raised its seed 26 months before the term sheet, has 46 full-time employees once the data is cleaned, and has a founder who calls six departures normal churn. "Composite" means the shape and the mistakes are real but the company is not. Every count in the example is illustrative. Every baseline I compare it against is published.

Conventions used throughout:

• T is the week the term sheet would be signed. T-8 means eight months before that.
• FTE means a full-time employee on payroll, not a contractor, intern, or advisor.
• Leaver means an FTE whose employment ended. Transfer means someone who left as part of a sale of part of the business.
• Key-person risk is the risk that the company depends on one individual whose exit would stall the product or the plan.

In the pitch meeting, the founder said: "Six people have left since the seed, including our Head of Sales, who went off to start a company. All normal churn."

By the end I need four things: a cleaned roster, a written gap against baseline, a class and reason for each exit, and three questions a vague answer won't get past.

The evidence runs out in specific places, so name them up front:

• Profile update lag has not been measured publicly. Nobody has published how long people take to update, or what share never do.
• Stage-split attrition rates. No published source gives an annual attrition rate split by early versus growth stage.
• Small-sample statistics. I found no VC-published method or confidence interval for reading exits on a team this small.
• Named thresholds. Rules like "multiple C-level exits within six months" or "engineering churn after a CTO change" appear in conversation, but none is established publicly.

Which dates do you anchor before reading a single profile?

Anchor three kinds of date: round close dates, cliff dates for each hiring class, and leadership changes. Without them an exit is just a month. With them it is a month next to something that might explain it.

A cliff is the date when the first tranche of an employee's equity vests, commonly 12 months after they start. For this read I approximate each hiring class's cliff as its round close plus 12 months.

The timeline matters because round-timed exits are mechanical. Each new round prices the equity the previous hiring class has vested, so exits bunch at the next round. A profile-derived study of more than 4 million job changes found that 54% of Series A hires who leave do so at Series B. A cluster right after a round is the expected pattern, not a finding.

This step took about 30 minutes. Every time estimate in this guide is a practitioner estimate, not a measured figure.

Rebuilding the joiner and leaver roster from public profiles

Pull everyone who lists the company as their current employer, then everyone who lists it as a past employer. Match both pulls on the company URL rather than the company name. Then clean every row until it is tagged FTE or excluded, with a reason. In the example, 81 raw profiles became 46 current FTE and 16 leavers, and 4 of those leavers later turned out to be transfers.

The two raw pulls returned 58 current profiles and 23 past ones. Each row needs the same fields, so the classification step later is mechanical.

Pull 1: Everyone who currently works at [company] ([company URL]), with title, function and start month
Pull 2: Everyone who worked at [company] ([company URL]) in the last three years, with start and end months and their current employer

Row fields:
role | function | status (FTE / excluded) | exclusion reason | start month | end month | date source | date confidence (high / medium / low) | next employer | provisional (Y/N) | class | one-line reason

Here is what cleaning removed:

Notes on each exclusion:

• Advisors often list the company as a current employer. They aren't staff, and including them inflates headcount.
• Placeholder employers are the most common source of strangers in the data. Employer strings like "TBD" or "Company", or a different firm with a similar name, match on name alone. Resolving by company URL removed four.
• Stale current profiles were two people who still listed the target as current but also showed a newer full-time role elsewhere, with no commits after that role began. I moved them to leavers with low date confidence.
• Acquired-in staff, meaning people who joined through an acquisition the target made, need their own exclusion. There were none here, but check, because their earlier tenure gets credited to the target.

Cleaning took about two hours. The slow part is the two pulls themselves: getting current and past staff matched to one company URL, with start and end months attached, rather than a name search that drags in every "TBD". Refolk returns that from one plain-English request, which means the hours go into cleaning and reading.

Dating each exit: what each source proves and how it lies

The profile end month is the primary date. Commit history and archived team pages corroborate it. No single source proves an exit month, so every exit gets a month, the source behind it, and a confidence level.

Some notes on the sources:

• Git dates. The commit date matches the author date unless someone rewrites history with an amend, a force push, or a rebase. GitHub shows the author date on profile pages and the commit date inside repositories, so the two views can disagree.
• Wayback CDX. CDX is the Internet Archive's capture index. It returns a timestamp in yyyyMMddhhmmss format for every capture of a URL. A capture tells you the person was listed on that date. It tells you nothing about when they joined or left.
• WARN. WARN filings are mandatory layoff notices. They don't apply to a 15 to 80 person team. Conference bios and backfilled job postings also exist as sources, but their reliability has not been established, so I don't use them for dates.

In the example, the founding engineer, who was employee number two, had a last commit to the core repository at T-4. Their profile end month was T-3, and the team page still listed them at the T-5 capture. That gives medium confidence with a month of T-3.

My first small wrong turn was here. A customer success manager disappeared from the T-1 capture of the team page, and I nearly moved them to leavers. CDX, collapsed by month, showed the page had been captured monthly until T-5 and only once since. The T-1 capture also listed fewer people overall, so the page had been trimmed. I kept them as current.

Lag runs in both directions. Recent leavers still look current, and recent joiners haven't added the company yet. So in the last quarter the alumni count runs low and the headcount runs high. Career advice puts the update anywhere from about two weeks to two months after a move. One academic study ignored job starts within four months of its cutoff for exactly this reason. I mark the last 90 to 120 days as provisional. In the example that covers two exits: the founding engineer at T-3 and an operations hire at T-2.

Stage-matched baselines for early-team departures

Compare the raw leaver count against Carta's table of cumulative leavers by headcount, and compare hire-year cohorts against published 12 and 24 month leave rates. Normalise by function before calling anything a function's churn. On teams under about 50 people, one exit moves a percentage too much for the percentage to carry weight on its own.

That table comes from the same profile-derived study of more than 4 million job changes. The study also found that 29.6% of startup hires leave within 12 months and 58.9% within 24. Both figures are measured on an equal-observation-window basis, which means a hire only counts once they have been observable for the full window. Carta's cap-table records put median startup tenure at 2.2 years, against 4.1 years across all industries, and around a 51% chance an employee leaves within three years.

Source: Carta. The share column is derived, and so is the 26-hire figure for the 25-person row.

The example against the baselines:

• Raw count. 12 attrition leavers (16 minus the 4 transfers) against a baseline of about 6 at 50 heads. That is double.
• Excluding the five-person sales cluster covered in the next sections, the count is 7. That is close to baseline.
• Cohort test. The seed-close hiring class was 18 FTE hired between T-26 and T-20. All of them have at least 20 months of observation, so the 12-month window is fully observed. Three left within 12 months, which is 17%, against 29.6%. I didn't compute the 24-month rate, because not all 18 have 24 months of observation yet. One VC due-diligence checklist puts it well: "Aggregate curves conceal churn that only appears in cohorts."

Read baselines in context. Voluntary departures on Carta are down 40% from their hiring-boom peak, and Carta's record 23% first-year loss belonged to a boom-era hiring class. A team churning at boom-era rates today sits above the current norm. Re-check both figures in Carta's latest compensation report before you rely on them.

Normalise by function. Team composition drives raw exit counts.

My first draft showed 7 engineering leavers, the largest raw number on the page. Four of them were the transfers. After removing them and normalising, engineering is the most stable function and go-to-market is the outlier.

The one public numeric threshold I found is "annual voluntary turnover above 15-20%", from a startup checklist with no stated method. OMERS Ventures makes the more useful qualitative point: "High turnover among the senior team is particularly concerning as it can show a lack of cohesion." Seniority and concentration carry more signal than the rate.

Classifying each exit: benign, explainable, or red-flag

Every exit gets one of three classes and a one-line written reason. The class depends mainly on two things: how senior the person was, and whether the exit sits in a cluster concentrated in one function. The founder's account decides between explainable and red-flag.

The example's 12 attrition exits, classified before the call:

• Benign (5). An account executive at T-15. An engineer at T-14, on the seed-class cliff. An engineer at T-6. A designer at T-11, at the extension. The operations hire at T-2, provisional. These six-month-plus exits are spread across functions and fit the baseline.
• Explainable, pending (1). Head of Sales at T-9. Their profile now shows a founder title at a new company, which is consistent with the founder's story.
• Red-flag, pending (6). Five go-to-market staff who left within 30 days at T-8, and the founding engineer at T-3.
• Transfers (4). Engineers who left with the side-product sale at T-13. They are corroborated by the acquirer's press release and kept out of attrition entirely.

Now compare this with the founder's story. Their six leavers match six of my seven non-cluster exits. The story is missing two things: a five-person go-to-market cluster, and the company's second-ever employee.

A leaver count that matches the baseline can still hide a layoff. Read the shape, not the total.

How this read goes wrong: failure modes and false positives

Most errors in this read come from mistaking a different event for attrition, or trusting a date source further than it goes. These are the eight I check for, including both wrong turns from the example.

1. Acqui-hire counted as attrition. An acqui-hire is a purchase made mainly to take on the people. The signature is several people leaving in the same month, all for one acquirer, with their titles carried over. I counted the T-13 group as a four-person engineering exodus until I checked the next employer: all four shared it, and the acquirer had published a press release. The check is an acquisition announcement plus more than half the cluster sharing the same next employer.
2. Quiet layoff read as churn. A reduction in force, or RIF, is a layoff the company didn't announce. I first filed the T-8 cluster as round-timed churn, because it came three months after the extension. Three things pointed to a RIF instead: five exits in one function inside 30 days, no backfill postings (meaning no ads to replace the leavers), and a careers page that listed six sales openings at T-9 and none at T-7. Layoffs are not rare. In a single month of Carta's published data, 12,161 people left voluntarily and 8,217 were laid off, so about 40% of exits were layoffs. Check archived careers-page captures before and after any one-function cluster.
3. Stale current titles. Profiles keep old employers for a long time. One Refolk sample of "Founding Account Executive" profiles included a large-enterprise employer, and career advisers describe contacts who hadn't updated in two years. Cross-check current status against the most recent post activity, commit dates, or team-page captures.
4. Lag in both directions. In the last quarter, alumni counts run low and headcount runs high. Re-pull 90 days later or label the count provisional. Never present an unadjusted last-quarter count as final.
5. Git dates treated as proof. Author dates survive rebases and can be set by hand. Use the last commit as an upper bound on activity only.
6. Wayback absence treated as departure. A missing capture doesn't mean the person had left. Compare the capture cadence using CDX collapsed by month, and check whether the page was trimmed, before inferring anything.
7. Placeholder employers. Employer strings like "TBD" and "Company" appear in real profile data, and matching on name pulls in strangers. Resolve every match by company URL.
8. Round-timed exits flagged red. A cluster after a round is the baseline. Flag it only when it is concentrated in one function or involves senior people.

One structural limit sits above all eight. With 12 exits there is no statistical test that separates bad luck from a pattern. Nobody has published a small-sample method for this in diligence. The classes above are judgements backed by written reasons, not significance tests, and the memo should say so.

The departure-diligence procedure, step by step

This is the repeatable version of the example, in the order I run it. The ordering is my own: diligence checklists usually start with founder questions and data-room requests, and I build the public evidence first so the questions can be specific. Read the lawful-basis note in the next section before starting step 2.

The founder call, the deletion, and keeping the read current

Take three questions into the call. Each one opens with dated evidence and targets one red-flag or pending exit. Decide afterwards, then destroy the individual-level roster. The point isn't to catch the founder out. The point is to find out whether their account of the team survives contact with the record.

1. The cluster
"Between [T-9] and [T-8], [five] go-to-market people left within 30 days, and the careers page went from [six] sales openings to none. Was that a reduction in force? What triggered it, who decided, and what did the people affected receive?"
Not past a vague answer: "We tightened the team." Follow up: "Which month did you decide, and what metric triggered it?"

2. The key person
"Your [second engineer]'s last commit to [the core repository] was [T-4], and their profile shows a new employer from [T-3]. When did they give notice, who owns that code now, and what happened to their unvested equity?"
Not past a vague answer: "They're still around." Follow up: "Who is on call for that service today?"

3. The sequence
"Your [Head of Sales] left at [T-9], the sales cluster left at [T-8], and the [VP Sales] joined at [T-6]. Did the plan change first, or the person?"
Not past a vague answer: "It was a mutual decision." Follow up: "What was the pipeline number in the month they left?"

In the example, the founder confirmed the T-8 layoff once the dates were on the table. It followed a missed pipeline target after the Head of Sales left. They then added it to the data room. The cluster moved to explainable. The memo also records that it had first been described as normal churn, which is a candour point in its own right. The founder said the founding engineer left for a co-founder role, named the engineer who now owns the core service, and offered the equity paperwork. That exit stays in the memo as a key-person item rather than a reason to stop.

Backchannel references. Former employees can confirm what the founder said. Reference density differs by market, which changes how discreet you can be.

To find the right references (leavers from the same function and window, plus where they went next), I ask Refolk for that slice directly instead of reverse-engineering it from the roster. Keep the number of calls small and the questions factual.

There is a real tension here. Independent verification is the whole point of the read, but the ICO necessity test may require you to ask the company first. Guidance derived from the ICO for M&A says employee data should be used exclusively for the evaluation, kept confidential, and destroyed or returned after use. The UK's newer "recognised legitimate interest" basis covers five public-interest conditions, not investment diligence. Nobody has published a specific retention period for an investor's working roster, so I delete it the day the decision is made and keep only the memo, which records classes and reasons by role.

Keeping the read current. If the deal is still live 90 days after the first pull, re-pull both rosters. Provisional rows become final, and recent joiners appear. Re-check the Carta baselines against its latest compensation report whenever you reuse this guide, because the voluntary-departure trend moves.