How to Write a Role Scorecard Before You Hire

Every scorecard, whether you call it a role scorecard, a job scorecard, or a hiring scorecard, has the same skeleton. The naming varies across templates (Slite); the substance does not.

Part 1: Outcomes. Three to five results the hire must achieve within 90 days, written as finished states. "Ship the billing migration to production with zero invoice errors" is an outcome. "Strong experience with payments systems" is a credential. Rhythm Systems frames the same idea as key results with accountability attached, and recommends that every essential responsibility in a department appear on someone's scorecard (Rhythm Systems).

Part 2: Metrics. For each outcome, name the measure, the current baseline, and the target. A metric without a baseline is a wish. "Reduce first-response time" means nothing; "take median first response from 9 hours to under 2 hours by day 90" means you can check it on day 91.

Part 3: Competencies. The skills and behaviors required to deliver those outcomes. Keep this list short. Recruiting guidance puts the practical ceiling at 6 to 12 job-specific competencies, with more than that diluting focus and causing interviewer fatigue (Pin). Slite's template suggests four to eight criteria, each with one sentence describing what a strong candidate shows (Slite).

The discipline that catches most people: each competency must connect to an outcome. If a competency does not serve any of the three to five outcomes, delete it. This is how the scorecard avoids becoming a personality wish list.

Use this as a working document, not a form. One page, plain language, written by the hiring manager, reviewed by anyone who will interview.

ROLE: [title]
REPORTS TO: [name]
PURPOSE (one sentence): Why does this role exist?

OUTCOMES (90 days)
1. [Finished state, verifiable by a third party]
2. [Finished state]
3. [Finished state]

METRICS (owner: this role)
| Metric | Baseline today | Target at day 90 | Source of truth |
|---|---|---|---|
| | | | |

COMPETENCIES (max 6, each tied to an outcome)
- [Competency]: evidence looks like [specific observable behavior]. Serves outcome [n].

NOT IN SCOPE (first 90 days)
- [Work this hire will not own yet]

HIRING SIGNALS
- Deal-breaker: [one thing that disqualifies regardless of other scores]
- Nice to have: [things that break ties only]

Two design choices are doing most of the work here. "Not in scope" prevents the classic failure where a new hire is measured against a job nobody could do. And separating deal-breakers from nice-to-haves prevents a strong impression on a peripheral skill from outvoting a weak score on a core outcome. Pin's data from a large set of roles found a median of seven criteria per role, with only about 23 percent treated as hard must-haves (Pin).

The vague version: "Senior full-stack engineer, 5+ years, startup experience, self-starter."

The scorecard version:

• Outcome 1: Take the checkout flow from a 6-minute deploy and weekly manual smoke test to a one-command deploy with automated tests on the critical path.
• Outcome 2: Close the three oldest open production bugs, or document why each cannot be closed.
• Outcome 3: Write the onboarding doc that gets a new contributor from clone to first merged pull request in under a day, and prove it by having one person actually do it.

Metrics: deploy frequency (baseline: weekly, target: on demand), test coverage of checkout paths (baseline: none, target: critical paths covered), production bugs open over 30 days (baseline: 3, target: 0).

Competencies: reads unfamiliar code and explains it in writing; debugs by bisecting rather than guessing; asks for help before day three of being stuck; writes tests for their own changes without being asked.

Why this works: every interview question can now be pointed at an outcome. "Walk me through a deploy you automated" tests outcome 1. "Tell me about a bug you closed that others had given up on" tests outcome 2. "Show me documentation you wrote that someone else used" tests outcome 3. The résumé becomes background, not evidence.

The competence-versus-outcome distinction also protects you from the generalist-versus-specialist argument. Founder Institute's guidance notes that early-stage companies usually favor generalists who can do multiple things (Founder Institute), while an RBCx panel of founders countered that startups in practice hire for contained, specialized roles and advised being specific about the skill set (RBCx). Both can be right: the scorecard tells you which is true for this role. If outcome 3 requires writing a doc, testing a deploy, and talking to customers, you have written a generalist scorecard without using the word.

The vague version: "Account executive, hunter mentality, track record of exceeding quota."

The scorecard version:

• Outcome 1: Build and maintain a pipeline of 40 qualified opportunities, defined as a booked call with a decision-maker who has stated a problem your product addresses.
• Outcome 2: Close the first five new customers, and for each, write a two-paragraph note on what almost stopped the deal.
• Outcome 3: Hand off the first ten closed accounts to whoever runs onboarding with a written record in the CRM that passes a spot check.

Metrics: qualified opportunities created per week (baseline: founder-generated, roughly 3, target: 10), deals closed (baseline: 0, target: 5), CRM completeness on closed accounts (baseline: n/a, target: passes spot check on 10 of 10).

Competencies: prospect research before a call; asks a question that changes the shape of the conversation; writes follow-ups within a day; says no to bad-fit deals without stalling.

The insight most scorecards miss: outcome 2 includes the learning artifact, not just the number. Five closed deals is luck-adjacent in a 90-day window; five closed deals plus a written account of what almost killed each one is a repeatable motion. That is what you are actually buying with a first sales hire. And when someone insists a candidate "just has the presence," you can point at competency rows and ask which one presence substitutes for.

The vague version: "Customer support specialist, empathetic, detail-oriented, comfortable with ambiguity."

The scorecard version:

• Outcome 1: Bring the open ticket backlog from 140 to under 30 while keeping the customer satisfaction rating stable or higher.
• Outcome 2: Write and publish the ten most-used macros, each derived from tickets that actually occurred.
• Outcome 3: Create the escalation path: which tickets go to engineering, which to sales, and what information each must carry.

Metrics: open ticket count (baseline: 140, target: under 30), first-response median (baseline: 9 hours, target: under 2 hours), reopened-ticket rate (baseline unknown, target: measured and stable), macro coverage (baseline: 0, target: 10 published).

Competencies: reads a frustrated message and replies to the actual problem; reproduces a bug from a customer description; writes in plain language with no jargon; keeps promises about follow-up dates.

This is the role where a good scorecard changes the interview most. "Detail-oriented" is untestable in conversation. "Reproduce this bug report from a customer email" is a 20-minute work sample that scores directly against competency two. The backlog outcome also clarifies scope: the agent is not just answering tickets, they are building the system that makes tickets answerable, which justifies a full-time hire over a rotating founder shift.

Once every candidate sits in front of the same outcomes, comparison becomes arithmetic with judgment on top. Two practices make it hold.

Structured interviews and anchored scores. A meta-analysis by Sackett and colleagues put the validity of structured interviews at .42, versus .19 for unstructured ones, and earlier work by Huffcutt and Arthur found structure-with-scoring formats reaching .57 (Pin's summary of both studies). You do not need to memorize the coefficients. You need the operational consequence: same questions, same criteria, same scale, scored immediately.

Evidence notes on every score. Slite's guidance is to record what the candidate said or did as facts, leaving out impressions nobody else can check (Slite). A 4 on "writes documentation someone else can use" with the note "candidate walked through a runbook they wrote, a colleague outside the team used it to resolve an incident" is comparable across candidates. "Seemed strong" is not.

A practical comparison table for your debrief:

The decision rule that follows: eliminate anyone with a deal-breaker hit, regardless of total score. Then compare on the outcome you most need in month one, not the average. A candidate with 4/4/1 may beat 3/3/3 if outcome 3 is genuinely deferrable to month four. Write down which outcome is deferrable before you see the candidates, or the scores will bend around whoever you liked.

One more guardrail: the scorecard must not quietly encode illegal criteria. Selection criteria should be job-related and consistently applied, and the EEOC expects employers to retain hiring records, with scorecards typically kept at least a year and two years for larger federal contractors (Pin, citing EEOC requirements). Bias creeps in through words like "culture fit" and "startup background." One RBCx panelist described being screened out years after founding a company because of a corporate résumé line, and recommended judging what the business needs rather than pedigree (RBCx). Every competence row should survive the question: could I defend why this predicts performance in this role?

The scorecard is not a document that dies in the hiring folder. Four downstream uses, each one a small lever.

The job description becomes an abstract of the scorecard. Lead with the outcomes, list the metrics you will share with the hire, and keep the competencies as the requirements section. Candidates who read it self-select: people who want measured outcomes apply, people who want a title do not.

Onboarding is pre-written. The 90-day outcomes are the first 90-day plan, with dates attached. This matters because the cost of a hire includes onboarding and lost productivity, not just recruiting, and those costs are hard to quantify without a plan to measure against (Indeed's hiring cost breakdown). A scorecard gives you the numerator.

Performance conversations have a baseline. Rhythm Systems recommends deciding how job scorecards will interact with performance reviews, development plans, and compensation before rollout, so the document does not become a surprise at review time (Rhythm Systems). If the scorecard was shared at offer stage, the review conversation is a status check, not a trial.

The role can be re-scoped honestly. If the hire hits two of three outcomes and the third turned out to be the wrong bet, you can say so with evidence, because the bet was written down. Scorecards you never wrote cannot be revised; they can only be argued about.

Where this touches the tooling: if one of your outcomes is building an AI feature, the model access layer is usually the first thing a new hire has to untangle. Quanta Inference puts text, image, video, audio, and embedding models behind one OpenAI-compatible API key, which is the kind of decision that belongs on the scorecard as "one provider integration, not five," rather than in the backlog as a discovery project.