Senior Data Analyst Interview Preparation Guide | Airbnb (2026)

Direct answer

Sponsorship means spending your own credibility to open a door someone couldn't open for themselves, which is different from mentoring, which is advice given directly to the person. The core act is advocating for them by name in a room they aren't in, backed by specific, evidence-based reasons they deserve the opportunity.

What sponsorship requires

Political capital and timing, not just advice. Mentoring can happen anywhere, anytime, one on one. Sponsorship requires actually being present, or having enough standing, in the room where a real decision gets made: a promotion committee, a staffing decision, an assignment to a high-visibility project.

An evidence-backed case, not a vague endorsement. "They're great" doesn't move a room. Specific, concrete contributions you can vouch for personally do. Building this case ahead of time, before the opportunity comes up, is part of the work.

Deciding when it's warranted. The right moment is when someone is already delivering at the target level but lacks the visibility or exposure to be considered for it, there's a real decision window open, and you have enough credibility in that specific room for your advocacy to actually carry weight.

Making the specific ask. Vouching in general terms is weaker than naming the specific opportunity and asking for the specific outcome: this person, for this role, on this team, now.

Aftercare. Sponsorship only compounds if the person knows it happened. Telling them what you did lets them lean into the opportunity and know someone is actively in their corner, not just quietly hoping things work out. Following up on the outcome, win or not, matters too.

Worked example

Someone you work closely with does excellent work but has almost no visibility outside their immediate team. A high-visibility opportunity, or a promotion cycle, comes up in a room they aren't part of. You go in with specific, concrete contributions you can personally back, not general praise, and explicitly vouch for their readiness for that specific opportunity. Afterward, they're included in the opportunity or the promotion conversation, and you tell them directly what you did and why, rather than letting them find out secondhand or not at all.

Trade-offs and pitfalls

Sponsoring someone whose work you can't concretely back with specifics spends your credibility on hope rather than evidence, and if it doesn't pan out, it costs you standing in that room for the next person you'd want to sponsor.

Sponsoring quietly and never telling the person defeats much of the point. They don't know to lean into the opportunity, and they don't know someone is actively advocating for them, which is often as valuable as the opportunity itself.

Sponsorship is finite. You have a limited amount of credibility to spend across your whole network, which means you genuinely cannot sponsor everyone equally, and who you choose to spend it on is a real, sometimes uncomfortable decision worth being honest with yourself about.

A common confusion is treating a glowing performance review comment as sponsorship. Real sponsorship requires actually being in the room, advocating for a specific decision, not just praising someone in the abstract where it doesn't reach the decision-maker.

Direct answer

The decision is entirely about expected cell counts under independence, not raw counts: compute the expected table (row total times column total divided by N), and if any expected cell falls below about 5, the usual chi-square approximation isn't trustworthy. For a small 2x2 table, use Fisher's exact test, which is exact and needs no asymptotics. For a larger table with low expected counts, approximate the null distribution by Monte Carlo simulation of tables with the same expected probabilities. Otherwise, when every expected count is at least 5, use the standard Pearson chi-square test.

Approach

1. Compute expected counts from the marginal totals: expected[i, j] = row_sum[i] * col_sum[j] / N.
2. If the table is 2x2 and any expected cell is below 5, run Fisher's exact test.
3. Else if any expected cell is below 5 for a larger table, run a Monte Carlo chi-square: simulate many tables under the independence null (a multinomial draw with cell probabilities equal to expected / N) and estimate the p-value as the fraction of simulated chi-square statistics at least as extreme as the observed one.
4. Otherwise, run the standard chi-square test.

import numpy as np
from scipy.stats import chi2_contingency, fisher_exact
from numpy.random import default_rng


def auto_contingency_test(table, monte_carlo_iters=10000, random_state=0):
    """
    table: 2D array-like of non-negative counts.
    Returns {'test', 'statistic', 'p_value'}.
    """
    table = np.asarray(table)
    if table.ndim != 2:
        raise ValueError("Input must be a 2D array")
    if (table < 0).any():
        raise ValueError("Counts must be non-negative")
    N = table.sum()
    if N == 0:
        raise ValueError("Table has zero total count")

    row_sums = table.sum(axis=1, keepdims=True)
    col_sums = table.sum(axis=0, keepdims=True)
    if (row_sums == 0).any() or (col_sums == 0).any():
        raise ValueError("Table has a structurally empty row or column (sums to zero); collapse or remove it before testing.")
    expected = row_sums @ col_sums / N
    low_expected = (expected < 5).sum()
    rows, cols = table.shape

    if rows == 2 and cols == 2 and low_expected > 0:
        odds_ratio, p = fisher_exact(table)
        return {"test": "fisher_exact", "statistic": odds_ratio, "p_value": p}

    if low_expected > 0:
        rng = default_rng(random_state)
        p_cell = (expected / N).ravel()
        chi2_obs, _, _, _ = chi2_contingency(table, correction=False)
        exceed = 0
        for _ in range(monte_carlo_iters):
            sim_flat = rng.multinomial(N, p_cell)
            sim_table = sim_flat.reshape(table.shape)
            chi2_sim, _, _, _ = chi2_contingency(sim_table, correction=False)
            if chi2_sim >= chi2_obs:
                exceed += 1
        p_mc = (exceed + 1) / (monte_carlo_iters + 1)  # add-one smoothing avoids p=0
        return {"test": "monte_carlo_chi2", "statistic": chi2_obs, "p_value": p_mc}

    chi2, p, dof, exp = chi2_contingency(table, correction=False)
    return {"test": "chi_square", "statistic": chi2, "p_value": p}

Key points

• The "expected count of at least 5 in every cell" rule of thumb drives the branch, not the observed cell counts or total N alone. A large table can still have low expected counts if it has many categories.
• Fisher's exact test is applied here only to 2x2 tables, its usual formulation. Larger sparse tables use Monte Carlo instead of extending Fisher's exact combinatorics.
• Monte Carlo simulates from the independence null, a multinomial draw with cell probabilities equal to expected / N over the fixed total N. It approximates the null of independence; it does not exactly condition on both margins the way Fisher's exact does.
• Add-one smoothing on the Monte Carlo p-value avoids ever reporting p = 0, which would otherwise happen whenever no simulated table is as extreme as the observed one.

Worked example

Executed with monte_carlo_iters=10000 and random_state=0 for the Monte Carlo branch:

Re-running the sparse case with the same random_state=0 reproduces the identical statistic and p-value: repeating the call returns exactly 7.0636 and 0.139486 again. That is the point of pinning the seed, anyone re-running this function on the same table and seed gets the same reported p-value.

Complexity

Computing expected counts is O(R x C) for an R by C table; the chi-square and Fisher branches are O(R x C). The Monte Carlo branch is O(iters x R x C), which dominates for large monte_carlo_iters, with O(R x C) additional memory per simulated table, not retained across iterations.

Edge cases

• An all-zero table raises (N=0 is undefined); negative counts raise.
• A row or column that sums to zero is caught by an explicit guard before the expected-count computation and raises a clear ValueError ("structurally empty row or column"), rather than being silently routed anywhere. Without that guard, scipy's own chi2_contingency raises a much less actionable internal error when it hits a zero expected cell; either way, a structurally empty category needs to be collapsed or removed by the caller, not simulated around.
• A single borderline expected cell (say 4.9) routes to Monte Carlo even though a chi-square approximation would likely still be adequate. Exposing the 5-count threshold as a parameter rather than hardcoding it avoids over-triggering the slower branch on marginal cases.

Trade-offs & pitfalls

• Fisher's exact vs the Monte Carlo simulated null: Fisher's exact test conditions on both the row and column margins and enumerates the exact null distribution of tables sharing those margins, so its p-value is exact, not approximate. That exact conditioning is also why the standard formulation is a 2x2-only tool: enumerating every table with fixed margins gets combinatorially expensive as the table grows beyond 2x2. Monte Carlo instead draws simulated tables from a multinomial with cell probabilities equal to expected / N, which works for any table shape but does not condition on the observed margins the way Fisher's does. It approximates a related, not identical, null, and the reported p-value carries simulation noise that shrinks only as $1/\sqrt{\text{iters}}$, not to zero.
• When each is right: reach for Fisher's exact whenever the table is 2x2, regardless of how small the counts are, since it costs nothing extra and gives an exact answer. Reach for Monte Carlo only once the table is larger than 2x2 and has low expected counts; a borderline Monte Carlo p-value (close to the alpha threshold) is itself uncertain and deserves either more iterations or a fixed, reported seed rather than being treated as a firm cutoff.
• Computational cost at scale: each Monte Carlo iteration costs a multinomial draw plus a chi-square recomputation, so total cost is O(iters x R x C). Tightening the p-value's precision by roughly $\sqrt{10}$ means going from, say, 10,000 to 100,000 iterations, a 10x runtime increase for a proportionally small precision gain. That cost compounds when the test sits inside a larger loop (bootstrapping over many sub-tables, or running per group in a big categorical breakdown), so the iteration count is a real budget decision, not a free knob to crank up.
• Collapsing sparse categories vs simulating around them: when the low counts come from categories that are conceptually mergeable (adjacent low-count levels, or a long tail of rare "other" values), collapsing them into fewer, higher-count groups before testing is usually the better move: it fixes the expected-count problem directly, keeps the test exact or asymptotically valid, and avoids the simulation cost entirely. Reach for Monte Carlo instead when the categories are analytically distinct and merging them would erase the question the test is meant to answer, meaning the sparsity is real signal from having many genuine categories, not an artifact of over-fine binning. Whichever categories get collapsed should be decided from domain reasoning before looking at the result; collapsing categories after seeing which cells drove significance is a form of post-hoc data snooping.

Direct answer

When I've been stuck for hours with no real progress, the move is to timebox the solo effort, then escalate with a tight, evidence-backed ask rather than a vague "I'm stuck." I pick the person most likely to have relevant context, hand them exactly what I've tried and ruled out plus my current best hypothesis, and ask a specific question I can act on. I also treat the conversation as a chance to learn the debugging path, not just to get the bug fixed, so I ask them to walk me through their reasoning rather than just take over.

Structured elaboration

Three things separate an escalation that gets fast, useful help from one that wastes everyone's time.

Recognize the point to escalate. Hours of no forward progress, the same hypothesis getting disproven twice, or a growing business impact are all signals to stop debugging in isolation. Escalating isn't giving up; treating a stall as a private failure and grinding past it is usually the more expensive choice, since it delays the fix and burns morale.

Frame the ask so it's cheap for the other person to answer. A strong ask front-loads: what's broken and its impact, what I've already tried and ruled out (so they don't repeat my dead ends), my current best hypothesis, and the specific, answerable question I need from them, not "can you help me debug this." Vague asks force the helper to reconstruct the whole problem from scratch, which is slower for both people and more likely to produce a shallow answer.

Protect the learning, not just the fix. If I let a colleague take the keyboard and fix it themselves, I get a working system and no new skill. Instead I ask them to pair with me, narrate their reasoning, and explain the "why" behind their diagnosis, not just the "what." After the session I write up the root cause and what I'd check first next time, so the time spent debugging together converts into a pattern I now own, not just a one-off save.

Worked example

At a previous job I spent most of a morning chasing an intermittent issue where an order-events pipeline was silently dropping a small fraction of events downstream, and the billing system consuming them was under-counting as a result. I'd checked the obvious things: manually retried the failing batch (it succeeded, ruling out a permanent data problem), confirmed the consumer wasn't crashing, and grepped the logs for errors with nothing conclusive.

At that point I stopped and escalated to the engineer who owned the downstream consumer, since the pattern pointed at something on their side of the boundary. Instead of "the events pipeline is dropping stuff, can you look," I sent: "Orders occasionally don't reach billing. Confirmed: not a crash, not a permanent data issue (manual retry succeeds), happens only on retried events, started around the deploy three weeks ago. My hypothesis: the idempotency key (a value the system uses to recognize "I already processed this exact request" so it does not get repeated) change in that deploy might be silently deduplicating legitimate retries as if they were true duplicates. Can you confirm whether that key changed, and if so, walk me through how dedup decides a retry is a duplicate?" That question was specific enough to answer in five minutes instead of forcing them to re-derive the whole investigation.

We paired for fifteen minutes; they confirmed the key change and walked me through the dedup logic rather than just patching it themselves. I found the actual bug (a timestamp component in the key that shifted on retry) while they explained the design, wrote the fix, and added a short note to our team's runbook describing the symptom and the check I'd now do first.

Trade-offs and pitfalls

Escalating too early, before doing basic legwork, burns trust and wastes the helper's time on something a search or a log read would have answered. Escalating too late, after silently struggling well past the point of diminishing returns, delays the fix and can read as an unwillingness to ask for help. The most common mistake once you do ask is dumping raw logs or a vague "not working" and expecting the other person to do the triage; that shifts the cognitive load onto them instead of narrowing it for them. The other common trap is letting the helper drive the keyboard for the whole session: the bug gets fixed, but you learn nothing and will be back in the same spot next time.

Direct answer
Replace a vague quantifier with a specific number, a specific comparison point, or an explicit definition of what counts, so the reader can check the claim rather than just trust your impression of it.

Structured elaboration

• "Significant increase" is unfalsifiable on its own: significant compared to what, and by how much? Fix it by naming the actual number and the baseline it's compared against.
• "Large drop" has the same problem in the other direction; a reader can't tell if that means a 5% dip or a 50% collapse.
• The general pattern: replace a subjective adjective ("significant," "large," "modest") with either a number and a baseline, or, if the exact number genuinely isn't available, an explicit statement of the range and why it's uncertain, which is still more falsifiable than a bare adjective.
• A quick self-check: could someone else look at the underlying data and disagree with whether your adjective was the right one? If yes, the phrase is doing too much subjective work and needs a number behind it.

Worked example
Vague: "Revenue saw a significant increase this quarter."
Specific: "Revenue grew 18% quarter-over-quarter, from $4.2M to $5.0M."

Vague: "There was a large drop in signups after the pricing change."
Specific: "Signups fell 34% in the two weeks after the pricing change, from roughly 1,400/week to about 920/week."

Vague: "Customer satisfaction scores showed a modest improvement."
Specific: "Our NPS (Net Promoter Score, a customer-loyalty survey metric typically scored from -100 to 100, based on how likely customers are to recommend you) moved from 32 to 38, a 6-point increase, over the last two survey cycles."

Each rewrite keeps the same claim but replaces the reader's guesswork with a number and a comparison point they can independently evaluate.

Trade-offs and pitfalls

• If you genuinely don't have the precise number, don't invent a specific-sounding one to appear rigorous; say "we don't have an exact figure yet, but early signals suggest an increase" rather than fabricating false precision.
• Numbers without a baseline can still mislead ("revenue grew 18%" sounds good until you learn it grew from a very small base); include enough context that the number is honestly interpretable, not just numeric.
• Overloading every sentence with numbers can make a document harder to read, not easier; reserve the rigor for the claims that are actually load-bearing for a decision.

PostgreSQL's ILIKE does case-insensitive pattern matching directly; for engines without it, wrapping both sides in LOWER() gets the same result.

Structured elaboration

-- PostgreSQL
SELECT email FROM customers WHERE email ILIKE '%@gmail.com' OR email ILIKE '%@yahoo.com';
-- Portable (no ILIKE)
SELECT email FROM customers WHERE LOWER(email) LIKE '%@gmail.com' OR LOWER(email) LIKE '%@yahoo.com';

Both domains need their own comparison, joined with OR: there's no single LIKE pattern that matches "ends in gmail.com or ends in yahoo.com" in one clause, since a pattern only expresses one shape at a time. Note the pattern literals themselves must already be lowercase in the second, portable form, since only the column side is being normalized by LOWER().

Worked example

Given emails 'a@Gmail.com', 'b@YAHOO.com', 'c@other.com': both queries correctly return the first two rows (matching regardless of how the domain's case varies) and exclude the third, since 'other.com' matches neither the gmail.com nor the yahoo.com branch of the OR.

Trade-offs and pitfalls

Wrapping the column in LOWER() (or any function) can prevent the engine from using a plain B-tree index on that column, since the index is built on the raw values, not their lowercased form; a functional index on LOWER(email) recovers the ability to seek instead of scan, at the cost of maintaining an extra index. This is worth mentioning but isn't required to answer the query itself correctly.

Direct answer
Map nominal data (unordered categories) to color hue or shape, ordinal data (ordered categories without meaningful numeric spacing) to a sequential color scale or position along an ordered axis, and interval or ratio data (meaningful numeric spacing, with ratio data also having a true zero) to position, length, or area, since those channels support precise magnitude comparison that nominal/ordinal data doesn't need or support.

Structured elaboration

• Nominal: categories with no inherent order (e.g. product line, region); map to hue (a categorical color palette) or shape, since there's no magnitude to encode, only identity.
• Ordinal: categories with a meaningful order but no consistent numeric spacing (e.g. customer satisfaction: low/medium/high); map to a sequential color scale (light to dark) or an ordered position on an axis, preserving the ORDER without implying the gaps between categories are numerically equal.
• Interval: numeric data with meaningful spacing but no true zero (e.g. a calendar date, or a temperature-like index); position along an axis works well, but ratio statements ("twice as much") aren't meaningful, so avoid area or a zero-anchored bar chart implying a ratio comparison that isn't valid.
• Angle: a weaker channel than position or length for ratio data (per Cleveland-McGill: William Cleveland and Robert McGill's classic 1984 study that ranked how accurately people judge different visual channels, from position and length at the top down to angle, area, and color at the bottom; humans judge angles less accurately), most familiar as pie or donut slice size; usable for ratio data in a pinch, but a sorted bar chart is generally the more precise choice when exact ranking matters.
• Ratio: numeric data with a true zero (e.g. revenue, count of users); this is where length, area, and zero-based bar charts are fully valid, since "twice the length/area" genuinely means "twice the value."
• Why some encodings are more perceptually accurate: position and length are judged by the human visual system with the least error across viewers (per Cleveland-McGill), which is why ratio/interval data (where those channels are valid) should generally prefer them over area or color when precision matters.

*Worked example (e-commerce sales dashboard)

• Nominal: payment method (credit card, PayPal, etc.) shown as distinct colored segments in a stacked bar, since there's no inherent order.
• Ordinal: customer satisfaction tier (low/medium/high) shown with a sequential color scale from light to dark, preserving order visually.
• Interval-like: a day-of-week index used for seasonal pattern coloring, where position matters but "Wednesday is twice Monday" isn't a meaningful statement.
• Ratio: revenue by region shown as bar length, where a bar twice as long genuinely means twice the revenue.

Trade-offs and pitfalls
Using a bar chart (implying a ratio, zero-based comparison) for interval data without a true zero, or using color to represent ratio data where a viewer needs precise comparison, are the two most common mismatches between data type and encoding.

Choosing between Total Revenue and Number of Engaged Paid Accounts as a north star is really a choice about what stage and business model the company is in, since each rewards a different kind of growth and can actively mislead if picked at the wrong stage.

A framework for the decision

Three diagnostic questions for leadership

1. "If we doubled revenue this quarter purely through a large one-time enterprise deal with no repeat usage, would we consider that a genuine win for the business?" (A 'no' points toward Engaged Paid Accounts, since Total Revenue alone can't distinguish durable growth from a one-off windfall.)
2. "Is our biggest current risk that we're not charging enough for the value we deliver, or that customers aren't sticking around and expanding?" (Under-monetization points toward Total Revenue; churn/engagement risk points toward Engaged Paid Accounts.)
3. "Can most teams in the company directly influence this metric, or does it depend heavily on a small sales/enterprise motion outside most teams' control?" (A metric only sales can move is a weak company-wide north star regardless of which one you pick.)

Trade-offs and pitfalls

A pure Total Revenue north star at an early stage risks the team optimizing for large, one-off deals or aggressive discounting that inflate the number without building durable product-market fit; a pure Engaged Paid Accounts north star at a later, scale stage risks under-emphasizing the actual monetization efficiency the business needs to prove to investors. Many mature companies eventually pair a primary north star with the other as an explicit guardrail, rather than picking one and ignoring the other entirely.

Direct answer. Default per-column statistics assume each column's values are distributed independently of every other column, so when two columns are actually correlated, the optimizer multiplies their individual selectivities together and ends up with an estimate far lower (often wildly so) than the true combined selectivity; extended statistics explicitly capture how those columns co-vary, letting the optimizer estimate the combined predicate's selectivity directly rather than assuming independence.

Structured elaboration. If a city column and a state column are each individually somewhat selective on their own, but every value of city in the data only ever co-occurs with one specific state (a real-world correlation: cities belong to exactly one state), the independence assumption badly overestimates how selective city = X AND state = Y really is: multiplying each column's standalone selectivity together implies the combined predicate is far MORE selective than it actually is, since knowing the city already tells you the state with certainty. Extended (multi-column) statistics record the actual joint distribution across a specified set of correlated columns, so the optimizer can look up (or closely approximate) the real combined selectivity instead of computing a product that assumes independence.

Worked example. Two predicates might each independently match 10% of rows on their own; if they were truly independent, the combined predicate would match roughly 1% (10% times 10%). If the columns are perfectly correlated (every row matching one predicate also matches the other), the true combined match rate is still 10%, not 1%, a ten-fold estimation error that can easily push the optimizer toward an index-heavy plan appropriate for a genuinely rare combination, when the real combination is common enough that a scan-based plan would have been the better choice.

Trade-offs and pitfalls. Extended statistics have to be explicitly created and targeted at the specific column combination that's actually correlated, most engines don't infer correlation automatically and build multi-column statistics for every possible column pair on their own, since that would be prohibitively expensive to maintain; you generally need to notice the estimation error first (via an estimate-actual mismatch on a predicate involving those columns) before you know which specific column combination is worth the investment. Once created, verify the fix by re-checking that predicate's estimated-vs-actual row count, rather than assuming creating the statistics automatically resolved the issue, since the statistics also need to be genuinely representative of the current data to help.

Direct answer: This is a personal-fit story in STAR format, and the honest, credible version of this answer connects a real value you hold (belonging/inclusion, specifically) to a concrete past action, not a generic claim that you "believe in diversity," which any candidate can say without evidence.

Structured elaboration:

1. Name the specific value, precisely. "Belonging and inclusion" is broad; be specific about what that means to you in practice (for example, actively making sure quieter voices get heard, or making onboarding genuinely welcoming for people who don't share the team's existing shorthand and context).
2. Situation-Task-Action-Result. Pick one real, specific instance, not a composite of "things I generally do." Describe the situation concretely, what you specifically took on, the action you took, and an honestly-stated result.
3. Connect it forward, specifically. Rather than a generic "so I'd bring that here too," name something concrete about how this cross-functional environment specifically would benefit from that same behavior (e.g., "in a fast-moving cross-functional team, making sure the quieter specialist voice gets heard before a decision is locked in matters even more, because that's often where a real risk gets caught").

Worked example: "One value I hold strongly is making sure people who don't have an obvious 'in' still get heard and get real opportunities, not just symbolic inclusion. On a past project, a contractor on our team, brought in for a specific skill set, had genuinely valuable input on an architecture decision but wasn't included in the core planning meetings by default, since contractors historically weren't. I pushed to include them in the relevant sessions, and their input changed our approach to a scalability risk we'd otherwise missed until much later. It took a bit of pushing against 'that's just how we've always run these meetings,' but it was a small, concrete change with a real result. In a cross-functional environment like this one, where the person with the most relevant knowledge isn't always the one automatically in the room, I'd bring that same instinct to actively check who should be there but isn't yet."

Trade-offs and pitfalls: Avoid a purely values-statement answer with no concrete instance behind it; interviewers can tell the difference between someone reciting a value and someone who's actually acted on it. Also, keep this proportionate; a topic mostly owned by candidate-company-values-fit content elsewhere means keep the answer light and specific rather than turning it into a full essay on your DEI philosophy.

Situation: At my last company, Marketing wanted detailed weekly, channel- and creative-level campaign metrics for optimization, while Finance demanded reconciled ROI and spend allocation for monthly forecasting. Both priorities were urgent and required overlapping data sources, threatening to overload our two-person analytics team.

Task: I needed to negotiate scope and timelines so both teams got actionable insights without burning out my team or producing low-quality work.

Action:

• Convened a one-hour joint prioritization workshop to align on decisions they’d make from the data (optimization vs. forecasting).
• Proposed an MVP split: a near-term automated weekly dashboard for Marketing focused on key levers (CTR, CPA, conversion rate by channel/creative) and a parallel monthly reconciled ROI report for Finance that used the same ETL with additional cost allocations.
• Negotiated timelines: 3 weeks for Marketing MVP, 4 weeks for Finance full report (Finance accepted a 1-week interim reconciliation summary).
• Defined scope clearly with a RACI: analytics builds ETL + dashboards, Marketing validates segmentation, Finance validates cost rules.
• Technical steps: built one reusable ETL in SQL to join ad platform, CRM, and billing data; created parameterized Tableau dashboards to support both use-cases; automated nightly refreshes; documented assumptions and a data dictionary.
• Protected the team: limited ad-hoc requests during build phase, set a buffer sprint day for urgent fixes, and cross-trained a marketing analyst to handle basic dashboard filters.

Result: Delivered the Marketing MVP in 3 weeks and the reconciled Finance report in 4. Marketing reduced time-to-insight for campaign decisions by ~60%; Finance gained month-end ROI figures with <5% reconciliation variance versus budgets. Ad-hoc firefighting fell ~40% because of automation and documentation. Both teams reported higher trust in metrics and agreed the staged, shared-ETL approach balanced their needs without overloading analytics.