The req asks for a data modeler, a systems architect, a process designer and someone who can actually build — in one person, inside your band. It has not been filled because that person is rare, expensive and usually already employed.
So the work waits. Or it gets split across three people who each own a third of a problem. Or it lands on the ops person who was already at capacity, which is how it ends up back on your desk.
There is a third option nobody puts in a job req: don't hire it, embed it.
The req, roughly
That is four jobs. Which is why it is still open.
Every RevOps leader has written one of these, and most of them know while they are writing it that it will sit. The description is not unreasonable — the work really does require all of it. It is the packaging into one salary, one seat and one hiring cycle that does not survive contact with the market.
Why this is possible now
Think about what the four-job description is really compensating for. A business analyst writes the requirement, a designer shapes it, a developer builds it, someone tests it and a project manager holds the whole thing together. Most of the elapsed time in that chain is not the work. It is the handoffs between the people doing the work.
That tax is what made the unicorn req necessary in the first place — if one person could hold the whole line, nobody would need to hire four people's skills into one seat and hope. Working AI-native removes most of it. The analysis, the build, the checks and the documentation happen in one place, held by one operator who understands your operation, which is why the ground one person can genuinely cover is now wider than the market has priced.
That is a claim about staffing, not about speed. It does not mean the work gets done carelessly. It means the coordination overhead the req was built to absorb is largely gone.
What embedded actually means
The data model, the pipelines, the workflows, the integrations, the reporting, and custom builds where configuration runs out. In your portal, in your standups, shipping things your team can point at.
It is worth being direct about what this is not, because the word "fractional" has been used to sell the opposite. This is not a monthly strategy call. It is not a retainer that produces a deck and a list of recommendations for someone else to implement. If the output of a month is a document, you have bought advice, and advice was not what the req described.
And the standing rule that separates this from renting a pair of hands: you end up able to run it without me. Your people learn the system as it gets built, because a dependency I create is a problem I have handed you.
Some of what looks like a staffing gap is really an operating-model problem: the systems are there, nobody made them how the business actually runs, and filling a seat underneath that will not fix it. That is a different purchase — scoped, project-shaped, with an end — and it lives at ryanginsberg.com.
Same person, same standards. Two different purchases, made by two different people at two different moments, and worth saying out loud rather than pretending every buyer wants the same thing.
Read it to me and I will tell you honestly which parts I would own, which parts still want a hire, and whether embedding is the right shape for your situation at all. If it isn't, that is a useful thirty minutes either way.
Book 30 minutes