Project Management for Recruitment Projects

The candidate pipeline is a project before it's a hire

Recruitment usually gets tracked in a spreadsheet that one person maintains, updated whenever they remember, or in whatever the applicant tracking system's basic export looks like once you've stopped paying attention to it. Either way, "where are we with the Bangalore ops hire" turns into a message to the recruiter, who has to go and reconstruct the answer.

The pipeline itself has a very ordinary shape: candidates move through stages (sourced, screened, first interview, panel, offer, hired) one at a time, and a hire stalls when too many candidates sit at one stage without anyone moving them forward. That's a board, with columns and limits, not a list.

ShipSprint runs recruitment as exactly that: a board per open requisition, or one shared board with a swimlane per role, where the card is the candidate and the column is the stage they're at.

Where WIP limits earn their keep

Every recruiter has watched a strong candidate go cold because feedback sat unread for a week and a competing offer arrived first. The pipeline didn't fail; a stage inside it quietly overflowed and nobody noticed until the candidate mentioned another offer in a follow-up email.

The single most common failure in a hiring pipeline is candidates parked at "awaiting interview feedback" for two weeks because the interviewer's own workload swallowed the follow-up. A per-column WIP limit makes that visible the moment it happens rather than the moment the candidate withdraws: if the interview column is capped at six and it's full, the next candidate genuinely cannot move in until someone clears a decision on one of the six already there.

That's the same mechanism engineering teams use to stop a review column silently becoming a queue, applied to people instead of pull requests. It doesn't schedule the interview or chase the interviewer. It just refuses to let the backlog hide.

It also reframes a conversation that's usually awkward. "You have too many candidates waiting on you" lands very differently as a column that's visibly full to everyone on the hiring team than as a message from the recruiter that can read as a personal complaint about someone's pace.

What this is honestly not

• No resume parsing. Candidates get added to the board as cards; nothing reads a resume file and extracts fields for you.
• No interview scheduling integration. Booking the interview slot still happens in your calendar tool; the board tracks that the interview needs to happen and records when it did.
• No job board syndication or candidate sourcing. Sourcing is whatever you already do; the board starts once a candidate exists.
• What it is: the same board-and-WIP-limit mechanism used for engineering sprints, applied to a hiring pipeline instead of a backlog of tickets.

If you need dedicated applicant-tracking-system features (structured resume data, scorecards tied to interview kits, offer letter generation), those live in specialist ATS tools, and this isn't a replacement for one. What it's good for is teams whose current recruitment tracking is a spreadsheet or a shared inbox and who want the same visibility their engineering team gets, without buying a second full HR platform just for hiring.

How recruitment sits next to the rest of HR

Recruitment is usually one thread inside a busier HR calendar. While a requisition is open, onboarding for the last hire is probably still running, and a policy review might be happening in parallel. Running all three as boards on the same subscription means a hiring manager isn't logging into three different tools to check three different things, and the recruiter's pipeline sits next to, not separate from, the onboarding board the successful candidate lands on next.

The question every hiring manager asks, answered without a status call

"Where are we on the Bangalore hire" is a question a recruiter answers dozens of times across an open requisition, and every time it's asked directly it costs them ten minutes of reconstructing an answer from memory or a spreadsheet. Put the pipeline on a board and the answer is a glance: how many candidates are at each stage, how long each has sat there, and which cards haven't moved in over a week.

That last figure is usually the most useful one a hiring manager never had before. A candidate who's been "awaiting feedback" for nine days isn't a status update, it's a decision someone is avoiding, and a board that shows stalled time makes avoiding it a little harder than a spreadsheet ever did.

It also changes what a weekly hiring sync is for. Instead of spending the meeting having the recruiter narrate the pipeline out loud, the board is already visible going in, and the meeting can spend its time on the two or three candidates who actually need a decision.

A pipeline needs an exit as much as an entrance

Most hiring pipelines get built with a lot of attention on how candidates come in and almost none on how they leave. A candidate who's rejected, withdraws, or simply goes quiet for a month still needs their card moved somewhere, and "delete it and pretend they were never there" throws away information a future search might want: did this person apply for a different role two years ago, and how far did they get.

A closed column that candidates move to, tagged with why (not a fit, withdrew, position closed, went silent), keeps that history without cluttering the active pipeline view. It also protects the WIP limits: a candidate who's gone quiet but is still technically "in interview" is quietly eating a slot that could go to someone actually moving, and a closed column is where they belong once it's clear they've stalled for good.

The same closed column is what makes a later question answerable: how many candidates did it actually take to make this hire, and at what stage did most drop off. That's not a report ShipSprint generates automatically, but it's a question a board with an honest closed column can answer by scrolling back through it, which a spreadsheet with rows silently deleted never could.