An employee handbook documents the policies, norms, and expectations of your company — from PTO and compensation philosophy to communication norms.
An employee handbook is the written record of how your company actually works — policies (PTO, expenses, IP assignment), norms (communication, meetings, documentation), and philosophy (compensation, career growth, decision-making). Great handbooks are read by candidates during interviews, referenced by new hires in week one, and updated when the underlying practice changes. Bad ones are 100-page legal boilerplate documents that were signed once at onboarding and never opened again.
Standard sections: (1) Company overview — mission, values, history. (2) How we work — communication norms, meeting culture, documentation standards, decision-making. (3) Compensation — philosophy, band structure, refresh cadence, promotion process. (4) Time off — PTO policy, holidays, parental leave, sabbaticals. (5) Benefits — health, retirement, learning stipends. (6) Legal — IP assignment, confidentiality, code of conduct. (7) Role-specific onboarding paths. GitLab and Basecamp handbooks are worth studying as reference points.
The handbook should be edited whenever practice changes — not on an annual review cycle. Companies where the handbook diverges from actual practice quickly lose the handbook's credibility. Editability matters: hosted in a wiki (Notion, Confluence, GitBook) with visible edit history, not a PDF locked in HR's Google Drive. Every employee should be able to propose edits via PR; leadership approves policy changes.
GitLab, Basecamp, and Buffer publish handbooks publicly. Benefits: recruiting differentiator (candidates self-select on culture fit), forces internal clarity (writing for public audience surfaces contradictions), builds industry trust. Costs: competitors read it too, some policies become negotiation anchors with vendors and candidates. For most companies, publishing selectively (values, how-we-work, without confidential specifics) captures most of the benefit.
(a) Stack-specific technical documentation — belongs in eng wiki. (b) Team-specific rituals — belong in team pages. (c) Aspirational statements about culture that don't match reality — actively harmful. (d) Every possible edge case codified as policy — over-specification signals low trust and slows judgment. Handbooks should describe principles and defaults; individual managers apply judgment for edge cases.
New hires should read the handbook in week one, structured with a checklist (not 'read this 100-page doc'). Common practice: 30-minute onboarding session walking through the philosophy sections, self-directed reading of the reference sections, first-week manager conversation about anything unclear. Track whether new hires actually complete this; unread handbooks signal a culture that talks about writing but doesn't practice it.
Investor directory · Fundraising library · Articles A–Z · Company funding database