A hiring pipeline your small team can actually keep up with

A pipeline is useful when it helps someone act. A column called “Interesting” might describe a feeling, but it doesn't tell a teammate whether to read a portfolio, arrange a conversation or wait for feedback. Start by listing the decisions your team needs to make before offering someone the role.

For a small team hiring a product designer, those decisions might be: does the application contain relevant work, is the role a practical fit, can the candidate explain their approach, and do we have enough evidence to make an offer? Each decision needs a place in the process. It doesn't automatically need a separate meeting.

Keep a short role brief beside the pipeline. Write down the work this person will own, the few capabilities you need to understand and the people involved in the decision. That brief gives the stages a purpose. Without it, moving a card can become a substitute for making progress.

Use the example below as a starting point, then adapt it to the role. “Review” can include reading an application and a short introductory conversation. “Interview” can contain more than one conversation if each has a distinct purpose. You don't need to show every internal task as a new stage.

The person listed as responsible is a team agreement. It can live in your hiring brief or meeting notes; a pipeline tool doesn't have to assign it automatically. The important thing is that the team knows who is picking up the next step.

“I've had a look” isn't much of a handoff. A useful review records what was considered, what the reviewer learned and what should happen next. It can be short: “Portfolio shows work on a similar product. Ask about their contribution to the research in the first conversation.”

Before an interview, the next person should be able to find the application, relevant notes, the purpose of the meeting and the questions they are responsible for exploring. Afterwards, they should leave evidence that helps the decision maker, rather than repeating the candidate's résumé.

Agree a response expectation your team can maintain. For example, you might decide to review new applications on two named days each week. This is an operating choice, not a universal deadline. Tell candidates when they should expect an update, and change that expectation openly when circumstances change.

A useful pipeline meeting can be built around three questions:

• Who is waiting for us, and what is the next action?
• Which decision is blocked, and what information would unblock it?
• Has anything about the role changed enough that we need to update candidates?

Read across the stages instead of reciting every name. If several interviews are complete but no decisions have been recorded, the problem is probably the handoff after the conversation. Adding another stage won't solve that. Agree who will gather the missing feedback and when the team will decide.

Keep withdrawn and declined applications distinct from people still being considered. An active pipeline should describe work the team intends to do. Closing an application with a clear reason is more useful than leaving it in “Review” indefinitely.

Rolefern lets you configure stages for a job, keep candidate profiles and files together, and collect shared reviews. Start with one live role. Add the stages you need, agree the handoffs with your team and use candidate notes to make the next action understandable.

The habits around the tool still matter. Decide who reviews applications, what interviewers need to record and how you will keep candidates informed. A clear workspace supports those agreements; it doesn't make the agreements for you.

Before adding another stage, ask whether it would change a decision or simply rename work already happening. A small pipeline that the team keeps current is a better starting point than an elaborate process nobody maintains.