← CatZep/Engineering Guides/Management & Leadership/People Management
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.
Student edition · understand, apply, verify
Build ownership and operational learning through authority, incentives, clear standards, and fair accountability.
What you should be able to do: Make reporting risks safe while tracking user impact and action completion.
Context-dependent people-management guidance, not a universal HR/legal policy or verified autobiographical record. Work from observable behavior, explicit expectations, appropriate privacy, fair support/accommodations, and your organization's qualified process. Example outcomes are illustrative, not guaranteed.
Read these definitions first, or use the linked terms as you go. The examples and limitations are local to this guide; companion pages are optional.
Ownership names who drives follow-through; accountability names who answers for outcomes. Decision rights specify who chooses/approves and who is consulted.
Example. A migration has a coordinating owner, service owners, and named release authority.
Boundary. DRI/RACI/DACI are local conventions, not guarantees. Role labels do not replace authority, capacity, and follow-through.
A shared belief that asking questions, reporting mistakes, or disagreeing can happen without humiliation or retaliation. It supports learning alongside clear standards.
Example. A junior engineer reports a suspected fault early; the lead examines evidence instead of attacking the person.
Boundary. It does not mean universal comfort/agreement or no accountability. Power, incentives, and context shape who can speak safely.
Toil is repetitive operational work that scales without lasting improvement. Incident response restores safe service first; an error budget relates risk to a user-defined SLO.
Example. Automate a repeatedly safe recovery after checking failure cases, and measure reduced effort/errors with an operator escape path.
Boundary. Not all recurring work is waste. Automation can amplify errors; preserve necessary safety controls. Budgets are policy, not universal mandates.
An SLI measures a user-relevant outcome; an SLO sets its target over a window. For a success-ratio SLO, the allowed bad fraction is 1−SLO. An SLA is a contractual commitment that may use different definitions.
Example. 99.9% successful requests over 1 billion requests allows 1 million bad requests. A time-based 30-day availability target instead allows 43.2 unavailable minutes.
Boundary. Request and time budgets are not interchangeable under variable traffic or partial failure. SLOs are not universally stricter than SLAs; choose both from their definitions and user needs.
Outputs are produced things; outcomes are changes for users/business/team. Useful metrics state definition, denominator, population, period, and attribution limits.
Example. 'Shipped a tool' is output. 'Median onboarding fell ten to six days in this cohort' is an outcome with sample/context caveats.
Boundary. Before/after does not prove sole causation. Avoid gaming, selection bias, hidden costs, and unlike-team comparisons.
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.
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 answerPractice draft: first-person narratives below are not independently verified autobiographical evidence. Use their structure, not their claimed results; replace with your genuine safe-to-share experience.
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.
An illustrative situation to practice reasoning, communication, and fair evidence gathering.
| Step | Evidence, decision, and expected result |
|---|---|
| Define the desired outcome | Fewer unnecessary interruptions while preserving timely detection of user-impacting failures. |
| Measure both sides | Track actionable pages, detection time, missed incidents, recovery workload, and the SLO denominator. |
| Change the system | Tune/dedup alerts with owners and runbooks; preserve critical signals and review the impact of every removal. |
| Reinforce learning | Thank early reports, track corrective work, and address harmful conduct through fair evidence. Blameless analysis is not lack of accountability. |
No. Pages can decrease by disabling detection. Include user outcomes, coverage, missed incidents, and sustainable effort.
Write the expected outcome/behavior, observed evidence, context and alternative explanations, your agreed support/action, decision owner, review date, and evidence that would change the plan. Keep confidential personnel material out of public examples.
Use genuine, safe-to-share evidence. Example numbers here illustrate reasoning; they are not claims about your work or a guaranteed outcome.