Hiring Brief Template for Founders

A hiring brief is the founder's internal agreement about one role before anyone searches, interviews or approves an offer. It turns a broad request into a decision document that another person can apply consistently. Copy the blank template below, complete it with the hiring manager and save the version that was approved.

What this brief is for

Keep the hiring brief separate from the public job description (JD). The JD explains the opportunity to candidates; the internal brief records the reasoning, trade-offs and approvals behind it. It is also different from an interview scorecard, which captures evidence from assessments, and a candidate shortlist, which records what is known about particular people. The brief comes first and gives those later documents a stable reference.

Copyable blank hiring brief

ROLE AND OUTCOME
Role / team / hiring manager:
Outcome this person owns by [date or milestone]:
Scope: [what is included] | Out of scope:

MUST-HAVES AND NICE-TO-HAVES
Must-have 1 and why it is essential:
Evidence that could support it:
Must-have 2 and why it is essential:
Evidence that could support it:
Nice-to-have(s) and why they help:
Acceptable adjacent backgrounds:

CONSTRAINTS AND SOURCING BOUNDARIES
Location, working pattern, time-zone or authorisation constraint:
Other job-related boundary:
Sources or profiles to include:
Sources, titles or assumptions not to use, and why:

ASSESSMENT PLAN
Stage and owner:
Job-related question or work sample:
Evidence to record:
Unknowns to verify:

OWNERS, APPROVALS AND BUDGET INPUTS
Final decision-maker / brief approver:
Evidence reviewer(s):
Compensation range, currency, variable pay and benefits input:
Budget approver and exception path:
Target start date and approval dependencies:

DECISION RULE
Advance when:
Hold or verify when:
Close when:
Who can change this brief, and what must be recorded:
Brief version / owner / approval date:

Fictional filled example

All facts and figures in this example are fictional and are not market benchmarks. Replace them with approved facts for the actual role.

ROLE: Foundry Labs, first product engineer, reports to founder Mina
OUTCOME: By the fictional Q2 launch milestone, own a usable billing workflow from design through monitored release.
SCOPE: TypeScript service, customer feedback loop and deployment runbook. OUT OF SCOPE: hiring, sales and mobile apps.
MUST-HAVES: shipped and operated a customer-facing web service; can explain trade-offs to non-engineers.
NICE-TO-HAVE: payments experience. ADJACENT: platform engineer with ownership of an internal workflow.
CONSTRAINTS: fictional hybrid schedule, two Hong Kong office days; confirm work authorisation separately.
SOURCING: include public professional profiles and repositories; do not filter by university, employer prestige or "culture fit".
ASSESSMENT: founder conversation, system-design discussion and a short fictional work sample; record decisions, scope and unknowns.
OWNERS: founder approves brief; engineering adviser reviews evidence; founder makes final decision.
BUDGET INPUT: fictional HK$720,000-HK$900,000 annual base range, pending approval; record currency, variable pay and benefits before any public announcement.
DECISION RULE: advance only when every must-have is supported or has a named verification step; hold unknowns; close for a documented job-related conflict.

Complete the fields before searching

Write one observable outcome, then define the scope and exclusions that make ownership clear. A tool list is not an outcome. For each must-have, explain why it is essential and what evidence could support it. Keep nice-to-haves visibly separate so a preference does not quietly become a rejection rule. Include adjacent backgrounds when transferable work could meet the outcome; decide what evidence would make that route worth reviewing.

Record genuine constraints such as working pattern, location, time-zone overlap or work authorisation separately from capability. Sourcing boundaries should say which public professional sources are relevant and which assumptions are out of scope. Do not use degree prestige, brand-name employers, arbitrary years, accent, personality labels or vague "culture fit" as proxy criteria unless a documented job requirement truly depends on an underlying capability. Prefer the capability and the evidence directly.

Missing public evidence is unknown, not absent. Write the question, owner and assessment stage that will verify it. A profile that does not mention a technology does not prove the person lacks it; equally, a keyword does not prove ownership or current ability. Use the same verification question for comparable candidates and keep source evidence distinct from interpretation. A brief should make uncertainty visible to reviewers instead of hiding it inside a score or confident summary.

Set assessment, approvals and the decision rule

Name each assessment stage, its owner and the job-related evidence to record. Keep the process separate from the brief: the brief says what must be tested, while a scorecard records what happened. Confirm compensation range, currency, variable pay, benefits, working pattern and budget approver before outreach. These are planning inputs, not permission to infer a candidate's expectations.

The decision rule should make the next action explicit. For example, advance when all must-haves are supported or assigned to a defined verification step; hold when a material unknown remains; close when a stated requirement is not met after verification. Name who can change a must-have, boundary or budget input, and record the reason and new version. This prevents a founder's late preference from being applied only to some candidates.

Where candidate sourcing fits

Talent Summoner is our product, not the hiring decision. Its candidate-sourcing tool starts with a role brief and searches LinkedIn, GitHub and other public professional sources across 200M+ profiles. It returns a ranked shortlist against must-haves and nice-to-haves with plain-English reasoning. Review the evidence and unknowns yourself; your team owns outreach, interviews, approvals and the final decision. It is not an ATS, an agency, an automated outreach sender or a decision-maker. Check the current pricing only after the role and budget inputs are approved.

Wrong fit for this template

Do not use this brief as a public JD, a legal hiring policy, an interview transcript or a candidate database. It is a poor fit when the role has no accountable owner, the outcome is still exploratory, compensation cannot be approved, or the team is unwilling to verify unknowns. Resolve those gaps first rather than making the search criteria more elaborate.

FAQ

What should a founder put in a hiring brief?

Record the outcome, scope, must-haves, nice-to-haves, evidence, constraints, sourcing boundaries, assessment plan, owners, approvals, budget inputs and decision rule. Include a version and approval date.

Is a hiring brief the same as a job description?

No. A public JD invites candidates and describes the opportunity. An internal brief records decisions, evidence, boundaries and approvals so the JD, scorecard and shortlist stay aligned.

Should missing profile information disqualify someone?

No. Treat it as unknown and assign a job-related verification step. Missing public evidence is not proof that a candidate lacks the capability.

Does Talent Summoner decide who gets hired?

No. Our product organises public-profile sourcing and explains ranked results. People verify evidence, own outreach and interviews, and make the final decision.

Copy the blank brief for one open role, get the outcome and budget inputs approved, and then start a candidate-sourcing search with the decision-maker and reviewer named.

Talent Summoner product facts read from our live candidate sourcing, candidate ranking and pricing pages, verified 19 August 2026. We re-verify this page quarterly — tell us if something changed.