Guide / Buying Signals

Hiring signals: how to use job posts as buying triggers

A public job post is one of the few honest things a B2B company puts on the internet. It is a budget announcement in disguise, signed off by finance, with a date attached. In this guide I will walk through how we read hiring signals, which roles open which buying windows, where to source the data, and how to write a message that does not sound like you set a Google alert on their head of engineering.

Why a job post is a budget announcement

To post a role publicly, a company has to clear three internal gates: finance approved the salary band, a hiring manager agreed to own the seat, and someone wrote a job description specific enough to attract candidates. Those three things together mean the budget exists, the work is real, and the team has already decided how the new hire fits in. Job posts are slower than rumours and noisier than internal memos, but they are the most reliable public statement of intent you can find for free.

A new role almost always comes with tooling spend. A new Head of Sales will buy something to make her first quarter look organised. A third QA engineer means QA stops fitting on one person, which means test tooling, environments and ownership. A first DevOps hire means cloud spend is large enough to need a dedicated owner. Each of those is a buying window that opens for about a quarter and then closes once budgets harden.

Which roles signal which buying windows

The role itself is the signal. Seniority and count change which window is opening. A rough map we use:

None of these are guarantees. They are probabilities you can layer on top of an ICP filter to shrink your weekly list to the accounts that have something on the line right now. For our agency clients selling into engineering teams, the third QA hire is one of the cleanest predictors we have. For clients selling RevOps software, the first VP Sales is the one we set the rest of the workflow around.

Where to source hiring data

There is no single perfect source. We almost always combine two or three to cover the gaps.

• LinkedIn job posts. The richest source for white-collar roles in tech. Sales Navigator filters and the public jobs feed are both usable. Coverage is best for roles posted by recruiters, weaker for roles only listed on the company career page.
• Company career pages. The source of truth, since this is what finance actually signed off on. Scraping career pages is fragile but pays off for a defined target list. We do this for the top few hundred accounts on a named TAM, not for the long tail.
• Public job boards and aggregators. Indeed, Wellfound and country-specific boards. Useful for breadth, weaker on filtering. Good as a fallback when LinkedIn is missing a posting.
• Specialist providers. Several vendors aggregate hiring data with structured fields like role family, seniority and tech stack mentioned in the JD. Worth the credits when the role family matters more than the company name.

We pull the raw feed into our enrichment surface (usegrit.io, Clay works too), normalise the fields we care about (company, role, seniority, posted date, location, stack mentioned in the JD), and apply filters before anything enters a workflow. The filter is where most of the value is. Raw hiring data without filtering is noise.

Filtering the noise

The first time you wire a hiring feed into your outbound system, your inbox will fill with garbage. Job posts are noisy because companies repost roles, agencies relist on behalf of clients, and large companies post a steady stream of routine backfills that signal nothing. Three filters do most of the cleanup.

1. Seniority. For most B2B sellers, the signal lives at lead, head or VP level for the first hire in a function, and at IC level once you are looking at count thresholds. Filter accordingly.
2. Count thresholds. One QA engineer is hygiene. Three in a quarter is a buying window. Wire a rolling 90-day window per company and per role family, and only fire when the count crosses the threshold.
3. Recency. A post older than 60 days is either filled or stale. Fresh posts within the last 14 to 30 days are the sweet spot for outreach. After that, the buyer is in interviews and not reading your email.

A fourth, softer filter is exclusions. We exclude companies actively being acquired, companies that just laid off in the same function, and recruiting agencies posting on behalf of multiple clients. These are easy to script once you have seen the patterns.

How to reference a hire without sounding like a stalker

The mistake most teams make on hiring signals is leading with the signal. A message that opens with "I saw you posted a role for a Senior QA Engineer" sounds exactly like what it is: an automation that triggered on a public feed. The buyer reads it, decides you are watching too closely, and archives.

A better pattern is to reference the implication of the hire, not the hire itself. If a SaaS just opened a third QA role, the implication is that someone on the team is about to inherit a test pipeline that does not scale. Lead with that observation, name the pain a person in that seat usually faces in the first 60 days, and offer one concrete thing you can do about it. The job post is the reason you are writing this week, but it does not have to be the reason you give in the message.

A small detail that matters: write to the function lead, not to the new hire. Most teams reflexively message the brand new VP in week one along with two hundred other vendors. Better to write to the person who owns the budget, or to the founder if the company is small, and frame the message around what the new hire will need.

Common mistakes

• Reacting to every post. If your workflow fires on every match, your sending reputation will tank and your message quality will collapse. Filter hard before the workflow runs.
• Messaging the new hire on day one. They are getting onboarded and pitched at the same time. Wait 30 to 60 days, or message the budget owner instead.
• Treating the post as the whole story. A job post is a probability, not a confirmed buyer. Layer it on top of ICP and firmographic fit, never use it on its own.
• Letting the data go stale. A hiring signal six months old is a noise generator. Date-stamp every record and expire it ruthlessly.

Where this fits in the broader signal stack

Hiring is one of four signals we lean on most. The others are funding events, tech stack changes and job changes at named accounts. They overlap. A funding round is often followed by a hiring spree, which produces the job posts you would otherwise scrape one at a time. The job change of a champion to a new company often shows up first as a job post they wrote themselves before their LinkedIn updates.

The mistake I made for years at RightHello, when the agency model was still bodies sending volume, was treating every signal as the same priority. Hiring signals deserve more weight than most because they are slow, public and budget-backed. If you are starting from zero, this is the first signal I would wire in. If you want the wider framework, the how to build a GTM system guide covers where signals plug into the seven-step model. If you want the definition layer, start with what is GTM engineering.