Building a Culture of Ownership & Operational Excellence
Final Prep · People Management — how to build a team where people own outcomes end-to-end, reliability is a first-class value, and operational rigor is a habit rather than a heroics.
This question tests whether you can build a durable culture — not just ship a project. Culture is what the team does when you’re not in the room. The interviewer wants concrete mechanisms, not slogans: how you create real ownership through DRIs and end-to-end responsibility, how you make reliability a value with blameless postmortems and healthy on-call, how you hold a quality bar, and how you build the psychological safety that makes people surface problems early instead of hiding them. Answer in CARL shape, and be specific about the operational rigor — SLOs, runbooks, error budgets — that an ads-infra team lives and dies by.
What this question is really testing
Whether you understand that culture is built by systems and incentives, not by posters. Anyone can say “we value ownership.” The senior signal is showing the concrete mechanisms that make ownership rational — clear DRIs, recognition tied to operational work, blameless postmortems that make it safe to surface failures — and understanding the deep link between psychological safety and operational excellence: teams that punish mistakes hide them, and hidden problems become incidents. For an ads-infra leader, they’re also checking that you treat reliability as a feature with a budget, not an afterthought.
How to answer- Make ownership real with DRIs. Every system and workstream has a directly-responsible individual who owns it end-to-end — from design through on-call through cleanup — not a diffuse “the team owns it” that means no one does.
- Write down the quality and reliability bar. Codify SLOs, error budgets, and the definition of “done” (tested, monitored, runbooked) so the bar is a team property, not folklore.
- Run blameless postmortems. Treat every incident as a lesson about the system, not a search for a culprit — that’s the single biggest driver of both reliability and safety.
- Protect on-call health. A burned-out rotation is a reliability risk; track pages-per-shift, fix the noisy alerts, and make on-call sustainable so ownership doesn’t mean suffering.
- Recognize ownership and build safety. Reward the unglamorous operational work in perf and shout-outs, and model that surfacing a problem early is celebrated, not punished — incentives and safety are what make the culture stick.
- Ownership operationalized via DRIs and end-to-end responsibility, not slogans.
- Reliability treated as a first-class, budgeted value with SLOs and runbooks.
- Blameless postmortems and a real grasp of why blame destroys reliability.
- On-call health tracked and defended, not tolerated.
- The link between psychological safety and operational excellence made explicit.
A worked example (CARL)
Context. I inherited the Ads Events storage team at a point where reliability was a real problem. The events pipeline — the write path for every impression and conversion — had recurring incidents, on-call was miserable (the primary was getting paged a dozen-plus times a shift, mostly on noise), and ownership was diffuse: when something broke, three people would half-look at it and no one felt truly accountable. Worse, the culture around incidents was quietly blameful, so people were slow to raise emerging problems and postmortems were thin and defensive. The team was firefighting, not owning.
Actions. I attacked it on four fronts at once, because culture doesn’t move on one lever. First, ownership: I assigned a named DRI to each major system — ingestion, the storage tier, the aggregation-freshness path — and made explicit that the DRI owned it end-to-end, design through on-call through cleanup. Diffuse ownership became individual accountability, but I paired that with authority: DRIs got real say over their system’s roadmap, so ownership was a source of agency, not just blame. Second, the bar: we wrote down SLOs for the paths that mattered (write success rate, aggregation freshness) with an error budget, and I made “done” mean tested, monitored, and runbooked — a system without a current runbook wasn’t finished. Third, the reliability culture: I reset how we ran postmortems to be genuinely blameless — the first question was always “what about the system let this happen,” never “who.” I ran the first few myself and deliberately started with an incident where my prioritization was part of the cause, so the team saw that the point was learning, not punishment. Every postmortem had to produce a concrete systemic fix with an owner and a date, tracked to closure. Fourth, on-call health: I treated the paging load as a bug. We ran an alert-quality sweep, killed or tuned the noisy alerts, and set a target for pages-per-shift, tracked weekly. I also changed the incentives — in perf and in team shout-outs I explicitly recognized the operational work (the runbook someone rewrote, the noisy alert someone finally killed), because that work is usually invisible and I wanted the team to see it was valued as much as feature launches. On the safety side, I made a point of publicly thanking people who raised a risk early, even when it turned out to be nothing, to make surfacing problems the rational move.
Results. Over two quarters the change was concrete. Pages per on-call shift dropped by more than half after the alert sweep, which made on-call sustainable and freed the DRIs to do proactive reliability work. Incident rate on the core paths fell and time-to-detect improved, because people were surfacing problems earlier instead of hiding them. Postmortem quality went up sharply — they became real learning documents that produced durable fixes rather than defensive write-ups. And the ownership stuck: when something broke, there was a clear DRI who moved on it, and the “three people half-looking” pattern was gone.
Learnings. The lever I underrated at first was psychological safety. I initially thought reliability was a tooling and process problem; it was at least as much a fear problem — people hid emerging issues because raising them felt risky. Once blameless postmortems and early-surfacing recognition made it safe, the operational metrics moved on their own. The lesson I carry: you can’t buy operational excellence with process alone; you have to make it safe to be honest about failure, and you have to pay for ownership with both authority and recognition.
Common follow-ups
What does a blameless postmortem actually look like in practice?
How to answer- Ask “what,” not “who.” Frame every finding around what in the system, tooling, or process allowed the failure — human error is a symptom of a system that made the error easy.
- Require systemic action items. Every postmortem produces concrete fixes — a guardrail, an alert, a runbook — each with an owner and a date, tracked to closure.
- Model it from the top. The leader owning a postmortem for their own decision is the fastest way to make it safe for everyone else.
- Share the learning widely. Circulate postmortems so the whole org learns once, and so people see that surfacing failure is rewarded with respect.
How do you make on-call sustainable?
How to answer- Treat paging load as a bug. Track pages-per-shift and set a target; noisy alerts are a reliability risk because they hide the real signal and burn people out.
- Invest the error budget in toil reduction. When you’re within SLO, spend the slack on killing noisy alerts, automating manual steps, and writing runbooks.
- Keep runbooks current and reachable. A stale runbook lengthens every incident; make “runbooked” part of the definition of done.
- Rotate fairly and recognize it. Balance the load, protect recovery time after bad shifts, and make on-call quality count in perf.
How do you balance reliability work against feature velocity?
How to answer- Use an error budget. An SLO plus budget turns the trade into an explicit, data-driven decision instead of a values argument — over budget means reliability wins the sprint.
- Make reliability a funded line, not slack. Reserve explicit capacity for operational work so it isn’t the thing that always loses to the next feature.
- Show the business cost. Frame incidents in terms the org feels — data loss, billing freshness, trust — so reliability investment is understood as protecting revenue.
- Automate to escape the trade. The durable answer is tooling that raises reliability without a permanent velocity tax.
How do you sustain the culture as the team grows or you leave?
How to answer- Encode it in artifacts. Written SLOs, the definition of done, and the postmortem process outlive any individual and let new hires absorb the bar quickly.
- Grow culture-carriers. The DRIs and senior engineers who embody ownership are how the culture propagates — invest in them as multipliers.
- Onboard to the values explicitly. Teach new hires the reliability bar and the blameless norm on day one, not by osmosis.
- Keep the incentives aligned. If perf and recognition keep rewarding ownership, the culture holds; if they drift to features-only, it erodes.
- SEV / incident records — pull the incident-rate and time-to-detect trend, and the postmortem action items closed.
- On-call dashboards (ODS / Unidash) — pull pages-per-shift and alert-noise trends before and after the sweep.
- SLO / reliability dashboards — pull the SLO attainment and error-budget burn for the core paths.
- The internal wiki — pull the written SLOs, definition of done, runbooks, and postmortem template you set.
- Perf records & eng-satisfaction surveys — pull evidence that operational work was recognized and that on-call health and team sentiment improved.