← CatZep/Engineering Guides/Management & Leadership/People Management
People Management — a senior engineer and a product manager have a fundamental, high-friction disagreement over technical debt versus shipping a new feature; how you mediate and what the outcome is.
Student edition · understand, apply, verify
Resolve engineering/product tension through a shared outcome and explicit risk/value tradeoffs.
What you should be able to do: Translate technical constraints into user/business impact while respecting product and safety decision rights.
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.
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.
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.
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.
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 is really about whether you can lead through conflict instead of around it. A weak answer picks a side (“engineering was right, we paid down the debt”) or dodges (“I told them to compromise”). A strong answer shows that you treat the friction as a signal of a missing shared goal, separate each person’s stated position from their underlying interest, force the decision onto data rather than volume, and facilitate a durable tradeoff that both people own — while protecting the working relationship for the next disagreement. Answer in CARL shape (Context, Actions, Results, Learnings), with most of your words on the actions.
Two things. First, judgment under a false binary: technical debt versus feature velocity is almost never actually all-or-nothing, and the interviewer wants to see you refuse the binary and find the third option grounded in cost and value. Second, influence without authority: a good outcome isn’t you overruling one party — it’s you getting two smart, invested people to a decision they both stand behind, so the friction doesn’t recur on the next call. The most common failure mode is a manager who “resolves” the fight by fiat, wins the battle, and quietly loses the trust of whichever side lost.
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 the Ads Events storage team, a senior engineer and the PM for a downstream analytics surface hit a wall. The PM had a committed launch for a new event-reporting feature with a hard external window; the senior engineer was adamant that our ingestion path had accumulated real debt — a fragile schema-migration step that had already caused two on-call incidents — and that stacking a new feature on top would make the next incident worse. Both of them were escalating to me separately, and the tone between them had gone from technical to personal, which is the point where a manager has to step in.
Actions. I pulled them into one room rather than letting it stay two angry side-channels. I opened by refusing the framing: this wasn’t “debt vs. feature,” it was “how do we serve the customer commitment without setting ourselves up for a worse incident.” Then I separated positions from interests out loud — I told the engineer I heard that his real worry was reliability and on-call load, and I told the PM I heard that hers was a real external commitment with a date, and I said plainly that both were legitimate and neither was going to be steamrolled. Next I took the heat out of the argument by putting it on data: I asked the engineer to quantify the debt — incident frequency, the actual dev-velocity drag, the on-call hours — and I asked the PM to quantify the feature’s value and to be precise about which part of the launch was truly deadline-bound versus nice-to-have. That reframing did most of the work, because it turned out the risky migration step and the specific feature slice the PM needed weren’t the same code path. From there I facilitated rather than dictated: I let the two of them design the sequence. We landed on shipping a scoped version of the feature that avoided the fragile path, while committing to a funded, scheduled two-week paydown of the migration step the following sprint — written down, with the engineer as DRI on the paydown and the PM explicitly signed up to protect that sprint from new scope. I made the tradeoff and its reasoning visible to both of them and to my skip, so nobody felt quietly overruled. Finally I addressed the relationship directly: I named that the escalation had gotten personal and set the expectation that disagreement was fine but it went through shared data, not through me as a referee.
Results. The feature shipped inside its window on the scoped path, and the debt paydown happened the next sprint as committed — and the migration step stopped generating incidents afterward. More importantly, the two of them ran their next disagreement themselves, over data, without escalating to me. The pattern — quantify the debt, quantify the value, sequence the tradeoff — became something the team reused.
Learnings. The friction was a symptom of a missing shared goal, not a personality clash. Once both interests were named as legitimate and the argument moved onto cost and value, the “impossible” binary dissolved into a sequencing problem. The lesson I carry: my job in these moments is not to be the smartest person who picks the winner, it’s to be the person who builds the frame where two smart people can find the answer and still trust each other afterward.
An illustrative situation to practice reasoning, communication, and fair evidence gathering.
| Step | Evidence, decision, and expected result |
|---|---|
| State both needs | Product needs a launch outcome; engineering identifies a data-loss failure mode under peak load. |
| Quantify options and uncertainty | Compare reduced scope, staged rollout, durability fix, and schedule change with impact and evidence. |
| Preserve nonnegotiables | Do not turn a legal/security/data invariant into a negotiable score. Escalate to the proper owner when it cannot be met. |
| Agree an inspectable plan | Name release authority, scope, test/abort gates, owners, and a follow-up date. |
No. Real decisions cross boundaries; define shared criteria, constraints, and actual authority rather than relying on a slogan.
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.