Have an account? Log in
Five years as the recruitment team Hubstaff never had to build
A 55-person company that had never had a recruiter, in a market where the engineers it needs do not answer job ads. In the last seventeen months alone: 31 hires, 12 of them Ruby on Rails engineers.
31Hires in seventeen months
12Ruby on Rails engineers among them
5 yearsAs their recruitment functionTL;DR
- Who. Hubstaff, a time tracking and workforce management platform based in Indianapolis. Around 55 people when we started, roughly 130 now, fully distributed.
- What they needed. A recruitment function. They did not have one. Before 2020 they posted roles, filtered the inbound and that was good enough. When remote hiring went mainstream that stopped working, and the CEO was doing the sourcing himself.
- Why it was hard. Their core engineering stack is Ruby on Rails and they hire senior. That is a small market, it does not respond well to job ads, and the bar does not move.
- What we did. We became their recruitment team on an RPO model. One recruiter at first, up to three at a time after that, working inside their tools and their process. We also moved them onto a better ATS and rebuilt how their hiring managers give feedback.
- What happened. Five years as their recruitment function, and in the seventeen months from March 2024 alone, 31 hires including 12 Ruby on Rails engineers.
About Hubstaff
Hubstaff builds time tracking, proof of work and workforce management software used by distributed teams. It is headquartered in Indianapolis and has been remote-first since long before that was common, which is also why its own hiring has always been global rather than local.
When we started it was a company of around 55 people. It is now roughly 130. A large part of that growth is net new roles, and a large part is replacing people who moved on, which is a different and less visible kind of hiring work.
We came in through a recruiter we had placed who later joined Hubstaff's HR team, and the first conversation was with the CEO directly.
The brief
Be the recruitment function. Development first, then marketing, product and customer support. Fully remote, hired across Europe and the Americas with no fixed timezone requirement. Senior Ruby and Ruby on Rails engineers as the hardest and most constant part of the work, run end to end from sourcing to offer.
The 5 problems we had to solve
Problem #1: "Posting the role used to be enough. Then it stopped working."
Before 2020, Hubstaff could publish a remote role and filter what came in, and the quality was good enough to hire from. When remote work went mainstream, every company in their market was suddenly advertising the same remote role to the same people. Inbound did not dry up, it got worse: more applications, fewer of them good.
What we did
We moved them from filtering to searching. Outbound sourcing on LinkedIn and Stack Overflow Talent became the main channel rather than the backup, with inbound kept running underneath it. The two behave completely differently and we tracked them separately from the start, weekly, so the decision about where to spend recruiter hours was made on conversion rates rather than on habit.
Problem #2: "Our CEO is doing the sourcing."
The person doing the most important recruiting activity in the company was the CEO. He wanted to talk to every candidate, which was right, but he was also personally finding them, which was not sustainable and not what his time is for.
What we did
We took the top of the funnel off him and left him the part that mattered. The process became: our screening interview, then the CEO, then the CTO. He still met every serious candidate. He stopped spending his week looking for them.
Problem #3: "Senior Ruby on Rails engineers are a small market."
Ruby on Rails is not where the volume is. Senior Rails engineers who are also strong communicators, available, and interested in a product company are a narrow slice of a narrow market, and the great majority of candidates in any given week are not it.
What we did
We ran it as a continuous search rather than a series of vacancies. Twelve Ruby on Rails engineers were hired in the seventeen months from March 2024, which is the part of this account that is hardest to replicate and the reason the relationship lasted five years rather than one search.
Problem #4: "We are not hiring once. We are hiring continuously."
Hubstaff was not filling a vacancy, it was running a hiring function. Thirty-one hires in seventeen months, across development, marketing, product and customer support, with backfills arriving alongside new roles. A transactional relationship, where a supplier appears for one search and disappears afterwards, does not build anything: the market knowledge, the screening standard and the candidate pipeline are rebuilt from nothing every time.
What we did
We ran it as a function rather than a series of transactions. Six recruiters across the period, up to three at any one time, working continuously rather than search by search. The pipeline of Rails engineers was never rebuilt from scratch because it was never dismantled, and the same is true of the screening standard and the market knowledge. That continuity is the whole reason thirty-one hires in seventeen months was possible at all.
Problem #5: "Our recruiters spend half their time on admin."
Recruiting capacity is not only headcount, it is what the headcount can actually spend its time on. Scheduling, chasing feedback, moving candidates between stages and rewriting notes is work that produces nothing and consumes a lot.
What we did
We researched the market and migrated them to Ashby. It cut administrative time for the recruiters by around half, gave the leadership team reporting they did not previously have, and got faster and better-written feedback out of hiring managers, which is the input that actually determines how fast a pipeline moves.
How we actually ran it
- A recruiter inside the company, not an agency outside it. Their tools, their ATS, their meetings. Up to three of ours at a time, six people across the period.
- Outbound as the primary channel. LinkedIn and Stack Overflow Talent, with inbound applications filtered underneath it rather than relied on.
- Weekly KPIs, split by channel. Applications, candidates sourced, interviews conducted, candidates approved and interviews scheduled, tracked separately for inbound and outbound, every week.
- Our screening interview first. Then the CEO, then the CTO. Three conversations, no wasted stages.
- Tooling and process as part of the job. The ATS migration, the reporting, and the feedback format from hiring managers were ours to fix, not theirs.
