← CatZep/Engineering Guides/Management & Leadership/People Management
People Management — how to run a team split across timezones so it moves as one, with async-first communication, local ownership, and no HQ-versus-satellite hierarchy.
Student edition · understand, apply, verify
Design distributed collaboration around overlap, durable written context, and equitable participation.
What you should be able to do: Make handoffs and decisions usable without requiring every person to attend the same call.
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.
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.
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.
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.
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 lead a team you can’t gather in one room. Distributed teams fail in predictable ways: decisions made in a hallway that half the team never sees, a satellite site that gets the leftover work and no real ownership, meetings scheduled for HQ’s convenience at 11pm for everyone else, and knowledge trapped in people’s heads instead of documents. The interviewer wants the mechanisms that prevent all of that: async-first communication with written decisions of record, timezone-fair meeting practices, genuine local ownership of whole areas, a documentation and trust culture, follow-the-sun on-call, and a deliberate refusal to let an HQ/satellite hierarchy form. Answer in CARL shape.
Whether you default to async and written as the operating system of the team, and whether you understand the political trap of distributed work: the HQ/satellite hierarchy, where the site the manager sits in gets the interesting work, the real decisions, and the promotions, while remote sites get commodity tasks and quietly disengage. The senior signal is treating documentation as the substrate for trust (you trust output, not hours-at-desk seen), giving remote sites ownership of whole areas rather than slices, and actively distributing the inconvenience — of meeting times and of on-call — fairly.
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. My Ads Events Infra team was split across two sites with roughly an eight-hour offset — the larger group where I sat, and a smaller group in another region. The pattern when I took over was the classic satellite failure: the remote site was doing execution work on tickets scoped by the main site, the real design decisions happened in synchronous conversations the remote engineers were asleep for, and their standups were scheduled at the tail of their day for our convenience. Predictably, the remote engineers were disengaged, their growth had stalled, and we’d lost one strong person who felt like a contractor rather than an owner. Meanwhile the whole team was slower than it should have been, because so much depended on a few hours of overlap.
Actions. I reset the operating model. First, I moved the team to async-first and made written decisions non-negotiable: any decision of consequence had to be captured in a doc or task with the reasoning, not settled verbally in an overlap-hours call. I started a lightweight decision log so the remote site woke up to what was decided and why, not just an outcome they had to reverse-engineer. Second, and most important, I gave the remote site ownership of a whole area — I moved the aggregation-freshness subsystem to them entirely, roadmap through on-call, and stopped scoping their work from my site. They now owned an end-to-end piece of the pipeline that mattered, with a named tech lead there who set its direction. Third, I fixed meeting fairness: I rotated the painful slot so my site took the awkward-hours meeting half the time, cut the number of standing synchronous meetings hard (replacing most with written updates), and made a rule that any decision reached in a meeting was re-posted in writing so the absent site could weigh in before it was final. Fourth, I built the trust substrate: we invested in real documentation — design docs, runbooks, architecture overviews — so people could act without waiting for a timezone overlap, and I was explicit with my own site that we evaluated output, not who was visibly online. Fifth, on-call: I set up a follow-the-sun rotation so each region covered its own daytime and handed off cleanly, which ended the misery of the remote site taking pages in the middle of their night. Throughout, I watched the second-order signals of hierarchy — who got the interesting projects, who got credited in reviews, who got promoted — and deliberately corrected toward the remote site where it had been starved.
Results. Over about two quarters the dynamic changed. The remote site’s ownership of the aggregation subsystem stuck — they shipped a freshness improvement that my site hadn’t had bandwidth for, and their tech lead started representing that area directly in cross-team reviews. Velocity across the whole team improved because far less work was bottlenecked on overlap hours. On-call satisfaction went up on both sides after follow-the-sun. And the retention signal reversed: the remote engineers’ engagement scores in the team survey rose, and we promoted one of them the following cycle — the first promotion that site had seen in a while, which mattered symbolically as much as individually.
Learnings. The thing that actually fixed it wasn’t better tooling or more meetings — it was giving the remote site real ownership of a whole area. Everything else (async decisions, fair meetings, follow-the-sun) was necessary support, but ownership was the root cause of both the disengagement and the fix. The lesson I carry: a distributed team fails not because of distance but because of hierarchy, and the antidote is distributing ownership, decisions, and credit as deliberately as you distribute work.
An illustrative situation to practice reasoning, communication, and fair evidence gathering.
| Step | Evidence, decision, and expected result |
|---|---|
| Publish the needed context | State status, blocker, owner, evidence, next action, and deadline in a durable record. |
| Clarify response expectations | Specify urgent escalation versus normal asynchronous work; time zones do not imply constant availability. |
| Rotate unavoidable meetings | Share inconvenient hours fairly and collect written input before decisions. |
| Measure handoff quality | Track missed context/rework and completion, not green online indicators or message counts. |
Do not assume that. Check actual expectations, language/context access, calendars, workload, and individual feedback.
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.