Root cause analysis: getting past the first plausible answer
Root cause analysis works out why something went wrong deeply enough that fixing it prevents a recurrence. Its main difficulty is stopping too early, at an answer that sounds satisfying.
Most HR policy lists are written for organisations with an HR department. A company of fifteen needs a much shorter set — and needs each one to be short enough that people read it.
Search for HR policies and the examples you find are written for organisations with a compliance function and several hundred staff. A company of fifteen people needs a far shorter list, and needs each policy to be a page rather than nine — because a policy nobody has read has no effect except in a dispute, where it will be read very carefully indeed.
This is a starting set for a small company, with a note on what each one is actually for. It is not legal advice, and the required content of several of these is set by employment law where you operate rather than by convention.
Grievance and disciplinary procedures are the ones to get right first, and the ones where local law most often dictates the steps. They are also the only policies certain to be examined by someone hostile. Everything else can be improved gradually; these two should be correct from day one, and checked against the rules in your jurisdiction rather than copied.
A usable policy answers three questions in its first paragraph: who does this apply to, what do I have to do, and who do I ask. Most published examples answer none of them until page three, after a statement of commitment that exists to be quoted and does nothing else.
Length is not a proxy for rigour. A one-page expenses policy that states the limits, the evidence required and the payment date prevents more disputes than a six-page version that qualifies every sentence. The long version tends to be long because it was written to cover the author rather than to inform the reader.
Both work. A handbook reads better for new starters and is easier to hand over as one thing; separate policies are easier to update without reissuing everything and easier to point at in a specific conversation. The practical compromise most small companies land on is separate documents plus a short handbook that introduces them and links out.
What matters more than the shape is version control. Two versions of the sickness policy circulating, one in an old handbook and one in a shared folder, is worse than having neither, because both sides of a disagreement can produce a document supporting them.
Ettex Docs is the practical home for this: each policy as a document with the version history kept, comments for review before publication, and sharing so there is one address for the current version rather than copies in three inboxes. Duplicating an existing policy as the starting point for the next one is faster than beginning from a blank page.
It does not contain a policy library, and there is no jurisdiction-specific template to fill in. That is deliberate: employment law differs by country and often changes, and a generic policy that looks authoritative is worse than none, because it gets relied on. Draft against your own rules, and have anything with legal consequence reviewed by someone qualified in your jurisdiction.
Holiday and leave, sickness, expenses, code of conduct, and grievance and disciplinary. The last two are usually the most legally constrained.
A page for most. Length signals caution rather than rigour, and unread policies only take effect in disputes.
Either. Separate documents are easier to update; a handbook reads better for new starters. Many companies keep both, with the handbook linking out.
As a structural starting point, sometimes. As finished text, no — statutory content varies by jurisdiction and a plausible-looking policy will be relied on when it matters.
Annually, plus immediately after any incident the policy handled badly and whenever the underlying law changes.
Recording acknowledgement during onboarding is common practice and useful evidence. Whether it is required depends on local rules.
Write the policies people already ask you about, keep each to a page, get the grievance and disciplinary ones checked properly, and make sure only one version of each is in circulation.
Root cause analysis works out why something went wrong deeply enough that fixing it prevents a recurrence. Its main difficulty is stopping too early, at an answer that sounds satisfying.
A code of conduct says how people here are expected to behave and what happens when they do not. Its value is not aspiration — it is having decided the hard cases before one arrives.
A project charter names the objective, the boundaries, the sponsor and the person authorised to run the work. Its main use comes months later, when people disagree about what was agreed.