I read somewhere between thirty and fifty job specifications a month. Some are ours, written with a client after a long briefing. Most are not. They are documents candidates forward to me with one question: is this worth applying for?
The honest answer is usually in the document, but not in the parts people read first. A job spec is a negotiated text. Several people have edited it, each with different priorities, and what survives tells you a good deal about the role and the organisation behind it.
Why specs read the way they do
A typical senior technology specification is drafted by a hiring manager, edited by HR to fit the grading framework, checked by legal for anything risky, and sometimes rewritten by a recruiter for tone. By the time it is published, the original intent has been smoothed over.
That is why the useful signals tend to be structural rather than verbal: what is listed first, what is vague, what is oddly specific, and what is missing.
Ten signals worth reading for
The order of responsibilities. The first three bullets are usually what the hiring manager wrote before anyone else touched the document. Treat them as the real job. Anything after the sixth bullet is often inherited from an older spec.
Oddly specific requirements. “Experience migrating a payments platform to cloud within a regulated environment” is not a generic line. It describes a problem the team has right now, or one the last person in the role did not solve.
The reporting line. If it is missing, or reads “reporting to the leadership team”, the role may not have a clear sponsor yet. Ask who signed off the headcount.
Team size, stated or not. “Lead a growing team” with no number usually means two or three people and a promise of more. That can be a real opportunity, but find out whether the budget for more is approved.
The verbs. “You will build” and “you will run” are different jobs. “Build” means the thing does not exist yet. “Transform” usually means it exists and people are attached to it.
Words that soften pressure. “Fast-paced”, “comfortable with ambiguity” and “able to wear many hats” are honest signals. They often mean the team is under-resourced or the strategy is shifting. Neither is a problem if you go in knowing it.
How wide the salary band is. A band from £110,000 to £160,000 tells you the grade is not settled, or that two levels are being hired under one spec. Ask which end the budget was built around.
Essentials against desirables. Twelve essential requirements and two desirable ones suggests a hiring manager who has not decided what matters. Four essentials and six desirables suggests someone who has.
What is missing. A senior technology role with no mention of budget, vendors or stakeholders outside engineering is either narrower than the title suggests, or written by someone who has not thought about it yet.
How long it has been live. If the same spec has been on the careers page for four months, ask why. Sometimes the bar is high. Sometimes the role has been offered and declined twice.
What to do with what you find
None of these signals is a reason to rule a role out on its own. They are reasons to ask better questions. In a first conversation, whether with a recruiter or the hiring manager, I suggest asking three things:
What does success look like at twelve months, and who decides?
Why is the role open now, and what happened to the last person in it?
Which part of the specification would you drop if you had to?
The last question is the most useful. A hiring manager who can answer it straight away has a clear view of the job. One who cannot is likely to measure you against all fourteen bullets.
A short worked example
A spec I reviewed last month, for a Head of Platform Engineering at a London insurer, opened with a responsibility about “driving a culture of reliability”. The fourth bullet asked for “experience reducing major incidents in a high-availability environment”. The band was £140,000 to £175,000, and the reporting line read “to the CTO or delegate”.
Read together, those lines described a platform with recent outages, a CTO who might not be the day-to-day manager, and a role the business had not fully graded. The candidate asked about all three in her first call. The answers were good, and she accepted the role with a confirmed reporting line to the CTO and a base at the top of the band.
That is the point of reading closely. Not to find reasons to say no, but to arrive at the first conversation already knowing what to ask.
