Onboard & develop: the 30-day plan and the policies people actually read

Your team already has the new-hire onboarding and policy plain-language playbooks — the worked recipes for building a first-week checklist and turning one policy into something a new hire can read. This module is the layer above the recipe. It’s where you master the two documents that determine whether a new hire actually succeeds and whether the rules your team operates under are real ones — build them for your own hire and your own policy, and prove, against a real rubric, that you can.

It’s Module 3 of the certifiable People & HR track, and it builds directly on the competency framework you built in M1. The 30-day plan is only as good as the competency framework it inherits from.

Onboarding fails quietly. The new hire’s calendar is full, they’ve met everyone, the Notion page has forty links — and on day sixty you discover they’ve been afraid to ask the question they’ve had since day three. A plan that works isn’t full; it’s specific. It tells one person what they’re supposed to know by the end of week one, what they’re supposed to be able to do by day thirty, and what the moment is when you’ll both know whether they got there. That’s a different document than a calendar. And a policy that nobody reads isn’t a policy — it’s a liability that looks like one.

Why the 30-day plan is the start of the performance record

The failure mode of onboarding is the information dump. A stack of Notion pages, a week of coffee chats, a walkthrough of the product — and then the new hire is “set up.” The problem isn’t that those things are wrong; it’s that they’re not a plan. A plan has outcomes, not events. It answers: what should this person know by the end of week one that they didn’t know at the start? What should they be able to do by day thirty — specifically enough that you and they both know whether they did it? What is the moment when you’ll find out?

The craft of the 30-day plan is exactly that specificity:

• Week 1 controls overwhelm. A new hire’s first week should have a short list of people to meet, a short list of things to read, and a short list of tasks — not all of everything. The judgment is that understanding the top ten client profiles by Friday matters more than attending every standing meeting this week. The deliverable for week one is not “settling in” — it’s being able to tell their manager the three things they’re most confused about, which is a real thing and an assessable one.
• Day 30 has an assessable moment. “Settling in by day 30” is not a milestone. “Leads a solo onboarding call for one new client without a shadow” is. The difference is that the second one can be evaluated — it happened or it didn’t, it went well or it didn’t, and the how-it-went is the data for the first review conversation. This is the connection to M1: the 30-day plan is the opening of the evidence base, not a separate thing from the competency framework. If M1 said “relationship management” is a core competency for this role, the day-30 milestone should demonstrate it.
• The 90-day arc connects to the role. The 30-day plan sits inside a 90-day arc. Week one is controlled introduction; the end of month one is a solo moment; the end of month three is the question of whether this person is performing at the level the role requires. The plan sets the arc so nothing about the first review is a surprise — it was visible from day one.
• The plan is what Claude inherits. Feed onboarding-plan.md into any manager conversation, any check-in, any review prep, and Claude applies your milestones, not a generic onboarding template. The document makes the intent explicit so it can be reused, adapted for the next hire, and handed off when the manager changes.

The first-week design — controlling overwhelm without abandoning the new hire

The first week is the highest-leverage week of the entire employment relationship, and it is almost universally done wrong. The common failure is the opposite of abandonment: it’s saturation — every team does an intro call, every process gets a walkthrough, every tool gets a login — and by Thursday the new hire can remember none of it and hasn’t done anything yet. A first week designed by the hiring manager who wants to be helpful produces a new hire who is politely overwhelmed.

A first week that works is designed, not assembled:

• Name the three things that matter most this week. For a new CSM at a bookkeeping SaaS, week one is not “meet everyone.” It’s: understand who the clients are (read the top-ten profiles), understand the CS team’s current division of labor (meet the two existing generalists, not the whole company), and understand the one rule that makes everything else safe (read the client data policy — because this person now has access to client financial records). Everything else waits.
• Protect the new hire from the company’s eagerness. Every team wants face time with the new hire in week one. The manager’s job is to say no on behalf of the new hire. A new hire who spends every hour in introductions has no time to think, and the questions they’re not asking because they don’t want to look ignorant in front of the tenth person they just met are the questions that will bite in week three.
• The Friday debrief is the deliverable. A check-in on Friday of week one — “tell me the three things you’re most confused about” — is not a kindness. It’s the data collection that prevents a sixty-day drift. It’s also assessable: a new hire who can name three specific things they’re confused about is engaged; one who says “it’s all good” either isn’t confused yet (which means week one was too light) or is afraid to say (which means the culture is the problem, and you learn it now, not on day sixty).

The policy rewrite — specific rules versus aspirational principles

Most policies fail for the same reason: they were written by lawyers to be legally defensible, not by people managers to be operationally followed. “The Company shall maintain strict protocols pertaining to the handling and processing of client-originated data” is not a rule — it’s a commitment to have rules. A new hire reads it, nods, and has no idea whether forwarding a client’s invoice to their personal email to work from home is against policy or not. (It is. The policy just doesn’t say so.)

The judgment of the policy rewrite is threefold:

• Strip every “shall” and replace it with the actual rule. “The Company shall ensure…” means nothing unless you say what it ensures. “Client data never leaves the Mizan platform” is a rule. “Client data is subject to applicable data protection measures” is a principle. Every sentence in the policy should be testable: a new hire in a specific situation should be able to read it and know what to do without asking anyone.
• Lead with what the policy protects, not the legal obligation. The most effective first sentence of a confidentiality policy is not a definitions section — it’s the reason the rule exists: “This policy keeps your clients’ financial data from leaking. That matters because a leak damages the client’s business and ends Mizan’s reputation.” A new hire who understands what they’re protecting follows the rules more reliably than one who was handed a compliance document.
• Know which changes are cosmetic and which change meaning. Replacing “shall” with the present tense is cosmetic — it sharpens the sentence without changing the rule. Removing a sentence because it’s repetitive might delete a rule that was there for a reason. Changing “client-originated data” to “client data” might narrow or broaden scope depending on the original intent. The craft of using Claude for a policy rewrite: let Claude rewrite fast; read every change for whether it altered a rule rather than just a sentence. Flag any change that altered meaning for a legal review before the policy ships. This is the human judgment that makes the rewrite safe.

The bilingual standard — a policy only half the team can read is a policy that doesn’t work

A policy that exists in English only in a UAE-based team where a significant portion of the staff reads Arabic first is not a policy that works. It’s a policy that the English-fluent half of the team is bound by and the Arabic-first half of the team technically signed but didn’t absorb. That’s a legal document, not an operational one.

The bilingual standard for this module is the same one the Finance & Ops track sets for board narratives — author, don’t translate — and for a client data policy it has specific edges:

• The Arabic version is written, not run through a translation tool. A translated policy reads like a translated policy — the register is off, the sentence structures are calques, and a native Arabic reader registers the inauthenticity immediately. The Mizan team is UAE-based; the policy language should feel like something a Mizan manager would actually say to a colleague, not like a legal document that was fed through a machine. The rule is that the Arabic version is authored from the intent of each rule, not from the English sentence.
• The technical terms stay in English. “Client data,” “Mizan platform,” “VAT filing,” “payroll data” — these stay in English in the Arabic version, because they are proper nouns in the context of this team. A policy that translates “the Mizan platform” into Arabic is harder to follow, not easier. The bare-English-keyword convention applies: technical terms, product names, and role titles stay in English; the rest of the sentence is natural Arabic.
• The one-page constraint holds in Arabic too. A policy that’s one page in English and three pages in Arabic because the translation is verbose is a translation, not an authored version. Arabic prose can be concise. The discipline of one page — every rule specific, nothing aspirational — applies in both languages.
• A new hire who joins without Arabic fluency gets the English version; a new hire who joins without English fluency gets the Arabic version; both versions say the same thing. This is the test: read a rule in each version and confirm it produces the same behavior in the same situation. If the Arabic version is vague where the English is specific, the rewrite isn’t done.

Your assignment

Build the two documents for one real hire in one real role — your own (recommended: you get infrastructure your team inherits) or the sample hire Rania Al-Khaldi, Mizan’s new Senior CSM whose first 30 days are worked through this module. Open your role context — the job description from M2, the competency framework from M1, the relevant policies — in Claude Desktop, approve each read in the “Ask permissions” prompt, and work in the chat. No terminal needed.

Module 3 deliverable — onboard & develop

1. onboarding-plan.md  (one page per section)
   - Week 1 in detail: the three things to know, the three people to meet,
     the two things to read, the Friday debrief prompt
   - Weeks 2–4: one milestone per week, stated as a specific outcome
     not a list of activities
   - Day-30 moment: one assessable event (a solo call, a delivered output,
     a presented reflection) that tells you and the new hire whether they
     got there
   - The connection to M1: name the competency-framework element each
     week-1 focus and day-30 moment maps to

2. [policy-name]-rewrite.md  (one page maximum)
   - Every rule specific and actionable — a new hire could make a decision
     from it without asking
   - No "shall" / "is required to" / "applicable regulations" — the actual
     rule in plain language
   - Lead sentence: what the policy protects and why it matters
   - Flag (in a comment or footnote, not in the policy body): any sentence
     where you changed a rule's meaning and why a legal check is needed
     before shipping

Bilingual teams: both documents in Arabic, authored not translated. Every
rule in the Arabic version produces the same behavior as the English.
Technical terms (product names, role titles, data categories) stay in English.

The M1 competency framework from Module 1 is load-bearing here — the day-30 milestone should name the competency it demonstrates. If you haven’t completed M1, do it first.

How it’s graded — the rubric

Your two files are scored against five criteria. Each is meets / nearly / not yet — and “nearly” on any one is a revise, not a pass.

Module 3 rubric

1. The plan has a milestone      Not a calendar of meetings. Each week has
   structure                     a specific outcome, and day 30 has an
                                 assessable moment — it happened or it
                                 didn't, and you'll both know.

2. The plan traces to the        The 30-day goals are the beginning of the
   competency framework          evidence base for the first review. M1 is
                                 load-bearing: name the competency each
                                 milestone demonstrates.

3. The policy is specific        Every rule is a rule, not a principle.
                                 A new hire in a specific situation could
                                 make the right call without asking anyone.

4. No meaning was changed        The plain-English version keeps every rule
   in the rewrite                the original had. A legal reviewer could
                                 confirm no content was lost or altered.
                                 Changes that altered meaning are flagged.

5. Both documents are bilingual  Arabic versions authored, not translated.
                                 Every rule produces the same behavior in
                                 both languages. Technical terms in English.

The discipline is what a Head of People at a Series A company would demand: an onboarding plan that makes a new hire’s first 30 days legible — to them and to their manager — and a policy that a new hire actually reads, understands, and follows because every rule is clear enough to act on.

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.

onboarding-plan.md — Rania Al-Khaldi, Senior CSM, Mizan (excerpt)

Week 1 — Orientation (outcome: Rania knows the three things that matter most)
  People to meet
    - Omar (manager) — day 1, set expectations and communication rhythm
    - Tariq and Hana (the two CS generalists) — day 2, understand current
      division of clients and the informal knowledge they hold
    - The finance team lead — day 3, brief (these are Rania's primary internal
      clients; she should know who they are, not everything they do)
  Things to read
    - The client data & confidentiality policy (she has read-access to client
      financials as of day 1 — this is not optional)
    - The top-10 client profiles: industry, size, which features they use,
      any known friction points
  Things NOT to do this week
    - No solo client calls
    - No ownership of any open support tickets
  Friday debrief with Omar
    "Tell me the three things you're most confused about."
    This is a deliverable, not a check-in. Rania should come with three
    specific things, not "it's going well."

Weeks 2–4 milestones
  Week 2: Shadow Tariq and Hana on two live client calls each. Debriefs
           after each: what question came up, how was it handled, what
           would Rania have done differently?
  Week 3: Co-lead one onboarding call with Tariq (Rania leads the intro and
           the product walkthrough; Tariq handles anything unexpected).
  Week 4: Prepare a one-page overview of the three renewal risks she sees in
           the current client portfolio, based on the client profiles and
           the shadows.

Day-30 milestone (assessable)
  Lead a solo onboarding call for one new Mizan client: < 5 employees,
  low-complexity bookkeeping setup, no active disputes.
  Present a 10-minute 30-day reflection to Omar:
    - Three things learned
    - Three things still unclear
    - First three renewal risks she'd flag in the current portfolio

Competency-framework connection (M1)
  Week 1 → Product knowledge (the foundational competency; no relationship
             management is possible without it)
  Week 3 → Client communication (first assessed moment of the core CSM skill)
  Day 30 → Renewal risk identification (the commercial competency that
             distinguishes a Senior CSM from a generalist)

client-data-policy-rewrite.md — Mizan (excerpt)

What this policy protects
  Mizan's clients trust us with their financial records — VAT filings,
  invoices, payroll data, bank account details. A leak damages the
  client's business and ends Mizan's reputation. This policy is how
  we make sure that never happens.

What counts as client data
  Any financial record, invoice, payroll figure, VAT return, or bank
  detail belonging to a Mizan client — whether it's in the platform,
  in a support ticket, or in a conversation with the client.
  If you're not sure whether something is client data, it is.

Where it lives
  Client data stays in the Mizan platform and in Mizan's approved
  internal tools. The full list is in the internal tool registry
  (link). If a tool isn't on that list, it doesn't touch client data.

What never happens
  - Client data never goes into a personal email account.
  - Client data never goes into a personal cloud folder (Google Drive,
    Dropbox, iCloud, or similar).
  - Client data is never shared with a third party without written
    approval from the client and sign-off from the CEO.
  - Screenshots of client financial data are never sent in WhatsApp,
    Telegram, or any messaging platform, including internal ones.

Who is responsible
  Every Mizan employee with platform access is responsible for following
  this policy. The Head of People owns the policy; the CEO approves
  any exceptions. There are no exceptions for convenience.

---
[Flagged for legal review before publishing: the third bullet under
"What never happens" changed "prior written consent" to "written approval
from the client and sign-off from the CEO" — confirm this matches the
intent of the original clause and the UAE data protection requirements.]

What you’ve proven — and what’s next

Clear the rubric and you’ve built two things that your team will use beyond the module: an onboarding system with real milestones, and a policy that a new hire actually reads and follows. The credential you’re earning is “Certified People & HR with Claude” — and Module 3 is where the track turns from hiring into the full lifecycle of developing the people you hire.

From here the track moves into the conversations that determine whether people stay and grow:

• Module 4 — the first review: the performance conversation structure, the evidence base you started building in M1 and M3, and how to use Claude to prepare a review that’s specific, fair, and useful — not a surprise in either direction.
• Module 5 — the difficult conversation, Module 6 — team design and role architecture, then the capstone — one complete hiring-to-review cycle for one role, graded into the certificate.

If you’re rolling this across a team, the operating guide is the data, privacy, and approval layer that goes underneath all of it — the People & HR equivalent of the finance controls doc, covering what Claude is allowed to see, who approves what, and how you keep sensitive HR data inside your workspace.