Your team already has the competency-framework, inclusive-jd, and sensitive-comms playbooks — the worked recipes for drafting one framework, cleaning one JD, and writing one hard message. This module is the layer above the recipe. It’s where you master the three files every hire, review, promotion, and org change inherits — what you’re actually hiring for, whether your pool is wide or quietly narrow, and how to say the thing the org needs to hear — build them for a real role and a real scenario, and prove, against a real rubric, that you can.
It’s Module 1 of the certifiable People & HR track, and it’s the one we leave open. Read it, do the assignment, and you’ll know exactly what the depth is worth before you put a team through the rest.
Every downstream HR action — the interview, the offer, the first-year review, the promotion decision, the org change — is a withdrawal from three accounts: what you’ve decided good looks like at each level, whether the pool you’re drawing from is as wide as your role actually allows, and whether people trust what you tell them when things are uncertain. Most teams never fund those accounts, so every interview re-guesses the criteria, every JD quietly excludes candidates nobody meant to exclude, and every hard message arrives after too much hedging and not enough truth. The foundation is where you fund all three once, and it’s the highest-leverage hour in the whole track.
Why the foundation is the highest-leverage investment in the track
People operations breaks quietly, one vague standard at a time. A competency gets written as a personality trait — “strong communicator,” “strategic thinker,” “team player” — and two interviewers walk out of the same conversation with completely different reads, because nobody agreed what they were scoring. A job description lists seven years of experience, a degree, and three tool certifications that weren’t in the original role, so the hiring manager gets a pile of technically-qualified candidates who are wrong for what the role actually does. A message about restructuring arrives wrapped in four paragraphs of reassurance and one buried paragraph of what’s actually changing — and the team reads every word except the one that matters and spends the next week filling in the gap with rumour.
Three documents fix all three. A competency-framework.md decides what good looks like at each level — the observable behaviors that define a CS Specialist versus a Senior CSM versus a CS Lead, written precisely enough that two interviewers independently score the same candidate the same way. An inclusive-jd.md decides who you’re actually inviting to apply — genuine must-haves separated from preferences, with no coded language that shrinks the pool before a qualified candidate even clicks. A sensitive-comms.md decides how you hold trust when things are hard — the message that says the thing directly, names what’s uncertain, and doesn’t bury the lede in reassurance the reader can tell you don’t fully mean.
Build them once and every later task inherits them: you feed the framework into an interview guide and the questions score against behaviors, not vibes; you feed the JD into an offer process and the shortlist is wide for the right reasons; you feed the sensitive-comms standard into every org-change message and the team hears the thing instead of reading between the lines. That’s why this is Module 1. Skip it and Claude helps you run a faster process built on guesses about what “good” looks like — which is worse, not better, because the mistakes compound downstream.
The competency framework — observable behavior is the only standard worth writing
The playbook gives you the steps to write the framework. Mastery is the judgment inside it — the difference between a competency that’s actually usable in an interview or a review and one that sounds right and means nothing when someone has to score against it.
- A feeling is not a competency. “Strong communicator” could describe someone who sends clear emails or someone who presents to a board under pressure or someone who de-escalates a difficult client in real time — these are completely different things, and an interviewer has to guess which one they’re evaluating. An observable behavior closes that gap: “Presents churn analysis to a founder in under 10 minutes without preparation, leading with the so-what, not the method.” That’s a standard two interviewers apply the same way, a manager references in a performance review, and a promotion committee uses when deciding whether someone has grown into the senior level.
- Three levels is the minimum that’s useful. A framework that defines only one level is a job description, not a framework. The value is the progression — what moves someone from Specialist to Senior, and from Senior to Lead — because those transitions are where managers rely on gut and where promotion decisions get contested. Write the observable jump at each level explicitly, and you answer the question before it becomes a grievance.
- The framework is the source of truth the JD inherits. The must-haves in your JD should trace directly back to Senior-level behaviors in the framework — not to “what the last person in this role happened to have.” If a requirement in the JD doesn’t map to a competency, it’s either a real competency you forgot to write or a filter you added without reasoning. Building the framework first forces that discipline.
- The framework is what Claude inherits downstream. Feed
competency-framework.mdinto an interview debrief, a review cycle, or a calibration session and Claude evaluates against your standard for your function — not a generic rubric it generates on the spot. One file, written once, makes every talent decision for that role family consistent with the last.
The inclusive JD — widening the pool is a craft, not a checklist
The playbook gives you the prompts to audit a JD. Mastery is the judgment that distinguishes a JD that widens the pool from one that sounds inclusive and quietly closes it — and the failure mode is almost always the same: well-intentioned requirements that weren’t interrogated.
- Must-haves earn the label. Every line in the requirements section is a gate — someone who doesn’t clear it doesn’t apply. The discipline is asking, for each one: would we genuinely not interview someone who lacks this, or is this what we assume the right candidate will have? Degree requirements, specific tool certifications, and years-of-experience minimums are the three most common gates that close the pool without intending to. The test is: if the best candidate for this role had a non-traditional path, would this gate stop them?
- Preferences belong in a different section. “GCC market experience preferred” is not a barrier; “GCC market experience required” excludes qualified candidates from everywhere else in the world who would learn it in ninety days. Separating genuine requirements from genuine preferences isn’t softening the role — it’s writing the role accurately. The Senior CSM who spent five years running enterprise accounts in London and speaks Arabic is a stronger candidate than one the requirements-as-written filter out.
- Lead with what the role actually does. Most JDs open with “we are a fast-growing SaaS” and bury the actual work four paragraphs down. The candidate who reads this role is trying to answer one question in the first thirty seconds: is this my kind of problem? Answer that first. “You’ll be the named owner for 15–20 UAE SMB clients, managing the full lifecycle from onboarding through renewal, and you’ll be the internal voice for what those clients need” is a better first paragraph than three sentences about the company’s mission.
- Coded language shrinks the pool silently. “Rockstar,” “ninja,” “culture fit,” “digital native,” “high-energy” — these signal who the hiring team pictures in the role, and they’re pictures that aren’t the role. A JD that describes what the role does and what it requires is inclusive; a JD that describes who the hiring team wants to be impressed by is not.
The sensitive message — saying the thing is the hardest craft in HR
The playbook gives you the steps to draft the message. Mastery is the judgment that separates a message the reader trusts from one they can tell was written to make the sender more comfortable — and that gap is almost always visible in the first paragraph.
- The reader should know the point by the end of the first paragraph. The failure mode of every sensitive message is the same: four paragraphs of context, reassurance, and values-signalling before the one sentence that contains the news. The reader knows something is coming, reads through the preamble with mounting anxiety, and arrives at the actual information already primed to distrust the framing. Say the thing first. “We’re changing how the ops team is structured. Here’s what’s changing, here’s what isn’t, and here’s what we’re still working out.” That’s a message the reader can respond to. The context and the reasoning come after — not as a warm-up.
- Uncertainty named honestly is more reassuring than uncertainty papered over. The instinct in a sensitive message is to project confidence — to write as if everything is figured out and the path is clear — because uncertainty feels like weakness in the sender. But the team knows when things aren’t figured out, and a message that pretends they are reads as evasive. “We don’t yet know what this means for the two roles that report to this team — we’ll have that clarity by the end of July” is a sentence the reader can hold. “We’re committed to supporting everyone through this transition” is not.
- The message optimises for the reader’s clarity, not the sender’s comfort. A CEO who is uncomfortable delivering hard news writes a long message. A leader who has done this writes a short one. Every sentence in a sensitive message earns its place by answering a question the reader has — what’s changing, what’s not changing, what happens next, and when — and everything else comes out. The test is: can the reader walk away from this message and explain to a colleague what just happened? If not, the message isn’t done.
- Tone is a decision, not a default. A restructuring message and a role-elimination message and a “we made a decision you won’t like” message are different, and the register should reflect the weight. Direct is not cold. Holding the uncertainty is not weakness. Not burying the lede is the most respectful thing you can do for a team reading difficult news under real pressure.
The bilingual standard — the part most HR teams skip until it’s a problem
For a MENA team this isn’t a translation step you run at the end. It’s a standard you set in the foundation, so the JDs, onboarding documents, policy rewrites, and org-change messages the track produces after this module inherit it. The rule is the same one the Finance and Sales tracks teach — author, don’t translate — and for HR it has its own hard edges.
- The JD for a bilingual market is authored in Arabic, not translated. A job description that reads as translated loses candidates who know the register and can tell. For a role where the candidate will be representing your company in Arabic to clients — a Senior CSM whose client-facing language is Arabic — the JD that reaches them in natural Gulf Arabic is itself a signal about what kind of team they’re joining. M2’s interview synthesis and M3’s onboarding documents inherit this standard.
- The sensitive message in Arabic is harder than the English version, on purpose. Sensitive communications in Arabic carry register signals that translation consistently gets wrong — the level of formality, the way uncertainty is held, the phrasing that reads as respectful rather than bureaucratic. The only way to get this right is to author the Arabic version with the same deliberateness as the English, not to run the English through a tool and check if it sounds right.
- Terminology is consistent across documents. If the competency framework uses a specific Arabic term for “client success” or “account ownership,” the JD uses the same term — not a different one a translation chose. Inconsistency across documents is the sign of a translation workflow; consistency is the sign of authorship. Set the glossary now.
- The same rubric applies to both languages. An Arabic JD that doesn’t clearly separate must-haves from preferences fails the inclusive-JD rubric in Arabic. An Arabic sensitive message that buries the lede fails the message rubric in Arabic. The bilingual standard isn’t a separate easier bar — it’s the same bar, in both languages, which is what makes it a credible professional standard.
Your assignment
Build the three foundation documents for one role and one communication scenario — your own (recommended: the output is real infrastructure your hiring managers and people team use) or the sample company Mizan, a UAE-registered GCC bookkeeping SaaS at ~28 people, working through Series A growth. Open the folder with your inputs — your org chart, an existing JD, a draft of the message you need to send — in Claude Desktop, approve each read in the “Ask permissions” prompt, and work in the chat — no terminal needed.
Module 1 deliverable — the HR foundation
1. competency-framework.md (one to two pages)
- the role family and the three levels (e.g. Specialist / Senior / Lead)
- observable behaviors at each level — specific enough that two interviewers
score the same candidate the same way, no personality traits
- the observable jump between levels (what earns a promotion, in behaviors)
- the behaviors the JD's must-haves will trace back to
2. inclusive-jd.md (one page)
- opens with what the role actually does (the client outcome, not the company
mission statement)
- genuine must-haves — traces back to Senior-level behaviors in the framework
- genuine preferences, in a separate section, not framed as requirements
- no coded language; no requirements that weren't interrogated
3. sensitive-comms.md (one page)
- the point in the first paragraph — what's changing, what's not, what's
still being worked out
- uncertainty named honestly, not papered over
- written for the reader's clarity, not the sender's comfort
- short: every sentence earns its place
Bilingual teams: confirm the authoring standard with one section of the JD
and the first paragraph of the sensitive message authored in Arabic —
not translated; the register should be Gulf-natural.
The HR Foundation toolkit gives you a fill-in template for each of these and the prompts that build them, so you’re filling in structure, not staring at a blank page.
How it’s graded — the rubric
This is the part the free playbook doesn’t have, and the part that makes the credential mean something. Your three files are scored against five criteria. Each is meets / nearly / not yet — and “nearly” on any one is a revise, not a pass.
Foundation rubric
1. Competencies are Each behavior could be scored in an interview or
observable review. No competency is a feeling or a personality
trait. The jump between levels is named explicitly.
2. The JD widens the pool Genuine must-haves are separated from preferences.
No coded language. The role outcome is clear in the
first paragraph. Requirements trace to the framework.
3. The message says The reader gets the point in the first paragraph.
the thing No burying the lede. Uncertainty is named, not
papered over. Optimises for reader clarity.
4. The Arabic version Narratives authored (not translated), terms
reads native consistent with the framework's Arabic glossary,
register Gulf-natural. Same rubric, both languages.
5. The framework is the The JD's must-haves trace to Senior-level behaviors
source of truth in the competency framework. They are not two
independent documents that could contradict each other.
The discipline is deliberately what a senior people leader would demand: a foundation that’s vague, pool-shrinking, or evasive fails quietly — in the wrong hire, the contested promotion, the org-change that lost trust — so it has to be caught here.
The bar, shown — a worked model answer (Mizan)
You don’t have to guess what “meets” looks like. Here’s a passing excerpt for the sample company — yours doesn’t need to look like this, it needs to clear the same bar.
competency-framework.md — Mizan Customer Success (excerpt)
Role family: Customer Success
Levels: CS Specialist · Senior CSM · CS Lead
Senior CSM — observable behaviors
- Owns the success plan for 15–20 SMB accounts without being prompted;
updates it after every substantive client interaction.
- Flags renewal risk 60 days out with a specific recovery plan (the account,
the risk, the proposed action, the owner) — not a status update.
- Presents churn analysis to a founder in 10 minutes without preparation,
leading with the so-what, not the methodology.
- Runs the Arabic-language client relationship for their bilingual accounts
without escalation; notices when a client's tone has shifted before it
becomes a written complaint.
The jump from Specialist to Senior CSM
A Specialist manages the task (sends the QBR deck, logs the call, escalates
the issue). A Senior CSM manages the outcome: they own whether this account
renews, and they can name what's at risk and why two months before the date.
inclusive-jd.md — Mizan Senior CSM (excerpt)
What you'll do
You'll be the named owner for 15–20 UAE SMB clients — the person they call,
the person who knows their business, and the internal voice for what they
need. Your measure of success is renewal and expansion, and you'll see the
signals early enough to act on them.
Must-haves (genuine gates)
- 3+ years in a B2B SaaS customer success or account management role
- Bilingual Arabic / English — you'll run some client relationships entirely
in Arabic
- UAE-based — clients are in market and expect in-person availability
Preferences (not barriers)
- Experience with GCC SMB clients (you'll learn the market; we're not
filtering for it)
- Background in bookkeeping, accounting, or fintech (helpful, not required)
sensitive-comms.md — CEO to ops team, Mizan (excerpt)
Subject: how the ops team structure is changing
We've decided to change how the ops team is organised. This note explains
what's changing, what isn't, and what we're still working out.
What's changing: the ops team will no longer report as a single unit under
one head. From August 1st, finance ops and client ops will report separately —
finance to the CFO, client ops to the VP CS.
What isn't changing: your roles, your day-to-day work, and your team
relationships. You're not being split up; the reporting line is moving.
What we're still working out: the two roles that currently sit between the
teams — we haven't made those decisions yet and we'll communicate them by
July 31st. We won't make you wait past that date.
What you’ve proven — and what’s next
Clear the rubric and you’ve done something the free path can’t certify: you’ve built a real, professional-grade people foundation and demonstrated the judgment behind it. That’s the Foundation stage of “Certified People & HR with Claude.”
From here the track turns the foundation into a working people function, each module assessed the same way:
- Module 2 — the hiring engine: the interview synthesis and hiring system that turns the competency framework into a structured, defensible process — from first-round scoring to offer calibration.
- Module 3 — onboard and develop: the onboarding system and policy rewrite that gives a new hire a running start and keeps the team operating from documented standards instead of institutional memory.
- Module 4 — reviews and retention: the performance review cycle, the engagement survey, and the offboarding system that close the loop on growth, signals, and exits.
- Module 5 — org change and leadership: the org-change communication and change management layer that holds trust when the structure shifts — and the capstone, one org’s people cycle run end to end, graded into the certificate.
First, make what you built reusable. Grab the HR Foundation toolkit — the CLAUDE.md and the three templates that turn the documents you just wrote into files your whole team installs and inherits. And if you’re rolling this across a team, the People & HR operating guide is the data, privacy, and sign-off layer that goes underneath all of it.