Role Intake & Kickoff Brief — Tech Recruiter / People Ops Capstone — SkilsMVP

What you'll produce

A one-page Role Intake & Kickoff Brief — the document you write coming out of your kickoff meeting with the hiring manager, and the foundation every later deliverable in this capstone builds on. It converts a vague wish-list job description into a sharp, agreed target: the real must-haves vs. nice-to-haves, 2–3 concrete "what great looks like" profiles, the team/context, the candidate pitch (why a great person would actually want this), and the logistics (seniority, salary band, location/remote, timeline, interview loop). This is the single highest-leverage artifact a recruiter produces (Topic 8): get it right and your sourcing, screening, and close all aim at the same target; get it wrong and you'll burn weeks sourcing the wrong people. It also proves the partnership skill interviewers probe hardest — that you can run an intake, push gently past a wish-list to the essentials, and turn a busy manager's hand-waving into a plan you can both be held to.

Instructions

Capture the basics first. Company, role title, hiring manager, the req's age and urgency, and why this role exists now (the business reason — what breaks if it stays open). One or two sentences each. This frames every decision that follows.
Separate must-haves from nice-to-haves — and force the split. Take the manager's requirement list and sort every item into exactly one of two buckets. The test for a must-have: "Could someone do this job well without it?" If yes, it's a nice-to-have. Aim for no more than 4–5 true must-haves — a longer list is a wish-list, and your job (Topic 3, Topic 8) is to push back on it. Where you down-graded something, note why in one phrase so you can defend it later.
Write the "what great looks like" profiles. Describe 2–3 realistic example candidates the manager would be thrilled to hire — in plain prose, as if describing a real person ("a senior backend engineer who scaled payments at a mid-size fintech…"), not a list of keywords. These become the literal targets for your sourcing Boolean strings (Deliverable 2). Make at least one of them non-obvious (a slightly different background that still hits the must-haves) to prove you're widening the pool, not narrowing it.
Describe the team and context. Who they'll work with, what they'll build, the stack/working style, and — crucially — what makes someone succeed here specifically. This is the raw material for both screening (Deliverable 4) and the pitch.
Draft the candidate pitch (the "why join"). In 3–5 sentences, answer: why would a great, currently-employed engineer want to leave their job for this one? Lead with what's genuinely compelling (the problem, the scope, the stage, the team), not boilerplate. You will reuse this almost verbatim in outreach (Deliverable 3) and the close (Deliverable 6) — so make it true and specific.
Pin down the logistics. Seniority level, salary band (base + equity/bonus where relevant), location/remote policy, target start/timeline, and the interview loop stage-by-stage (who, what, how long). Vague logistics here cause dropped candidates later (Topic 7).
Ground the salary band in market data — don't repeat a number you were handed. The band is a researched recommendation, not a guess. Triangulate it from named sources for this role, level, and location — e.g. levels.fyi and Pave / Option Impact for tech comp by level, published comp surveys (Radford, Mercer, Glassdoor/LinkedIn salary insights) for ranges, and the company's internal pay-equity data (what current engineers at this level actually earn) so a new hire doesn't land above the existing team. Cite which sources you used and what range they imply. Then compare the manager's stated band against that market read, and if it's below market, flag it at intake — quantify the gap ("the 50th percentile for a senior backend engineer in NYC is ~$X; your band tops out below that") and say what it costs (slower pipeline, losing finalists at offer, or being forced to drop a must-have). A below-market band you surfaced and put on the table is a talent-advisor move; a below-market band you quietly accepted is how the search stalls.
Add a "market reality" note and one agreed action. As the market expert (Topic 8, Topic 9), state honestly whether the must-haves are findable at the stated band and timeline — and capture one thing the manager agreed to do or decide (loosen a requirement, confirm or raise the band, commit to feedback turnaround). An intake without an agreed trade-off usually means you didn't push hard enough.
Keep it to one page and get sign-off. End with a single line: "Confirmed with [manager] on [date]" — the brief is an agreement, not your private notes.

Worked example

Role Intake & Kickoff Brief — Senior Backend Engineer (Ledger team)

Company / role: Northwind (≈120-person Series B fintech, NYC, payments infrastructure) — Senior Backend Engineer, new headcount on the Ledger team. Hiring manager: Dana Whitfield, VP of Engineering. Req status: open ~4 weeks, weak inbound (8 applicants, 0 advanced). Urgency: high. Why this role exists now: Northwind is shipping a new double-entry ledger product that a key partnership depends on; the team is one senior backend engineer short to hit the launch. Target: filled within 8 weeks (by ~Aug 10). Every week open pushes the launch.

Must-haves (the real bar — 4):

5+ years backend engineering, with real ownership of production services (not just feature work).
Strong in Python or Go — Dana confirmed she'll trade language familiarity for distributed-systems depth; a strong Go engineer who hasn't written Python is fine.
Distributed-systems fundamentals — has built or operated systems where correctness under concurrency/failure matters (consistency, idempotency, queues).
Domain proximity to money-movement correctness — payments, ledgers, banking, trading, billing, or similarly high-stakes data where being wrong is expensive.

Nice-to-haves (won't gate a candidate):

Kubernetes / specific infra tooling (learnable on the job — down-graded from "required").
Prior startup / 0-to-1 experience (a plus for comfort with ambiguity, not a filter).
CS degree (explicitly dropped — Dana agreed it over-filters strong self-taught engineers).
Fintech brand-name experience (the skill matters, not the logo).

What "great" looks like (3 profiles):

A. A senior engineer at a mid-size fintech (think a Plaid/Marqeta-tier company) who has spent 3+ years on payments or ledger services, owns a service end-to-end, and is getting bored as the company gets big and slow — wants more scope and earlier-stage impact.
B. A Go backend engineer from a high-scale non-fintech (ride-share, logistics, ad-tech) who has obsessed over exactly-once processing and data correctness at scale. Non-obvious profile: no fintech logo, but the hard skill — correctness under concurrency — transfers directly. Would need a light ramp on payments domain; Dana is happy with that.
C. A founding/early backend engineer from a seed-stage startup that didn't make it, who built core financial infrastructure mostly solo, is hungry, and wants a stable-but-still-early Series B with real users and runway.

Team & context: Joins the 6-person Ledger pod (1 staff eng/tech lead, 4 engineers, 1 PM), reporting to Dana for now. Stack: Python + Go services, Postgres, gRPC, AWS, event-driven (Kafka). Working style: small, high-autonomy, ships behind flags, light process. **Succeeds here = ** someone who can own an ambiguous problem without a spec, cares about correctness over cleverness, and is comfortable being one of the senior voices in the room (this is not a role for someone who needs heavy direction).

Candidate pitch (why join): You'd own core services of a brand-new ledger product at the layer where correctness actually matters — the kind of greenfield, high-stakes system most engineers only get to maintain, not build. Northwind is Series B with real revenue and a named partner already waiting on this, so it's early-stage scope with far less existential risk than a seed startup. The team is small and senior, so your work ships and your voice carries. And the problem space — moving money correctly at scale — is genuinely hard and genuinely respected by good engineers.

Logistics:

Seniority: Senior (IC, not managing). Could flex to Staff for an exceptional A-profile.
Salary band: $185–215K base + 0.15–0.30% equity + standard benefits. Market read: levels.fyi and our Pave/Option Impact percentiles put a NYC senior backend engineer (L4/L5-equivalent) at roughly $190–230K base at the 50th–75th percentile; the 2025 Radford survey agrees. Internal pay equity: our two current senior backend engineers sit at $195K and $205K, so the band can't realistically open below ~$190K without underpaying relative to the team. Flag raised at intake: Dana's first-pass band of $170–195K topped out below the NYC median and would have left us competing for the bottom of the market on a tight, expensive profile — likely losing finalists at offer or stalling the pipeline. After walking through the sources, Dana raised the band to $185–215K and confirmed she can go to $225K base for a clear top finalist.
Location / remote: Hybrid — 2 days/week in the NYC office; open to strong remote candidates in US Eastern/Central time zones.
Timeline: Offer out within ~6 weeks; signed by week 8.
Interview loop (5 stages): (1) Recruiter screen — me, 30 min. (2) Hiring-manager chat — Dana, 45 min. (3) Technical: systems design — staff eng, 60 min. (4) Technical: coding/pairing — 2 engineers, 60 min. (5) Values/collaboration — PM + 1 eng, 45 min. Loop fits in one week if scheduled tightly.

Market reality & agreed action: This is a tight, expensive profile and the original JD's "Python and Go, Kubernetes, fintech, CS degree, exactly-once at scale" list would have left almost no findable pool inside 8 weeks. Agreed in kickoff: Dana (a) accepts Python or Go, (b) drops the degree and Kubernetes requirements, (c) opens the search to strong remote Eastern/Central candidates, (d) raised the base band to $185–215K after we showed her original top-out sat below the NYC median (levels.fyi / Pave / Radford), and (e) committed to 48-hour turnaround on interview feedback so we don't lose finalists to slow loops (Topic 4/7). I'll bring 3–4 calibrated profiles within a week to confirm we're aimed right before going wide.

Confirmed with Dana Whitfield (VP Eng) — kickoff held, brief reviewed and agreed.

Rubric

The app's AI scores the learner's submission against these criteria and gives feedback. Levels: Needs work (1) / Solid (2) / Excellent (3). Passing = every criterion at Solid or above.

Must-haves vs. nice-to-haves discipline — 1: copies the JD wish-list or marks everything a must-have · 2: a genuine split with a short must-have list · 3: ≤4–5 defensible must-haves, each nice-to-have justified, with at least one requirement actively pushed back on and re-bucketed.
"What great looks like" profiles — 1: missing, or a list of keywords · 2: 2–3 realistic profiles in plain prose · 3: 2–3 vivid, hireable profiles tied to the must-haves, including one non-obvious background that widens the pool.
Candidate pitch — 1: generic boilerplate ("great team, competitive pay") · 2: a clear, role-specific why-join · 3: a compelling, true, candidate-first pitch you could paste into outreach, leading with what genuinely excites this profile.
Logistics completeness — 1: key items (band, level, location, loop) missing or vague · 2: all logistics present and concrete · 3: all present, specific, and realistic — including a stage-by-stage interview loop and a real salary band with flex.
Market-grounded salary band — 1: a number with no basis (invented, or just the manager's figure repeated) · 2: a band stated as a range with some rationale · 3: the band is a researched recommendation — triangulated from named sources (e.g. levels.fyi, Pave/Option Impact, a published comp survey, internal pay equity) with the implied range cited, and if the manager's band is below that market read the learner flags it at intake, quantifies the gap, and names what it costs (rather than silently accepting a below-market number).
Talent-advisor judgment (market reality + agreed action) — 1: no market read; pure order-taking · 2: notes the market is tight · 3: states honest findability against band/timeline and captures a concrete trade-off or decision the manager agreed to.
Coherence & usability as a foundation — 1: scattered notes, no sign-off · 2: a clean one-page brief · 3: a crisp, one-page, signed-off brief that visibly sets up sourcing, screening, and the close (the rest of the capstone).