DoorDash Senior Revenue Operations Manager - Comprehensive Interview Preparation Guide

Overview / goal
Design a nightly pipeline to replicate Salesforce → Snowflake using Fivetran ingestion and dbt transformations so revenue teams get consistent, auditable data for forecasting and dashboards.

High-level architecture

• Fivetran connector for Salesforce → raw schema in Snowflake (raw_* schemas, one table per SF object).
• dbt project transforms raw_* → modeled_* (staging, marts for ACV, ARR, opportunities).
• Orchestration via Airflow or Prefect to sequence: trigger Fivetran sync status check → wait/verify → run dbt models.

Incremental vs full

• Use Fivetran CDC/incremental by default for objects that support CDC to minimize load.
• Periodic full-refresh (weekly/monthly) for critical small objects or after schema migrations (controlled by orchestration).

Schema evolution

• Let Fivetran auto-detect and add columns into raw tables; store column metadata in a schema_registry table.
• In dbt, use schema.yml tests and version-controlled models; implement nullable fallback columns and defensive parsing for new fields.
• On breaking changes (field type change/drop), the orchestration pauses nightly runs, notify owners, and require manual dbt migration PR.

Idempotent writes

• dbt models use incremental strategy with unique key (salesforce_id) and updated_at logic:
  • insert new rows, update changed rows via merge (Snowflake MERGE ensures idempotency).
• Use transactional staging tables and atomic swaps (write to temp then rename).

Error handling & retries

• Orchestrator retries Fivetran API checks and dbt runs with exponential backoff (3 attempts).
• Capture Fivetran and dbt logs into centralized S3/Logging workspace.
• On persistent failures, create incident in Slack/email to data and revenue ops on-call.

Access controls

• Principle of least privilege in Snowflake: read-only role for analysts, transform role for dbt service account, admin for ops.
• Fivetran uses dedicated SF integration user with only necessary object access; store secrets in vault.

Validation & monitoring

• Post-run dbt tests: unique/not_null, freshness, rowcount comparisons vs previous run, reconciliation (e.g., total opportunities, sum of amount).
• Data quality checks implemented as dbt tests + Great Expectations or custom SQL sensors.
• Produce nightly data quality report and SLA dashboard (success/fail, latency, row deltas) surfaced in Looker/Tableau and Slack alerts.

Why this fits Revenue Ops
This design minimizes latency/cost, provides auditable, idempotent loads and automated quality checks so forecasting and GTM reporting are reliable and actionable for sales and finance stakeholders.

Executive summary (what I’d own as Revenue Ops lead)
I’d run the migration as a program: inventory Salesforce reporting assets, define canonical metric definitions, build a deterministic mapping to the new CRM, execute a staged ETL/backfill with reconciliation gates, and orchestrate stakeholder communications to eliminate reporting gaps.

Mapping strategy

• Inventory dashboards, reports, custom fields, formulas, and downstream ETL/BI feeds.
• Define canonical metric specs (e.g., ARR, ACV, SQL → Opp conversion) with business rules and sample SQL/pseudocode.
• Field-to-field mapping table: source field, transformation rule, data type, cardinality, owner, and backward-compatibility notes (legacy IDs, record status).
• Map time buckets and fiscal calendars explicitly to preserve trend continuity.

Backfill & continuity approach

• Build incremental ETL that supports both delta and full historical loads.
• Run a full historical backfill into the new CRM/warehouse in a sandbox; keep dual-write or CDC for a transition window.
• Maintain a read-only archival copy of Salesforce dashboards for legal/audit access.

QA / validation checks

• Row counts, key aggregates, and hash-based record matching.
• Metric-level reconciliations: week-over-week totals, cohort comparisons, and anomaly detection thresholds (e.g., >2% variance flags).
• Spot-checks with business users and automated tests (unit, integration).
• Smoke test dashboards in parallel; shadow reports for 2–4 weeks.

Minimizing downtime & rollback

• Freeze non-critical report changes during cutover; schedule cutover during low business impact hours.
• Enable a short dual-running period where reports read from new CRM; fallback plan to Salesforce if critical thresholds fail.

Stakeholder communications & governance

• RACI: data owners, BI engineer, CRM admin, finance, sales ops.
• Communication cadence: weekly status, pre-cutover readiness sign-off, 24-hour and 1-hour cutover alerts, and post-cutover validation report.
• Provide change log, updated metric definitions, and training sessions for report consumers.

Success metrics

• <2% variance on primary revenue metrics, zero critical dashboard downtime beyond scheduled window, and stakeholder sign-off on a reconciliation report.

Overview / Goals
Build a scalable RevOps org of 12 specialists while protecting service continuity, employee growth, and institutional knowledge. Phased 9-month plan: Define roles, assess skills, transfer responsibilities in waves, create career ladders, and implement knowledge capture.

New role definitions (examples)

• Analytics Lead (2): forecasting, dashboards, cohort analysis, self-serve BI.
• Systems & Integrations (3): CRM admin, ETL, API, release management.
• Process & Enablement (3): playbooks, SDR/AE workflows, onboarding, SOPs.
• Revenue Strategy & Ops (2): cross-functional projects, pricing, GTM experiments.
• Data Quality & Governance (2): master data, SLA, audit controls.

Skills assessment

• 1-week competency survey + hands-on task per domain (SQL, SFDC config, process mapping).
• Calibration interviews and scorecard (technical, domain, influence).
• Map current staff to target roles and gap analysis.

Phased transfer (3 waves)

• Wave 0 (0–1mo): shadowing, document current responsibilities, identify critical tickets.
• Wave 1 (2–4mo): transfer low-risk tasks; co-owned handoffs with runbooks.
• Wave 2 (5–7mo): full ownership of specialized teams; rotation weeks for context.
• Wave 3 (8–9mo): optimization, backfill, stabilization.

Career paths

• IC ladder (Analyst → Senior → Principal) and Mgmt ladder (Lead → Manager → Director) with skills/impact benchmarks, compensation bands, and learning plans.

Preserve institutional knowledge

• Mandatory runbooks, playbooks, decision logs, and code comments in a centralized wiki.
• Pairing program (2-week shadow + recorded walkthroughs).
• Monthly “war-room” retrospectives and a living RACI matrix.
• Quarterly knowledge audits and handoff sign-offs.

Success metrics

• <10% SLA breach during transition, zero reporting downtime, time-to-competency targets (30/60/90 days), employee retention >90%.

I’d run this plan with weekly steering, stakeholder checkpoints, and clear escalation paths to ensure smooth split and continued revenue operations health.

Situation & objective
Design a fair, data-driven territory plan for 60 quota reps selling a mid-market product to maximize coverage, efficiency, and predictable revenue.

Segmentation variables

• Firmographics: industry vertical, company size (employees, ARR bands)
• Geography: state/metro to minimize travel and respect time zones
• Propensity: intent signals, engagement score, technographic fit
• Account status: existing customers (expansion), named/seed, net-new
• Strategic priority: high-touch logo targets vs. high-volume self-serve

Sizing territories (TAM + workload)

• Calculate TAM per account as historical ARR or modeled ACV; sum by segment/geography.
• Workload score = (expected pipeline effort) = α * number of target accounts + β * average deal complexity + γ * expected travel/time. Normalize to reps.
• Allocate territories so each rep’s TAM and workload score are within ±10% of team median.

Quota allocation rules

• Start with bottoms-up: convert allocated TAM → achievable pipeline → quota using historical conversion/PV metrics.
• Base quota = median productivity * normalized workload; apply uplift/dealer for strategic accounts (+10–20%).
• Floor/ceil: min quota to preserve ramp fairness; stretch targets for top performers.

Annual rebalancing process

• Quarterly monitoring of coverage, quota attainment, capacity signals.
• Formal annual rebalance: refresh TAM, propensity models, churn/expansion trends; propose moves minimizing account churn (use 30–60 day transition with joint ownership).
• Governance: data-driven recommendations + stakeholder sign-off (Sales, CS, Finance); communicate changes 60 days pre-rollout with enablement playbook.

This plan balances fairness, predictability, and strategic focus while enabling measurable reassignments and minimal customer disruption.

Decision framework (RICE + Risk):

• Reach: how many reps/processes/customers affected
• Impact: % lift in revenue conversion, forecast accuracy, cycle time
• Confidence: data quality, stakeholder buy-in
• Effort: cost and FTEs
• Risk: compliance, revenue leakage, bad decisions

Score each initiative across these axes (0–10) and prioritize by (Reach * Impact * Confidence) / Effort, with a risk penalty.

Quantitative factors

• Revenue uplift potential (e.g., +2–10% conversion)
• Forecast accuracy improvement (pp change)
• Cost savings (FTE hours automated * hourly rate)
• Error rate / reconciliation time reduction
• Implementation cost and run rate
• Time to ROI (months)

Qualitative factors

• Data trust and auditability
• Cross-team dependence and adoption friction
• Strategic scalability (foundation vs. point automation)
• Regulatory/compliance exposure
• Change management complexity

Time-to-value (estimates from RevOps perspective)

• Data governance (master data, reconciliation, automated checks): 3–9 months to meaningful value (clean master, reliable reports), 9–18 months for full ROI.
• Automation (lead routing, playbooks, sequence automation): 1–4 months for quick wins (faster lead follow-up, increased conversion), 4–8 months for measurable revenue impact.

Recommendation under ambiguity

• If current data cleanliness <80% or frequent reconciliation/forecast disputes exist → prioritize Data Governance first. Rationale: automation amplifies bad data; governance is foundational and reduces risk of wrong sales actions and forecasting errors.
• If data is already reliable and lead response/time-to-contact is the binding constraint → choose Automation to capture immediate revenue.

Given ambiguity and typical RevOps contexts where poor data is common, I would choose Data Governance first to protect long-term revenue decisions while enabling future automation.

Mitigation for non-selected option

• Quick wins: implement low-effort automations (e.g., simple lead assignment rules) that don't rely on full master data.
• Safeguards: add validation steps, flag and quarantine records for manual review.
• Roadmap alignment: reserve a budget slice for pilots and integrate governance milestones to unlock automation sprints.
• Metrics & monitoring: instrument KPIs so the moment data quality reaches thresholds, automation can be scaled with confidence.

Brief framing (role): As a Revenue Operations Manager I’d combine operational systems and signals to build a reliable quarterly revenue forecast — focusing on ARR/MRR, bookings, upsell/churn risk, and timing (payment/invoicing). Below are primary sources, common data quality issues, and recommended update cadence.

CRM (Salesforce/Sales Cloud)

• Use: opportunities, stage history, close dates, ACV, contact/account hierarchy.
• Quality issues: stale stages, duplicate accounts, missing close reasons, forecast category misuse.
• Cadence: daily sync; formal forecast refresh weekly.

Billing / Invoicing (Stripe, Zuora, Chargebee)

• Use: recognized revenue schedule, billing cycles, renewals, partial payments.
• Quality issues: mismatched product SKUs, delayed invoice posting, manual credit notes.
• Cadence: near real-time for transactional, nightly aggregates for forecasting.

Invoicing / AR (QuickBooks, NetSuite)

• Use: invoice status, aging, payment timing, collections risk impacting cash forecast.
• Quality issues: unapplied payments, incorrect terms, manual adjustments.
• Cadence: daily/weekly for cash timing; monthly close reconciliation.

Marketing Automation (HubSpot, Marketo)

• Use: pipeline-sourced leads, campaign influence, lead-to-opportunity velocity.
• Quality issues: lead source inconsistencies, duplicate leads, stale lifecycle stages.
• Cadence: daily for funnel metrics; weekly for campaign impact.

Customer Success (Gainsight)

• Use: renewal dates, NRR/GRR signals, health scores, expansion opportunities.
• Quality issues: subjective health scoring, missing renewal notes, inconsistent tagging.
• Cadence: daily sync for critical flags; weekly rollup for forecast changes.

Product Telemetry

• Use: usage trends, adoption metrics, feature engagement that predict churn/expansion.
• Quality issues: sampling bias, instrumentation gaps, tenant mapping to accounts.
• Cadence: near real-time for alerts; weekly trends for forecasting.

External Market Indicators

• Use: sector growth, competitor pricing changes, macroeconomic indicators, market spend cycles.
• Quality issues: lagging indicators, noisy signals, relevance to customer cohort.
• Cadence: monthly / quarterly review; ad-hoc on major market events.

Closing note: combine these with a single source of truth (data warehouse), enforce data contracts and reconciliation routines, and drive cross-functional cadence (weekly forecast review, monthly re-forecast) to keep the quarterly forecast accurate and actionable.

Situation & objective
I would define the sustainment program to preserve ROI from a three-year revenue transformation by embedding governance, measurement, learning, incentives and an intentional transition into BAU so revenue processes keep improving.

Governance & health checks

• Quarterly Revenue Steering Committee (CRO, Finance, Sales Ops, CS, Marketing) for strategic decisions.
• Monthly RevOps Tactical Forum for backlog, blockers, and system issues.
• Automated weekly health checks: data sync success rate, lead-to-opportunity conversion, forecast accuracy, quota attainment; alerting when thresholds breach.

Continuous improvement

• Biweekly CI sprints: backlog from stakeholders, A/B tests, process tweaks; 90-day experiments with defined success criteria.
• Quarterly Kaizen reviews to roll up winning experiments.

Sustainability KPIs

• Forecast accuracy (% vs actual), pipeline velocity, churn rate, % of deals using new playbooks, time-to-revenue for new logos, data quality score.
• Dashboards with owners and SLAs for remediation.

Learning & refresh

• Role-based 6-month microlearning curriculum + just-in-time playbooks in LMS.
• Quarterly “office hours” and annual certification refresh for sellers/CS on new processes.

Incentive alignment

• Tie 20–30% of Sales/CS variable comp to behavior KPIs (process adoption, data hygiene, follow-up SLAs) alongside revenue targets.
• Team-level OKRs with mixed financial and adoption metrics.

Transition to BAU

• 12-month taper: convert program PMO into a RevOps enablement pod, transfer roadmaps, freeze new major initiatives to BAU backlog prioritization.
• RACI, runbooks, and a 6-month hypercare window with defined escalation paths.
• Quarterly executive reviews first year post-transition to sustain momentum.

I’d document everything, assign owners, and treat sustainment like a product with backlog, roadmap, and KPIs.

Approach (brief)
Calculate for each month in the last quarter (by created_at) the count of leads created that month and the subset that reached lifecycle_stage = 'SQL' after being 'MQL'. Use stage_changed_at to ensure conversion happened after creation, and use the month of created_at as the grouping key to avoid double-counting.

SQL (ANSI)

WITH last_quarter AS (
  SELECT *
  FROM leads
  WHERE created_at >= DATE_TRUNC('month', CURRENT_DATE) - INTERVAL '3 month'
    AND created_at <  DATE_TRUNC('month', CURRENT_DATE)
),
mql_to_sql AS (
  -- determine if a lead converted from MQL to SQL after creation
  SELECT
    lead_id,
    DATE_TRUNC('month', created_at) AS month,
    MAX(CASE WHEN lifecycle_stage = 'SQL' THEN stage_changed_at END) AS sql_at,
    MIN(CASE WHEN lifecycle_stage = 'MQL' THEN stage_changed_at END) AS mql_at
  FROM last_quarter
  GROUP BY lead_id, DATE_TRUNC('month', created_at)
)
SELECT
  month,
  COUNT(*) AS leads_created,
  SUM(CASE WHEN mql_at IS NOT NULL AND sql_at IS NOT NULL AND sql_at > mql_at AND sql_at >= created_at THEN 1 ELSE 0 END) AS converted_mql_to_sql,
  ROUND(100.0 * SUM(CASE WHEN mql_at IS NOT NULL AND sql_at IS NOT NULL AND sql_at > mql_at AND sql_at >= created_at THEN 1 ELSE 0 END) / NULLIF(COUNT(*),0),2) AS conversion_pct
FROM mql_to_sql
GROUP BY month
ORDER BY month;

Assumptions & boundary handling

• Grouping by month(created_at) attributes conversion to the lead’s creation month (ownership by marketing).
• We require sql_at > mql_at and sql_at >= created_at to ensure conversion happened after creation and after MQL state — avoids counting leads that converted before creation or simultaneously.
• Using DATE_TRUNC ensures month buckets; leads with stage changes on the exact boundary are deterministically included based on timestamps (>= for start, < for next month).
• If lifecycle history is in multiple rows, ensure upstream ETL preserves ordered stage_changed_at events; otherwise use an events table or window functions to reconstruct transitions.

Approach (brief)
I’d run a structured reconciliation: align committed CPQ orders to billed/recognized revenue by key dimensions (order_id, acct_id, invoice_id, product_sku, revenue_date, currency).

Exports / Tables to pull

• CPQ committed orders export (order_id, quote_id, acct_id, product, qty, price, committed_date, start_date, end_date, currency, amendment_flag)
• Order management / ERP orders (order_id, invoice_id, invoice_date, billed_amount, currency, status)
• Billing recognition ledger (recognition_id, order_id, revenue_date, recognized_amount, GL_code)
• AR / Credit memos (invoice_id, credit_amount, reason)
• Integration logs (middleware success/failure, timestamps)
• FX rate table for period

Example SQL checks

-- Sum committed vs recognized by order
SELECT c.order_id, c.acct_id, SUM(c.committed_amount) AS committed, COALESCE(SUM(r.recognized_amount),0) AS recognized
FROM cpq_committed c
LEFT JOIN revenue_recogn r ON c.order_id = r.order_id
GROUP BY c.order_id;

Check mismatches, unmatched invoices:

SELECT r.invoice_id FROM revenue_recogn r
LEFT JOIN erp_invoices e ON r.invoice_id = e.invoice_id
WHERE e.invoice_id IS NULL;

Common root causes

• Timing: recognition period cutoff vs CPQ committed_date
• Amendments / cancellations not reflected
• FX conversion differences or rates not applied
• Failed/missing integrations or duplicate records
• Unapplied credits or manual journal entries

Stakeholders to interview

• Finance (Revenue Accounting) for recognition rules
• Billing/AR for invoice issues and credits
• Sales/RevOps for amendments and committed definitions
• IT/integration team for middleware logs
• Customer Success for contract amendments

Remediation

• Short-term: isolate variance by bucket (timing, FX, integration, credits), apply manual correcting JE with approval
• Mid-term: automated reconciliation job with alerts for mismatches by order_id and thresholds
• Long-term: tighten CPQ->ERP mapping, add required fields (amendment_id), schedule FX snapshot at close, SLA on integrating amendments, run daily integration health dashboards

Metrics to track

• Mismatch rate by period, time-to-resolution, number of failed integrations, % of amendments applied within SLA.

Brief definition

Leading indicators predict future revenue performance (early signals you can act on). Lagging indicators measure outcomes after the fact (confirm results, validate strategy).

Three leading indicators (weekly scorecard)

• Pipeline coverage ratio (value of open opportunities / quota)

  • Why leading: reflects future capacity to hit targets.
  • Action: if below threshold, trigger pipeline generation programs, reassign reps, or accelerate deal progression.

• Marketing-qualified leads (MQLs) accepted by SDRs

  • Why leading: upstream flow of vetted demand that will convert into opportunities.
  • Action: investigate drop-offs between channels and SDR acceptance; optimize campaign targeting or lead handoff SLAs.

• Sales activity velocity (avg touches per opportunity per week + time-to-first-response)

  • Why leading: activity cadence drives conversion rates and deal velocity.
  • Action: coach reps, automate follow-ups, adjust playbooks if velocity lags.

Three lagging indicators (weekly scorecard)

• Bookings / new ARR closed this week

  • Why lagging: result of prior activities and pipeline.
  • Action: reconcile forecast accuracy, run win/loss analysis, adjust resource allocation.

• Win rate by cohort

  • Why lagging: shows effectiveness of go-to-market and qualification after deals close.
  • Action: refine qualification criteria, update ICP, or tailor enablement for low-performing segments.

• Churn / logo loss (weekly trend)

  • Why lagging: outcome of retention efforts and product-market fit.
  • Action: escalate at-risk accounts to CS, root-cause churn, prioritize retention initiatives.

Each metric includes thresholds and owner, and should be trended week-over-week to distinguish noise from signal.