Panel Debrief Alignment

Panel debrief alignment

Runs after any interview round where two or more people formed a view: a panel, a final round, or a hiring manager plus the candidate's own debrief. Produces a decision, not a summary.

The prime rule: never average the panel. Two strong yeses and a quiet no do not add up to a yes. Disagreement is the data. The job is to find exactly where the reads split, why, and whether the split can be closed with evidence the process already holds.

Template placeholders

Replace every {{...}} before enabling. The setup checklist in references/setup-customization-checklist.md covers each one.

• {{ATS}}: where candidates, interview stages and feedback live
• {{NOTES_TOOL}}: interview recordings or notes, if you record interviews
• {{REVIEW_CHANNEL}}: where the debrief card is posted for the hiring manager
• {{HIRING_MANAGER}}: who makes the call on each role
• {{COMPLIANCE_OWNER}}: who receives bias flags
• {{DRIFT_WINDOW}}: hours before a stalled process escalates (default 48)

Trial mode (recommended for the first three roles)

Run with every write to {{ATS}} switched off. Post the card to {{REVIEW_CHANNEL}} marked TRIAL, and let the hiring manager compare it with how they would have called it. Switch writes on once the cards match their judgment, or once they prefer the card.

Diagnostic questions (before the first run)

Ask these once per team. They usually show where the debrief process is leaking.

1. Do interviewers write feedback before the group debrief, or does the group debrief happen first?
2. When the panel splits, who decides, and on what basis?
3. How often does a candidate hear a concern for the first time at rejection?
4. How long, on average, between the final interview and an offer or a no?
5. Which interviewer's "no" has turned out to be right most often?

The play

Step 1. Pull the inputs

• From {{ATS}}: the role, the agreed hiring criteria or scorecard if one exists (use its ranking), every interviewer's written feedback for this round, and the candidate's stage history.
• From {{NOTES_TOOL}}, if available: interview notes or transcripts for this round.
• The candidate's own read, from whoever holds the relationship (hiring manager, recruiter or talent partner): what they thought happened, what they were asked, where they felt strong and where they felt exposed.
• If no agreed criteria exist, ask the hiring manager for the three to six things this hire must prove, and use those.

Missing inputs are named at the top of the card, never filled with a guess. A debrief without the candidate's read runs the panel half only and says so.

Step 2. Check for contamination

Compare each feedback timestamp with the group debrief time. Feedback written after a group discussion, or only given verbally in one, is tagged (group) and cannot on its own make a row ALIGNED. Once the most senior person speaks, everyone else anchors to them and the independent signal is gone.

Step 3. Build the alignment map

One row per hiring criterion, then one row per concern anyone raised. Classify each row against the evidence bar in references/alignment-states-and-scales.md:

• BLIND: one side raised something the other has not registered at all. Worked first, every time.
• DIVERGENT: both sides engaged, different reads. Including interviewer against interviewer.
• UNCLEAR: a feeling with no example. Converted into a question, never decided on.
• ALIGNED: both sides read it the same way, with evidence from each.

Every row cites a quote or an observed behaviour from each side. "Great energy" is not evidence.

Step 4. Rate interest on both sides, separately

Panel conviction and candidate intent, each 1 to 5 against the anchors in the same reference, each with a quote. Flag any single interviewer two or more points from the rest of the panel. That outlier is usually the most important row on the map.

Step 5. Translate the soft language

Run every piece of feedback through references/vague-positive-phrase-library.md. Praise with no example, no next step and no urgency is a slow no. Name it in those words and attach the forcing question.

Step 6. Broker each concern

For every BLIND and DIVERGENT row: whose concern it is, whether it is solvable, and the move. Four kinds, lightest first: unused evidence the candidate has not shown, a targeted reference question, a short paid or time-boxed work sample, or a direct question. Patterns that recur in GTM hires are in references/brokering-moves.md. Log every resolved concern there, so the next debrief inherits a move that already worked.

Step 7. Write the momentum plan

Three actions, each with an owner and a deadline inside {{DRIFT_WINDOW}} hours. Where the owner is waiting on someone else, the plan states what happens at the deadline. "Waiting on client" or "waiting on the panel" is not an action.

Step 8. Post the card and stop

Post the debrief card to {{REVIEW_CHANNEL}}, full content every time, never a pointer elsewhere. A human decides.

[Candidate] / [Role] / Round [n] / [date]
Reads in: [interviewers] + candidate ([who debriefed them]) | Missing: [none or who] | Contaminated: [none or who]
Panel conviction: [1-5] "[quote]" | Outlier: [name, score] | Candidate intent: [1-5] "[quote]"
BLIND ([n]): [one line each]
DIVERGENT ([n]): [one line each]
UNCLEAR ([n]): [question to ask, and who asks it]
Slow-no flags: [phrase, who said it, forcing question]
Bias flags: [any feedback excluded and why, or none]
Momentum: 1. [action] [owner] [by when] 2. ... 3. ...
Decision: Advance to [next step]? Yes / No
          Broker [top concern] before deciding? Yes / No

Step 9. Write back, after the decision

Only after the hiring manager answers:

• Log the debrief as a note on the candidate in {{ATS}}: states, top concerns, the decision and who made it.
• Move the stage only if the answer was Yes, and only to the stage named on the card.
• Create the momentum actions as tasks with their owners and deadlines.
• Read every write back. Not found means retry once, then post a visible warning on the card: "ATS write failed, manual entry needed". Never report a write that did not land.

Write failures never block the card. The card is the primary output.