Lyft Applied Scientist (Senior Level) - Comprehensive Interview Preparation Guide

Latency budget for an ML inference endpoint is the maximum allowed end-to-end time (request arrival → response) you allocate per request to meet UX and SLA (service-level agreement) goals. It’s typically expressed as percentiles rather than an average.

Definitions:

• p95 latency: 95th percentile - 95% of requests complete within this time; 5% take longer.
• p99 latency: 99th percentile - 99% of requests finish within this time; the slowest 1% define p99 (the tail).

Why tail matters more than average for user-facing systems:

• A low average can hide rare but severe delays that degrade user experience (e.g., a few slow responses cause visible UI jank, timeouts, or unhappy users).
• SLAs and SLOs are customer-facing and usually tied to tail behavior (customers notice long tail latency, not average).
• Tail events can cascade (retries, queue buildup) and amplify system instability.

One technique to reduce p99 latency - request hedging (speculative execution):

• Idea: for requests nearing a latency threshold, send duplicate requests to a second replica and return the fastest response.
• Why it helps: mitigates impacts of stragglers due to noisy neighbors, GC pauses, cold starts, or rare model slow paths.
• Implementation notes:
  • Only hedge after a small delay (e.g., start hedge at 50th/75th percentile latency) to avoid extra load.
  • Limit hedged fraction and cancel in-flight duplicates when one returns.
  • Combine with capacity headroom (reserve replicas) and careful monitoring to avoid overload.
• Trade-offs: extra resource cost and increased load; must tune thresholds to balance cost vs p99 reduction.

Other complementary options: provisioned/warm instances to avoid cold starts, isolate model-serving JVMs to avoid GC spikes, set concurrency limits, and use prioritized low-latency hardware.

Also covers (folded from merged near-duplicates): Also folds 6dbb00d0 (inbound, Netflix-framed why-tail-latency-matters restatement).

Definition (concise)

• Data drift: change in the distribution of input features p_train(x) → p_prod(x).
• Concept drift: change in the conditional relationship between inputs and targets p(y|x) over time (model no longer maps inputs to correct outputs).

Three practical detection methods

1. Statistical two-sample tests

   • Use Kolmogorov–Smirnov for continuous features, Chi-square for categorical; run per-feature and aggregate with Bonferroni or BH correction.
   • Example: KS p < 0.01 on feature "session_length" → raise suspicion.

2. Proxy metrics / population-level features

   • Monitor feature distribution summaries (mean, std, percentiles), derived ratios, and missingness rate. Sudden shifts in feature importance (via SHAP on recent batch) also signal drift.
   • Example: median transaction_amount up 40% vs baseline.

3. Label-informed drift and performance monitors

   • When labels available, track model metrics (AUC, calibration, PSI, lift). Use Population Stability Index (PSI) for grouped distributions; for concept drift, monitor calibration drift and degradation in AUC over sliding windows.
   • Example: sustained 5% AUC drop over 7 days triggers investigation.

Alerting strategy (latency vs noise)

• Multi-tier alerts:
  1. Quiet anomalies: minor stat test p-value triggers logging and increased sampling / automated data snapshot (no human alert).
  2. Elevated: aggregated signals across multiple features or proxy metric breaches (e.g., 3 features fail KS or PSI > 0.2) trigger on-call notification.
  3. Critical: performance degradation (AUC drop + calibration error) or business KPI impact triggers immediate paging.
• Use rate-limiting and rolling-window confirmation (require anomaly persists for N consecutive windows or affects >M% of traffic) to reduce false positives.
• Add automated remediation: shadow model retraining pipeline and feature-validation checks before human intervention.
• Include runbook documenting checks, likely root causes, and rollback/retrain steps.

Direct answer

Keep a single, easy-to-find decision log tied directly to the work it affects: what was decided, the options considered, the reasoning, and who owns it, updated by whoever is making the decision at the moment it is made, not reconstructed later from memory.

Structured elaboration

What belongs in an entry

A short, consistent structure works better than a long one, because people will actually fill it out: a title, the date, who owns it, the context in one or two sentences, the options considered with their trade-offs, the decision itself, and the reasoning behind it in a few bullet points.

Where it lives

The log needs to be one discoverable place, linked from the tickets, docs, or roadmap items it affects, not scattered across meeting notes and chat threads. A shared doc or wiki page with a simple table works; the tool matters less than the discipline of always linking to it.

Who keeps it current

The person who owns the decision, not a rotating scribe with no stake in it, writes or finalizes the entry, ideally right after the decision is made, while the reasoning is still fresh and easy to state accurately.

How it gets used afterward

In retrospectives, revisit decisions that affected the outcome and check whether the original assumptions held. For onboarding, a short list of the most consequential recent decisions gives a new team member the context that would otherwise take weeks of osmosis to pick up.

Worked example

A team is deciding between two ways to notify users of an event: a push notification versus an in-app banner. The entry, once decided, looks like this: title, "Notification channel for event alerts"; date and owner, the decision owner's name and the date; context, users were missing time-sensitive alerts under the current in-app-only approach; options considered, push notification (faster delivery, requires a new permission prompt), in-app banner only (no new permission needed, slower to be seen), and both channels (best coverage, more engineering and support surface); decision, push notification with an in-app banner as a fallback for users who decline the permission; reasoning, the delay in the in-app-only approach was the specific problem being solved, and the fallback covers users who opt out.

Anyone who later asks why the team does not just use an in-app banner, since it is simpler, can read this entry and see the trade-off was already considered, rather than re-litigating it from scratch.

Trade-offs and pitfalls

A log nobody updates is worse than no log: it creates false confidence that the reasoning is captured somewhere, while actually going stale. The fix is keeping entries short enough that updating one takes minutes, rather than requiring a formal write-up every time.

A log can also be used as a weapon later, such as insisting a past decision still holds in a situation where circumstances genuinely changed and revisiting was the right call. The log should record reasoning, not lock in a decision forever; a review date or a note on when to re-evaluate keeps it a living reference instead of a trap.

Direct answer

Sign flips and unstable coefficients after adding correlated features is the signature of multicollinearity: the new features carry mostly redundant information, so the loss surface has a long, flat valley and many different coefficient combinations fit the data almost equally well. Confirm it with the variance inflation factor (VIF) for each predictor and the condition number of X^T X, and fix it by dropping or combining redundant features, applying PCA, or using ridge or elastic net regularization.

Structured elaboration

Why it happens: the OLS variance of a coefficient is

$\text{Var}(\beta_j) = \frac{\sigma^2}{(n-1)\,\text{Var}(x_j)\,(1-R_j^2)}$

where $R_j^2$ is the R-squared from regressing feature j on every other predictor. As $R_j^2 \to 1$ (feature j becomes a near-linear combination of the others), the denominator shrinks toward zero and the variance explodes. VIF is exactly that blow-up factor:

$\text{VIF}_j = \frac{1}{1 - R_j^2}$

Diagnosis:

• VIF: regress x_j on every other predictor, take that R_j^2, compute VIF_j. A common rule of thumb flags VIF > 10 (equivalently R_j^2 > 0.9); some practitioners use a stricter VIF > 5 cutoff.
• Condition number: the ratio of the largest to smallest eigenvalue (or singular value) of X^T X, after centering and scaling. Condition numbers above roughly 30 are commonly flagged; near-duplicate columns push one singular value toward zero, inflating this ratio.

Fixes and when to use them

Worked example

Suppose x2 is nearly a linear function of x1, giving $R^2 = 0.98$ when x1 is regressed on the other predictors:

$\text{VIF}_{x_1} = \frac{1}{1 - 0.98} = 50$

A VIF of 50 is five times the common VIF > 10 flag: it means x1's coefficient variance is 50 times larger than it would be if x1 were uncorrelated with the other predictors, which is precisely the mechanism behind wide standard errors and sign flips across resamples. Ridge regularization counters this directly: adding lambda to X^T X adds lambda to every one of its eigenvalues, so the smallest eigenvalue (the one collinearity pushes toward zero) grows proportionally the most, shrinking the condition number and stabilizing the coefficient estimates.

Trade-offs & pitfalls

Pairwise correlation alone can miss the problem: two features can each show low pairwise correlation with every other predictor individually but still be a near-linear combination of several other predictors together; VIF catches this, a simple correlation matrix does not. PCA fixes the numerical instability but the resulting components are linear combinations of the raw features, so per-feature coefficient interpretability is genuinely lost, not just technically inconvenient, and that needs to be flagged to any stakeholder who expects a specific feature's effect. Regularization stabilizes coefficients but does not tell you which of the correlated features is truly causal, that requires domain knowledge or a design change, not a statistical fix.

Direct answer: An end-to-end RLHF platform at this scale (roughly 100M preference pairs, daily fine-tuning runs) needs to separate the always-on serving path from the heavy offline training path, use tiered storage matched to access patterns, and build in checkpointing and immutable artifact versioning so daily runs are reproducible and cheap to roll back.

Structured elaboration:

• Major components: an ingestion and validation service (schema checks, deduplication, PII filtering) sitting in front of a preference store; an annotation service backing human-labeling UI; reward-model training on a GPU cluster; a policy-optimization cluster (PPO-style, with actor/learner separation); an artifact repository for versioned models and checkpoints; a serving layer for both the reward model (batched scoring) and the policy (rollout generation); and a monitoring/governance layer over all of it.
• Data flow: production comparisons, annotator judgments, and any active-learning-selected pairs all land in the ingestion pipeline, get validated and deduplicated, and are written both to a hot store (fast reads for recent pairs, used for sampling and reward-model training minibatches) and a cold, partitioned object store (bulk historical data, used for large offline training runs).
• Storage and sharding: partition the cold store's preference data by date, model version, and a shard key (so training readers can each own a disjoint prefix range and read in parallel without hotspotting); keep a document-store index over the data for fast filtering during active sampling; use a columnar, compressed format for the bulk of the 100M pairs, since most access patterns are large sequential reads during training rather than point lookups.
• Compute and storage sizing: reward-model training and the PPO policy update both need GPU/TPU capacity, but the compute and storage considerations are asymmetric, reward-model training reads large batches of static preference data (I/O-bound, benefits from streaming and prefetch), while policy optimization needs to also generate rollouts and re-score them, so it typically needs a mix of generation-optimized and training-optimized hardware; storage for model checkpoints (versioned, kept for rollback) usually dominates over raw preference-data storage once you retain many days of daily fine-tuning history, so a clear checkpoint retention policy is part of the cost model, not an afterthought.
• Cost-saving opportunities: use preemptible/spot GPU capacity for the less time-critical reward-model training, with frequent checkpointing to tolerate preemption; run a full retrain on a weekly cadence and incremental fine-tuning on daily deltas rather than a full 100M-pair retrain every day; tier storage (hot store for the last few weeks of active data, cold archival storage for older history); and batch/autoscale the serving layer aggressively, since reward-model and policy inference both benefit heavily from batching GPU requests.

flowchart TB
    Ann[Annotation Service] --> PrefStore[(Preference Store hot/cold)]
    Ingest[Ingestion + Validation] --> PrefStore
    PrefStore --> RM[Reward Model Training]
    RM --> Artifacts[(Artifact Repository)]
    Artifacts --> PPO[Policy Optimization Cluster]
    PPO --> Artifacts
    Artifacts --> Serving[Serving Layer]
    Serving --> Monitor[Monitoring + Rollback]
    Monitor -.-> PPO

Worked example: A concrete daily cycle: an Airflow-style DAG triggers each morning, pulls the latest promoted reward model and the delta of new preference pairs since the last run (rather than the full 100M), runs an incremental PPO fine-tuning pass on a fixed GPU-hour budget, validates the resulting policy against a held-out evaluation set and safety regression suite, and only promotes the new checkpoint to the canary serving stage if it clears both bars; a full reward-model retrain on the entire accumulated dataset runs on a separate, weekly schedule, since it is far more expensive and does not need to happen daily to keep the policy improving incrementally.

Trade-offs and pitfalls: Chasing strong consistency everywhere in this pipeline is unnecessary and expensive, the cold historical store can tolerate eventual consistency, while only the hot store used for live sampling and dedup checks needs to be strongly consistent. Using preemptible compute for cost savings adds real operational complexity (checkpointing must be frequent and reliable, or a preemption mid-run wastes GPU-hours), so the savings need to be weighed against the added reliability engineering it requires. Immutable, versioned artifacts (models, datasets, sampling-policy snapshots) are what make daily runs auditable and reversible, skipping this discipline to move faster is a common shortcut that makes a bad daily run very expensive to diagnose after the fact.

Linearizability and serializability sound similar but answer different questions. Linearizability is about a single object: every operation on it must appear to happen instantaneously at some point between when it was invoked and when it returned, and that ordering must match real time. Serializability is about multiple objects touched by a transaction: the outcome of running several transactions concurrently must be equivalent to running them in some serial order, but that order does not have to match real time or even the order the transactions actually started in. A system can have one property without the other, and assuming the wrong one silently breaks a different class of guarantee.

Two mechanisms that actually enforce serializability

• Two-phase locking (2PL): a transaction acquires every lock it needs before releasing any of them, and once it starts releasing locks it may acquire no more. This physically prevents conflicting concurrent access, at the cost of blocking and potential deadlock.
• Optimistic concurrency control (OCC): transactions proceed without locking, then get validated at commit time; if another transaction's concurrent writes conflict with what this one read, it aborts and retries. This avoids blocking under low contention but wastes work under high contention.

When you need one but not the other

Consider a key-value store advertising single-copy semantics: every replica must behave as if there is exactly one physical copy of the data, so any client reading a key right after a write, from any client, on any replica, sees that write or a later one, never a stale value. The same requirement shows up as a highly available configuration service needing linearizable reads: if a client reads a feature flag or a routing rule right after it changed, it must get the new value, since acting on a stale one applies the wrong policy. Neither of these needs serializability: there is no multi-key transaction to isolate, just one key's recency.

The mirror case: a reporting system running multi-row aggregate queries across many tables needs those queries to see an internally consistent snapshot (serializability, or at least snapshot isolation), but does not need that snapshot to be the absolute latest possible instant in real time. A report built from data a few hundred milliseconds behind the live system is fine, as long as every row it reads is mutually consistent with every other row it reads.

Worked example: what breaks if you assume the wrong one

Linearizable but not serializable, no cross-key transaction: a key-value store gives linearizable single-key reads and writes but has no multi-key transactions. A funds transfer moves 30 units from account A (currently 100) to account B (currently 50) as two separate linearizable writes: write A=70, then write B=80. A concurrent reader can land exactly between the two writes and read A=70 and B=50. Both individual reads are linearizable, each reflects the latest write to that specific key at the moment it was read, but the reader just observed a total of 70+50=120, when the true, fully-settled total is 70+80=150: 30 units appear to have vanished mid-transfer. That is the anomaly linearizability alone does not prevent, because it says nothing about atomicity across two different keys.

Serializable but write-skew possible, snapshot isolation only: a hospital scheduling system enforces one invariant, that at least one doctor remains on call.

$\text{doctors on call} \ge 1$

Two doctors, Alice and Bob, are both currently on call, so the on-call count is 2. Both, concurrently, read a snapshot showing 2 doctors on call and each independently decide it is safe to go off-call, and both commit that decision under snapshot isolation, since neither transaction's write conflicts with what the other actually wrote (each only writes their own on-call flag). The result: 0 doctors on call, violating the invariant, even though each transaction, viewed alone against its own snapshot, looks perfectly valid. Full serializability, not just snapshot isolation, would detect that these two transactions' reads and writes interfere and force one to abort; snapshot isolation's weaker check does not.

Trade-offs & pitfalls

• Common wrong turn: treating serializable as automatically meaning fresh or linearizable. It is not: transactions can be serialized in an order that does not match when they actually ran.
• Common wrong turn: treating a single-key linearizable store as if it gives transactional safety across several keys. It does not, by itself, unless the store also offers multi-key transactions on top.
• Snapshot isolation is cheaper than full serializability, since it does not need to detect every possible interleaving, only genuine write-write conflicts, and is what most production databases default to, which is exactly why the write-skew anomaly above shows up in practice more often than people expect.

Direct answer

Making model training reproducible across machines and runs requires fixing every source of randomness, enabling deterministic GPU kernel implementations, controlling data-loading order, pinning package versions inside a containerized environment, and logging enough environment metadata alongside every run that a later attempt to reproduce it knows exactly what to reconstruct.

Structured elaboration

• Seed every RNG source: Python's random.seed(), NumPy's np.random.seed(), and the framework's own CPU and per-GPU RNG seeds.
• Enable deterministic operations: PyTorch's torch.use_deterministic_algorithms(True) combined with torch.backends.cudnn.deterministic = True and torch.backends.cudnn.benchmark = False forces slower but bit-reproducible kernel choices.
• Control data loading order: fix the data loader's shuffling seed and, for multi-worker loading, ensure each worker's seed is deterministically derived (e.g. via worker_init_fn).
• Pin environment and versions: pin CUDA, cuDNN, and framework versions, since different versions can produce different numerical results for the same operations.
• Containerization: package the pinned environment (OS libraries, CUDA/cuDNN, Python/framework dependencies) into a versioned, immutable container image (e.g. a tagged Docker image, never :latest) rather than relying on a host machine's environment staying unchanged over time; this is what actually makes "pin the versions" enforceable across different physical machines, since two hosts running the same container image are guaranteed to see the identical software stack, whereas two hosts each independently following a version-pinning document can still drift (a slightly different OS-level library, a manually-installed system package) in ways a lockfile alone doesn't catch.
• Logging environment metadata: at the start of every run, log (to the experiment tracker or alongside the checkpoint) the exact container image tag/digest, the git commit hash of the training code, the full resolved dependency versions (not just the top-level pinned ones, since transitive dependencies can also vary), the hardware used (GPU model/count, driver version), and the seeds used; without this, a run from three months ago that needs to be reproduced or audited has no reliable record of what actually produced it, making "reproducible in principle" (the seeds and code exist) meaningless in practice if nobody can reconstruct which exact environment they applied to.

Worked example

A checklist applied to a PyTorch training run: random.seed(42), np.random.seed(42), torch.manual_seed(42), torch.cuda.manual_seed_all(42), torch.backends.cudnn.deterministic = True, torch.backends.cudnn.benchmark = False, a DataLoader with worker_init_fn deriving each worker's seed from the base seed plus worker ID, run inside a container image tagged train:v1.4.2-cuda12.1-torch2.1.0, with the run's metadata log recording that image tag, the code's git commit hash, and the resolved pip freeze output; running the same image on a different physical machine six months later, using the logged metadata to reconstruct the exact setup, reproduces bit-identical (or numerically identical to floating-point tolerance) loss curves.

Trade-offs & pitfalls

Deterministic mode has a real performance cost, so it's typically enabled specifically for debugging/reproducibility-validation runs. Skipping containerization in favor of "just document the versions" is a common shortcut that looks equivalent on paper but fails in practice, since undocumented OS-level or transitive-dependency drift between two "identically configured" bare-metal hosts is a frequent, hard-to-diagnose source of irreproducibility that containerization eliminates by construction.

Direct answer

Decide what to delegate by looking at two things: where the task sits relative to the person's current skill level, and what happens if they get it wrong. Delegate work that stretches them but is reversible or cheap to fix. Keep for yourself work that needs context you can't hand off in time, decisions whose blast radius exceeds the trust you've built with this person so far, or one-off tasks where teaching would take longer than doing it. Treat each handoff as a deliberate intervention, not an offload: pick the task for the specific gap it targets, define what "done" looks like up front, and calibrate how much support comes with it.

Decision framework

Match difficulty to their zone of growth. Too easy and it's busywork with no development value. Too hard with no support and it's discouraging or risky. The sweet spot is a task just past what they've done independently before.

Weigh reversibility, not just difficulty. Prefer delegating decisions that are cheap to undo (a first draft, a component design, a low-stakes customer interaction) over ones that are hard to walk back (a commitment made externally, a change with security or compliance exposure). Trust for higher-stakes delegation gets built incrementally through the reversible tasks.

Compare time-to-teach against time-to-do. If explaining the task well would take meaningfully longer than doing it yourself, and it's a one-off with no repeat value, do it yourself. If it's a skill they'll use again, the teaching cost is an investment that pays back on the second and third time.

Define the support structure explicitly. Delegating isn't handing off and disappearing. Decide in advance: what checkpoints happen, what they can decide alone versus what needs a quick check-in, and what "stuck enough to escalate" looks like.

What you keep. Work that needs institutional context you can't transfer in the available time, early-relationship politically sensitive conversations, and anything where a mistake would damage a stakeholder's trust in the team broadly rather than just cost you some rework time.

Worked example

Say you're leading a project with three distinct pieces. One is well-scoped, reversible, and slightly above where this person has worked before: a strong candidate to delegate as a growth task, with a design check-in before they start building and a review before it ships. Another piece is customer-facing with real cost if it goes wrong: you either delegate it with heavy pairing so you catch problems before they land, or you keep it yourself this round and delegate the next similar piece once trust is established. The third is a one-off internal chore with no growth value: you delegate it purely for your own capacity, not as a coaching move, and you say so, because dressing up busywork as a growth opportunity erodes trust.

Trade-offs and pitfalls

Delegating only "safe" tasks because failure is expensive to you personally caps the person's growth. They never build judgment under real stakes if you only ever hand them things that can't go wrong.

Delegating and then vanishing looks like empowerment but is often abdication. The failure mode shows up late, when it's expensive to fix, because there was no checkpoint designed to catch it earlier.

Over-specifying the implementation defeats the purpose. If you hand someone a task but dictate every step, there's no room left for them to exercise judgment, which is the actual thing you're trying to develop.

The honest trade-off: delegating a stretch task usually costs you more short-term time, in reviewing and coaching, than doing it yourself would. That extra cost is the investment, and it's worth naming rather than pretending delegation is free.

Direct answer
Single exponential smoothing maintains one smoothed level, updated each period as a weighted blend of the new observation and the previous smoothed value ($S_t = \alpha y_t + (1-\alpha) S_{t-1}$); the forecast for ALL future periods is simply the final smoothed level $S_n$ (SES has no trend or seasonal component to extrapolate further), and alpha controls how much weight recent observations get versus the smoothed history.

Structured elaboration and worked example (executed, cross-checked against statsmodels)

import numpy as np

def simple_exp_smoothing(values, alpha):
    smoothed = np.empty_like(values, dtype=float)
    smoothed[0] = values[0]                       # initialize at the first observation
    for t in range(1, len(values)):
        smoothed[t] = alpha * values[t] + (1 - alpha) * smoothed[t - 1]
    return smoothed, smoothed[-1]                  # forecast = last smoothed level

Run on [112, 118, 132, 129, 121, 135, 148, 142, 130, 145] with alpha=0.3:

from-scratch smoothed:      [112. 113.8 119.26 122.182 121.827 125.779 132.445 135.312 133.718 137.103]
from-scratch next forecast: 137.103

Cross-checked against statsmodels.tsa.holtwinters.SimpleExpSmoothing with the same alpha (optimized=False): the fitted values matched exactly once accounting for statsmodels' indexing convention (its fittedvalues[t] is the one-step-ahead forecast made BEFORE seeing $y_t$, i.e. it equals our smoothed[t-1], not our post-update smoothed[t]) - after aligning on that offset, max abs diff = 0.0 and both implementations agree on the final forecast, 137.103.

This cross-check caught a genuine implementation bug on the first attempt: an initial version computed "next forecast" as alpha * values[-1] + (1-alpha) * smoothed[-1], which double-applies the last observation (since smoothed[-1] already incorporated it in the recursion), producing 139.47 instead of the correct 137.10. The correct SES forecast is simply the final smoothed level itself, $\hat{y}_{n+h} = S_n$ for every horizon $h \ge 1$ - SES has no mechanism to extrapolate differently at different horizons, which is itself an important limitation to flag (see below).

• Initialization choices: initializing $S_1 = y_1$ (used above) is the simplest and most common convention; an alternative is to initialize with the average of the first few observations, which reduces sensitivity to a noisy first data point at the cost of a slightly more complex setup. The choice mostly matters for a short series; its influence fades geometrically as more observations are smoothed in.
• How alpha controls responsiveness: alpha close to 1 makes the smoothed level track new observations almost immediately (responsive, but passes through more noise); alpha close to 0 makes it change very slowly (smooth, but slow to react to a genuine shift). Alpha is typically chosen by minimizing in-sample or backtested one-step-ahead error rather than picked by hand.

Trade-offs & pitfalls
SES has no trend and no seasonality component - its forecast is FLAT (the same value) at every horizon, which makes it a poor choice for any series with a visible trend or seasonal pattern (that's exactly what Holt's linear method and Holt-Winters extend it to handle). The implementation trap surfaced above generalizes: any time you're tempted to apply "one more update step" to produce a forecast from a recursive smoothing state, check the model's actual mathematical definition of its forecast function rather than assuming intuition about "the next step" is correct - for SES specifically, the forecast function is constant in the smoothed level, not a further-updated value.

I would move quickly because a one-week blockage is usually a clarity problem, not a technology problem.

First, I would bring both teams together and restate the facts: what is blocked, what the milestone depends on, and what happens if nothing changes. Then I would ask each team to explain its assumption about ownership. Often the disagreement is about boundaries, not willingness.

Next, I would decide the immediate owner based on capability and dependency, not pride. If needed, I would split the work into a temporary owner for this milestone and a permanent owner for later. For example, one team might own the interface definition while the other implements the code.

If they still cannot agree, I would escalate with options, not complaints: who can do it fastest, who has the right context, and what the risk is for each choice. That keeps the relationship intact because the discussion stays focused on delivery.

After the milestone, I would document the ownership rule so the same dispute does not happen again. The goal is to unblock the work, make the decision fair, and avoid turning a coordination issue into a personal conflict.

For example, on a project one week from a data-pipeline migration milestone, the platform team and the analytics team each believed the other owned writing the schema-validation logic that would catch bad records before they reached the new pipeline. The platform team's assumption was that analytics, as the consumer of the data, should define what counted as valid. The analytics team's assumption was that platform, as the pipeline owner, should implement any validation logic that ran inside the pipeline. Bringing both teams together surfaced that this was exactly a boundary problem: nobody disagreed on doing the work, they disagreed on who was supposed to start it. The immediate decision, made on capability and dependency rather than either team's preference, was that analytics would own defining the validation rules, the business logic of what counts as a bad record, since only they had that context, while platform would own implementing those rules inside the pipeline code, since only they had write access to it and the deployment pipeline. That split unblocked both teams within a day, and the milestone shipped on schedule with the validation logic live. Afterward, the rule, rule-definition belongs to the data consumer, rule-implementation belongs to the pipeline owner, was documented so the next migration didn't reopen the same argument.