Roughly a third of the ServiceNow roles that land on my desk have the wrong title on them.
Not slightly wrong. Wrong in a way that costs the client six weeks and a rejected offer.
The job spec says developer. The interview questions are about integration design and platform governance. The salary band is set at developer level. The candidates who could actually do the work take one look at the money and pass, and the ones who fit the money can’t answer the questions.
Here is how we help clients sort it out before the advert goes live.
The three roles, in plain terms
Developer. Builds what has been specified. Flows, scripts, UI, catalogue items, integrations that someone else has designed. Give a good ServiceNow developer a clear ticket and they will close it. Ask them to sit in front of a CFO and challenge the business case for a Now Assist rollout, and you have put them in the wrong room.
Technical consultant. Sits between the client and the build. Runs the workshops, translates what the business says it wants into what the platform can actually do, then either builds it or hands it to developers. This is the role most people mean when they write “developer” in a job spec. It needs the technical depth of a developer plus the willingness to be in a room with stakeholders who disagree with each other.
Architect. Owns the shape of the platform. Instance strategy, data model, integration patterns, upgrade path, what goes on ServiceNow and what does not. An architect’s value is mostly in the things they stop you doing. If you have one instance, one module and a two-person team, you do not need one yet.
The question that usually settles it
When a client is not sure which one they need, we ask this: who decides how the work gets done?
If the answer is “we tell them what to build”, it is a developer.
If the answer is “we want them to work that out with the business”, it is a technical consultant.
If the answer is “we want them to tell us what we should be building at all”, it is an architect.
That one question resolves most of it in about thirty seconds on a call.
What goes wrong at each level
Hiring a developer when you need a consultant. The most common one. You get someone who builds exactly what the ticket says, and the tickets are wrong because nobody has run a proper workshop with the business. Six months in, the platform works and nobody uses it.
Hiring a consultant when you need a developer. Less damaging, more expensive. You have paid a premium for stakeholder skills you are not using, and the person gets bored. They usually leave inside a year, and their exit interview says “the work wasn’t what I expected”.
Hiring an architect too early. This one comes up when a business has bought a lot of ServiceNow and panicked. A strong architect with no team to direct and no scale to manage will spend three months writing standards documents and then start looking. Architects want complexity. If you cannot give them any, someone else will.
Not hiring an architect when you should have. Usually visible about two years in, when you have four integrations built four different ways, customisation nobody can explain, and an upgrade everyone is afraid of. That is the expensive version.
What this means for your job spec
A few things we ask clients to be specific about before we take a role to market:
Who writes the requirements? If the answer is the person you are hiring, say so in the advert. It changes who applies.
How many people will they work alongside? A consultant in a team of twelve is a different job from a consultant who is the entire ServiceNow function. Both are legitimate. Candidates need to know which one they are walking into.
Which modules, honestly. “ITSM plus a bit of HRSD” is a real answer and it is fine. “Full platform” when you mean ITSM makes experienced people suspicious.
What does the first six months look like? Greenfield implementation, BAU support, and rescuing a bad implementation attract very different people. The third one, done honestly, attracts more people than you would expect. Plenty of good consultants enjoy a mess.
Is the title negotiable? Sometimes the work is architect-level and the internal band is not. Say it early. We would rather find someone who wants the scope more than the title than lose a candidate at offer.
Where partners and customers differ
If you are a ServiceNow partner, your consultants need client-facing polish and the ability to move between three accounts in a week. Your developers need throughput.
If you are an end customer, the same titles mean something different. Your consultant will spend more time on internal politics than on discovery workshops, and your developer will be closer to the business than a partner-side developer ever gets.
Candidates know the difference. When a customer-side spec reads like a partner-side spec, it reads as though you have copied it from somewhere. Which, usually, you have.
Getting it right first time
Most of the mis-hires we get asked to fix were not skills failures. The person could do the job in the spec. The spec just described a job the business did not need.
Twenty minutes scoping the role properly before it goes live saves a lot more than twenty minutes.
If you are about to open a ServiceNow role and you are not certain which of the three it is, send me the spec and I will tell you what I think. No charge and no pitch attached.