Analytics With a Seat at the Table: How DoorDash Builds a Centralized Data Team

Lachs says she has two core beliefs about structuring a data team. First, analytics should sit alongside engineering, product and operations as a function that drives business impact, not one that answers questions through Jira tickets and builds dashboards on request. That was never the team she wanted to build, and she describes the service-desk version of the job as one she would not want herself.

Her second, more contrarian view is that analysts should not be embedded in business units. "Central" here mostly means reporting lines: marketing analytics belongs to the broader analytics org rather than reporting into the head of marketing. The goals, however, are shared with partner teams, and DoorDash has experimented with the embedded alternative in the past and found it much more problematic.

She concedes that business leaders like embedding for good reasons: camaraderie, a sense of ownership, and control over the roadmap. DoorDash solves for those by dividing the central team into pods that map onto how product, engineering, operations and marketing are organized. Analysts are effectively embedded with their partners and share their goals, but their reporting line runs up through her, so success is mutual while the central benefits are preserved.

Lachs lists several benefits of the central model. The first is a consistent and higher talent bar, since every candidate is judged against the same technical and soft-skill rubric. The second is growth: a senior data scientist in marketing has nowhere to go if the only path is inside marketing, whereas a central org lets people move to merchant analytics or into a management role elsewhere, which helps retain talent.

Third is consistency of methodology and metrics, so "sales" means one thing everywhere and a churn-prediction model is built once with input from six teams instead of six times. Seeing the same problems across teams also helps the group spot issues early and automate them, which she describes as seeing around corners. Finally, there is team culture: a shared identity, peer review and like-minded colleagues are much harder to build in small, isolated pockets.

The conversation turns up a small coincidence: both DoorDash and Airbnb's early data teams nicknamed themselves the "A-Team." Lenny notes that Airbnb's later moved toward a data-science identity, while Lachs says her team will always be the A-Team.

Lenny asks how a team can be proactive while still answering a constant stream of questions. Lachs says it never gets easier: exploratory work is the first thing to slip because its expected value is uncertain compared with a known deliverable that makes someone happy. DoorDash counters this by setting goals for self-directed work and running hackathons, and business partners support the time because past deep dives have fed future roadmaps.

Her example is a hackathon on referrals as a consumer-acquisition channel, which looked below average on engagement and payback. Instead of just cutting spend, the team tried referring each other and even committing referral fraud (leaving the office with an embarrassing number of cupcakes). They found the channel was bimodal: strong users referring strong users, plus a group posting codes online to harvest credits under lax fraud rules and no caps. The result was better fraud checks and caps, and a lesson that averages can be badly misleading.

On pushing back, Lachs says leadership should set the operating model so junior analysts are not forced to say no alone. Because the team shares goals with its partners, it can ask whether a new request outranks the other three things planned for the week, and make the trade-off explicit rather than suffering in silence. She also admits to occasionally knocking out a quick favor to build goodwill.

Technical skills are table stakes at DoorDash, with a screen to check them. What Lachs says separates her best people is curiosity and self-motivation: the person who notices something odd after the question is already answered and keeps pulling the thread without being told. She says she cannot teach it, so she screens for it.

One method is to plant something subtly wrong in a case and see whether the candidate notices, or where they go once it is pointed out. Another is to ask for past examples where they noticed an anomaly and investigated. She admits soft skills are much harder to test than hard ones, and that questions often assess something other than what they literally ask.

The early interview stages combine a coding exercise with a short business case, usually based on a real DoorDash problem. Most candidates get something wrong because the interviewer knows the business better, and Lachs watches how they react to being told so, how they take new information and pivot. She also pushes everyone to commit: "If you had to make a call right now, what would it be?"

Lachs jokes that she has a job she would never be hired for today, since she has no traditional data-science training. She began in investment banking, was DoorDash's first general manager, and taught herself SQL and Python out of necessity when the company needed someone to work out how to set goals and gauge market performance about ten years ago. Founder and CEO Tony Xu recognized that strength in her.

She argues the background helps: she can hire PhD statisticians and machine-learning specialists who are more technical than she is, while keeping them pointed at business impact thanks to her finance-driven pragmatism. She says the mix has been a good partnership between their depth and her grounding.

Asked what let her succeed, she says she has imposter syndrome like everyone else, and that it all happened organically. She needed data, did not want to keep bothering an engineer, so she learned Python, and she solved the problem in front of her rather than designing a global org. She credits a competitive streak and a DoorDash culture of doing whatever it takes to win, down to taking out the garbage on Saturday nights.

Lachs recalls launching Boston in the winter of 2014 as the first GM, in a team of four. They went out at 5 a.m. to hand out promo codes attached to snack bars. Their sales rep, whose pay depended on signing merchants, joined in too, which she cites as an example of extreme ownership of the outcome that Tony Xu and the other co-founders instilled.

On her first visit to the Palo Alto headquarters, then in a former animal hospital, a big site outage hit and the roughly twenty-person company dropped everything to do customer support. She went out dashing to fetch pizza for the team so that dashers would not be pulled away, and she says that night was one of the largest refunds as a share of the company's bank account. It was given because the service had failed and the company wanted to do right by customers.

The tradition continues in the WeDash program, where employees dash or do customer support several times a year. Lachs goes pair dashing with a colleague. It builds empathy for consumers, dashers and merchants, and it is also a good way to catch bugs in the product.

Extreme ownership, she says, is both cultural and a hiring trait, and it comes from the top. She expects her data scientists to care about solving the problem rather than the box they fit in. Just the day before, a team whose affordability launch had not worked simply made phone calls to customers, because qualitative research was what was needed to unblock the next test.

Lachs says she has learned most about metrics from picking bad ones. The first lesson is to find short-term inputs that drive a long-term output. Retention is a poor goal because it is nearly impossible to move quickly, so teams should find its inputs and use experiments to test whether they really predict it.

The second lesson is to keep metrics simple. Data scientists love composite scores with weighted coefficients, but nobody knows whether a 0.1 increase is good. A simple metric that people understand and can discuss across the company will drive better outcomes than a perfect-looking composite no one can interpret.

Third, DoorDash quantifies levers in a common currency so that trade-offs can be made across teams. What does lowering price by a dollar buy in volume, compared with cutting delivery time by a minute? Everything is expressed as gross order value and volume, from fixing a login flow to signing a Thai restaurant in Sacramento or putting more dashers on the road, which tells the company where to spend its next dollar or team-hour.

A merchant-health score illustrates the simplicity point. It blended active hours, photos and menu completeness into a number like 0.35 that nobody could interpret. DoorDash replaced it with a few direct measures, such as how many new merchants get an order in their first seven days, plus goals on photo coverage and accurate hours. Lenny describes a similar Airbnb healthy-host metric that ended up being tackled one factor at a time, and adds that keeping a team on one metric until the opportunities run out is more efficient than rotating.

Averages hide the worst experiences, so DoorDash sets goals and metrics around edge cases. A key example is "Never Delivered," orders that simply never arrive. They are very rare and invisible in average delivery-time metrics, yet they cause churn and are expensive, since the order is refunded and food has to be repurchased and redelivered.

A cross-functional team including quality analytics, product, engineering and ops aims to eradicate them by working out why they happen (human error, fraud) and then preventing or fixing them in flight. Lachs says frequency understates importance because a bad experience also costs all the customer's later orders, which never show up as an observed event.

She adds a warning for data people: ask what data you do not have. People who cannot log in never reach an order, so they are not in the denominator and the dataset misses them entirely. Finding and fixing such problems requires deliberately looking for them.

Managing data people across countries, Lachs says, has been more similar than different. Different currencies, languages and EU versus non-EU regulation add complexity, but many problems resemble earlier ones, which feels like "going into a test having seen the answer key." She still tests for cultural differences and is pleased when something turns out new.

On AI, she is most excited about making her own team more productive. The analytics team has long run weekly Office Hours to help colleagues with SQL and analysis, and she wants to let non-technical users edit queries themselves, for example adapting a query to show gross order value for grocery. The internal tool is called Ask Data AI, named after the Slack channel that used to host open data questions, matching DoorDash's habit of very literal names.

Her closing advice is that you do not need formal training in what you are building. The analytics team is a net importer of talent, with people joining from engineering, ops, marketing and finance. She values a mix of backgrounds, from consultants to statisticians and economists, and of company stages, so startup hustle and experience of scale both inform the team.