Building a Technical Advisory Bench From the Engineers Who Solved It

You have a hard build ahead: a scaling milestone, a new domain, or a risky migration where a wrong call costs months. This playbook is for founders and engineering leaders who need two or three technical advisors who have provably done the exact thing you are about to attempt. It takes you from naming the risk to a signed agreement, and it qualifies people on evidence of the specific problem rather than on the logo behind them.

Most advice on how to find technical advisors for a startup starts with tap-your-network and advisor marketplaces, matching on reputation. That optimises for the wrong thing. A well-known name who scaled a different system is worth less than an unknown Staff engineer who shipped precisely your migration. This guide inverts the search: start from your technical risk, find the companies that already crossed that milestone, name the engineers who led it, and confirm authorship from public artifacts before you ever reach out.

Why match on the problem, not the logo

Match advisors on evidence they personally solved your specific problem, not on where they worked. An engineer who was at a company during a famous migration but never touched it is a false positive, and the most common one.

The reason this matters is supply. The comparable problem is not scarce at the senior level. In Refolk's index of professional profiles, 3,886 US Staff or Principal engineers carry both Database Migrations and PostgreSQL skills. A migration-risk bench is a sourcing-precision problem, not a scarcity problem. When you cannot find the right advisor, the bottleneck is almost always your filter, not the talent pool.

So the discipline is precision. Logo-matching feels productive because famous names are easy to list, but it fails the only test that counts: can this person show they led the exact work? The rest of this playbook is built around producing that proof for each name before it reaches your shortlist.

What a good result looks like

A good result is a ranked shortlist of named engineers, each tied to a specific comparable problem they demonstrably solved, plus the companies that crossed the milestone, a verified authorship check, and a first-contact plan with a defensible equity-and-time offer. Anything less is a list of names you still have to qualify.

Concretely, the deliverable has five parts:

• A one-line risk spec you can search against, phrased as a testable outcome.
• 8 to 15 companies that crossed that milestone, each with a dated public artifact.
• A ranked shortlist of two or three primary advisors plus two backups, each with two independent artifacts confirming they led the work.
• A conflict clearance on the top names covering current employer, competing advisories, and invention-assignment constraints.
• An offer plan with a FAST-style grant, a cadence, a success metric, and the IP paperwork ready to attach.

The end-to-end procedure

Run these eight steps in order. The first three are discovery, the middle two are qualification and ranking, and the last three are contact and closing. Time estimates assume one founder or eng lead plus one sourcer.

Two ordering notes from practitioners. Some run conflict clearing after mutual interest rather than before, to avoid diligence on people who never engage; that is defensible if your build is not IP-sensitive. And reading one postmortem thoughtfully takes about 15 to 20 minutes, so budget the discovery steps realistically rather than assuming you will skim.

Reading the public signals that a company crossed the milestone

The strongest public signal is a named engineering-blog case study with quantified scale. It tells you both that the milestone happened and who to look for. Weaker signals - a job title, a company's funding stage - suggest capacity but never prove the specific work was done.

Four artifact types carry most of the weight, in roughly descending order of what they prove:

• Named postmortems with numbers. Stripe published a migration that moved a column into its own table across hundreds of millions of objects with many dependencies and no downtime allowed. That is a spec, an outcome, and an author trail in one document.
• Conference talks with a technical thesis. DoorDash described moving sessions functionality out of the monolith into a microservice using magic cookies, kill switches, and experimentation throughout the rollout. OpenAI's Postgres talk offered a reusable insight: if you are not too write-heavy, you can scale Postgres to very high read throughput with read replicas and a single master.
• Speaker pages and bios. A Databricks Data and AI Summit speaker page describing an executive experienced in leading cloud migrations and platform modernization across high-growth organizations names a milestone leader directly.
• Commit and issue history. The most granular signal, and the one most in need of verification, because author fields are forgeable.

Match your spec to the artifact, not the company. A company can cross a milestone while the person you are talking to sat two teams away from it.

Verifying authorship instead of tenure

Authorship, not tenure, is the only defensible filter, and the cheapest way to apply it is the Verified badge on signed commits. Anyone can set the author field of a Git commit to any value, so a long track record can be fabricated; a cryptographic signature cannot.

Here is the mechanism. Signed commits attach a cryptographic signature that produces a clear Verified badge, distinguishing commits actually authored by a person from commits made without their signature. SSH-based commit signing arrived in Git 2.34 in November 2021, with GPG signing available since 2012. GitHub can flag unsigned commits as Unverified. So when you review a commit history, the badge is your single cheapest disqualifier: no signature, no proof of that person's hand on that code.

Two cautions. Sources disagree on whether an unsigned commit history counts for anything - treat an unsigned history as unverified rather than as evidence, and lean on a second artifact instead. And review tooling is not infallible: the GitProxy Hidden Commits exploit, tracked as CVE-2025-54586, injected ghost commits that bypassed standard review views. So verify signatures against the platform's own badge, and corroborate.

For each shortlisted name, require two independent artifacts before promoting them. A signed commit plus a bylined postmortem. A named talk plus a patent listing them as inventor. Two artifacts that agree on who led the work is the bar that separates a leader from a bystander.

When your search phrase, not the talent pool, is the bottleneck, Refolk lets you ask for the exact combination of skill, seniority, and evidence in plain English rather than reverse-engineering a boolean string. That matters because over-constraining is the most common self-inflicted wound in this work, as the next section shows.

Sizing the offer against the market

The market pays roughly a third of the published standard, so cite FAST as a ceiling, not a clearing price. The Founder Institute's FAST agreement, used across tens of thousands of startups, sets a grid running from 0.1% to 1% across three stages, and it is the reference founders anchor to.

The published grid and the observed market diverge sharply. FAST recommends the columns below; Carta's H1 2024 medians ran well under them.

At Series A the observed median is roughly one-third of the FAST recommendation. Only 10% of pre-seed advisors received 1% or more, so an expert-tier ask is the exception, not the default. Y Combinator notes advisor RSAs typically range 0.2% to 1% while NSOs range 0.1% to 0.5%. For reference, here is the original FAST grid so you can see where the anchor comes from.

FAST publicly released in 2011, updated to Version 2 in August 2017, and v3 in June 2026 collapsed three involvement levels to two while raising the Standard pre-seed tier from 0.25% to 0.50%. It is not uncommon for a technology startup to allocate a 5% pool across an advisory board.

On time: the original FAST suggests 5 to 20 hours per month, but practitioner write-ups narrow this to 2 to 5 hours for a standard engagement and 5 to 10 or more for strategic roles. Vesting is monthly over two years with a three-month cliff, far shorter than the founder and employee standard of four years with a one-year cliff.

FAST is a negotiation anchor, not a clearing price, so citing it alone quietly over-offers by a factor of three.

How this goes wrong

The failure modes here are predictable, and most of them cost you either equity or IP. Work through them explicitly before you commit to anyone.

• Logo-matching, not problem-matching. An engineer who was at the company during the migration but never touched it. Check: require a personal artifact, not an employment overlap.
• Trusting an unsigned commit history. Author fields are trivially forged, so a long track record can be manufactured. Check: look for the Verified badge and cross-reference a second artifact.
• Conference-bio inflation. Abstracts claim someone led work they merely coordinated. Check: match the talk to a blog byline or an issue thread under their handle.
• Advisor sharks. Experienced founders warn about people who ask for 0.25% to 1% for the grace of their presence, deliver little, and collect equity from multiple startups. Check: tie equity to a scoped deliverable and use the three-month cliff.
• IP conflict ignored. An advisor still bound by an employer PIIA can taint your IP. Check: require Exhibit A disclosure and a section 2870-type carve-out before work starts.
• Over-narrow sourcing query. One keyword can starve a search. Check: constrain on skills and titles first, add free-text phrases last, and loosen if the count collapses.
• Dead equity from no cadence. Roughly half of advisor relationships lose momentum after a few months. Check: agree a written cadence and a success metric at signing.

The over-narrow query deserves a number, because it is the failure that masquerades as scarcity. In Refolk's index, the same skill profile behaves very differently across markets and constraints.

Adding one narrow free-text phrase collapsed the US pool from thousands to single digits. The lesson: rare literal phrases rarely appear in profiles even when the underlying skill is common. Constrain on skills and titles, add phrases last, and loosen the moment the count collapses. Two further reads from the same data: country transfer is not automatic, so a US-tuned query returned zero in the UK and must be re-specified per market; and in the 3,886-person sample, Staff Software Engineers outnumbered Principal Engineers roughly 1.3 to 1, with employers including Confluent, Salesforce, Google, and Stord.

Clearing conflicts and papering the deal

Resolve IP and conflict-of-interest questions before an advisor does any work, not after. The advisor agreement generally includes an assignment by the advisor of all IP rights in inventions or works they conceive, create, or develop in the course of providing services, or that are based on your confidential information.

The mechanism is a Proprietary Information and Inventions Assignment Agreement, also called a Confidential Information and Inventions Assignment Agreement. Have all advisors, consultants, contractors, and employees sign one. The real friction is that a good advisor is often already bound: they may worry the assignment conflicts with obligations to a current employer, a university, or other startups they advise. That is why Exhibit A exists - it lists prior inventions excluded from assignment and any agreements that may restrict the advisor's ability to work for you. Get it filled in truthfully before work starts.

In California, Labor Code section 2870 provides that an employer may not require assignment of an invention the person developed entirely on their own time without the employer's equipment, supplies, facilities, or trade secrets, except inventions relating to the employer's business or resulting from work for the employer. California agreements require the section 2870 notice. Treat this as a legal requirement, not a formality.

Subject: Your work on the [zero-downtime table split] at [Company]

Hi [Name],

I read your [postmortem / watched your talk] on [the specific migration], especially the part about [magic cookies / read replicas / kill switches]. We are about to attempt [your one-line spec], and your writeup is the closest public account I have found to our situation.

I am not asking for free consulting. I would like 30 minutes to test one decision: [the exact fork in the road you face]. If it is useful on both sides, I would want to talk about a formal advisor role.

Would [two time options] work?

[Your name]

Equity: [0.15%-0.25%] of fully diluted shares, RSA
Vesting: monthly over 24 months, 3-month cliff
Cadence: [monthly 45-minute call] + async review between
Success metric: [the specific decision or milestone the advisor is accountable for]
IP: PIIA signed before first session; Exhibit A disclosure attached
CA only: Labor Code section 2870 notice included
Filing: 83(b) election filed within 30 days where the grant is a purchase of restricted stock

Keeping the bench alive after you sign

A signed grant is not a working relationship. Roughly half of advisor relationships lose momentum after a few months, and the mechanism that prevents it is structural: tie equity to deliverables. The three-month cliff plus a named success metric is what converts a grant into retained value, because it gives both sides an early, low-cost exit if the fit is wrong.

Run the bench small and one-on-one. At the earliest stage, start with two or three core advisors who add value immediately; most startups keep it to three to six, and the most effective advisory boards run between five and nine. Boards rarely meet as a full group - advisors are engaged one-on-one on specific questions, with quarterly meetings and ad hoc calls between, or a monthly 45-minute call plus async review. The Founder Institute recommends working with a potential advisor for at least a month and spending at least eight hours together before signing, which doubles as your final authorship check: someone who led the work will show it in the first two calls.

Re-run the sourcing when the risk changes. The bench you build for a Postgres migration is the wrong bench for a compliance-driven rebuild, because the comparable problem is different and so are the artifacts. Keep your one-line spec current, and when the next hard build lands, start again at step one. The method is durable even when the names are not.