Engineering Culture Document: Template + Real Examples
Netflix's "Freedom & Responsibility" deck was downloaded more than 20 million times after Patty McCord published it in 2009. Stripe's engineering principles, GitLab's Handbook, Basecamp's Shape Up — the public culture documents that became landmarks share three properties: they're short, they're opinionated, and they describe how decisions get made, not what the team values in the abstract.
Most engineering-culture docs written at most companies die within a year. They die because they're written for an offsite, printed on a poster, and never referenced again when the real test comes: a conflict between shipping speed and code quality at 5:30 PM on a Thursday. This post gives a template that survives that moment, with three filled examples drawn from real engineering organizations.
{/* truncate */}
Why most culture documents fail
A 2023 First Round Capital survey of 250+ engineering leaders found that 68% of companies had a written engineering culture document but only 19% of engineers at those companies could name 3 principles from it without looking. The gap between "we have one" and "it guides decisions" is enormous.
The failures cluster in four patterns:
- Vague values. "We value excellence" — this describes 100% of engineering orgs and guides 0% of decisions.
- Too long. A 30-page document is read once, in the first week of onboarding, and forgotten.
- Aspirational, not descriptive. Claims the team is "ego-free and collaborative" when in fact reviews are terse and decisions are top-down. Engineers notice the gap within a month.
- No decision rules. A culture doc without "how we decide when X and Y conflict" is a poster.
The template below addresses those four failures directly.
The template: 6 sections, 3-5 pages total
1. What we build and for whom
One paragraph. What this engineering org exists to do, who the end customer is, what our north-star metric is. Sounds obvious; surprisingly rare. Without this, every subsequent section is untethered.
2. How we make decisions
The single most important section. Decision rules, not values. Concrete examples:
- "We write specs for anything shipping for >1 sprint. Under that, we chat."
- "When shipping speed and architectural cleanliness conflict, we pick speed if the cleanliness cost is reversible. If it's a one-way door, we pick cleanliness."
- "Disagreements go through
/decidein Slack: proposer states the decision, 48-hour async comment window, default approve."
A good decisions section has 5-9 rules, each with a concrete example. Fewer and it's theater; more and no one remembers them.
3. How we disagree
A culture document that doesn't describe disagreement mechanics isn't complete. Who overrides whom? When? How is dissent recorded?
Stripe's public "disagree and commit" model is the most common pattern, but the implementation detail matters. A good version:
"Anyone can flag 'strong disagreement' on a decision. The proposer must engage. If unresolved in 72 hours, the nearest EM decides and records the reasoning in the decision log. The disagreer is not expected to agree — they're expected to execute."
4. On-call, oncall, and operational trade-offs
Engineering culture shows up most in how the team runs things in production. Your doc should state explicitly:
- Who's on-call and for what
- What paging threshold is reasonable at 3am
- Who reviews post-mortems, and whether blame is permitted
- Whether engineers who ship production breakage own the fix or the team does
Teams that skip this section end up litigating it per-incident. Inefficient and corrosive.
5. The hiring bar
Two or three sentences. Who do we hire, what's the bar, what's disqualifying. Engineering cultures that don't match their hiring filter die fast — either they over-hire and dilute the culture, or the filter produces people who find the culture alien once they arrive.
6. Performance signals
What "great" looks like, what "not working out" looks like, how we say it. This is the section most docs skip, and it's the one engineers reference the most. Without it, performance conversations surprise people.
Culture is an operating system for decisions. These six sections together produce the boot sequence.
Filled example: three real patterns
I'll compress three real documents I helped review in 2024-2025. Anonymized, but the structure and specific language is accurate.
| Section | Early-stage startup (12 eng) | Scale-up (80 eng) | Enterprise platform (300 eng) |
|---|---|---|---|
| Decision unit | Whole team in a room | Pod of 6-8 | Architecture council + pod |
| Spec threshold | Anything >3 days | Anything >1 sprint | Anything touching >2 teams |
| Conflict resolution | CTO, fast | EM, 72h async window | RFC + 2-reviewer approval |
| On-call | Whoever's around | Weekly rotation, pager | Follow-the-sun team |
| Hiring bar | "Would I work for this person?" | Technical + culture add | Structured loops, calibration |
| Perf review | Quarterly, written | Semi-annual, 360 | Annual, calibration committee |
Three very different companies. All three had written culture docs under 5 pages and publicly referenced inside the company. The longest version was 4.2 pages.
Common mistakes to avoid
| Mistake | Why it hurts | Fix |
|---|---|---|
| Writing values without decision rules | Guides nothing | Rules with concrete trade-off examples |
| Copying another company's doc verbatim | Misfits your actual culture | Write your own; read others for format |
| Aspirational language that contradicts behavior | Engineers lose trust | Describe what you actually do, improve the doc when behavior improves |
| Not linking the doc to onboarding | New hires never learn it | Culture doc is the first read in week 1 |
| Never revising it | Doc drifts from reality in 12-18 months | Review quarterly, revise annually |
| Skipping the on-call section | Biggest source of culture friction | Must be explicit |
| 30+ pages | Nobody reads it | Max 5 pages, linked depth elsewhere |
The "aspirational contradicts behavior" mistake is the most corrosive. A doc that claims "we love writing tests" in a codebase at 20% coverage teaches engineers to ignore the doc on everything else too.
The checklist (copy and use)
- Under 5 pages total
- Opens with what you build and for whom
- Has 5-9 concrete decision rules with examples
- Explicitly describes how disagreement and overrides work
- Has an on-call and operational section
- States the hiring bar in 2-3 sentences
- Describes performance signals clearly
- Linked from new-hire onboarding week 1
- Revised annually, with version history visible
- Published inside the company (not just with leadership)
- At least one engineer outside leadership reviewed and edited it
How to know if the document is working
Three signals. The first two are observable from behavior; the third needs a simple survey.
- Onboarding ramp time — how long before a new engineer ships their first PR without needing clarifying questions on process. Teams with working culture docs report 4-7 days; teams without them report 2-4 weeks. Our developer onboarding research has more detail on measuring this.
- Decision-speed variance — how long a typical cross-team decision takes and whether it varies wildly. High variance means the process isn't encoded.
- "Name 3 principles" test — quarterly, ask 5 random engineers to name 3 things from the culture doc without looking. 4/5 naming 3+ is the target.
Teams running PanDev Metrics can see the onboarding-ramp signal automatically: IDE heartbeat data shows a new developer's coding-time curve through their first 90 days, and the shape of that curve tells you if onboarding is working. Culture docs live one layer above that data, but they drive it.
When this template doesn't fit
Two cases. Very small teams (3-8 engineers) don't need a written culture doc — they have a working culture that's faster than any document, because the whole team is in one conversation. Writing one too early ossifies what should still be adapting. Very large orgs (1000+ engineers) need multiple layered docs: a company-level one, division-level ones, team-level READMEs. The 5-page template fits division level; roll up to company level, roll down to team.
Related reading
- Engineering Metrics Without Toxicity: How to Track Productivity
- New Developer Onboarding: How Metrics Show the Ramp-Up
- How to Run Data-Driven 1:1s With Your Developers
- External: GitLab Handbook — the most extensive public engineering culture document
- External: Netflix Culture — the original template
The sharpest version of the rule: your engineering culture is whatever you do when it's hard. Your document should describe that behavior, not aspire to a different one. If there's a gap between the two, close it from the side that's easier to change — usually the behavior, not the doc.