A job posting open for a year is a roadmap nobody wrote

I spent a few days reading the job boards of 2,798 funded companies, which I recognize isn't a normal hobby.

I went in looking for one thing and came out with another. That second thing is what this piece is about, and the detour is part of the point.

What I went looking for

The role everyone talks about when a growth company stalls is the senior demand gen hire. The VP of Growth req that sits open for five months while the CEO runs the ad account on Sunday nights. I assumed that was the most common stuck seat in the market, because it's the one people complain about out loud.

So I built a scanner to count it, which is how I handle most feelings these days.

It turned out to be the smaller half of the story.

What the boards actually said

Of the companies I could read, 27% had a req in the implementation layer that had been open more than 60 days. Forward Deployed Engineer, Solutions Architect, Implementation Manager, Deployment Strategist. Different titles, same actual job, which is getting a customer live on the thing they already bought.

The stuck senior demand gen req showed up at 8%.

2,798

funded Series A and B companies scanned, 546 with a public board I could read

27%

had an implementation req open more than 60 days

8%

had a senior demand gen req stuck that long

That's 3.3 to 1. The gap I wasn't looking for was more than three times as common as the one I was.

I want to be careful about what that number means. It doesn't say demand gen is solved, plenty of those companies have a growth problem too. It says the bottleneck a funded company is most likely to be quietly stuck on sits after the sale, in the part of the business where the software is supposed to just work.

The req is the receipt

A job posting is one of the few documents a company publishes about its own operations without a marketing team softening it first. It names the problem, the budget, the urgency, and how long they've been failing to solve it, with a date stamp.

When you read enough of them in a row, which I don't recommend on a weeknight, the patterns get loud.

The sharpest one I found was a req titled Senior Implementation Manager, Windchill. Windchill is a product lifecycle management system. When a company names a hire after a single integration, that integration is being rebuilt by hand for every customer, and somebody upstream decided the fix was a person.

A few other tells kept showing up:

A recruiter hired to fill the delivery roles. This is a rational move if the problem is that you can't find people. It's an expensive move if the problem is that the job as written can't be done by one person, because now you're paying a professional to search for someone who doesn't exist.

A senior req replaced by junior versions of the same function. The senior implementation role comes down and a new-grad and an intern version go up. The company has quietly bet the work is teachable. Work that's teachable is work that can be written down, and work that can be written down is mostly work a product could do.

The same role open in three cities at once. That reads like a tight talent market. More often it's a job description carrying more than one job, and no single labor market happens to grow the person who can do all of them.

The person in the posting

Read the requirements on those implementation reqs and you'll find someone who understands machine learning, and regulatory document workflow, and the customer's legacy systems. They should also be able to run an executive relationship without making anyone nervous.

That person exists. There are maybe forty of them, and they're all employed.

So the req sits. Onboarding stays manual. Each new customer waits on a calendar that belongs to two overbooked engineers, and revenue recognition moves at hiring speed instead of software speed.

The industry spent a couple of years selling software that works out of the box, and is now staffing the humans required to make it work out of the box.

Nobody planned it that way. It accumulated, one heroic implementation at a time, until the heroics became a headcount line.

Why companies reach for a recruiter

This is a reasonable diagnosis, just one made from the wrong seat. The wrong, very comfortable, hard-to-get-up-from-for-a-new-point-of-view seat.

From the CEO's chair, the symptom looks like this: deals are closing, customers are waiting, and we don't have enough people to get them live. Every word of that is true, and the obvious response to "not enough people" is "hire people." When the hire doesn't come, you hire someone to find the hire.

The question that gets skipped is why getting a customer live requires a rare person at all.

Sometimes the answer is fine. Some products genuinely need a human in the loop, and a great implementation team is a competitive advantage. But when the role has been open for a year, the company has run a long, expensive experiment on whether that person can be found, and the market has answered.

A posting that stays open for a year is a product roadmap nobody has written down yet. Every manual step that rare person would have done is a feature request. The integration in the job title is the first one.

There's also a budget angle that rarely gets said out loud. An approved req is money the company already committed. A stuck one is committed budget producing nothing, quarter after quarter, while the work it was meant to fund gets done badly by whoever is nearest. Reframed that way, the open seat stops being a hiring metric and becomes the most honest line item on the plan.

The frame that actually helps

The useful version of this conversation is about making the hire land.

If the role can be cut down to something a real human can do, because the repeatable parts got built into the product or the process, you can fill it in weeks instead of quarters. The person you hire does the judgment work, and the copy-paste work stops depending on whether they exist.

That's a different project than recruiting, and it usually starts with someone writing down, step by step, what the last three implementations actually required. Most companies have never done that, because the person who knows is too busy doing it.

How I counted

Public data only, and I'll be specific, because a number like 27% deserves to have its homework shown.

• The population. US companies at Series A and B, 11 to 200 employees, pulled from a funding-filtered list. 2,798 scanned.
• The readable subset. Most applicant tracking systems publish every open role, with posting dates, through a public job board. 546 of the 2,798 had one I could read programmatically. Every percentage here is out of those 546, and the rest of the population is unknown, which is worth saying plainly.
• "Stuck." A unique title open 60 days or more.
• Evergreen postings excluded. Some companies keep the same title posted all year as a standing pipeline. That's a recruiting habit, and counting it would have inflated the number, so a title posted over and over didn't count.
• Two buckets. Implementation layer (forward deployed, solutions, implementation, deployment roles) and senior demand gen. A company could land in both.

And the limits, because every instrument has them. Posting dates aren't perfectly reliable: some systems refresh a date on any edit, which makes old reqs look young, and some do the opposite on boards that are always open. My title matching was conservative, and it missed at least one company with a dozen open delivery roles because their titles didn't fit the pattern. If anything, I think the implementation number is understated.

I didn't name any of the companies, for what should be obvious reasons, and because I'd like to keep getting invited to things.

What the detour taught me

The more interesting finding, for me, was about the sampling frame. I went looking for the gap I already believed in, built from the roles I happened to be looking at, and if I'd checked a hand-picked list of twenty companies I would have found it and stopped.

Scanning the whole population is what surfaced the bigger pattern sitting next to it. It changed what I'm building and who I'm talking to.

Which is, I'll admit, slightly on the nose for a piece about diagnosing the problem before you staff the solution.

If you run one of these companies and you've got a req that's been open since the spring, read it again like a stranger would. It's telling you what to build.