Part A — Someone on Team B tells you they feel shut out because key people on Team A deliberately leave them out of conversations about work both teams share. You don't have any formal authority over either team, and a launch is only three weeks away.

1. Walk through, step by step, how you would figure out what's going on in the first two days (the specific questions you'd ask, the documents you'd look at, the signs you'd watch for). 2) Present your stakeholder map and a detailed communication plan (who, when, which channel, what you aim to achieve). 3) Explain immediate steps to reduce risk and protect both psychological safety and the delivery schedule. 4) Set out clear criteria for deciding when to bring in HR or senior leaders. 5) Suggest leading and lagging success measures (both quantitative and qualitative) to confirm the intervention is working, and how you would track them. 6) Name two probable ways your plan could fail and how you would adjust.

Part B — Give a concrete example (using STAR) where you had 14 days or fewer to pick up a new domain or tool to deliver something high-stakes. What did you decide not to do, how did you confirm you were focusing on the right things, and how did you gauge the impact? Mention one error you made and what you would change.

Part C — Provide a specific instance of a disagreement with a senior stakeholder who challenged your analytical method. How did you uncover their interests versus their stated position, what compromises did you suggest, and how did you measure the effect of the final choice on business results?

Overview: This question assesses interpersonal leadership, working across teams, resolving conflicts, learning a new domain quickly, mapping stakeholders, and the capacity to quantify analytical trade-offs and their impact in a data science setting.

Solution

Part A — Inclusion Across Teams and Delivering Under Deadline Pressure

Assumptions:

• You act as a neutral cross-functional ally with no formal authority (for instance, a data science or technical program manager type role) backing a launch that is coming up soon.
• Aim: bring back inclusive decision-making and safeguard delivery dates without escalating too early.

1) The first two days: figuring out what's happening (questions, documents, signals)

0–6 hours: hear them out, write it down, and define the scope

• One-on-one with the person who raised it (the Team B colleague)
  • Questions:
    • Could you describe the last two or three decisions you were left out of (who, when, where, what effect)?
    • What exactly was said or done that came across as exclusionary (quotes or screenshots if you have them)?
    • What is the actual effect on deliverables, dependencies, or risks?
    • What would "success in three weeks" mean to you? What are you okay with me sharing, and with whom?
  • Documents to ask for: meeting invitations, doc links and comments, Slack or Teams threads, decision records, pull requests or issues.
  • Signals to watch for: a pattern of missing invites, private channels making decisions about shared work, FYI notices sent after the fact, dismissive remarks, work reassigned without agreement.
• Tell your manager right away that you're looking into a cross-team risk; settle on how discreet to be and where the escalation lines are.

6–24 hours: gather neutral perspectives from multiple angles

• One-on-one with the influential person or people on Team A (product manager, tech lead, engineering manager)
  • Questions:
    • What are the biggest launch risks and the critical path dependencies involving Team B?
    • How are decisions made right now (RACI or DRI)? Are there any confidentiality limits?
    • What has been difficult about working with Team B? What would a good collaboration look like?
  • Signals: unclear roles, pressure to move quickly, worries about Team B's quality or reliability, the "too many cooks" argument.
• One-on-one with the shared PM or TPM and both EMs (or the closest equivalents)
  • Questions:
    • What is the agreed RACI or DRI for decisions that affect shared work?
    • What is the launch checklist and the go/no-go criteria? Where are we red or amber?
    • Which decisions have to be inclusive, and which can stay local?
  • Signals: no RACI, decision forums that aren't documented, ownership that isn't clear.

24–48 hours: confirm the facts and look for patterns

• Go through the documents
  • PRDs, technical and design docs and their sharing settings, decision logs, roadmaps and OKRs, the issue tracker (Jira or similar), code reviews, experiment plans, calendars (who is invited to what), Slack channels.
• Put together a brief "current state" summary
  • What took place, when, who is affected, the effect on timeline and quality, how clear the roles are, and the immediate risks.
• Do a quick pattern check
  • Is the exclusion happening systematically (across multiple decisions or people) or just occasionally? Are there any possible policy or code-of-conduct issues?

2) Stakeholder map and communication plan

Stakeholder map (by role and level of interest/influence)

• High influence, high interest: Team A PM/TL/EM, shared PM/TPM, your manager.
• High influence, medium interest: Product leadership or director(s) sponsoring the launch.
• Medium influence, high interest: Team B DS (the person who raised it), Team B EM/PM.
• Advisory: Legal, Policy, or People Partner (only if needed), QA or Release manager. Communication plan (who, when, channel, goal)
• The person who raised it (Team B DS):
  • When: Day 0 and a check-in on Day 2.
  • Channel: one-on-one.
  • Goals: listen to concerns, confirm facts, agree on what can be shared, settle on success criteria and boundaries.
• Team A influencers (PM/TL/EM):
  • When: one-on-ones on Day 1; a joint working session on Day 2.
  • Channel: one-on-one first, then a facilitated group meeting.
  • Goals: agree on decision governance (RACI/DRI), inclusive forums, and immediate process fixes that won't slow the launch.
• Shared PM/TPM plus both EMs:
  • When: joint working session on Day 2; then a 15-minute daily triage until things stabilize.
  • Channel: a 30–45 minute live working session; a shared doc; daily stand-up or triage.
  • Goals: confirm RACI, define decision forums, create one shared plan and risk log, assign DRIs and SLAs.
• Wider teams:
  • When: after agreement, post a short update.
  • Channel: shared Slack channel plus doc.
  • Goals: publish a clear RACI, inclusive decision forums, SLAs, escalation path, and commitments. Message themes (brief, neutral, focused on outcomes)
• We need a predictable and inclusive way to make decisions that affect shared work.
• Propose: a shared channel, a decision log, explicit DRIs, and a short daily triage until launch.
• Commitments: include all relevant stakeholders in forums; write up decisions; a 24-hour SLA for cross-team questions.

3) Immediate risk reduction (psychological safety and timelines)

Psychological safety

• Set up a shared, open channel for project decisions; stop private decision-making on shared work.
• Keep a decision log (date, DRI, context, options, decision, dissent).
• Establish meeting norms: send the agenda 24 hours ahead; go round-robin for input; rotate the facilitator; record dissent explicitly.
• Provide one-on-one and anonymous input (a quick form) for people who don't feel comfortable speaking up. Delivery timelines
• Hold a daily 15-minute cross-team triage on critical path, blockers, and risks (red/amber/green status).
• Make DRIs and SLAs clear: code reviews, data requests, experiment approvals, doc reviews.
• Stop scope creep: require change proposals to go through the decision log.
• Prepare fallback plans: feature flags, staged rollout, guardrail metrics, and automatic rollback criteria.

4) Clear criteria for escalation

Escalate to HR right away if

• There are allegations of harassment, discrimination, or retaliation; personal attacks or slurs.
• There are concerns about psychological harm or safety. Escalate to senior leadership (product or engineering) if
• After 48–72 hours with agreed changes, exclusion continues in two or more additional decisions affecting shared work.
• Team A (or B) refuses to adopt basic inclusive governance (shared channel, decision log, RACI) that directly puts the launch at risk.
• There is material launch risk (for example, critical path blockers lasting more than three days, repeatedly missed SLAs) without a workable mitigation. Documentation for escalation
• A timeline of incidents, artifacts or screenshots, documented requests and responses, impact on deliverables, and proposed remedies already tried.

5) Success metrics and how to track them

Leading indicators (weekly)

• Inclusion coverage: the percentage of decisions in the log where both teams are represented (target at least 90%).
• Response SLAs: median response time to cross-team questions (target 24 hours or less; ideally 4 hours or less during business hours).
• Participation: number of cross-team comments on shared docs or PRs; cross-team reviewers per PR (target at least 2 total, with at least 1 from each team).
• Pulse safety: a two-question anonymous check-in (1–5) on "I feel included in decisions affecting my work" and "I can speak up without negative consequences" (target a 1-point increase from baseline).
• Risk burndown: active blockers and open risks trending downward week over week. Lagging indicators
• Launch timeliness: met versus slipped; if slipped, the number of slip days attributable to collaboration issues.
• Quality: post-launch incidents or regressions attributable to cross-team misalignment; rework hours.
• Sustained sentiment: monthly team climate pulse; 360 feedback that mentions collaboration. Instrumentation
• Calendar analytics: check invite lists for decision meetings against the stakeholder list.
• Slack and Docs: shared channel adoption; doc access lists; comment counts; decision log completeness.
• Issue tracker: cycle time, SLA adherence, cross-team review counts.
• A quick anonymous survey (for example, a form with timestamp and team) stored in a sheet for trend tracking.

6) Probable failure modes and how to adjust

Failure mode 1: The process feels like punishment; Team A gets defensive and works more in private.

• Course-correct: Reframe around launch risk and successful outcomes, not blame. Cut down on ceremony (use lighter templates), point out quick wins, and acknowledge Team A's constraints. Failure mode 2: The added process slows delivery.
• Course-correct: Put time limits on meetings, shift to async updates, narrow decision forums to only the necessary roles, and set a "default to proceed" with published dissent when risk is low.

Part B — Learning Quickly Under a Deadline (STAR)

Example STAR: Using geo-experimentation to measure incrementality in 14 days or less

• Situation: Two weeks before a major budget decision, leadership needed a reliable read on the incremental impact of a large marketing campaign where user-level attribution was not trustworthy. No one on my team had run geo-experiments recently.
• Task: Learn and carry out a practical geo-experiment (a market-level randomized test) to inform a multi-million-dollar spending decision before the finance gate.
• Actions:
  • Scoping and cuts (Day 1–2):
    • Cut: building a general-purpose library, advanced Bayesian structural time series, and elaborate dashboards.
    • Focus: matched-market randomization with difference-in-differences (DiD), pre-trend checks, power analysis, and a simple readout.
  • Rapid learning plan (Day 1–3):
    • Two 30-minute expert consultations; read two canonical papers or guides on geo-lift and DiD; drafted a two-page design doc (assumptions, risks, analysis plan).
  • Prototype and validation (Day 3–6):
    • Built a Python notebook to: match markets on history and seasonality, run power simulations, perform DiD with placebo tests, and compute confidence intervals.
    • Back-tested on three prior campaigns to validate bias and variance and calibrate expected lift error.
  • Pilot and execution (Day 7–12):
    • Ran a 10-day test on 10 matched market pairs (treatment and control) with pre-registered guardrails.
    • Daily monitoring with pre-set stop conditions (for example, severe divergences, external shocks).
  • Readout (Day 13–14):
    • Produced a one-page executive summary with lift estimate, 95% CI, sensitivity analyses, and a clear recommendation.
• Results:
  • The measured incremental lift was 6% (95% CI: 2–10%), substantially lower than the 20% implied by multi-touch attribution.
  • Leadership reallocated budget, avoiding overspend and improving expected ROI. We also adopted the design as a template for future geo-tests.
• Mistake and what I would do differently:
  • Mistake: The initial power analysis underestimated variance due to regional shocks, resulting in a borderline-wide CI.
  • Fix: Increase market pairs and extend duration for future tests; add synthetic controls as a robustness check. I also added a pre-registered external events log to flag shocks.
• How I validated I was learning the right things:
  • Expert reviews on the design doc; success criteria agreed up front (minimum detectable effect, CI width, decision threshold).
  • Back-tests with prior campaigns to check calibration; placebo tests to validate parallel trends.
• How I measured impact:
  • Quantified the delta between attribution-based and incremental lift; tied to dollars avoided or redirected.
  • Secondary: time-to-decision met the 14-day gate; methodology reused by two other teams within a quarter.

Part C — Disagreement With a Senior Stakeholder About Analytical Method

Example: Incrementality versus attribution for a spending decision

• Situation: A senior marketing leader wanted to scale a campaign based on last-click attribution that showed about 20% lift. I disagreed, arguing that we needed an incrementality test to avoid overestimating the impact.
• Task: Reach a decision that balanced speed and confidence without putting quarterly revenue at risk.
• Actions:
  • Uncover interests versus positions:
    • Position (stakeholder): "Scale now; attribution says 20%." Interest: hit revenue targets quickly, minimize the risk of underspending.
    • My position: "Run an experiment first." Interest: make a confident, defensible decision; avoid wasted spend and false positives.
  • Trade-offs proposed:
    • Rapid compromise: a two-week geo-experiment on 10 matched pairs covering about 15% of spend while keeping the remaining 85% as is.
    • Calibrate: use the experimental lift to adjust the attribution model going forward.
    • Guardrails: pre-registered KPIs, stop-loss thresholds, and executive-aligned decision rules.
  • Execution:
    • Designed DiD with pre-trend checks; daily monitoring; transparent updates to the stakeholder.
• Results and quantified impact:
  • Experimental lift: about 6% (95% CI: 2–10%), not 20%.
  • Decision: proceed with a smaller scale-up and reallocate part of the budget to higher-ROI channels.
  • Estimated impact: avoided several million dollars in low-ROI spend over the q …[truncated]…