The Job Decoder — 6 questions that tell you what a role actually is
The short answer
A job description is not a description of the work — it is a document written by committee for three audiences that are not you: the applicant-tracking software (keyword filter), HR and legal (risk language), and the internal pay-grade system (the words that justify the salary band). The actual work is the one thing it is not optimised to convey. To understand any role, ignore the prose and answer six questions: (1) what does this person do all day; (2) what are they really measured on — the one or two numbers that decide if they are good; (3) who do they work with; (4) what is the number-one failure mode that quietly kills the role; (5) what skills actually get the work done, not the certifications listed; (6) how do you break in. Answer those six and you understand the job — the posting answered almost none of them.
The Job Decoder — six questions
- 01
What does this person actually do all day?
Strip the verbs like 'drive', 'own', and 'lead' and ask what lands in their inbox on a Tuesday. A master-data manager does not 'ensure data integrity' — they decide the rules for what a product or vendor record is and who may change it, and they run the queue of change requests. Describe the day, not the aspiration.
- 02
What are they really measured on?
Find the one or two numbers that decide whether they are good at it. A buyer is measured on realised savings and the terms they lock, not on 'managing stakeholders'. A planner is measured on forecast accuracy and stockout-versus-excess. If you cannot name the metric, you do not yet understand the role.
- 03
Who do they work with?
Map the real interfaces — the handful of roles they negotiate, hand off to, and depend on. This is where a role's power (or lack of it) lives: a steward who 'works with' the business but cannot make it comply has no authority, whatever the title says.
- 04
What is the number-one failure mode?
Every role has a characteristic way it goes wrong. The steward named on paper with no time or authority. The buyer who starts at T-30, after the leverage expired. The PMO that reports colour instead of making decisions. Knowing the failure mode tells you what the job is really defending against.
- 05
What skills actually get the work done?
Ignore the certification list and ask what the good people can actually do. For most operations roles it is: go deep in one domain before going wide; write a rule, not just spot a bad record; read a number at the right level of detail; and govern — know who decides. These beat the tool certification almost every time.
- 06
How do you break in?
Name the realistic entry path and the adjacent role people come from. Most enterprise-operations roles are entered sideways (analyst → steward → lead → owner), not applied to cold. Knowing the on-ramp is worth more than knowing the destination.
A job description is not a description of the job
I have hired into these roles, worked across them on both sides of the table, and written more of these documents than I would like to admit. Here is the uncomfortable truth from the inside: the job description is almost never a description of the job.
It is a document written by committee, for three audiences, and none of them is the person trying to understand the work:
- The applicant-tracking software. Most large companies filter applications automatically before a human reads them. So the posting is written to match search terms, not to inform a reader. “Stakeholder management, cross-functional alignment, data-driven decision-making” are there to clear a filter.
- HR and legal. “And other duties as assigned” exists so the role can change without rewriting the contract. The generic competencies and compliance hedges are risk management, not description.
- The internal pay grade. Words like “strategic”, “senior”, and “complex” are often there to justify the band the role sits in. The same task is “execution” at one level and “strategic delivery” at the next.
And then there is copy-paste lineage: most descriptions are forked from an older one nobody rewrote. The role drifted over five years; the posting did not. You are reading an archaeology of what the job used to be.
The six questions that decode any role
The fix is to stop reading the prose and start interrogating the role. Six questions do it:
- What does this person do all day? — the work that actually lands, not the verbs.
- What are they really measured on? — the one or two numbers that decide if they are good.
- Who do they work with? — the real interfaces, and whether they have authority over them.
- What is the number-one failure mode? — the characteristic way the role goes wrong.
- What skills actually get the work done? — not the certifications listed.
- How do you break in? — the realistic on-ramp and the adjacent role.
Answer those and you understand the job. The posting answered almost none of them.
A worked example — “Master Data Manager”
Take a real line from a posting: “ensure data integrity across enterprise systems and drive governance initiatives.”
Decoded:
- All day: they own the rules that decide what a product, vendor, or customer record is, and who is allowed to change it — and they run the queue of requests to create and change those records.
- Measured on: quality at the field level (not “the data is 90% clean”, but whether the specific field a planner depends on is right) and how fast the change queue clears.
- Works with: the business owners who want records created, and the IT team that runs the system the records live in.
- Number-one failure mode: the steward who is named on paper but given no time and no authority — the queue backs up and everyone blames “the data”. It is not the data. It is the operating model.
- Skills that matter: going deep in one domain (product, vendor, or customer) before going wide; writing a rule, not just spotting a bad record; reading quality at the field level; and governance literacy.
- Break in: analyst → data steward → master-data lead → global process owner, and from there sideways into governance, AI readiness, and transformation.
None of that was in the posting. All of it is the job.
If you are the one writing the description
Answer the same six questions in plain words. You will get fewer applicants who matched keywords and more who can actually do the work — which is the entire point of writing the thing.
This is the umbrella tool for The Job, Decoded — a series that takes the roles across enterprise operations one at a time. Each role-decode links its own free checklist and the operator-grade pack behind it.
Frequently asked
Why are job descriptions so hard to understand?
Because they are not written to inform you. A typical corporate job description is optimised for three things at once: passing the applicant-tracking software's keyword filter, satisfying HR and legal (hence 'and other duties as assigned' and the generic competencies), and justifying the internal pay grade ('strategic', 'senior', 'complex'). On top of that, most are copy-pasted from an older version nobody rewrote, so they describe a role that has since drifted. The actual day-to-day work is the one thing none of those forces optimise for.
How do I figure out what a job actually involves before I apply?
Run the six questions in the Job Decoder against the posting: what they do all day, what they're measured on, who they work with, the number-one failure mode, the skills that actually matter, and how people break in. The description will answer one or two; for the rest, look at the team's other postings, search the role title plus 'day in the life', and — best of all — ask someone who does it. The gap between the posting and those answers is the gap between the role's image and its reality.
What should I look for that a job description won't tell me?
Authority and the metric. A title tells you the level; it does not tell you whether the role can actually make decisions or whether it is accountable for something it cannot control. Find out what the person is measured on and whether they have the authority to move that number. A role that is measured on data quality but cannot make the business comply is a role set up to fail — and the description will read identically to one that works.
How do I write a job description people actually understand?
Answer the six questions in plain words: what the person will do day to day, the one or two things they will be measured on, who they will work with, the hardest part of the job, the skills that actually matter, and the kind of background that succeeds. You will get fewer applicants who merely matched keywords and more who can actually do the work — which is the point.
The Job, Decoded series takes the roles across enterprise operations one at a time — master data, procurement, planning, transformation, PMO, transition, AI governance — and each has a matching operator-grade workbook, handbook, or course. Decode the role for free; get the done-for-you tool when you run it for real.
Browse the operator-grade packs →Written by Petko Petkov — 15 years inside enterprise IT operations. Vihren Labs publishes operator-grade templates and playbooks for the enterprise IT stack.