# Reading a Competitor's Next Build From Open Reqs and Exits

*You can take one competitor, pull its live reqs and recent departures, and produce a dated, evidence-cited hypothesis of its next product or market move with a confidence call.*

- Canonical URL: https://www.refolk.ai/guides/competitor-next-build-reqs-exits
- Pillar: Market and talent intelligence
- Format: Teardown
- Published: 2026-10-06
- Last reviewed: 2026-10-06
- Reading time: 16 min

This is the procedure for taking one named competitor and reading its next product or market move from the roles it just opened against the people who just left. It is written for strategy and research teams, talent-intelligence analysts, and operators sizing a market, and it carries a single company from raw req pull to a dated, cited hypothesis with a confidence call. Most public writing on this stops at "AI hires mean an AI launch"; this shows the arithmetic, including the two wrong reads that backfill and recycled postings produce.

The core move is pairing. Reading open reqs alone tells you where a company wants to grow. Reading departures alone tells you where it is bleeding. Only the two together tell you whether a hiring spike is a net-new team being stood up or ordinary churn being replaced. Get that distinction wrong and you cry wolf on every spike.

## Why open reqs leak a roadmap before the announcement

A competitor starts hiring 6 to 18 months before it announces the product those hires build. The sequence is fixed: strategic decision, budget approval, headcount approval, job posting, recruiting, hiring, onboarding, execution, announcement. Monitoring postings lets you catch the signal at the job-posting stage instead of waiting for the press release.

That 6 to 18 month window is the most-cited public range, and it is load-bearing for this whole method. Be honest about what it is: a practitioner estimate, not a peer-reviewed finding. Treat it as uncalibrated. A tighter, function-specific claim is better supported by pattern: multiple ML or AI engineer roles opened in a single quarter point to an AI feature announcement within 3 to 6 months.

**6-18 months - Typical lead time between opening roles and announcing the product**

The signal is visible at the job-posting stage, long before the announcement stage.

The volume of open roles is itself intelligence. A company that goes from 5 open engineering roles to 40 in a quarter is doing one of three things: preparing a major product push, absorbing significant attrition, or spending new funding. Volume alone cannot tell you which. The rest of this guide is about resolving that ambiguity on a single company, not guessing at it.

## What counts as a signal and what is just noise

The only explicit published threshold is 3 or more net-new roles in one function in a single weekly run. Below that, you are inside the noise. But a raw count means nothing until you have a baseline to count against, so the first month of this work is spent learning the competitor's normal cadence, after which new postings and removals stand out as meaningful against the established pattern.

The reason the threshold is 3 and not 1 is the ghost-job rate. A large share of listings are never filled, which means a cluster that looks real can be mostly air. Here is the noise floor you are betting against.

| Source | Rate never filled or ghost | Method |
|---|---|---|
| Ashby ATS | ~18% | Real ATS close-out data |
| Greenhouse | ~20% (1 in 5) | Platform study |
| ResumeUp.AI | 27.4% | LinkedIn listing analysis |
| Clarify Capital | ~33% | Employer self-report on intent |

Read the table as a range, not a single number. The Ashby close-out figure of about 18 percent is the strongest lower bound, because it comes from real requisition close-out data at well-run teams rather than survey intent. The Clarify figure of roughly 1 in 3 is the upper bound, based on employers admitting they posted with no near-term intent to hire. Any cluster under about four roles sits inside that band. The published 3+ threshold is really a bet that genuine intent clears the ghost rate.

> **Rule:** Establish baseline before you trust any spike
>
> A single universal cutoff does not exist. Run monitors for about a month first; thresholds are relative to each competitor's established pattern, not absolute.

There is a genuine order disagreement in the field here. One school recommends a full month of baseline before you trust any signal. The other starts pulling and classifying immediately and builds the baseline retroactively over the first few review cycles. If you have time, build the baseline first. If a specific threat is live now, start pulling and accept that your first two or three reads will be weaker because you are judging a spike against a thin baseline.

## The backfill test is the real filter, not the headcount

New capability is defined by the absence of a prior departure, not by raw volume. A backfill inherits an existing funded slot; a net-new role creates one. That single distinction is what separates a team being stood up from leavers being replaced, and it is the step most public analyses skip entirely.

The mechanics make the test reliable. A backfill reuses the existing role, its budget, and usually the old job description, so it is approved and posted fast, clearing in 24 to 72 hours. Net-new headcount has to win fresh budget and headcount approval, so it takes 1 to 3 weeks. The STAR framework's recurrence question captures the stakes: a replacement hire tells you about retention, a net-new role tells you about growth.

#### Classifying a single requisition

1. **Open req detected** - A new posting appears in the flagged function
2. **Search for prior departure** - Did someone leave the same role at the same level before this req opened?
3. **Departure found, title and level match** - Tag backfill - this is retention, not growth
4. **No prior departure or new title/seniority** - Tag net-new - this is a capability bet

*Every req is either backfill or net-new, and the deciding question is whether a departure came first.*

This is why pulling exits is not optional. If your source does not label a req as backfill or net-new, you derive it by checking whether a departure preceded the requisition for the same role. A net-new team shows up as roles with no matching prior departure, often carrying a title or seniority the organization never had before. The payoff is concrete: in one worked example, 59 percent of a rising req pile turned out to be backfill rather than growth. Had the analyst counted headcount alone, the read would have been exactly backward.

> Count the slot that opened with no one leaving to fill it; that is the whole bet.

## Reading the description internals once the cluster survives

For the net-new cluster only, the job description tells you the stack, the direction, and the infrastructure in the required-skills and architecture language. A posting asking for experience with Snowflake and dbt is strong evidence those tools are in use even when neither appears on the corporate website. A line like "building the next generation of real-time payment processing using event-driven architecture on AWS" gives you the stack, the product direction, and the infrastructure choice in a single sentence.

Weight the signals by where they sit. The published weighting from technographic analysis across 12 million companies is clear: location counts 3x, job title 2x, and description body and the ATS URL each count 1x. The practical consequence is that a net-new title the organization never carried before, say its first "Staff AI Engineer," is a stronger pivot signal than any buzzword buried in the responsibilities section.

> **Tip:** Seniority mix dates the maturity
>
> A shift from hiring junior developers to senior architects signals a maturing product line. Director and VP openings signal strategy being formed; individual-contributor clusters signal execution underway.

The newest direction often will not show up as a clean skill tag at all, because emerging-skill tags lag real supply. Refolk's index makes this visible. In Refolk's index of professional profiles, there are 50,920 US senior engineers tagged "Kubernetes" against just 109 tagged "Large Language Models."

| Skill (US, senior) | Population in index | Top employer | Ratio to LLM |
|---|---|---|---|
| Kubernetes | 50,920 | OpenAI | 467x |
| Large Language Models | 109 | Google | 1x |

Do not read that 467x as a true supply ratio. It is partly a tag-coverage artifact: emerging-skill tags lag real hiring, so the count understates new capability. The correct lesson is that the freshest direction hides in job-description text and titles, not in tidy skill tags, which is exactly why practitioners grep descriptions instead of trusting tag counts.

Geography is also part of the move, not just the function. A req's location dates and sizes the ambition. In Refolk's index, US AI/ML engineer-title supply is 6.29x the UK figure.

| Market | AI/ML engineer-title population | Top employer | US multiple |
|---|---|---|---|
| United States | 15,121 | Meta | 1.0x |
| United Kingdom | 2,404 | Meta | 6.29x |

So a UK-based competitor suddenly opening a US AI hub is not just adding roles; it is reaching into a pool more than six times deeper. The location of the req tells you how big a bet the company is making.

This pairing of who just arrived against who just left is the part that is tedious to do by hand across profiles and press. [Refolk](/) lets you ask for both sides of the ledger in plain English and get named people back with their prior employer, tenure, and destination.

I ran this search: `Machine learning and AI engineers who joined Databricks in the last 6 months, with their previous employer and title.` - [see the full result list](https://www.refolk.ai/s/qa4j7f7q7h).

*Returns named arrivals with prior employer and title, so you can match each req against who actually filled it and where they came from.*

## Where the departures come from and how to pull the cuts

Public departure and tenure exposure comes from three places: professional-network profiles carry self-reported tenure and where people went, press releases cover senior moves, and state WARN filings cover mass cuts. Log who left the flagged function in the trailing two to three quarters, with seniority, tenure, and destination, placed beside the reqs list so you can run the backfill test row by row.

WARN is the strongest public source for cuts. The WARN Act requires employers with 100 or more staff to give at least 60 days notice before a mass layoff, states publish those notices, and aggregators collect them from state labor departments, match employers to tickers, and show which companies are cutting, where, and how many. One public database holds more than 85,100 notices covering 9.0 million workers across all 50 states and territories; another aggregates notices from 29 state labor departments and matches them to public-company tickers.

The reason this matters for roadmap reading is that cuts and builds co-occur, and the combination is the clearest pivot signature there is. Two documented cases make the point.

| Company | Cut | Context |
|---|---|---|
| PayPal | 251 San Jose jobs (senior SWEs, directors, managers) | Part of a ~20% workforce cut redirecting $1.5B into AI |
| Oracle | 546 from America Cloud Infrastructure (~7.6%) | Cloud revenue grew 62% year over year |

Oracle cut cloud staff while cloud revenue grew 62 percent; PayPal cut 251 roles to redirect 1.5 billion dollars into AI. Departures in one unit plus reqs in another is the pivot signature. Reading either side alone would have missed it. The exits tell you what the company is walking away from; the reqs tell you what it is walking toward.

> **Watch out:** A WARN notice is a forecast, not a confirmed cut
>
> Notice counts are advance warnings. Numbers change, and some filings are amended or withdrawn, so treat the figure as a planning estimate and re-check the state record rather than hard-coding it.

## The step-by-step procedure

Run these eight steps on one competitor, in order. Steps 1 through 3 handle the reqs coming in; step 4 handles the people going out; steps 5 through 8 do the pairing and the write-up.

#### One competitor, raw pull to dated hypothesis

1. **Scope and baseline** - Pick one competitor, list its careers pages and ATS, and run monitors for about a month to learn its normal hiring cadence. Done means a baseline count of open roles by function and seniority.
2. **Pull live reqs and classify** - Save all new postings to a table, roughly 10 minutes per competitor, from the careers pages and LinkedIn Jobs tab. Classify each by function keyword, seniority, location, and named tools.
3. **Run spike detection** - Diff this period against baseline and flag any function with 3 or more net-new roles. Send yourself an alert if spikes appear, then save current counts as the new baseline. The whole run takes under five minutes weekly.
4. **Pull recent departures and tenure** - From professional profiles and press, log who left the flagged function in the trailing two to three quarters, with their seniority, tenure, and destination. For cuts, check state WARN filings. Done means a dated exits list beside the reqs list.
5. **Apply the backfill test** - For each new req, check whether a matching departure preceded it. If yes and the title and level match, tag it backfill; if there is no prior departure or the title is new to the org, tag it net-new.
6. **Read description internals** - For the net-new cluster only, extract named tools, architecture phrases, and seniority mix, weighting title and location mentions above body text. Done means a one-line stack-and-direction statement per cluster.
7. **De-noise** - Drop recycled and ghost reposts, then check whether three to five peers are hiring the same cluster. Done means the cluster survives both filters.
8. **Write the dated hypothesis** - State the predicted move, the evidence, the date window, and a confidence call. Done means a cited, dated hypothesis a colleague could challenge on its evidence.

The output of step 8 is a short, defensible artifact. Here is the skeleton to fill.

**Dated competitor-move hypothesis**

```
COMPETITOR: <name>
PREDICTED MOVE: <product or market move, one sentence>
NET-NEW CLUSTER: <count> roles in <function>, <seniority>, <location> - no matching prior departures
STACK/DIRECTION READ: <named tools and architecture, from job descriptions>
EXITS READ: <who left the adjacent unit, where they went, from WARN/profiles>
DATE WINDOW: <announcement expected between X and Y, using 6-18mo lead from first req date>
PEER CHECK: <N peers hiring same cluster: yes/no>
GHOST CHECK: <reposts and >90-day listings removed: yes/no>
CONFIDENCE: <high / medium / low> because <the single strongest and single weakest piece of evidence>
```

*Fill each line from your own worked case. Keep the evidence cited and the date window explicit.*

## How this read goes wrong

Eight failure modes are documented, and they are the most valuable part of this guide because every one of them produces a confident wrong answer. Treat each as a check you must pass, not a risk you merely note.

```figure
kind: matrix
title: Is the spike a real build?
caption: Two questions resolve most false positives: is the demand genuine, and is it net-new.
x: Reposted or ghost listings :: Fresh, filling listings
y: Preceded by departures :: No prior departures
quadrant: Ghost backfill - ignore, it is noise filling churn :: Real backfill - retention story, not a build
quadrant: Ghost wishlist - one-off reposts, drop them :: Net-new build - the signal you are hunting
```

- **Ghost-req inflation.** A cluster of 8 open ML roles where 3 are 6-month-old reposts is not an 8-role build. Check posting age and whether the same job-description text recurs. With 18 to 27 percent of listings never filled, assume some of any cluster is air.
- **Backfill dressed as growth.** Five new reqs, each preceded by a resignation at the same level, is replacement, not expansion. Match every req to a prior departure before you count it net-new.
- **Attrition spike read as expansion.** A jump from 5 to 40 engineering roles that coincides with a WARN filing or a visible exodus is turnover, not a build. Segment new versus backfill and cross-check WARN.
- **Market-wide trend as a single-firm move.** "They are building agents" collapses when six peers posted identical roles. Scan three to five peers for the same cluster before attributing it to one company.
- **Keyword negation.** A grep reads "migrating away from Oracle" as Oracle adoption. It is the opposite: a churn signal. Require phrase-level context around every tool hit.
- **One-posting wishlist.** A single tool mention is one manager's wish. A tool mentioned across five postings over six months is a committed stack; a tool mentioned once is not.
- **WARN over-read.** Notice counts are forecasts. Numbers change and filings are amended or withdrawn, so do not treat a WARN figure as confirmed headcount.
- **Crawl-gap false pivot.** A company going quiet across unrelated technologies is a scrape artifact, not a strategy change. Check its other detections; a company-wide gap means your crawl broke, not that the stack did.

> **Note:** Deterministic matching misses synonyms
>
> Keyword-based detection over hundreds of technologies works by exact matching, so it misses synonyms and renamings. When a cluster hinges on one tool name, confirm the term the company actually uses rather than trusting a single matcher.

## A checklist before you ship the hypothesis

Run this before the hypothesis leaves your desk. Each item is a specific check, not a topic to think about.

#### Ship only when every line is true

- [ ] A baseline of this competitor's normal hiring by function and seniority exists before the spike was flagged
- [ ] The flagged function has 3 or more roles after reposts and listings older than 90 days are removed
- [ ] Every req in the cluster has been checked for a preceding departure, and the net-new count excludes backfills
- [ ] Departures in adjacent units have been pulled from profiles, press, and WARN, and read alongside the reqs
- [ ] Named tools appear across multiple postings, not a single wishlist mention, with phrase-level context ruling out negation
- [ ] Three to five peers have been scanned and the cluster is not a market-wide trend
- [ ] The hypothesis states a date window derived from the 6-18 month lead off the first req date
- [ ] A confidence call names the single strongest and single weakest piece of evidence

## Keeping the read current

A hypothesis is a dated object, so re-run the spike detection weekly and re-date the window as new reqs appear. The step-3 run takes under five minutes once your monitors are set, and each run saves its counts as the new baseline, so the pattern you are judging against stays current without manual bookkeeping.

The two figures most likely to drift are the ones to re-check rather than memorize. The ghost-job rate is a range drawn from studies that update, so confirm the current lower and upper bounds against fresh ATS close-out data before you set your minimum cluster size. The 6 to 18 month lead time is uncalibrated; if you have ever watched one of your tracked competitors go from first req to announcement, use that observed interval for that company instead of the generic range. Over a few cycles you will have a per-competitor lead time, which is far more useful than the published average.

Finally, keep the exits ledger running between spikes. Departures do not arrive on the same schedule as reqs, and the pivot signatures worth catching, a unit being cut while an adjacent one is being built, only show up when you have both halves of the ledger maintained in parallel. The arithmetic is simple once the pairing is in place; the discipline is keeping both columns alive.

## Frequently asked questions

### How many new roles in one function count as a real signal?

The only explicit published threshold is 3 or more net-new roles in one function in a single weekly run. That number is really a bet that genuine hiring intent clears the ghost-job noise floor of 18 to 27 percent, so any cluster under about four roles sits inside the noise band. The threshold is relative to baseline, not universal, which is why you spend the first month learning the competitor's normal cadence before trusting a spike.

### How do I tell a net-new team from ordinary backfill?

Check whether a matching departure preceded each requisition. If someone left the same role at the same level before the req opened, tag it backfill; if there is no prior departure, or the title or seniority is new to the org, tag it net-new. This matters because a backfill inherits a funded slot and clears in 24 to 72 hours while net-new headcount takes 1 to 3 weeks, and one worked example found 59 percent of a rising req pile was backfill.

### How far ahead of a launch do the hiring signals appear?

The most-cited range is 6 to 18 months between opening roles and announcing the resulting product. A tighter function-specific claim is that multiple ML or AI engineer roles in a single quarter point to an AI feature announcement within 3 to 6 months. Treat the 6 to 18 month figure as load-bearing but uncalibrated, since these are practitioner estimates rather than peer-reviewed findings.

### Where do I find who left a competitor?

Three public sources: professional-network profiles carry self-reported tenure and where people went, press releases cover senior moves, and state WARN filings cover mass cuts. The WARN Act requires employers with 100 or more staff to give at least 60 days notice of a mass layoff, and aggregators collect those notices from state labor departments and match them to companies. Treat WARN counts as forecasts, not confirmed headcount, since some are amended or withdrawn.

### Why not just grep the job descriptions for tool names?

Keyword matching misreads negation and direction. The phrase migrating away from Oracle is a churn signal that a naive match counts as Oracle adoption, so you need phrase-level context around every tool hit. A single mention is also just one manager's wishlist; a tool that appears across five postings over six months is a committed stack, while a tool mentioned once is not.

### How do I avoid crying wolf on a market-wide trend?

Scan three to five peers for the same cluster before you call it a single-firm move. If six competitors all posted identical agent-platform roles, you are seeing a market trend, not one company's decision. This peer scan is one of two de-noising filters a cluster must survive, the other being the removal of recycled and ghost reposts.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/competitor-next-build-reqs-exits*