Why SAP Job Descriptions Repel the People They Need

If your role has been open for five months, the market is not the problem. The brief is.

The people you actually want are employed, busy and not scrolling job boards. They read a description for about twenty seconds, and in that time they are answering one question: is there anything here I could not get where I already am?

Most SAP job descriptions answer that question with “no” — not because the role is bad, but because the description was written to satisfy an internal process rather than to interest a specific person.

What strong candidates are actually looking for

Not perks. Not “dynamic team”. Four things, in roughly this order:

What will I own? Decision rights, scope, the thing that is mine.
What is the real problem? Where the programme actually is — including what is going badly.
Who will I work with, and who decides? Reporting line, sponsorship, distance to where decisions get made.
What does this do for my next five years? Which capability will I have afterwards that I don’t have now?

Almost no SAP job description answers any of these. Most answer a fifth question nobody asked: which modules and versions have you touched?

The five patterns that repel good people

1. The certification wall. A list of modules, versions and certifications as mandatory requirements. This selects for people who collect certifications and screens out people who make decisions. It also, quietly, screens out most career changers and anyone whose experience is broad rather than labelled. If a capability can be learned in six weeks by someone with judgment, it is not a requirement — it is a preference.

2. The impossible composite. The functional depth of a specialist, the architecture breadth of a solution architect, the stakeholder skills of a programme manager, plus a developer’s technical fluency — at one salary band. Strong candidates read this as “this organisation does not know what it needs”, and conclude the role will change shape three times in year one. They are usually right.

3. The sanitised problem. “Exciting greenfield transformation” when the truth is a recovery of a programme that has slipped twice. Ironically, the honest version attracts better people: experienced professionals are drawn to real problems and repelled by the suspicion that they are not being told the truth. Sanitising the brief filters out exactly the people who could fix it.

4. Responsibilities without authority. “Responsible for driving standardisation across all business units” — reporting three levels below the person who can actually approve a standardisation decision. Senior candidates spot this instantly; it is the single most common reason a strong candidate withdraws late.

5. No signal about the environment. Travel expectations, on-site policy, delivery model, whether the SAP team is a cost centre or a capability the business invests in. Leaving these vague does not keep options open; it makes cautious candidates self-select out and wastes everyone’s time in week three.

Why strong candidates decline late

The expensive failures are not the ones who never applied. They are the ones who reached final stage and walked away. Overwhelmingly, three reasons:

The role turned out to be smaller than described — the scope shrank as the conversation got specific.
They met the person they would report to and saw where the real decisions get made — elsewhere.
The process itself told them something. Six interviews over nine weeks, repeated re-explaining, silence between rounds. Nobody says “your process was the reason”. It usually was.

A hiring process is a working sample of the organisation. Candidates read it as one.

What to write instead

Cut the description to what a strong person needs to decide whether to spend twenty minutes on a conversation:

The mandate in one sentence. “You will own the design decisions for X across Y.” If you cannot write that sentence, the role is not ready to advertise.
The real situation, honestly. Where the programme is, what is hard, what the first six months look like. Including the uncomfortable parts.
Two or three genuine must-haves, and be explicit that the rest is learnable. State the capability, not the certification: “can run a Fit-to-Standard workshop and land a decision” beats a list of module codes.
Reporting line and sponsorship. Who you report to, who sponsors the programme, who signs the decisions.
The practical facts: location expectation, travel, delivery model, the shape of the package.
What the person gets out of it. The capability, the exposure, the thing they can point at afterwards.

That is a shorter document than most organisations produce today, and it will out-perform the long one — because it is written for a reader instead of for an approval workflow.

For recruiters

The same discipline applies, with one addition: a role you cannot describe honestly is a role you should not take to market. Presenting a role better than it is buys one placement and costs the relationship — with the candidate and eventually with the client.

This is why sapperment’s Featured Recruiters sign a public Recruiting Charter: the mandate is real, the role is described as it is, the candidate is represented as they are, the engagement model is disclosed, and nobody gets ghosted. Not because recruiters are the problem — but because the ones who work this way currently have no way to prove it.

The bottom line

The SAP market is not short of capable people. It is short of roles described clearly enough for capable people to recognise themselves in them.

Write the brief for the person you want to read it. If that person would not find it interesting, no amount of sourcing will fix it.

— Andreas BORN

Read The Talent Brief — the SAP skills, careers and hiring decisions that matter, once a month. Subscribe →