← CatZep/Engineering Guides/Management & Leadership/People Management
People Management — how to drive a decision when the data is thin, the stakes are real, and the team is split — without stalling and without gambling.
Student edition · understand, apply, verify
Make timely technical decisions with explicit uncertainty, reversibility, and review triggers.
What you should be able to do: Choose a bounded experiment and document why the available evidence supports the selected tradeoff.
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.
Record the problem, options, evidence, constraints, owner, chosen tradeoff, and reconsideration trigger. A reversible test reduces uncertainty before large commitment.
Example. Try one tenant with success/abort metrics and a data-safe rollback plan.
Boundary. Timeboxing does not bypass compliance/safety. Reversible means effects and data can actually recover, not merely that a flag exists.
Opportunity cost is benefit forgone by choosing one investment over another. Compare expected value, effort, uncertainty, constraints, and dependencies under finite capacity.
Example. A feature can delay reliability work; compare user benefit with risk reduction and explain the choice.
Boundary. ROI/RICE/weighted scoring are aids, not exact laws. Units, uncertainty, mandatory constraints, and critical paths can dominate scores.
A stakeholder is affected by or able to affect a decision. Alignment means understanding goals, constraints, tradeoffs, and the decision process; it does not require unanimous agreement.
Example. Finance values cost predictability, customers migration effort, and operations safe recovery. State these criteria before choosing.
Boundary. Consultation is not an unlimited veto. Name decision authority, required evidence, deadline, and escalation.
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.
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 make good calls when there is no obviously right answer — the defining situation of senior leadership. Two failure modes disqualify you: analysis paralysis (endless investigation while the window closes) and reckless gambling (a confident call with no signal behind it). The interviewer wants a disciplined process: frame the decision and its criteria, gather signal cheaply, size the reversibility (one-way vs two-way doors), decide and write it down, get a split team to disagree and commit, and revisit with data as reality lands. Answer in CARL shape, and show you can drive alignment when the team itself is divided.
Whether you have a calibrated bias to action: you move fast on reversible decisions and slow down only for the irreversible ones, rather than treating every call with the same weight. The central mental model is one-way vs two-way doors — reversible decisions should be made quickly by whoever’s closest, and only genuinely irreversible ones deserve heavy deliberation. They’re also testing whether you can write decisions down (so reasoning is legible and revisitable), and whether you can get a divided team aligned through disagree-and-commit rather than letting a stalemate rot or forcing a call no one will support.
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. On Ads Events Infra we hit a decision with real stakes and thin data: our events-storage layer was approaching a scaling ceiling, and we had to choose a path before the next traffic peak — roughly a quarter out. Two credible options, and the team was genuinely split. One camp wanted to adopt a new internal storage engine that promised much better write throughput but was newer and less battle-tested for our access pattern. The other camp wanted to extend our existing system with a sharding change — lower ceiling, but a known quantity. Both camps were led by strong engineers, both had real arguments, and the debate had been looping in design reviews for two weeks without converging. The cost of getting it wrong was high (a re-platforming on an infra layer is expensive to unwind) and the cost of not deciding was also high (we’d miss the runway to be ready for peak).
Actions. I started by reframing, because the debate had become “new engine vs sharding” in the abstract, which was unwinnable. I rewrote the decision as a concrete question with explicit criteria: which path gets us safely through the next two peaks on throughput, without regressing the billing-freshness SLA, at acceptable operational risk and cost? Naming the criteria immediately narrowed the argument. Next, instead of continuing to debate, I bought down the key uncertainty cheaply: the real unknown was whether the new engine held up under our fan-out read pattern, so I scoped a two-week bounded spike — a shadow-traffic replay of both options against those exact criteria — and had one engineer from each camp run it together, which also defused the tribalism. Crucially, I classified the reversibility out loud: fully adopting the new engine was close to a one-way door (expensive to unwind on a live infra layer), while the sharding extension was much more reversible. That framing told me the new engine needed to clear a higher bar of evidence, not just be marginally better on paper. The spike data came back mixed but decisive on the thing that mattered: the new engine won on write throughput but showed a read-tail risk against our pattern that the team couldn’t fully de-risk in the runway we had. Given the one-way-door nature and the hard freshness SLA, I made the call: ship the sharding extension now to be safe for the upcoming peaks, and fund a parallel, lower-stakes evaluation of the new engine for the longer-term ceiling. I wrote the decision up in a short decision doc — the question, the criteria, both options, the spike data, the reasoning, and explicitly what would make us revisit (specifically, the new engine de-risking its read-tail behavior). Then I brought the split team back together, walked through the reasoning transparently, acknowledged the new-engine camp’s case directly, and asked for disagree-and-commit — with the honest framing that this wasn’t “sharding wins forever,” it was “sharding now, revisit the engine with data.”
Results. The sharding extension shipped in time and carried us through the next two traffic peaks with the freshness SLA intact — the safe outcome the criteria demanded. The new-engine camp committed genuinely, partly because the decision doc made the reasoning legible and the revisit condition concrete, so they didn’t feel overruled — they felt deferred with a path. And the parallel evaluation paid off: two quarters later the new engine had matured and de-risked the read-tail concern, we revisited exactly as the doc said we would, and adopted it for the longer-term ceiling — this time with the evidence to make it a low-risk call.
Learnings. The two moves that mattered were reframing the decision around explicit criteria and reversibility, and buying down the core uncertainty with a cheap bounded spike instead of continuing to argue. The one-way-door framing is what kept me from making an exciting but irreversible bet on thin data. And writing it down — with the revisit condition named — is what turned a split team into a committed one: people commit to a call they understand and know will be re-examined. The lesson: match rigor to reversibility, decide in time, and make the reasoning legible.
An illustrative situation to practice reasoning, communication, and fair evidence gathering.
| Step | Evidence, decision, and expected result |
|---|---|
| Define the deadline and criteria | Peak traffic is twelve weeks away; specify throughput, read latency, durability, cost, and delivery confidence. |
| Identify the decisive unknown | Test the new engine's workload-specific read tail, not unrelated benchmark headline throughput. |
| Compare reversibility honestly | A pilot is not reversible unless data/clients/external effects can recover. Retain a bounded fallback and enough headroom. |
| Record the decision | Choose the safe plan under evidence/constraints and fund review when the named uncertainty changes. |
Not alone. Judge available evidence, uncertainty, alternatives, and process as well as result; avoid hindsight bias.
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.