Reading an Acquihire Target's Engineering Team From Public Evidence

This guide is for engineering managers, technical founders, and technical sourcers deciding whether a small company's engineering team is worth an acquihire offer, before you spend diligence time. The job is to go from a company name to a ranked roster that names the load-bearing engineers, flags who is likely to walk, and separates real builders from resume padding, using only public evidence. I carry one target end to end below, including the wrong turns, so you can follow along on your own case.

Most public advice here splits into two camps: acquihire term-sheet guides that never touch the code, and repo-level bus-factor tools that never touch the people. Neither hands you a named, ranked engineering roster you can act on. This teardown does, and it dwells on the two errors the checklist guides skip: crediting a heavy committer who already left, and mistaking a config-churner for a builder.

What "reading the team" actually means before an offer

The deliverable is a ranked list of named engineers, each tagged by recency-weighted ownership, builder-versus-trivial, and stay-versus-walk, ending in a go or no-go. You are answering one question in three parts: who holds the load-bearing knowledge, is that knowledge real or padded, and will those people still be here in a year.

"Load-bearing" is not a metaphor. It is the truck-factor set: the smallest group of engineers whose departure would leave more than half the codebase without anyone who understands it. The concept survives negotiation because it is the most common finding that does. When one engineer is the only person who understands the billing service, the buyer is exposed from the day the deal closes. Your job is to name that engineer before the offer, not discover them in month two.

That fragility is the reason the roster is decisive rather than decorative. In a small target, one name often is the company. The whole exercise is worth a day of analyst time precisely because getting it wrong means paying acquihire prices for a team whose value walks out with one person.

Three source layers feed the read, and each lies in a specific way. Learn what each proves and what it looks like when it deceives.

Git commit history is the spine. The Degree of Authorship family of methods infers a file's author from version history and estimates a truck factor from it. The GitHub contributors graph is the coarse view above it: it ranks by raw commit count, shows only the top 100 contributors, and excludes merge and empty commits. Profiles supply tenure and title but no code. No single layer is enough, and the graph on its own is actively dangerous.

The one company, carried through: scoping the code

Start by fixing the public surface: every public repo the org owns, plus the personal GitHub and LinkedIn of every named engineer. Done means a repo list and a candidate roster you can clone and query.

Take a worked target with a single main open-source repository and eleven engineers listed publicly. The contributors graph shows 34 contributors. That number is already lying to you in two directions, and both matter before you rank anyone.

First, the graph caps at the top 100 all-time contributors by commit count. On a small repo that ceiling never bites, but the ranking does: it orders by volume, which is a decoy the platform itself encourages. Second, the graph excludes merge and empty commits, and contributor insights only render for repositories with fewer than 10,000 commits. Our target sits at about 4,200 commits, so the insights render, but the ranking they render is the wrong one to trust.

So the graph gives you a scoping list of 34 names and a false leaderboard. Keep the list. Ignore the order. The order is what you are about to rebuild from scratch.

Normalising identities before you count anyone

Before any ranking, collapse the commit log into distinct humans. Run git shortlog -sne, build a .mailmap, and drop bots. Done means a deduped human list. Skip this and every downstream count is built on sand.

In the worked target, git shortlog -sne returns 41 author identities against 34 graph contributors and 11 public engineers. The gap is not 41 real people. Git treats author name and email as case-sensitive, so one engineer committing as Alex and alex, or from a work address and a personal one, splits into distinct authors. Two of our engineers had committed from three addresses each across a laptop swap and a domain migration. That alone inflated the count by four phantom authors.

Two more corruptions hide here. Squash merges can attribute a commit to XXX@users.noreply.github.com rather than the real author, so a genuine contributor's work vanishes behind a noreply address. Rebasing credits both the original author and the rebaser, so one refactor double-counts. The .mailmap file, placed at the repo root, maps these aliases together; git shortlog -se then shows the reconciled list.

After building the .mailmap and dropping two CI bots, the 41 identities resolve to 12 distinct humans: the 11 public engineers plus one former contractor who never appeared on any profile. That thirteenth-into-twelfth reconciliation is not bookkeeping. It is the difference between ranking people and ranking ghosts.

Recency-weighted ownership: finding the load-bearing names

Now compute who owns what, weighting recent work over old. Run a Degree-of-Authorship or bus-factor pass with a 1.5-year window so that departed contributors fall away. Done means per-file primary owners and a truck-factor set.

Bus Factor Explorer bounds the window: it considers only commits and files modified within the last 1.5 years of the most recent commit, and marks older files inactive. Underneath, the Degree of Authorship formula decays knowledge continuously, halving it every five months. The tool then iteratively removes top authors until the rest cover fewer than half the files. What remains is the truck-factor set.

Here is the first wrong turn, and it is the most common one. In the worked target, the all-time commit leader is an engineer I will call the founder-CTO. They top the graph by a wide margin. Cross them into your retention-critical list and you would build the entire deal thesis around them.

Rerun with the 1.5-year window and their Degree of Authorship collapses. They wrote almost nothing in 18 months. The graph shows their history; the window shows their absence. A public profile confirms a title change nine months ago to an advisory role. This is the departed-heavy-committer trap, and the gap between the all-time rank and the windowed rank is exactly what exposes it.

A name that tops the all-time graph but vanishes under recency weighting is your departed heavy committer, made visible.

With that name dropped, the windowed truck-factor set of the target is two engineers: one owns the data pipeline, one owns the API and auth. Two people cover more than half the active codebase. That matches the base-rate fragility of small teams exactly, and it means the go or no-go now hinges on two names.

There is a live order dispute worth naming. Bus-factor tools discard inactive files first, which is right for finding current owners. But a builder-versus-churner pass argues for keeping full history, so you can see who originally wrote code that has since been refactored. Run both. Reconcile them. The recency pass tells you who owns the code now; the full-history pass tells you whether a current owner is really a refactorer sitting on someone else's foundation.

Builders versus churners: what the ownership number hides

A high ownership score can still be trivial work. Split new-code contribution from rework, and flag anyone whose volume is lockfiles, formatting, or version bumps. Done means each name tagged builder, maintainer, or trivial.

Commit count alone is discredited. The documented alternatives are code-based tagging, where a commit is substantive if it introduces a new function and incremental otherwise; true-churn segmentation, which separates new code from an engineer rewriting their own recent work; and impact weighting such as line-impact scoring.

Here is the second wrong turn. In the worked target, a third engineer ranks high on commit volume inside the window and looks, on count alone, like a builder to protect. Inspect the file types and the picture inverts: their commits are overwhelmingly dependency lockfiles, formatting passes, and version bumps. They are a diligent maintainer of the build, not an author of the product. Crediting them as load-bearing would over-value the roster and misdirect a retention offer.

One caution the tooling insists on: churn is not automatically bad. An engineer with high churn might be doing genuinely exploratory work, learning a new technology, or refactoring. Always seek context before drawing conclusions from individual churn data. The config-churner above is trivial because the file types say so, not because the churn number is high. Read the files, not just the metric.

After this pass the worked roster reads: two true builders in the truck-factor set, one build-maintainer tagged trivial, three secondary contributors, and the founder-CTO parked as departed. The two builders are the deal.

Tenure and flight risk: who actually stays

A strong roster with no retention lock is still a no-go. Overlay tenure, recent title changes, and commit cadence on each load-bearing name, then flag stay-likely or walk-likely. Done means every retention-critical name carries a flight read.

The base rate caps your upside before you start. In MIT Sloan research covering about 4,000 US high-tech startup acquisitions across 1990 to 2011 and roughly 350,000 employees, 33 percent of acquired workers left within the first year against 12 percent of comparable regular hires.

Model your two builders as roughly one-and-a-half after year one unless vesting locks them. Acquihire retention packages commonly vest over 2 to 4 years, and higher pay cuts toward exit: high-income employees have a higher proclivity to depart. Publicly observable flight proxies are the commit graph going dark, a profile or title update, an "open to work" flag, and recent contribution dropping below the person's own prior baseline.

Scarcity sharpens this at the exact wrong point. A niche-skill load-bearing engineer has more outside options, which raises walk probability precisely where the codebase depends on them most. The systems-language gap makes the scale concrete.

In Refolk's index, only 497 US Senior or Staff engineers list Rust against 2,839 listing Go. If your load-bearing builder writes the Rust core, they sit in a pool one-sixth the size, with correspondingly more offers in hand. That is not a reason to walk from the deal; it is a reason to model that name as walk-likely and price the retention lock accordingly.

The scarcity also shapes who you are competing against for any name you do lose. In Refolk's index, 4,429 people are currently titled "Founding Engineer" in the United States, concentrated first in San Francisco and then New York, against 609 in the United Kingdom - a US pool about 7.3 times larger. Knowing where that pool sits tells you both how replaceable a departing name is and where the target's own people will land if they leave.

Mapping tenure and current cadence by hand across a dozen profiles is the slow part of this job. Refolk resolves each load-bearing GitHub name to a verified person with current title, tenure, and recent activity, which collapses the sourcer's half-day into a query. I still read the code myself; the profile layer just stops being the bottleneck.

The procedure, end to end

Here is the full run as a repeatable sequence. It matches the worked target above and reconciles the order dispute by running both ownership passes.

Budget it at one day of analyst time plus a few hours of sourcer and decision-maker time. Steps one and two are one to two hours each; steps three and four are a half day each; step five is two to four hours; step six is two hours. The reconciliation between the recency pass and the full-history pass happens inside step four and step six, not as a separate stage.

How this read goes wrong

Eight failure modes account for nearly every bad roster. The two most expensive are crediting a departed heavy committer and mistaking a config-churner for a builder, both walked through above. Here is the full set with the check for each.

• Crediting a departed heavy committer. A name tops the all-time graph but wrote nothing in 18 months. Rerun ownership with the 1.5-year window; if their Degree of Authorship collapses, drop them.
• Config-churner mistaken for a builder. High commit count that is lockfiles, formatting, and version bumps. Split true churn from new-code contribution and inspect file types before tagging.
• Inflated head count from split identities. One human appears as three authors through case or email variance. Run git shortlog -sne with a .mailmap before counting anyone.
• Squash-merge author erasure. The real author hides behind a noreply address. Read PR authorship on GitHub, not just the squashed commit author.
• git-blame overwrite illusion. A refactorer looks like the owner because they touched every line last. Use full-history Degree of Authorship, not current blame.
• Reading raw commits as impact. Commits per developer per day is a tempting metric and it misleads. Weight by new-function or line impact instead.
• Assuming the load-bearing name will stay. Base rate is about one in three gone in year one, so a strong roster with no retention lock is still a no-go. Confirm the vesting and retention exposure.
• Private-repo blind spot. The best engineers may commit mostly to private repos, so the public graph understates them. Triangulate with talks, published packages, and profile activity, and treat the public read as a floor.

Two limits I will state plainly. There is no published numeric bar for how many load-bearing engineers a target must have to justify an acquihire; the load-bearing concept is standard but precise retention-count thresholds are not established publicly. And every method here reads only public code, so a target whose best work is private will be systematically understated. Where the evidence is thin, say so in the roster and check it in live diligence rather than pretending the public read is complete.

Setting the read and keeping it current

Close by ranking the roster and writing the recommendation. Order names by recency-weighted ownership, mark the retention-critical set, and state a go or no-go tied to what a viable retention lock would cost. A defensible bar: retain everyone in the truck-factor set, and given base rates, plan for about one in three to leave in year one regardless.

For the worked target, the read is: two load-bearing builders, one of them in a scarce-skill pool and flagged walk-likely, both outside vesting today because the company is unacquired. Go is conditional on a 2-to-4-year retention package covering both names. Without that lock, model the roster as roughly one builder after year one, which does not clear an acquihire price. That is a defensible no-go, and it took a day to reach.

Keep the read current by re-running the recency pass, not the whole procedure. The 1.5-year window moves with every new commit, so a name that was load-bearing at first read can drift toward the departed-committer trap between your analysis and close. Re-check the windowed ownership and the flight proxies just before signing. The identity and builder work holds; the tenure and cadence layer decays fastest and is the one to refresh.