Engineering Culture
Building a learning organization where people do their best work.
Foundational Principles
Psychological Safety (Google Project Aristotle #1 Factor)
"Team members feel safe to take risks and be vulnerable in front of each other."
Signs of safety: - Admitting mistakes without fear - Asking "stupid" questions - Challenging decisions respectfully - Sharing half-formed ideas - Saying "I don't know"
Leadership behaviors: - Model vulnerability: "I was wrong about..." - Reward candor: "Thanks for catching that" - Respond to failure with curiosity, not blame - Explicitly invite dissent: "What are we missing?"
Blameless Post-Mortems
Process
- Timeline — What happened? (Facts only, no judgment)
- Impact — Who/what affected? How severe?
- Root Cause(s) — Systemic factors (not "human error") - "Engineer forgot to run migration" → "Deployment process lacks automated migration guard" - "Config typo" → "No config validation in CI; manual process"
- Action Items — Specific, owned, dated - Prevent recurrence (fix the system) - Improve detection (alerting, monitoring) - Reduce impact (rollback, feature flags)
Anti-Patterns
- "Action item: Be more careful" — Not actionable
- "Action item: Training" — Band-aid on process gap
- Blaming individuals — Destroys safety; hides systemic issues
- Skipping post-mortem for "small" incidents — Missed learning
Cultural Shift
From: "Who broke it?" → To: "What allowed it to break?"
Learning Organization Practices
1. Regression Tests for Every Bug
- Bug found → Write failing test → Fix → Test passes
- Prevents same bug returning
- Documents expected behavior
2. Code Review as Learning (Not Gatekeeping)
- Critique code, not people
- Ask questions: "What does this do?" vs "This is wrong"
- Share context: "This pattern handles X edge case"
- Approve with suggestions: "LGTM; consider extracting this..."
3. Explicit Risk Acceptance
- Document known risks (tech debt, shortcuts)
- Assign owner + review date
- Visible in backlog / risk register
- Not hidden in tribal knowledge
4. Visible Tech Debt
- Track in backlog with "tech-debt" label
- Quantify impact (slow builds, manual steps, bugs)
- Allocate capacity (e.g., 20% per sprint)
- Celebrate paydown
5. Written Record = Institutional Memory
- Commit messages — For the investigator 6 months later
- ADRs — For architectural decisions
- Runbooks — For operational procedures
- Meeting notes — Decisions + rationale + action items
"If it isn't written down, it didn't happen."
Failure as Normal
Design for Failure
- Timeouts + retries with exponential backoff + jitter
- Idempotency — Safe to retry
- Circuit breakers — Fail fast, prevent cascade
- Bulkheads — Isolate failures
- Graceful degradation — Reduced function > total outage
Error Budgets (SRE)
- Define SLO (e.g., 99.9% availability)
- Error budget = 1 - SLO
- Spend budget on releases — If budget exhausted, freeze releases
- Aligns dev velocity with reliability
Test Recovery Before You Need It
- Chaos engineering (GameDays)
- DR drills (quarterly)
- Runbook validation
- "What if this dependency goes down?"
Team Practices
Small Batches
- Small PRs (<400 lines ideal)
- Small commits (single logical change)
- Small deployments (single feature/fix)
- Smallness is the recurring superpower
Fast Feedback
- CI < 10 minutes
- Local dev environment ≈ production
- Feature flags for incomplete work
- Automate everything repeatable
Explicit Workflows
- Visualize work (Kanban board)
- Limit WIP (stop starting, start finishing)
- Clear Definition of Done
- Explicit policies per column
Respect for People
- 40-hour week sustainable pace
- No heroes — Heroics mask process problems
- On-call — Fair rotation; compensated; actionable alerts only
- Career growth — Explicit ladders; mentorship; learning budget
Decision Making
Two-Way Door Decisions (Reversible)
- Make quickly; try; learn; iterate
- Most decisions are two-way
- "Disagree and commit" — Voice dissent, then support
One-Way Door Decisions (Irreversible)
- Slow down; gather data; involve stakeholders
- Document in ADR
- Examples: Database choice, cloud provider, core framework
Decision Log
- Every significant decision recorded
- Context + alternatives + rationale
- Review periodically: "Does this still hold?"
Metrics That Matter (DORA + Team Health)
| Category | Metric | Elite Target |
|---|---|---|
| Delivery | Deployment frequency | On demand |
| Delivery | Lead time for changes | < 1 hour |
| Stability | Change failure rate | < 15% |
| Stability | MTTR | < 1 hour |
| Team | eNPS | > 30 |
| Team | Burnout indicators | Low |
| Team | Learning time | > 10% capacity |
Cultural Anti-Patterns
| Anti-Pattern | Symptom | Fix |
|---|---|---|
| Blame culture | People hide mistakes | Blameless post-mortems; focus on system |
| Hero culture | Same people always save the day | Reduce bus factor; automate; share knowledge |
| Meeting overload | No time for deep work | Async-first; meeting budgets; maker schedules |
| Silos | "Not my job" | Cross-functional teams; shared ownership |
| Technical debt denial | "We'll fix it later" (never) | Visible debt; allocated capacity; celebrate paydown |
| Decision paralysis | Endless debate | Two-way door default; time-box decisions |
| No psychological safety | Silence in meetings; no questions | Model vulnerability; reward candor; invite dissent |
Scaling Culture
As Organization Grows
| Size | Culture Mechanism |
|---|---|
| < 10 | Implicit; daily interaction |
| 10-50 | Explicit values; written practices; all-hands |
| 50-200 | Team-level autonomy; communities of practice; guilds |
| 200+ | Platform teams; enabling teams; explicit org topology |
Culture Carriers
- Engineering managers — Model behaviors; coach teams
- Staff/Principal engineers — Technical leadership; cross-team influence
- Tenured engineers — Oral history; mentor newcomers
- Onboarding — Culture immersion from day 1
Related Notes
- Team Topologies — Team structure for flow
- Agile Principles — Agile values and practices
- Test Pyramid — Testing as quality culture
- CI CD Best Practices — Automation culture
- Architecture Decision Records — Decision culture
- Documentation Principles — Documentation culture
Sources: Google Project Aristotle, Accelerate (Forsgren/Humble/Kim), Site Reliability Engineering (Google), Team Topologies, The DevOps Handbook, Blameless Post-Mortems (Etsy, Google), Psychological Safety (Amy Edmondson), DORA State of DevOps Reports