The TA Operating System

Applicants were waiting for a first answer. The first read of a CV depended on who picked it up, side spreadsheets drifted from the hiring record, and booking an initial call with the recruiting team took email back and forth.

I rebuilt how the team hires around one rule: machines run repeatable work; people set the bar and make hiring judgments. The work connects written standards, sourcing, candidate communication, assessment, and measurement around the applicant tracking system (ATS).

That experience informs the framework below: how I would design the whole hiring system, including the decisions, approvals, and feedback loops each stage needs. The implementation can vary with a team’s tools; the responsibilities and standards should remain clear.

It grows from my recruiting practice: understand the business problem, agree what contribution the team needs, and help the people involved make a decision they can explain. The operating system carries that discipline across searches, while the tools support particular moments in the work.

For the story behind the framework, read Machines Run the Repeatable Steps, People Make the Calls on Medium. I describe the rebuild, the early evidence, and what measuring the system revealed.

The system has one north star: joins against the headcount plan. This measures delivery against hiring commitments. Whether the hires strengthen the team becomes clearer after joining, through their contribution and the capability they help others develop.

Begin with the hiring system

An applicant tracking system records events. It rarely tells a leadership team where hiring is losing time, why it is happening, or who can unblock the next decision. A dashboard, a sourcing tool, or an AI workflow can help, but each becomes another isolated layer if the operating model is unclear.

The starting point is a shared view of the work: what the business needs, what good looks like for each role, which decisions belong to people, and how the team will see whether a search is moving.

I design the system around four connected outcomes:

• Candidate experience: candidates get clear communication, timely movement, and a thoughtful decision process.
• Talent Density: a written standard gives the team a consistent basis for assessing potential contribution. Evidence of improvement comes from what people contribute after joining.
• Funnel health: the team reaches relevant people, learns where conversion weakens, and directs effort where it can make a difference.
• Reliable operations: stalls, overloaded interviewers, missing feedback, and unclear ownership become visible in time to act.

An improvement needs to strengthen at least one of these outcomes without weakening another. That gives the team a practical test for every proposed automation or process change.

Put people in charge of the decisions that matter

The operating rule is simple: machines run repeatable work; people set the bar and make hiring judgments.

Automation prepares briefs, drafts messages, organises evidence, identifies delays, and applies defined rules. Model-generated assessments still need review. People decide what the team needs, interpret the evidence, and take responsibility for each hiring decision.

A model can interpret the same CV differently on another pass. A written bar gives it a common standard; it does not make the judgment deterministic. Human review, checks for uncertain outputs, and a fresh look at rejected profiles are part of how I examine where it may have missed something.

Set the standard first

• Agree the role bar with the hiring manager.
• Use a shared job-description template and capability ladder.
• Cite CV evidence for placement on the ladder, crediting work the person actually did.

Approve actions and respect the candidate

• Review and send one-to-one messages personally.
• Preview candidate-record changes in a dry run and require approval before execution.
• Apply contact rules to automated sequences: exclude previously rejected candidates and hold recent contacts back.
• Offer recording consent and an opt-out, with manual interviewer feedback when recording is declined.

Keep the evidence open to review

• Review every screening result and re-read a sample marked for rejection to check for missed evidence.
• Refer uncertain model outputs to a human. A missing role bar or unclear evidence should prompt a question before the workflow proceeds.
• Keep the ATS as the single record, with measurement reading from it.
• Keep interviewers and hiring leaders accountable for the assessment, decision, and explanation.

Agreement with an earlier screen alone cannot establish assessment quality. The review needs to examine the evidence behind it.

These controls make the system inspectable. They also create room for recruiters and interviewers to spend more time on the conversations, evidence, and judgment that candidates deserve.

Connect the whole hiring life cycle

The framework follows nine stages. The map shows the support I would design into each stage and the decision a human keeps. The detail below explains how I would apply it.

1. Plan the capacity and the hire

Connect each search to a planned seat, the capacity to interview, and the business reason the role exists. The hiring leader decides when a role opens and what priority it has.

2. Define the role and the bar

Write the contribution required, the essential evidence, and the conditions for success. The hiring leader signs off the role bar, job description, and interview plan before the search begins.

3. Make the opportunity clear

Prepare the careers content and hiring narrative around a real problem the role will own. A human edits and publishes it, ensuring the opportunity is both accurate and worth a candidate’s attention.

4. Find relevant people

Search against the agreed bar, map target organisations and adjacent pools, and build a repeatable referral path. The system can surface and prepare options; people decide who to contact and how to begin a meaningful conversation.

Agency intake follows the same standard. I would give agencies a submission route tied to the role and its written bar. Each submission should:

• Retain its source and surface any existing candidate record.
• Reach a named recruiter for review.
• Follow the same assessment standard as referral, sourced, and inbound candidates.

5. Engage and assess early evidence

Candidates can book conversations, responses can be organised, and a screen can apply the written bar. A recruiter reviews the evidence and approves every move. This gives candidates a timely answer without turning their experience into an opaque decision.

6. Run interviews that produce usable evidence

Each interviewer has a defined area to explore. Interviews, feedback, and debriefs connect back to the role bar, with room to investigate what a candidate actually did, owned, learned, and changed. The panel owns the hiring judgment.

I would connect the workflow through four steps:

1. Schedule: use the interview stage and interviewer availability, with recruiter coordination for complex panels.
2. Prepare evidence: with consent, use the transcript to draft evidence against the bar.
3. Review and decide: the interviewer checks the account, adds missing context, and sets the rating and recommendation before feedback is filed. Resolve gaps in panel write-ups before the final call.
4. Coach and calibrate: review how interviewers reached their assessments and choose what to improve in the next conversation.

Interview Evaluator already supports coaching from real transcripts: where a question found depth, where a follow-up was missed, and what to practise next. RishiOS supports role-specific criteria and scorecard checks.

7. Help both sides reach an offer decision

The team brings together the evidence, the candidate’s questions, and the conditions for contribution. Tools can prepare a closing brief and an offer narrative. Leaders remain responsible for the offer and the commitments it carries.

My approval framework would make three things explicit:

• Authority: who approves the terms and which exceptions need another decision.
• Progress: where the brief goes next and which approvals remain outstanding.
• Record: the approved terms and decisions filed against the candidate. Material changes return to the relevant approver before release.

The approval can run through a native workflow or a documented review with approvals filed in the ATS. In either case, the recruiter should be able to see who approved what and whether the offer is authorised to go out.

8. Carry the promise into joining

The offer should transfer the agreed work, authority, support, and expectations into the new hire’s first steps. This is where the team tests whether the hiring conversation described a role that can genuinely succeed.

9. Measure, learn, and improve

A read-only management view shows role health, funnel movement, waiting time, interviewer capacity, feedback completion, and referral activity. The team can then act on a live constraint instead of reviewing stale status updates.

The review should end with a change to test and a date to learn from it. I would run the improvement loop through five steps:

1. Find the constraint: examine where progress breaks down, using the hiring record alongside recruiter, candidate, and hiring-manager feedback. Keep joins against the plan as the delivery measure.
2. Choose a change: agree what we think is causing the problem, the change to test, and the signal that would show improvement. Record the baseline, an owner, and a review date before acting.
3. Test in the work: apply the change to a defined role or workflow. Record what changed so the team can interpret the result.
4. Check the effect: compare with the baseline and examine changes in role mix, volume, or capacity that could explain the difference. Check candidate experience and assessment quality alongside speed.
5. Keep, adjust, or stop: decide what the evidence supports. Feed the learning into the role bar, sourcing approach, interviewer coaching, approval rules, or workflow, then review the next constraint.

For example, if candidates wait for panel feedback, I would test clearer feedback ownership and reminders. Shorter waits would be useful evidence only if the write-ups still contain enough detail to support the decision.

The loop continues after joining. With the hiring leader, I would revisit the agreed contribution and the conditions for success: did the person receive the work, authority, and support described? What are they contributing, and how are they helping the team become more capable?

That review should distinguish gaps in assessment from gaps in onboarding or support. What we learn then informs the next role definition and interview plan. This is how post-hire evidence helps us understand whether Talent Density is improving.

Build on the tools the team already trusts

I start with the systems already in use and their native capabilities. The applicant tracking system remains the record. Other tools extend it only where they make a specific decision, action, or signal clearer.

The tools I have built show how I approach specific decisions and conversations. They are examples of capabilities that can support the wider framework; each project page explains what that tool actually does:

• Sourcing Compass makes the reasoning behind a search visible before outreach begins.
• Interview Evaluator helps interviewers learn from the evidence they gather in real conversations.
• RishiOS supports role-specific criteria, scorecard checks, and evidence discipline.
• Offer Wizard carries candidate and interview context into a personalised offer narrative.
• TA CentCom turns the underlying hiring record into a view of search health, accountable delay, and action ownership.

Together, they support a team’s judgment. They do not replace it.

Fit the implementation to the team

I would first agree the standard, the decision owner, and the record each stage needs to leave behind. Then I would choose how the team implements it: a native ATS feature, a connected tool, or a documented step with a clear owner.

Across different stacks, the requirements stay clear:

• Offer approvals: an explicit decision and a record.
• Agency submissions: a role, a source, and a reviewer.
• Interview feedback: evidence and an accountable assessment.

Those requirements give the team a stable basis for improving the workflow as its tooling changes.

Start where the evidence says hiring is stuck

The sequence matters. I begin by finding the constraint closest to the work: an unclear role, a queue where candidates wait, an interview loop with inconsistent feedback, or a stalled decision with no visible owner.

From there, the work usually follows seven steps:

1. Agree the outcome hiring serves and the few outcomes that protect it.
2. Write the role bar, a consistent job-description template, and the assessment standards.
3. Map the life cycle and decide which steps automate, assist, or remain human.
4. Check the existing stack’s capabilities before building for a gap.
5. Keep the applicant tracking system at the centre and gate consequential changes.
6. Establish a baseline through read-only measurement before changing the workflow.
7. Start where candidates wait longest. Test improvements with named owners and carry learning from hiring and post-hire contribution back into the standards and workflow.

If hiring progress or decision quality is holding a team back, the Hiring Health Assessment is the practical starting point. It identifies the main constraint against available evidence and maps the first changes in order.