Airbnb Staff Site Reliability Engineer Interview Preparation Guide

Direct answer
Put the ask, the essential context, and the next step in the first two sentences, so a busy reader can act on the email even if they only read the opening before deciding whether to reply now or later.

Structured elaboration

1. State the ask as the first sentence, not buried after several paragraphs of context: "I'd like to request temporary access to X" or "Could you approve Y by Thursday?"
2. Give only the essential context, one or two sentences of why this ask exists, not the full backstory. Include it because it makes the ask easier to say yes to quickly, not because it's interesting.
3. State the next step explicitly: what you need them to do, and by when, so they don't have to infer the deadline or the required action.
4. Use the subject line to state the ask, not just the topic: "Approval needed by Thursday: Q3 budget line" tells the reader more than "Budget question."
5. Keep the whole email short. If the request genuinely needs more context, put the essential ask up top and the detail below it, rather than making the reader wade through detail to find the ask.

Worked example
Subject: "Access request: prod DB read access, needed by Wednesday"

Body: "Could you grant me temporary read access to the orders table in prod? I'm investigating a customer-reported data discrepancy (ticket #4821) and need to check actual row values, which I can't do in staging since the issue only reproduces with real production data. Happy to have this access time-boxed to a few days and revoked afterward if that's easier to approve."

The ask (temporary read access) and the deadline context (needed by Wednesday) are in the subject line alone; the body confirms the specific ask, gives the minimum context needed to approve it, and proactively offers a constraint (time-boxed) that makes approval easier.

Trade-offs and pitfalls

• Leading with a long justification before the ask is the single most common failure; a reader has to hold the whole paragraph in their head waiting to find out what you actually want.
• Too little context can also fail: an ask with zero justification can force the reader to ask a clarifying question back, which is slower than including the one sentence of context that would have let them approve it immediately.
• For sensitive or high-stakes asks (a large budget approval, access to something risky), a slightly longer, more carefully justified email is worth the extra length; the "front-load the ask" principle still applies, it just means front-loading a well-justified ask rather than skipping justification entirely.

Direct answer

Persuading a skeptical stakeholder starts with diagnosing what kind of resistance you're actually facing, since the same "here's more data" response only works on an evidence-based objection. A political objection or a loss-of-control objection needs a different tactic entirely.

Structured elaboration

Objection taxonomy. Naming the type of resistance before choosing a tactic is what separates a senior answer from "I showed them more data":

Worked example

Situation. At a product org, a UX team relied on manual review of every design change against brand guidelines. A design systems lead proposed an automated linting check for a subset of mechanical rules. One senior designer resisted far more strongly than the proposal's scope seemed to warrant.

Stakes. The designer's review was a required approval gate; without their buy-in, adoption could be blocked or slow-walked indefinitely, regardless of how good the tool was.

The influence moves.

• Noticed the resistance didn't track with the evidence: false-positive-rate numbers didn't move the reaction at all, which was the signal something else was going on.
• Asked directly what was underneath the resistance, and learned it wasn't about accuracy: automating the check felt like it removed the designer's voice and shrank their judgment role.
• Reframed the proposal to preserve their say explicitly: the linter would catch only mechanical rule violations (spacing, contrast ratios), routing anything subjective to the designer's review, unchanged.
• Gave the designer a visible role in defining which rules counted as mechanical versus subjective, turning them from a blocker into the rule-owner.

Resolution. The designer became the tool's internal champion once their judgment role was made explicit rather than replaced.

What a senior candidate does differently. Doesn't try to win a trust objection with more data. A mid-level answer keeps citing the false-positive rate; a senior candidate diagnoses the objection type first and matches the tactic to it.

Trade-offs and pitfalls

• Misdiagnosis wastes your strongest tool. Aiming data at a political or trust objection wastes the one resource that can't solve that problem, and can read as tone-deaf to the stakeholder.
• Political objections sometimes can't be fully resolved through the stated concern, because the real driver is unstated. A senior candidate says plainly when they suspect this is happening rather than pretending the objection was purely rational.
• Preserving a role is not the same as granting a veto. The trade is scoping what the stakeholder keeps control over, not surrendering the decision.

Direct answer

Within a single region, 3 AZs give you low-latency, redundant links (typically sub-2ms), so placing 5 nodes as 2-2-1 across the AZs lets you lose one whole AZ and still have a majority (3 of 5) reachable to keep accepting writes. Across two regions you cannot split 5 nodes evenly, so one region ends up holding the majority (3-2), and the region with only 2 nodes can never reach quorum on its own. Split-brain avoidance is the same rule in both cases (only the side that can prove it holds a majority may accept writes), but the two-region case carries a real risk that someone fails the minority side over anyway during a long partition, which is how split-brain actually happens in practice.

Structured elaboration

Single-region, 3-AZ placement (e.g., 2-2-1):

• AZ-to-AZ links are low-latency and rarely fully partition from each other (same region, redundant fiber paths).
• Losing one AZ still leaves 3 of 5 nodes reachable, so majority quorum holds and writes keep flowing.
• This mainly defends against a single AZ outage (power, networking gear), not against a true network split.

Two-region placement (e.g., 3-2):

• The region holding 3 nodes always has majority quorum by itself; the region with 2 never does.
• If the inter-region link drops, the 2-node region correctly refuses writes (it can't reach quorum) while the 3-node region keeps serving. That is the safe outcome, but it means the minority region's healthy nodes go write-unavailable.
• The dangerous failure mode is a human or an automation script promoting the minority region to "keep serving" during the partition. That creates two sides independently accepting writes, i.e. split-brain, and the divergence has to be reconciled or discarded once the link heals.

Why this is mostly an operational risk, not a protocol risk: consensus protocols like Raft already refuse to commit without a majority, so the protocol itself prevents split-brain as long as nobody forces an override. The real risk is a health check or runbook that misreads "can't reach the majority" as "the majority must be down" and promotes the wrong side.

Worked example

With N=5, majority is ceil((5+1)/2) = 3 nodes. In the 2-2-1 AZ layout, losing any single AZ still leaves at least 3 nodes across the remaining two AZs, so quorum holds. In the 3-2 region layout, if the WAN link between regions fails, the 3-node region has quorum (3/5, can elect a leader and accept writes) and the 2-node region does not (2/5, must reject writes and serve stale reads at best) until the link recovers.

Trade-offs and pitfalls

• Multi-region protects against a whole-region outage that multi-AZ cannot, but it adds real commit-path latency (cross-region round trips) and makes the minority-region-unavailable outcome unavoidable with an odd node count split unevenly.
• A common mistake is assuming a 3-2 region split protects both regions equally. It does not: only the 3-node region can survive a partition alone.
• An even split (e.g., 4 nodes as 2-2 across two regions) is worse, not safer: neither side can reach majority alone, so both stop accepting writes, or someone bolts on a tie-breaker node that becomes a new single point of failure.
• Overly aggressive health-check timeouts can misread a slow but healthy cross-region link as a partition and trigger an unnecessary failover, which is why managed cross-region services (e.g., Aurora Global Database) use deliberately conservative promotion procedures rather than fast automatic failover.

What the interviewer probes next

Expect a follow-up on what happens to writes that were in flight on the minority side when the partition started, and whether you'd ever choose an even node count.

The core design decision is a two-level key: shard by a hash of the series identity so writes and label lookups distribute evenly, and chunk by time within each series so both compression and range queries stay efficient. Everything else (indexing, downsampling, compression) hangs off that.

Data model

Each sample is (metric_name, labels, timestamp, value). In practice you don't store metric_name and labels as free strings per sample; you compute a SeriesID once per unique combination:

and every sample after that is just (SeriesID, timestamp, value). The label set is stored once in a separate series-metadata record, not repeated per sample.

Partitioning and chunking

flowchart LR
  A[Sample Ingest] --> B[Hash by SeriesID]
  B --> C[Shard 1]
  B --> D[Shard 2]
  B --> E[Shard N]
  C --> F[Head Block: in-memory chunk]
  F --> G[Flush to Durable Chunk]
  G --> H[Inverted Label Index]
  G --> I[Block Storage]
  H --> J[Query: label lookup]
  I --> J

• Partition key: (time_window, shard_id) where shard_id = hash(SeriesID) mod N. Time-first partitioning means old partitions become immutable and can be compacted/downsampled/expired independently; sharding by SeriesID hash inside each time window spreads a hot series's neighbors across nodes instead of colocating them.
• Chunking: each series appends to an in-memory "head" chunk, flushed to a durable, compressed chunk when it hits either a time bound (e.g., 2 hours) or a size bound. Chunk metadata (SeriesID, start/end timestamp, min/max value) lets a query prune whole chunks without decompressing them.
• Compression: delta-of-delta for timestamps, XOR (Gorilla-style) for values within a chunk, general-purpose compression (LZ4/Snappy) over the chunk byte stream, dictionary-encoded label strings referenced by ID.
• Index structures: a primary LSM-style index maps SeriesID -> chunk pointers for fast range scans of one series; a secondary inverted index maps label_key=value -> [SeriesIDs], typically stored as compressed bitmaps (e.g., Roaring bitmaps) so a query like {job="checkout", env="prod"} becomes a bitmap intersection instead of a full scan.

Sizing the design against a concrete workload

Take 10,000,000 active series, an average of 6 label pairs per series (beyond the metric name), a 2-hour flush window at 15-second scrape interval, and a target of at most 2,000,000 active series per shard for balanced load:

active_series = 10_000_000
avg_labels_per_series = 6
bytes_per_posting_entry = 3          # Roaring-bitmap-compressed 32-bit series ID, moderately dense postings (assumption)
total_postings_entries = active_series * avg_labels_per_series
inverted_index_bytes = total_postings_entries * bytes_per_posting_entry

chunk_window_s = 2 * 3600
scrape_interval_s = 15
samples_per_series_per_chunk = chunk_window_s / scrape_interval_s
compressed_bytes_per_sample = 2      # consistent with the Gorilla-style bit math above, rounded up for a mixed workload (assumption)
head_bytes_per_series = samples_per_series_per_chunk * compressed_bytes_per_sample
head_total_bytes = active_series * head_bytes_per_series

target_series_per_shard = 2_000_000
min_shards = active_series / target_series_per_shard

Result: total_postings_entries = 60,000,000, inverted_index_bytes ≈ 180 MB, samples_per_series_per_chunk = 480, head_bytes_per_series = 960, head_total_bytes ≈ 9.6 GB, min_shards = 5.0 (round up to 8 for power-of-2 hash routing headroom).

That tells you two concrete things: the in-memory working set for the head block across all shards (~9.6 GB) comfortably fits on modern hardware split across 8 shards (about 1.2 GB/shard), and the inverted index itself (~180 MB) is small relative to the chunk data, meaning label-lookup cost is dominated by bitmap intersection speed, not index size. If active series grew 10x to 100M, head memory would grow to ~96 GB total, which is the point where you'd need to either shrink the chunk window (trading write amplification for lower per-shard memory) or add more shards.

Trade-offs

Pitfalls

• Choosing a partition key that's purely hash-based (no time component) makes retention expensive: you can't just drop a partition, you have to scan and delete, which is the mistake most designs make when they optimize only for write balance and forget that data has to expire.
• Sizing the head-block window without doing the arithmetic above (as many designs do) leads to either restart storms (window too large, recovery replays too much) or excessive flush overhead (window too small).
• An inverted index without a query-time cardinality guard turns a single broad label predicate (like an unbounded regex) into a full index scan across all shards; that needs a query-side cost limit independent of the storage design.

Situation: You're designing probes for a microservice running in Kubernetes behind a load balancer and autoscaler. Here's a practical, SRE-focused strategy.

Readiness probe (what + why)

• Purpose: signal "can serve real traffic". Prevents LB from sending requests until app is ready and removes pod from service during transient failures.
• Checks: HTTP GET /health/ready returning 200; verify that critical downstreams are reachable (DB connection pool non-empty, caches warm, feature flags loaded). Keep it fast (<200ms) and idempotent.
• Config example: initialDelaySeconds: 5, periodSeconds: 5, timeoutSeconds: 1, failureThreshold: 3 — allow short transients but remove pod within ~15s if repeatedly failing.

Liveness probe (what + why)

• Purpose: detect deadlocked or unhealthy processes that need restart.
• Checks: lightweight self-check (HTTP GET /health/live or TCP probe) that ensures event loop/threads are responsive; avoid expensive external calls.
• Config example: initialDelaySeconds: 30, periodSeconds: 10, timeoutSeconds: 2, failureThreshold: 3 — restart within ~36s if unresponsive.

How platform should handle failures

• Readiness failure: kubelet marks Pod NotReady → Endpoints controller removes it from Service → LB stops routing. Do NOT restart. Alert if prolonged NotReady (SLO breach).
• Liveness failure: kubelet restarts container. Ensure logs/metrics and crash-loop backoff policy are monitored; create alert on repeated restarts.

Impact on rolling updates, draining, and availability

• Rolling updates: readiness gate ensures new pods only receive traffic when readiness passes; set maxUnavailable conservatively (e.g., 10%) to preserve capacity.
• Draining/termination: use preStop hook + terminationGracePeriodSeconds > typical request timeout to let in-flight requests finish; readiness probe should immediately fail on SIGTERM so pod is removed from load balancer before termination.
• Autoscaling: HPA decisions should be based on ready pods; long readiness times can delay scale-up; ensure readiness is fast but accurate.
• Trade-offs: aggressive liveness restarts can mask slow failures; overly strict readiness may reduce available capacity during deployments. Tune thresholds based on real latency and failure modes; instrument and alert on probe-related events.

This combination keeps restarts targeted, avoids sending traffic to partially-initialized pods, and makes rolling upgrades and drains predictable.

Direct answer

Don't pick one replication strategy for the whole system, match the mechanism to each service's stated RPO (recovery point objective: the maximum amount of data, measured in time since the last durable copy, the service can afford to lose): synchronous or quorum replication for the zero-RPO service, change-data-capture streaming for the near-real-time service, and periodic snapshotting for the tolerant one. Then sequence recovery in dependency order so a service isn't restored before the upstream it depends on is back. Over-engineering shows up as spending synchronous-replication effort on the analytics service that only ever needed a daily snapshot.

Structured elaboration

Recovery ordering. Sequence recovery by dependency and criticality, not by which service happens to come back online first: promote the payments store first, the highest-integrity requirement and smallest tolerance for being wrong, verify it, then catch up and promote the profile replica, verify it, then resume analytics last, since nothing else depends on analytics being current.

flowchart TD
    F[Region A failure detected] --> P[1. Promote payments quorum replica, fence old leader]
    P --> V1{Verify: writes accepted, balances reconciled}
    V1 --> U[2. Drain CDC backlog, promote profile replica]
    U --> V2{Verify: profile lag = 0}
    V2 --> A[3. Resume analytics batch jobs from last snapshot]
    A --> V3{Verify: end-to-end smoke tests pass}

Worked example: setting the CDC alerting margin for the 30-second service

Assume the profile CDC pipeline runs with a measured steady-state lag of 8 seconds, a baseline from monitoring. The RPO budget is 30 seconds, so the available headroom before breaching the target is:

Set the alert threshold partway through that headroom, not right at the limit, so operators have real reaction time before an actual breach:

That leaves roughly 10 seconds of buffer between the alert firing and the RPO actually being breached, enough time for an on-call engineer to begin triage before the commitment is broken, not just a number picked because it's below 30.

Worked example: sizing the payments quorum's commit-latency cost

Payments run a 3-region majority quorum, 2 of 3 acks required to commit. Nearer replica round trip 20ms, farther replica 45ms. Since only one remote ack is needed alongside local:

This is the explicit, quantified latency tax paid on every payments write to guarantee RPO=0, weighed against the alternative, accepting some RPO on payments, which the requirement already ruled out.

Worked example: analytics snapshot cadence margin

The RPO target is 24 hours; a snapshot cadence set exactly at 24 hours leaves zero margin if a single run is delayed or fails. Running at a 20-hour cadence instead:

Trade-offs & pitfalls

• Recovering services in the wrong order, for example bringing user-facing profile reads back before payments is verified consistent, can let the system present data that later needs correcting once the higher-priority service catches up; sequence by criticality and dependency, not convenience.
• Setting the CDC alert threshold exactly at the RPO limit gives operators zero reaction time; build in the margin explicitly, as in the worked example.
• A cadence set exactly equal to an RPO target, as in the naive 24-hour snapshot case, has no tolerance for a single missed run; always leave margin.
• Applying the payments-grade synchronous mechanism to the profile or analytics services because it's "the safest option" is not safety, it's unnecessary latency and cost on writes that never needed that guarantee. Over-engineering the services that can comfortably tolerate a higher RPO, namely profile (30 seconds) and analytics (24 hours), by giving them payments-grade guarantees they don't need is exactly the failure mode this question is testing for.

Direct answer

Jenkins, GitHub Actions, and GitLab CI trade off along the same handful of axes: how much infrastructure you own, plugin/extension ecosystem breadth, and multi-tenancy and security posture. The right choice depends heavily on where your code already lives, your team's appetite for running infrastructure, and how much you need extensibility versus a smaller, more opinionated surface.

Structured elaboration

Jenkins uses a controller-agent architecture: you run and maintain the controller (or pay someone to), and it has by far the largest plugin ecosystem of the three, which is both its greatest strength (there's a plugin for almost anything) and its biggest operational liability (plugin compatibility, security patching, and version upgrades are an ongoing maintenance burden, and a bad plugin can take down the whole controller). Extensibility is effectively unlimited, but that comes with the highest maintenance overhead of the three options.

GitHub Actions is a fully managed SaaS platform tightly integrated with GitHub: no controller to run, workflows live as YAML in the repository, and GitHub manages runner infrastructure for hosted runners. Ease of use and integration with the rest of the GitHub ecosystem (PRs, issues, packages) is its strongest point; extensibility comes through a large but more curated marketplace of actions rather than Jenkins' raw plugin breadth, and self-hosted runners are available if you need to run inside your own network.

GitLab CI is a pipeline engine that's part of a broader, single-vendor DevOps platform (source control, CI, container registry, and security scanning in one product), configured via a .gitlab-ci.yml file, using lightweight Go-based runners. Its strength is that consolidation: less integration glue needed between separate tools, at the cost of being more opinionated about how you structure things if you want the full platform's benefits.

Security controls and multi-tenancy differ mainly by deployment model, not by inherent design: Jenkins self-hosted on-premise keeps everything inside your network but makes you responsible for isolation and patching; GitHub Actions and GitLab CI's hosted SaaS tiers handle infrastructure security for you but require trusting the vendor's isolation between tenants, while their self-hosted/self-managed variants give you the same control (and burden) as Jenkins.

Migration effort from an existing Jenkins setup is real and often underestimated: Jenkinsfile Groovy logic, especially anything using scripted-pipeline flexibility or complex shared libraries, doesn't translate directly to GitHub Actions or GitLab CI YAML, and a migration typically needs either automated translation for common patterns plus manual rework for the rest, or a deliberate re-architecture rather than a literal line-by-line port.

Worked example

A mid-size SaaS company already hosting code on GitHub, wanting to minimize infrastructure ownership, with straightforward build/test/deploy needs, is well served by GitHub Actions: no controller to maintain, tight PR integration, and a plugin ecosystem broad enough for typical needs. A regulated enterprise with strict on-premise requirements, heavy investment in custom Jenkins plugins, and existing operational capacity to run infrastructure might reasonably stay on self-hosted Jenkins despite the maintenance cost, because the migration cost and the loss of deeply customized plugin behavior would outweigh the operational savings.

Trade-offs and pitfalls

The most common mistake is comparing these platforms purely on feature checklists without weighing the migration cost from whatever you're currently running, which is frequently the dominant factor in the actual decision; a technically 'better' platform that costs six months of migration effort may not be the right call for a team under delivery pressure. The second is underestimating Jenkins' plugin-maintenance burden when comparing it against a managed SaaS platform on pure capability, since raw extensibility isn't free.

Direct answer

Escalation has to be a timed staircase, not a hope that someone notices: each tier gets an explicit timeout, and crossing it triggers the next tier automatically rather than waiting for a human to decide to escalate. The critical branch is distinguishing "primary hasn't acknowledged at all" (a much stronger, faster signal that they're unreachable) from "primary acknowledged but hasn't fixed it yet" (a slower, more judgment-based signal), and a specific person needs to be unambiguously the incident commander once the incident crosses into major-incident territory.

Structured elaboration

flowchart TD
    A[Page fires to primary] --> B{Acked within 5 min?}
    B -->|No| C[Auto-escalate to secondary]
    B -->|Yes| D{Mitigated or owned by 15 min?}
    C --> D
    D -->|No| E[Notify SRE lead and EM at 20 min]
    E -->|Sev1 criteria still met at 30 min| F[IC declares Major Incident]
    F --> G[Comms lead posts updates every 15 min]

Redundancy for an unreachable primary. The T+5m no-ack escalation exists specifically because "didn't acknowledge" is not the same failure mode as "acknowledged but stuck." An unreachable primary should trigger the fastest possible escalation, on multiple channels at once (page, SMS, phone call) rather than a single retry, since every minute the whole rotation is effectively uncovered.

Who declares Major Incident, and when. The role of Incident Commander should be predefined (whoever is the senior-most engaged responder at the moment of declaration, or a designated on-call IC rotation), not assigned ad hoc during the incident. Declaration criteria should be objective: customer-facing impact confirmed and no imminent fix, not a vibes call.

Audit trail. Every escalation event (page sent, ack received, tier crossed, IC declared) should be logged automatically by the paging tool with timestamps, not reconstructed from memory afterward. This is what makes the eventual postmortem's timeline accurate instead of approximate.

Worked example

A P1 outage affects payment processing. T+0: primary is paged, acknowledges within 2 minutes, and starts investigating (restart attempts, checking recent deploys). T+15m: the issue isn't mitigated and the primary flags they need help; the secondary engages and effectively becomes acting IC. T+20m: still unresolved, SRE lead and EM are notified via page and phone. T+30m: payment processing is still materially impaired with no fix in sight, so the SRE lead formally declares a Major Incident: opens an incident bridge, assigns a comms lead to post external status-page updates and an internal lead to keep driving the technical fix, and sets a 15-minute update cadence. Every one of these steps (ack time, escalation trigger, IC declaration) is logged automatically with a timestamp by the paging tool, which becomes the backbone of the postmortem timeline.

Trade-offs and pitfalls

• Pitfall: "someone will notice and escalate" with no explicit timer is the default at many small companies and reliably fails exactly when it matters most, at 3am with a skeleton crew.
• Pitfall: leaving IC as "whoever showed up" instead of a defined selection rule creates coordination ambiguity in the first minutes of a major incident, which is the worst possible time to negotiate who's in charge.
• Trade-off: the T+5m no-ack timeout should be noticeably tighter than the T+20m and T+30m escalation-for-non-progress timeouts, because "didn't acknowledge at all" is a much stronger signal of a coverage gap than "acknowledged and is still working on it." Making every tier the same length either escalates too aggressively on ordinary, in-progress incidents or too slowly on a genuinely unreachable primary.

Direct answer
A boundary check catches a specific class of bug (accessing an index, offset, or value outside the range the code actually handles correctly) at the moment it happens, instead of letting it silently produce wrong output or crash somewhere unrelated later; three concrete examples: array/list indexing, pagination offsets, and numeric limits.

Structured elaboration and worked examples

• Array indexing: the bug is an off-by-one or attacker-controlled index reading past the end of a buffer or list. The defensive check: validate 0 <= index < len(array) before accessing, raising a clear IndexError/custom exception instead of either crashing with a cryptic native error or, in an unsafe language, reading adjacent memory. A unit test: assert_raises(IndexError, get_item, [1,2,3], 5).
• Pagination offsets: the bug is a negative or absurdly large offset/limit from a client, which can either error confusingly deep in a SQL driver or, worse, silently return zero rows and look like 'no data' rather than 'bad request'. The defensive check: clamp or reject offset < 0 and cap limit to a sane maximum (say 1000) before it reaches the query layer. A unit test: assert paginate(items, offset=-5, limit=10) raises ValueError.
• Numeric limits: the bug is an integer overflow or an out-of-domain value (a negative quantity in an order, a percentage over 100) silently producing a nonsensical result instead of an error. The defensive check: validate the value's range explicitly before using it in a calculation. A unit test: assert_raises(ValueError, apply_discount, price=100, percent=150).

Trade-offs and pitfalls
Each of these checks is cheap individually, but the value comes from applying them CONSISTENTLY at every place the boundary is actually crossed (every array access from external input, not just the ones you happen to remember); a single unguarded pagination endpoint added six months later by someone who didn't see this pattern reintroduces the exact bug class. Treat these as patterns to lint for or wrap in a shared utility function, not as one-off checks to remember individually.

Month 0–1: Assess & signal change

• Run anonymous baseline surveys (psych safety, willingness to report incidents); collect incident history, missed postmortems, MTTR, SLO burn data.
• Quick wins: publish a one-paragraph “blameless incident policy” signed by execs; open an anonymous incident reporting channel (forms/Slack).
• Metrics baseline: MTTR, # incidents reported, % incidents with postmortem, psych-safety score.

Month 1–3: Build safe systems + runbooks

• Tooling: deploy an incident tracker (Jira/Playbook) with required fields, optional reporter identity, and a postmortem template focused on cause/contributing factors and action items.
• Create/curate runbooks and on-call playbooks; integrate into alerting so responders use documented steps.
• Process: mandate blameless postmortems within 7 days for Sev≥2; assign a neutral facilitator (rotating) trained in blameless facilitation.
• Leadership behavior: leaders attend first two postmortem meetings as observers, explicitly model curiosity (“what happened?” not “who failed?”).
• Metrics & targets (by month 3): +50% incident reporting vs baseline, 80% postmortem completion rate, MTTR reduced 20%.

Month 3–4: Embed learning and transparent metrics

• Learning loop: publish redacted postmortems & remediation trackers in a searchable “learning library”; run monthly “incident lessons” syncs to share patterns.
• Measurement: introduce SLOs + error budgets publicly; show real-time dashboards for SLO burn and active incidents.
• Incentives: align performance reviews to reliability contributions — reward documented remediation, runbook ownership, and mentoring rather than “no incidents.”
• Tactic: introduce “safety moments” into weekly standups; leaders start meetings by exposing one thing that went wrong and what they learned.

Month 4–6: Institutionalize and shift incentives

• Process: automate follow-ups—postmortem action items assigned with deadlines and tracked to closure; quarterly reliability OKRs tied to team compensation pools.
• Leadership dev: run coaching for managers on psychologically safe feedback, praising reporting and corrective actions publicly.
• Metrics & targets (by month 6):
  • Psych-safety score up by ≥20% from baseline
  • Incident reporting up (near-miss + low-sev) by ≥100% (shows transparency)
  • Postmortem completion ≥95% within SLA
  • MTTR down ≥30%; repeat incident rate down 50%
  • % of OKR compensation tied to reliability outcomes ≥10%

Tactics to shift incentives

• Replace “blame avoidance” KPIs with: postmortem participation, closed remediation rate, runbook completeness, and SLO health.
• Public recognition program (monthly) for teams that close action items and reduce incident recurrence.
• Budget for small reliability experiments — teams get microgrants to implement improvements discovered in postmortems.

Why this works

• Systems and tooling lower friction to report and learn.
• Processes enforce timely, blameless investigation and remediation.
• Leadership modeling and performance alignment change social and economic incentives from hiding incidents to surfacing and fixing them.
• Metrics provide objective feedback so leaders can see culture change and operational improvement.

Edge considerations

• Redact sensitive info when publishing.
• Start with volunteer teams for pilots to prove value before full rollout.
• Monitor for gaming (reporting noise) and refine metrics (focus on signal: repeat incidents, MTTR, remediation closure).