The tech stack hiding in plain sight in job posts

A job post is the most honest document a company publishes about its technology. The press release says "modernizing." The job post says which database, which cloud, which version, and what the new hire will be stuck maintaining.

If you sell services, read job posts before you read anything else.

Why job posts tell the truth

Hiring managers write job posts to get the right person through the door. They have every reason to be specific. If they need someone who knows a particular ERP, an old reporting tool and a specific cloud, they'll name all three. Vague posts get the wrong applicants.

So the stack is right there. Not the aspirational stack from a conference talk. The real one, including the parts nobody's proud of.

A company's annual report might mention "technology investments." Its job posts will tell you it's running an on-prem data warehouse, moving to a cloud platform, and needs someone who can do both for the next eighteen months.

What to look for

Read the requirements section, not the summary. The summary is marketing. The requirements are where the hiring manager tells you what's really running.

Look for pairs. "Experience with our current platform and the new one" means a migration is underway. That's a services opening, since migrations always need more hands than the company has.

Look for old names next to new ones. A post asking for mainframe experience and modern API skills is telling you about a bridge somebody has to build.

Look for the phrase "help us move to" or "lead the transition from." Those are a hiring manager telling you, in writing, what project they're staffing.

And look at the "nice to have" list. It's often where the next platform shows up first, before anyone's committed to it in public.

One post versus a pattern

A single post naming a platform is a weak signal. Companies backfill. People leave. One opening for a cloud engineer doesn't mean a program.

Three or four posts naming the same new platform in the same few weeks is different. Now you're looking at a decision that's been made and is being staffed. That's when the stack signal starts to matter, and it gets stronger when it stacks with something else at the account, like a new technology leader or a line in a filing about legacy cost. The buying signals guide covers how signals roll up to the account.

Age matters too. A post from last week tells you about a live decision. A post from five months ago tells you about a decision that's either staffed or stalled.

Turning the stack into an opener

Say a regional healthcare payer posts three roles in a month. Each asks for experience with their current claims platform and with a specific cloud data service. One says "help lead our migration."

You now know the platform, the target, and that they're staffing it internally. The technical lead on that migration is your reader.

Your team has posted three roles in the last month asking for experience on both the current claims platform and the new cloud data service. That usually means the migration is real and the clock is running on it. My guess is the hiring won't keep pace with the cutover date, and the people you have are carrying both systems at once. Is that the situation, or is the timeline looser than the posts suggest?

The research hook is the posts. The trigger is the clock. The hypothesis is the gap between hiring and the cutover. And the exit lets them correct you on the timeline.

What not to do

Don't open with "I noticed you're hiring." Everyone sends that. It names the signal without saying what it means.

Don't pitch your experience on the platform in the first line. They're not shopping for a platform expert yet. They're trying to hit a date.

Don't treat every post as a buying signal. Read for patterns, pairs and transitions. A single routine opening is noise.

Job posts are free, public and specific. They're the closest thing you'll get to reading a company's project plan. Most sellers skim right past them on the way to a press release.