hiring revops
RevOps job description: why yours attracts the wrong people
Two complete RevOps and GTM engineer job description templates, the phrases that repel strong operations candidates, and what a salary band does.
A RevOps job description should open with the specific problem the hire will fix, name the systems they will own, state the outcomes they will be judged on, separate the requirements that are genuinely required from the ones that are learnable, publish the salary band, and describe the process. A tool list does none of that. It is the reason the wrong people apply.
The short answers
- A job description is a filter. Its job is to make unsuitable people close the tab. Volume is not the goal, and on Ashby’s analysis of more than 100 million applications across 200,000 jobs, applications per hire have tripled since 2021 to more than 300.
- A tool list cannot separate anyone any more. Everyone has the tools and every CV claims all of them. Listing Salesforce, HubSpot, Clay and Outreach tells you nothing about who to interview.
- The role is not understood inside most companies either. Only 45 per cent of respondents to the 2026 State of GTM Engineering survey (n=228) said their own organisation clearly understands what a GTM engineer does.
- Publish the band, and publish a narrow one. A range wide enough to cover two different jobs tells a reader you have not decided which one you are hiring.
- In much of the US and the EU, the band is now a legal question. Eleven US states require pay information in the posting or at offer stage, and the EU Pay Transparency Directive had a transposition deadline of 7 June 2026.
- An invented title costs you twice. Nobody searches for it, and no matching algorithm on either side recognises it.
- Write requirements as verifiable behaviours. Both sides of the application are now automated, so a requirement that can be claimed in one line will be claimed in one line by everybody.
What a job description is actually for
Most job descriptions are written as descriptions. Somebody sits down and tries to capture the role: the reporting line, the tools, the team, the responsibilities, a paragraph about the company’s mission. The document that comes out is accurate and useless, because accuracy was never the point.
The point is selection. Every advert is a screening instrument that runs before your screening process starts, and it is the cheapest one you will ever operate. It costs nothing per candidate, it runs at any volume, and it is the only stage where the candidate does the work of deciding. A well built advert makes several hundred unsuitable people close the tab in eight seconds and makes eleven suitable people read to the bottom and think about it for a day.
That framing changes what a good advert looks like. If the document is a filter, then a line that everybody can agree with is dead weight. “Strong communication skills” filters nobody. “You will be the first operations hire and there is no documentation of the current Salesforce build” filters a great many people, correctly, and attracts a small number who find that specific sentence interesting.
Volume is the metric most hiring teams still watch, and it is the wrong one. Ashby’s data, covering five years to May 2026, shows applications per hire have tripled since 2021 and candidates are roughly half as likely to reach an interview as they were then. More applications did not produce more hires. They produced a longer queue in front of the same number of hires, and a screening stage that now consumes the time you meant to spend on assessment.
There is a real tension here and it deserves stating plainly. The recruitment advertising industry measures adverts on apply rate, and on apply rate, short wins. Appcast, from 10.2 billion clicks and 1.7 billion applications across more than 400 companies, reports that postings of 201 to 400 words convert at 8 to 8.5 per cent, postings under 200 words at 4.5 per cent, and postings over 701 words at under 5 per cent. Read quickly, that says write a short advert.
It says something narrower. Appcast’s population is dominated by high volume hiring, where the economics are cost per application and the bottleneck is getting enough people into the funnel. A RevOps manager search is the opposite shape: one hire, a small qualified population, and a bottleneck at assessment rather than at the top of the funnel. Optimising a senior operations advert for apply rate optimises the wrong number. You are not trying to raise the percentage of readers who apply. You are trying to raise the percentage of applicants who are worth an hour of your time, and those two move in opposite directions.
So the length rule for this kind of hire is not short. It is: every sentence must either attract a specific person or repel a specific person. Sentences that do neither come out.
Why the tool list stopped working
The standard RevOps advert opens with a list. Salesforce, HubSpot, Outreach, Gong, Clay, Marketo, Looker, dbt, Zapier, Chili Piper. Then a required-experience section that repeats the same list with numbers attached: “3+ years Salesforce administration”, “experience with marketing automation platforms”.
That list did work, once. In 2016 a candidate who had genuinely administered Salesforce was distinguishable from one who had not, because access to the tool was the scarce thing. Access is no longer scarce. Free tiers, trial instances, developer orgs, certification courses and a decade of tooling proliferation mean that anyone who wants to claim familiarity with any tool in the go-to-market stack can acquire enough to claim it in a weekend.
Two things follow, and both are fatal to the list as a filter.
Everyone has the tools. The median mid-level operations candidate in 2026 has touched a CRM, an enrichment provider, a sequencer, a BI layer and some form of automation. The stack is not the differentiator it was, because the stack has commoditised. What differs between candidates is what they did inside those tools, and the tool name carries none of that information.
And every CV claims all of them. This was true before generative writing tools and it is emphatically true now that a candidate can paste your advert into a model and get back a CV that mirrors your exact vocabulary. The screening consequences of that are a subject in their own right, but the consequence for the advert is simple: any attribute you name in a list will be present in the applications you receive, at close to 100 per cent, regardless of who applied. A filter that everything passes is not a filter.
The industry has not adjusted, partly because the role itself is not well understood inside the companies hiring for it. In the 2026 State of GTM Engineering survey, which drew 228 respondents across more than 30 countries, only 45 per cent said their organisation clearly understands what a GTM engineer does. When the hiring manager cannot describe the role in outcomes, the tool list is what remains. It is a proxy for a definition nobody has written.
The replacement is not a longer list or a shorter one. It is a description of the state of your systems and what has to be true about them in a year. That is not something a candidate can mirror back from your advert, because answering it requires them to have done the thing.
The phrases that repel strong operations candidates
Experienced operations people read adverts the way an underwriter reads a claim form. They are looking for the sentence that reveals what the job is really like. Certain phrases are load bearing in that reading, and most of the time the employer has no idea what has been communicated.
The table below is Rareix’s own read, drawn from debriefs with candidates who declined to apply or withdrew. It is not a published study. The signal column is what the candidate concluded, accurately or not.
| Phrase in the advert | What the employer meant | What an experienced ops candidate reads | Write instead |
|---|---|---|---|
| “Rockstar”, “ninja”, “wizard”, “guru” | We are ambitious and informal | This company has not hired at this level before, and the title will not survive a recruiter search | The real title, and nothing else |
| “Wear many hats” | The role is broad | There is no defined remit, no budget, and I will be doing manual data entry in month four | “You will own CRM architecture, reporting and enablement tooling. You will not own the SDR team” |
| “Fast-paced environment” | We move quickly | Priorities change weekly, nothing gets finished, and I will be judged on work that was cancelled | “Priorities are set quarterly. Two have changed mid-quarter in the last year, both after a pricing change” |
| “Must thrive in ambiguity” | We are early and unstructured | Nobody will tell me what success is, and it will be defined retrospectively | “There is no operating model yet. Your first job is to write one and get it agreed” |
| “Competitive salary” | We pay market rate | Below market, or the band is wide enough to anchor me low | The band, in numbers |
| “Self-starter with a can-do attitude” | We want initiative | No manager, no support, no headcount | “You report to the VP Sales, who has run RevOps before. There is no other ops headcount in year one” |
| “Other duties as assigned” | Standard legal boilerplate | The job will expand to fill whatever falls over | Delete it. It buys you nothing and costs you credibility |
| “Family” or “we work hard and play hard” | We have a good culture | Long hours, blurred boundaries, and a difficult conversation if I leave at six | Describe the working pattern in hours and days |
| “3+ years of Salesforce, HubSpot, Marketo, Outreach, Gong, Clay” | We use these tools | Nobody here knows which of these matters, so I cannot tell whether I am a fit | Two systems you actually own, and what state they are in |
| “Ideal candidate will have a degree in…” | We want rigour | The screen is a proxy, and I will be assessed on things that are not the job | Delete it unless it is a genuine legal requirement |
Candidates read a requirements list as permissions
This is the single most useful thing to understand about a requirements section, and it is the reason splitting it changes who applies.
Tara Sophia Mohr’s survey of more than a thousand professionals asked people who had decided not to apply for a role why they had not. The dominant answer was a version of “I did not think they would hire me and did not want to waste the effort”. Self-doubt about whether they could actually do the job came last, at around one respondent in ten.
That is a different mechanism from the one most hiring managers assume. People are not reading your requirements and concluding they lack the ability. They are reading them as a set of rules about who is allowed to apply, and following the rules.
Two things follow. Anything you list, you are excluding on, whether or not you meant it as a preference. And an undifferentiated list of nine bullets is read as nine gates, which is why the templates below split what is genuinely required from what is learnable and say which is which.
A RevOps manager job description template
What follows is a complete advert you can copy and fill in. The notes sit outside the template and explain why each section is built the way it is. Placeholders are in square brackets.
Section 1: the problem, first
Revenue Operations Manager [Company], [city] or remote within [region]. $120,000 to $145,000. Reports to the [VP Revenue / CRO].
We have 42 sales and marketing people and no single view of the pipeline. Salesforce was configured in 2022 by a contractor and has not been touched structurally since. Forecast accuracy last quarter was 61 per cent against commit. Three teams maintain three different definitions of a qualified opportunity, and the board pack is assembled by hand in a spreadsheet over two days at the end of every month.
We are hiring one person to fix that, own it afterwards, and stop it happening again.
Note. The first thing on the page is the specific failure state, in numbers. This is the change with the largest effect on a RevOps advert. A competent operations person reads that paragraph and knows immediately whether this is a problem they have solved before, which is exactly the judgement you want them to make instead of you. It is also unmirrorable: a candidate cannot generate this content from your advert, so anything they say back about it is real signal. The band and the reporting line appear above the fold because both are filtering criteria and hiding them wastes everyone’s time.
Section 2: the systems you will own
What you will own
- Salesforce, as the system of record. Full administrative ownership. Roughly 900 accounts, 4,000 contacts, one sandbox, 14 custom objects and an unknown number of unused fields.
- HubSpot Marketing Hub, and the sync between it and Salesforce, which currently fails silently on around 3 per cent of records.
- The pipeline and forecast reporting layer, currently a mix of Salesforce reports and a Google Sheet.
- The go-to-market data contract: how leads, accounts, opportunities and product usage are defined and where each definition lives.
What you will not own
- Quota setting and territory design, which sit with the CRO.
- Commission calculation, which sits with finance and runs in [tool].
- The BI stack outside go-to-market. [Company] has a data team and you will work alongside it.
Note. Naming what the role does not own is more informative than naming what it does, because scope creep is the most common reason experienced operations people leave a job and the most common thing they screen for in an advert. This section also gives real numbers about the estate. “Salesforce administration” is a claim anybody can match. “14 custom objects, one sandbox, a sync that fails on 3 per cent of records” invites a specific question in the interview and tells a strong candidate what the first month looks like.
Section 3: the outcomes you will be judged on
What good looks like at 12 months
- Forecast accuracy at 85 per cent or better against commit, measured at the start of each quarter.
- The monthly board pack generated from the system in under two hours, by anyone on the team, without you.
- One documented definition of a qualified opportunity, agreed by sales and marketing, enforced in the CRM rather than in a slide.
- Lead response time under 30 minutes in working hours, measured, not estimated.
- A written operating model for the go-to-market stack that survives your holiday.
Note. These are the terms of the job, and putting them in the advert does three things at once. It tells a serious candidate whether the targets are achievable given the systems described above, which is a real filter, because someone who has done this before will know whether 85 per cent forecast accuracy in twelve months is ambitious or fantasy in your situation. It commits you internally to a definition of success before you meet anyone, which is the same discipline a scorecard imposes on the rest of the process. And it gives you the material for the work sample later, because these are the outcomes you will ask a shortlisted candidate to plan against.
Section 4: requirements, split honestly
What you need to have done before
- Owned a CRM as the system of record, end to end, including the data model, for at least two years. Not “used” it. Owned it, including the decisions you got wrong.
- Rebuilt or materially restructured a reporting layer that people distrusted, and got them to trust it.
- Held a definitional argument between sales and marketing and closed it, in writing, in a way that stuck.
What you can learn here
- Our specific stack. If you have owned HubSpot and not Salesforce, or the reverse, that is fine.
- SQL beyond joins and aggregates.
- Our sector. We sell [product] to [buyer] and you can be taught that in six weeks.
- Managing people. This role has no reports in year one and may have two in year two.
If you can do the first list and not the second, apply. If you can do the second and not the first, this is not the right role and we will not be able to place you elsewhere in the company.
Note. Splitting the list is the change that most improves applicant quality, for the reason Mohr’s survey found: candidates read requirements as permissions. An undifferentiated list of nine bullets gets read as nine gates. Three genuinely required items and four explicitly learnable ones gets read accurately. The last sentence is unusually blunt and it is there deliberately, because a clear rejection in the advert saves a candidate an hour and saves you a screening call.
| Requirement | Genuinely required | Learnable in the role | Why |
|---|---|---|---|
| CRM data model ownership | Yes | No | The failure mode is silent and takes a year to surface. You cannot supervise what you cannot evaluate |
| Salesforce specifically | No | Yes | A HubSpot owner transfers in about eight weeks. A non-owner does not transfer at all |
| Rebuilding distrusted reporting | Yes | No | The hard part is the political work and never the SQL, and it does not come from a course |
| SQL | No | Yes | Joins and aggregates in two weeks, window functions in a month, and most of the job is not SQL |
| Cross-functional definitional authority | Yes | No | This is the actual job. Nothing else in operations works without it |
| Your sector | No | Yes | Six weeks, and sector experience is the most overrated screen in ops hiring |
| Marketing automation | No | Yes | Platform-specific, well documented, and taught by doing |
| People management | No | Yes | Only matters if the role gains reports, and most first RevOps hires do not |
Section 5: the band and the process
Salary and process
$120,000 to $145,000 base, plus [bonus structure], plus [equity]. We will not go above the top of that band, and we will tell you where in it we have landed at offer stage and why.
The process is four steps and takes three weeks from application:
- A 30 minute call with the VP Revenue about the problems above.
- A scored work sample: you get a description of our current Salesforce object model and 90 minutes to write what you would change and in what order. Paid at [rate], done in your own time, and you keep it.
- A 60 minute session with the CRO and the head of marketing, working through your work sample.
- Two reference calls, which we make after the offer conversation, not before.
We reply to every applicant. If you have not heard within five working days, chase us at [email].
Note. The band is a filter and a promise at once, and the sentence about not exceeding it is what makes the number credible. Publishing the process is a filter of its own: candidates who will not do a work sample self-select out here, at no cost to you, which is better than discovering it at stage two. The commitment to reply is the part most companies quietly break, and breaking it is expensive in a market this small, where the same eighty people are the pool for every RevOps search in your city.
A GTM engineer job description template
The GTM engineer advert has a harder job, because the title means different things at different companies and the candidate cannot assume. What a GTM engineer actually does has to be established by the advert itself.
Section 1: the problem, first
GTM Engineer [Company], [city] or remote within [region]. $145,000 to $175,000. Reports to the [VP Marketing / Head of GTM].
Our outbound motion is 6 SDRs sending 400 sequenced emails a week each, with a 0.9 per cent reply rate and a list built by exporting a saved search from [provider] once a month. We have no enrichment pipeline, no scoring beyond firmographics, and no way to react to a signal within a day of it happening. Every new campaign takes eleven days to launch because the data has to be assembled by hand each time.
We are hiring someone to build the systems that make that automatic, and to run experiments through them.
Note. The failure state again, and again in numbers. The specific numbers do a second job in this advert: they establish which version of “GTM engineer” this is. A candidate reading 0.9 per cent reply rates and manual list building knows this is an outbound systems role and not, for example, a product-led growth instrumentation role. Given that only 45 per cent of companies in the State of GTM Engineering survey can articulate what the role does internally, the advert has to do that work explicitly or the applications will be a random sample of the title.
Section 2: the systems you will own
What you will own
- The enrichment and scoring pipeline, from source to CRM field. Today that is [provider] plus manual work, and there is no reason it has to stay that way.
- Signal capture: job changes, hiring signals, product usage, technographics. None of this exists yet.
- The sequencing and routing layer in [tool], including the logic that decides who gets contacted and when.
- Any code, workflow or model that sits between a data source and a person receiving a message.
What you will not own
- Messaging and positioning, which sit with product marketing. You will run experiments on their copy and you will not write it.
- Quota, targets and SDR management.
- CRM administration and the data model, which the RevOps manager owns. You will build on it and you will not restructure it unilaterally.
Note. The boundary between GTM engineering and RevOps is where these hires go wrong most often, so the advert states it. If you are unsure which of the two you are hiring, the comparison between a GTM engineer and a RevOps manager is the place to settle that before you write anything, because an advert that hedges between them attracts people who are strong at neither.
Section 3: the outcomes you will be judged on
What good looks like at 12 months
- Reply rate on outbound at 3 per cent or better, on the same or larger volume.
- Campaign launch time from eleven days to under two, measured from brief to first send.
- An enrichment pipeline that runs without manual steps and that someone else can debug from documentation.
- At least eight experiments run and written up, including the ones that failed and what was learned.
- Signal-triggered outreach live on at least three signal types, with attribution back to pipeline.
Note. The last bullet on experiments is the one that separates this advert from the field. It tells a candidate that negative results are expected and reportable, which is the working condition strong GTM engineers ask about and rarely get a straight answer on. It also sets up the interview: you can ask about an experiment that failed and what changed afterwards, which is far more diagnostic than asking which tools they have used. The interview questions worth asking an operations candidate follow the same construction.
Section 4: requirements, split honestly
What you need to have done before
- Built and run a data pipeline that fed a live outbound motion, and kept it running when a source changed underneath you.
- Written code, of any kind, in production. Python, JavaScript, SQL, or heavy no-code with real logic in it. We will look at it.
- Designed and shipped an experiment with a defined hypothesis, a measurement plan and a written result.
What you can learn here
- Our specific tooling. We use [stack] and we will not screen on it.
- Our ICP and our sector.
- Anything about our CRM’s internals, which is not your responsibility.
- Formal software engineering practice. You do not need to have worked in an engineering team.
We would rather hire someone who has built three things badly and knows exactly why each one broke than someone who has been near a large well-run system without touching it.
Note. “Written code in production, of any kind” is doing precise work. It is genuinely required, because the job cannot be done without it, and it is deliberately agnostic about language and background so that it does not accidentally screen for computer science graduates. The final sentence tells a self-taught candidate from a non-engineering background that they are wanted, which is most of this population.
| Requirement | Genuinely required | Learnable in the role | Why |
|---|---|---|---|
| Running a live data pipeline | Yes | No | Everything else in the role sits on top of it, and it fails in ways you cannot see from the outside |
| Code in production, any language | Yes | No | The role is engineering work with a go-to-market target. Without it, the ceiling arrives in month three |
| Experiment design and write-up | Yes | No | The output of the job is learning, and undocumented learning is not output |
| Clay, Apollo, or your specific stack | No | Yes | Two weeks each. Screening on tool names is how you end up with the same shortlist as everyone else |
| Salesforce or HubSpot internals | No | Yes | Owned by RevOps in this structure, and picked up by osmosis anyway |
| Formal engineering background | No | Yes | Most of the strong population is self-taught from an operations or marketing start |
| Your ICP and sector | No | Yes | Six weeks, and easily taught by putting them on calls |
| AI model and prompt work | No | Yes | Moves too fast to screen on, and a good engineer absorbs it in a month |
Section 5: the band and the process
Salary and process
$145,000 to $175,000 base plus [bonus] plus [equity]. GTM engineering carries a premium over RevOps in this market and we have budgeted for it.
Process, three weeks, four steps:
- A 30 minute call about the pipeline problems above.
- A paid work sample: build a small enrichment and scoring flow against a 50 row sample we provide, and record yourself narrating what you did and why. Two hours maximum, paid at [rate].
- A 60 minute session walking through what you built, including what you would do differently with a week.
- Two reference calls, after the offer conversation.
Note. The narrated work sample is doing the screening that a tool list used to do and no longer can. It is the point in the process where claimed familiarity and actual fluency separate, and it takes two hours to run. Where the band should sit is a separate question with its own data, which is covered in the RevOps and GTM engineering salary benchmarks.
Before and after: a real advert, rewritten
Here is a composite of the adverts Rareix sees most often. Nothing in it is invented; every element appears repeatedly in live postings.
The before
Revenue Operations Rockstar
[Company] is a fast-growing, VC-backed SaaS company on a mission to transform the way businesses work. We are looking for a Revenue Operations rockstar to join our world-class team.
About the role The Revenue Operations Manager will play a key role in driving operational excellence across the revenue organisation. You will partner with cross-functional stakeholders to optimise processes, drive efficiency and support our aggressive growth targets. This is a fantastic opportunity for a self-starter who thrives in a fast-paced environment and is comfortable wearing many hats.
Responsibilities
- Own and administer our CRM and go-to-market tech stack
- Build reports and dashboards for the leadership team
- Support the sales team with process improvements
- Drive data hygiene and governance initiatives
- Partner with Marketing, Sales and Customer Success
- Other duties as assigned
Requirements
- 3+ years of experience in Revenue Operations, Sales Operations or a similar role
- Expert-level Salesforce administration; Salesforce certification preferred
- Experience with HubSpot, Marketo, Outreach, Gong, Clay, Chili Piper, LeanData, Looker
- Advanced Excel skills
- SQL proficiency
- Strong analytical and problem-solving skills
- Excellent written and verbal communication skills
- Bachelor’s degree in Business, Finance or a related field
- Must be a team player with a can-do attitude
What we offer Competitive salary, equity, unlimited PTO, and the chance to join a rocket ship. We are a family here and we work hard and play hard.
That advert will receive several hundred applications. It has no filter in it anywhere. Every requirement is claimable in one line, and every one of them will be claimed.
The after
Revenue Operations Manager [Company], Austin, TX or remote in the US. $120,000 to $145,000 plus 10 per cent bonus and options. Reports to the VP Revenue.
We have 42 people in sales and marketing and no single view of pipeline. Salesforce was built by a contractor in 2022 and nobody has owned the data model since. Forecast accuracy last quarter was 61 per cent against commit. The board pack takes two days to assemble by hand. Three teams use three definitions of a qualified opportunity.
One person owns fixing all of that, and then owns keeping it fixed.
You will own Salesforce as the system of record (900 accounts, 14 custom objects, one sandbox), the HubSpot sync that currently fails silently on 3 per cent of records, the pipeline and forecast reporting layer, and the definitions of lead, account, opportunity and qualified.
You will not own quota and territory (CRO), commissions (finance), or the wider BI stack (data team).
At 12 months, this has gone well if forecast accuracy is at 85 per cent or better, the board pack generates itself in under two hours without you, there is one enforced definition of a qualified opportunity, lead response is under 30 minutes in working hours, and there is a written operating model that survives your holiday.
You need to have owned a CRM data model end to end for two years or more, rebuilt a reporting layer people had stopped trusting and got them to trust it again, and settled a sales-versus-marketing definitional argument in writing in a way that held.
You can learn here our specific stack (HubSpot owners welcome), SQL beyond the basics, our sector, and people management.
Salary $120,000 to $145,000. We will not exceed the top of the band, and we will tell you where in it you have landed and why.
Process, three weeks. 30 minute call with the VP Revenue. A paid 90 minute work sample on our actual Salesforce object model. A 60 minute session on what you produced. Two reference calls after the offer conversation. We reply to everybody within five working days.
| What changed | Why it matters |
|---|---|
| “Rockstar” removed from the title | The title is now what a candidate searches for and what a matching algorithm recognises |
| Mission statement cut entirely | It filtered nobody and cost the first 40 words, which are the only ones most readers see |
| The problem moved to the top, with numbers | Turns the opening into a self-selection test that cannot be mirrored back from the advert |
| “Wear many hats” replaced with an explicit non-ownership list | Removes the single biggest reason experienced ops candidates decline |
| Responsibilities replaced with outcomes at 12 months | Candidates can now judge whether the targets are achievable, which is a real filter |
| Nine-item requirement list cut to three, plus four named as learnable | Candidates read requirements as permissions, so an undifferentiated list excludes on all nine |
| Tool list removed from requirements, kept as context | Everyone claims the tools, so the list had no discriminating power left |
| Degree requirement deleted | It was a proxy, it was never assessed, and it narrows the pool for nothing |
| “Other duties as assigned” deleted | Reads as unbounded scope to exactly the people you want |
| “Competitive salary” replaced with a band and a commitment | More applications and better ones, on SHRM’s employer data |
| Process and timeline published | Work-sample refusers self-select out before you spend a call on them |
| “We are a family” removed | Signals long hours to anyone who has been burned once, whatever was intended |
The rewrite is longer, 350 words against 239, and almost every added word is a specific: a number, a system state, an outcome or a boundary. What came out was the material that filtered nobody.
Salary transparency: what publishing a band does, and where it is now required
The commercial case is settled well enough to act on, and we have set out the survey evidence and what it means for a senior operations search in what publishing the band does to your applicant pool. The short version is that published ranges lift both application volume and application quality, and the lift is larger for roles like this one than the headline averages suggest.
What concerns us here is the drafting, which is where employers who have decided to publish still get it wrong. Three mistakes recur. Publishing a band so wide it carries no information, such as $100,000 to $175,000, tells a reader you have not decided what the role is, which is the same message the rest of a bad advert sends. Publishing the top of the band as the headline number and then anchoring every conversation below it costs you the trust you bought by publishing at all. And writing “competitive” or “DOE” is worse than writing nothing, because silence reads as an oversight and “competitive” reads as a decision.
The volume-and-quality result is the counterintuitive one, because the usual objection to publishing a band is that it will attract people chasing the top of it. In practice it removes the largest single category of wasted process: candidates who apply, invest four hours across two interviews, and discover at offer stage that the number was never going to work. For senior operations roles the effect is stronger than the averages imply, because your target candidates are employed, are not searching urgently, and filter on pay before they read anything else.
Adoption has grown and then flattened. Indeed’s Hiring Lab found that 57.8 per cent of US job postings on Indeed included some pay information in September 2024, up from 52.2 per cent a year earlier, with the growth rate slowing as the large states’ laws bedded in and the labour market softened.
The legal position is now the more pressing consideration for many employers, and it varies sharply by jurisdiction. Vendor trackers disagree with each other on several states, so the table below follows law firm alerts and SHRM’s compliance guidance on the 2025 state laws instead of any single tracker. The Maryland amendment is dated from Seyfarth Shaw’s alert on the Wage Range Transparency Act, New Jersey from Duane Morris on the Pay Transparency Act, and the older state laws from Paycor’s state-by-state summary.
| Jurisdiction | In force from | Applies to | What must be disclosed |
|---|---|---|---|
| Colorado | 1 January 2021 | Any employer with at least one Colorado employee | Compensation and a general benefits description in every posting |
| Maryland | 1 October 2024 (amended act) | All employers posting Maryland roles | A good faith wage range plus benefits and other compensation, in the posting |
| California | 1 January 2023 | 15 or more employees, at least one in California | Pay scale in the posting; pay scale to employees on request |
| Washington | 1 January 2023 | 15 or more employees | Salary range and a general description of benefits in the posting |
| New York State | 17 September 2023 | 4 or more employees | Compensation range for any role performed in New York |
| Hawaii | 1 January 2024 | 50 or more employees | Hourly rate or salary range in the posting |
| Illinois | 1 January 2025 | 15 or more employees | Pay scale and a general benefits description with the posting |
| Minnesota | 1 January 2025 | 30 or more employees in Minnesota | Starting salary range and a general benefits description |
| New Jersey | 1 June 2025 | 10 or more employees over 20 calendar weeks | Hourly wage or salary, or a range, plus benefits |
| Vermont | 1 July 2025 | 5 or more employees | Compensation or compensation range in the advertisement |
| Massachusetts | 29 October 2025 | 25 or more employees | Pay range in postings, and to applicants and employees on request |
| European Union | Transposition deadline 7 June 2026 | Employers with staff in a member state, any size | Initial pay or pay range to the applicant before the interview, or at the latest during it |
| United Kingdom | No general requirement | n/a | Nothing mandated. Publishing is a commercial decision |
Two features of the EU regime catch employers out. It does not require the range in the advert: Directive (EU) 2023/970 requires that applicants be informed of the initial pay or pay range before the interview or at the latest during it, which many employers will satisfy by publishing anyway because it is simpler than operating a separate disclosure step. And transposition is uneven: member states were required to implement by 7 June 2026 and progress varies considerably, with some legislating early and others, including the Netherlands, announcing delays. Check the national law where the role sits, and do not rely on the directive alone.
The reporting side arrives shortly after. Employers with 150 or more staff report gender pay gap data from 2027 on 2026 figures, and an unexplained gap of 5 per cent or more in any category of worker triggers a joint pay assessment and remedial action. That has a bearing on adverts, because a band you publish becomes evidence about how you set pay.
For where the band should actually sit, the salary benchmarks post carries the UK and US numbers and the sources they came from.
Writing requirements when both sides are automated
The application process is now machine-mediated at both ends. Candidates paste your advert into a model and receive a tailored CV and covering letter in twenty seconds. Employers run the results through parsers, matchers and increasingly through models that score fit. Job seekers were submitting applications to LinkedIn at roughly 11,000 a minute by mid-2025, and Ashby’s five-year data shows applications per hire tripling over the same period.
This changes what a requirement is. A requirement used to be a claim you asked a candidate to make about themselves, on the assumption that most people would not make a false one. That assumption held when writing the claim cost effort. It costs nothing now, and the model doing the writing has your advert in front of it, so it will use your exact phrasing. Anything you can state, they can restate.
Three properties make a requirement survive that.
Requirements that describe outcomes with numbers attached are hard to fake and easy to check. “Rebuilt a reporting layer people had stopped trusting” cannot be answered convincingly without a story containing names, dates and a specific fight. You will ask for that story, and a fabricated one falls apart at the second follow-up question.
Requirements phrased as decisions expose reasoning. “Tell us about a data model decision you got wrong and what it cost” produces answers that a model can generate in outline and cannot ground in a real system. The grounding is the signal.
Requirements attached to an artefact do the work directly. Asking for a small piece of built work, narrated, moves the assessment out of the written layer entirely. That is the whole argument of the post on what AI-written applications did to screening, and the advert is where you announce it.
There is a second-order effect on the requirements list itself. Because models mirror your vocabulary, an advert stuffed with tool names produces a pile of applications stuffed with the same tool names, which then defeats your own keyword matching. Keyword screening works only when keywords are scarce. Writing a shorter, more specific requirements list is now partly a defence of your own filtering: fewer terms to match on, and terms that are harder to claim.
One thing to avoid: do not write requirements designed to trip up automated applicants. Instructions hidden in white text, deliberate nonsense criteria and similar tricks catch careless humans, produce nothing useful, and read as adversarial to exactly the senior candidates you want. Put the difficulty in the work sample, where it belongs.
What to call the role, and what an invented title costs
Titles in this space are unstable. The same job is advertised as Revenue Operations Manager, Sales Operations Manager, GTM Engineer, Growth Engineer, Revenue Systems Manager, Business Operations Manager and, at companies with strong internal culture, as things like “Revenue Architect” or “GTM Alchemist”.
An invented title costs you in three places at once.
Search is the obvious one. Candidates search for the title they already hold or the one they want next. A title nobody types does not appear. This is also why the length matters: Appcast’s click data puts one to three word titles at 3.41 average clicks against 2.75 for titles of 13 words or more, and its 2026 guidance puts the best performing range at four to six words, with a marked drop above ten.
Matching is the less obvious one. Job boards, LinkedIn’s recommendation systems and every ATS matching layer work from title normalisation. A title outside the taxonomy gets mapped badly or not at all, and the role stops being surfaced to people who never searched for it. The failure is silent: you see fewer applications and no explanation.
The third cost lands after the hire. An unusual title is a tax on the person who holds it, at their next search and at their next promotion conversation, and experienced candidates know this. A senior operations person will read “GTM Alchemist” as a signal that the company has not thought about their career, which is a reasonable inference.
| Title you might be tempted by | What it costs | Post this instead |
|---|---|---|
| Revenue Rockstar, GTM Ninja, Growth Guru | Zero search volume, poor matching, and it repels senior candidates | Revenue Operations Manager |
| Revenue Architect, GTM Alchemist | Internally meaningful, externally invisible | Revenue Operations Manager, or Head of Revenue Operations if it is genuinely a lead role |
| Business Operations Manager, for an ops role | Matches finance, strategy and internal ops candidates, so you get the wrong pool | Revenue Operations Manager |
| Sales Operations Manager, for a full RevOps remit | Attracts a narrower population, and the strongest RevOps people filter it out | Revenue Operations Manager |
| Marketing Operations Manager, for a full RevOps remit | Same problem in the other direction | Revenue Operations Manager |
| Data Analyst, for a systems ownership role | Attracts analysts who do not want to own systems | Revenue Operations Manager or Revenue Operations Analyst, depending on seniority |
| GTM Engineer, for a role with no build component | Attracts builders who leave in six months when they find out | Revenue Operations Manager |
| Automation Engineer, for a GTM engineering role | Matches RPA and internal IT candidates | GTM Engineer |
The two-part solution most companies land on is to post the standard title and use the internal name internally. If you must signal something extra, do it in a subtitle line under the title, where a human reads it and the matching layer ignores it.
One nuance for GTM engineering specifically. The title has enough search volume to be worth using and not enough standardisation to be self-explanatory, which is why the State of GTM Engineering figure of 45 per cent matters. Use the title, then spend your first paragraph defining which version of it you mean. Getting the title right and the definition wrong produces a pile of applications from five different professions.
The section by section checklist
Run a draft against this before it goes live. Each section has one test it has to pass, and the test is always the same in structure: does this sentence change who applies.
| Section | What goes in it | What to leave out | The test it must pass |
|---|---|---|---|
| Title | The standard market title, four to six words | Invented titles, seniority padding, internal codes | Would a candidate type these words into a search box |
| Header line | Location, working pattern, salary band, reporting line | “Competitive”, “DOE”, “flexible” without definition | Can a reader disqualify themselves in ten seconds |
| Opening paragraph | The specific problem, with numbers | Mission statements, funding stage, adjectives about the team | Could a competitor have written this identical paragraph |
| Systems owned | Named systems, their current state, size and known faults | Every tool anyone in the company uses | Does a candidate now know what they are inheriting |
| Systems not owned | The boundaries, and who holds each one | Nothing. This section always earns its space | Does it answer the scope creep question before it is asked |
| Outcomes at 12 months | Five or fewer, each measurable | “Drive efficiency”, “support the team”, “improve processes” | Could you tell, at 12 months, whether it happened |
| Genuinely required | Three or four, each a thing they have done | Tool names, degrees, years of experience as a proxy | Would you actually reject a strong candidate for missing it |
| Learnable | Named explicitly, with a rough time to competence | Anything you would in fact reject on | Does this widen the pool without lowering the bar |
| Salary | The band, plus what determines position within it | A range wider than 25 per cent of the low figure | Would a candidate at the top of the band still apply |
| Process | Every stage, the time each takes, total elapsed time | Vague promises about moving quickly | Can a candidate plan their next three weeks around it |
| Response commitment | A specific number of working days, and an address to chase | “We will be in touch if successful” | Will you keep it |
Two structural checks on top. Read the advert as a candidate who is happily employed and not looking: does anything in it justify a reply. Then read it as a candidate who is unemployed and applying to forty roles a week: does anything in it stop them. If both answers are no, the advert is a description and it will behave like one.
Write the advert as a filter and accept fewer applications
The reason a RevOps job description attracts the wrong applicants is almost never the tools listed in it. It is that the document was written to describe a role to a general audience, when its actual function is to make several hundred specific people decide not to apply and eleven specific people decide to.
Everything in the two templates above follows from that. The problem goes at the top because it is the only part of the advert a candidate cannot mirror back at you. The non-ownership list goes in because scope is what experienced operations people actually screen on. Outcomes replace responsibilities because outcomes can be judged. The requirements list is split because candidates read it as permissions. The band goes in because it removes the largest category of wasted process and, in a growing list of jurisdictions, because it is required.
Expect fewer applications. Count the ones worth an hour instead, before and after, and judge the change on that number. If you are also unsure whether the role you are describing is a RevOps manager at all, settle that before you write a word, because no amount of good advert writing rescues a job that has not been defined.
Related reading
- How to hire a RevOps manager, the full hiring process this advert sits inside.
- Which of the roles you are actually hiring, across sales ops, marketing ops, RevOps and GTM engineering.
- What a GTM engineer actually does, if the second template is the one you are filling in.
- RevOps salary benchmarks, for the band that goes in the advert.
- RevOps interview questions, for the stage after the advert has done its filtering.
- What AI-written applications did to screening, and what still works once the written layer stopped filtering.
- Why ops hires fail in the first 90 days, which is usually traceable to the advert being wrong about the job.
- Work sample tests against interviews, the evidence for the assessment step the advert announces.
Questions
What people ask about this.
- What should a RevOps job description include?
- Six things, in this order: the specific problem the hire will fix, stated with numbers; the systems they will own and explicitly will not own; the outcomes they will be judged on at twelve months; requirements split into genuinely required and learnable; the salary band with a commitment about how it will be applied; and the full interview process with a timeline. Everything else in a standard template is either decoration or a duplicate.
- Should I list the tools?
- List them as context, not as requirements. Naming Salesforce and HubSpot and describing their current state tells a candidate what they are inheriting, which is useful. Requiring "3+ years of Salesforce, HubSpot, Marketo, Outreach and Clay" filters nobody, because every application you receive will claim all five. The tool list stopped being a screening instrument when tool access stopped being scarce, and generative writing tools finished it off.
- Will a harder job description reduce my applications?
- Yes, and that is the intended effect. A specific advert with real numbers, three genuine requirements and a published work sample will reduce raw volume noticeably and increase the number of applicants worth an hour of your time. Given that applications per hire have tripled since 2021 on Ashby's data while interview rates halved, volume is not the constraint on your hiring. Screening capacity is.
- Should I put the salary in the job advert?
- Yes, and in eleven US states and much of the EU you have no choice. Where you do have a choice, publish anyway, and publish a band narrow enough to describe one job. The evidence on what that does to your applicant pool is in [the salary benchmarks guide](/blog/revops-salary-benchmarks/); the drafting mistakes that waste a published band are earlier in this post.
- What should I call the role?
- Revenue Operations Manager, if the remit covers systems, reporting and process across sales and marketing. GTM Engineer, if there is a genuine build component and the person will write code or heavy automation logic. Sales Operations Manager or Marketing Operations Manager only if the remit really is that narrow. Never an invented title: it has no search volume, no matching behaviour, and it reads to senior candidates as a company that has not thought about their next move.
- How long should a RevOps job description be?
- Between 400 and 700 words for the advert itself, which is longer than the general recruitment advertising benchmarks recommend and appropriate for this kind of hire. Appcast's data, from adverts dominated by high volume roles, shows apply rate peaking at 201 to 400 words. That optimises for applications per click, which is not your problem. Your problem is applications per qualified applicant, and specificity costs words.
- Do I have to publish a salary range by law?
- It depends where the role sits. Eleven US states require pay information in the posting or at a defined point in the process, including Colorado since 2021, California and Washington since 2023, Illinois and Minnesota since 2025 and Massachusetts since 29 October 2025. In the EU, the Pay Transparency Directive had a transposition deadline of 7 June 2026 and requires the initial pay or range before the interview, though not necessarily in the advert. The UK has no general requirement, so publishing there is a commercial choice.
- How many requirements should a job description have?
- Three or four genuinely required, and a separate list of what is learnable. Candidates read a requirements list as permissions rather than preferences: Tara Sophia Mohr's survey of more than a thousand professionals found that the reason people gave for not applying was mostly "I did not think they would hire me and did not want to waste the effort". Self-doubt about ability came last. A nine-item list is read as nine gates, and it excludes on all nine.
- Can I just use a job description template from Indeed or SHRM?
- You can use the structure. The content will not work, because generic templates are built to describe a role in a way that applies to any employer, and describing is the opposite of filtering. A template that could be used by four hundred companies produces an advert that is indistinguishable from four hundred others, which pushes the entire selection burden onto your screening stage. Take the section headings and write the contents from your own systems.
- How do I stop AI-written applications from overwhelming a good advert?
- You cannot stop them, and the advert is the wrong place to try. What the advert can do is put the discriminating step outside the written layer: publish a paid work sample in the process section so that applicants know written material is not the deciding evidence, and phrase requirements as specific things done rather than attributes held. Never plant hidden instructions or trick criteria; they catch careless humans and read as adversarial to senior candidates.
- Should the job description mention the interview process?
- Yes, with the number of stages, what happens at each, how long each takes and the total elapsed time. It filters out candidates who will not do a work sample before you spend a screening call finding out, it gives employed candidates the information they need to plan, and it is the single easiest thing to include that almost nobody does. Add a response commitment with a real number of days and keep it.
Tell us the role. We will tell you honestly whether we can fill it.
Nothing owed until someone starts.
Book a call