← CatZep/Engineering Guides/Management & Leadership/People Management
People Management — how you coach a deeply technical, execution-focused engineer to think like a product owner and focus on the real internal-customer experience.
Student edition · understand, apply, verify
Connect engineering decisions to customer problems, viable constraints, and measured adoption.
What you should be able to do: Form a testable user hypothesis and learn from evidence without treating users as a proxy metric.
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.
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.
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.
This question tests whether you can grow people, not just direct them. A weak answer treats product thinking as a lecture (“I told them to care about the customer”) or as a personality they either have or don’t. A strong answer shows that you connect the engineer to the real customer and the real “why,” shift how success is defined from output to outcome, coach through questions rather than answers, and then hand over genuine ownership of a customer-facing result so the mindset sticks. Answer in CARL shape (Context, Actions, Results, Learnings), with most of your words on the actions.
Two things. First, whether you understand that product thinking is a learnable skill, not innate talent — and that the fastest teacher is contact with the customer’s actual pain, not a slide about “customer obsession.” Second, whether you can coach without stealing the work: the point is to grow an engineer who asks “should we build this and for whom” on their own, not one who waits for you or the PM to hand them fully-specified tasks. On an infrastructure team this matters even more, because the “customer” is usually another engineering team, and it’s easy to optimize a system nobody actually finds usable.
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 had an excellent engineer on the Ads Events storage team — deeply technical, one of the best debuggers I’ve worked with — who consistently built things that were elegant but that downstream teams struggled to adopt. He’d shipped a new ingestion client library that was, by every internal benchmark, faster and more correct than the old one, and he was frustrated that adoption had stalled. His instinct was that the downstream teams were being lazy. The real issue was that he’d optimized for the system’s internals and never for the experience of the engineer who had to integrate it, and he genuinely didn’t see the difference.
Actions. I started with the why rather than the what. In our 1:1 I didn’t tell him the library was hard to use — I asked him who the customer was, and he answered with a system, not a person. So I made it a person: I arranged for him to pair for an afternoon with an engineer on one of the downstream analytics teams who was mid-migration onto his library, and I asked him to just watch and take notes, not help. He came back visibly rattled — he’d watched a competent engineer take two hours to do something he thought was a five-minute setup, tripping over unclear defaults, a confusing error message, and missing migration docs. That single afternoon did more than any feedback I could have given. From there I reframed success explicitly: I told him “done” for this work wasn’t “the library is fast,” it was “three downstream teams have migrated and would recommend it,” and I made that the goal we tracked. Then I changed how I showed up in reviews: instead of critiquing his design, I asked questions — who is this default for, what does the integrating engineer see when this fails, what’s the smallest change that would’ve saved that engineer the two hours — and I made myself wait for his answers instead of supplying them. I also gave him real ownership of the outcome: I made him the DRI for adoption, not just for the code, which meant he owned the migration guide, the office hours, and a short feedback loop with each adopting team. I deliberately did not take that customer relationship on myself, even when it would have been faster.
Results. He rewrote the defaults and the error messages, wrote an actual migration guide, and ran two office-hours sessions — and adoption moved from stalled to the majority of target teams over the following quarter. More importantly, on his next project he opened with a one-pager about the internal customer and the problem before he wrote any design, unprompted. The change generalized: he became the person on the team who’d ask “but who is this for” in other people’s reviews.
Learnings. I’d been tempted to just tell him “make it easier to use,” which would have gotten me a slightly better library and no change in the engineer. What actually moved him was contact with the customer’s pain plus ownership of the customer’s outcome. The lesson I carry: you don’t install product thinking by explaining it, you install it by connecting the engineer to a real person they’re accountable to — and then getting out of the way.
An illustrative situation to practice reasoning, communication, and fair evidence gathering.
| Step | Evidence, decision, and expected result |
|---|---|
| Find the underlying need | Interview representative users and inspect their workflow with appropriate consent/access. |
| State a hypothesis | Reducing a specific manual step should improve successful completion for a defined cohort. |
| Build a bounded experiment | Choose scope, privacy/access, success/guardrail metrics, and a decision date. |
| Learn and adjust | Compare observed behavior and qualitative feedback; stop or adapt when benefit is absent, even if the implementation is elegant. |
No. Reliability, maintainability, security, and operational cost affect user outcomes and sustainable delivery.
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.