Do you need someone to establish trusted business metrics? Explain why conversion declined? Determine whether a product change actually caused an improvement? Forecast what happens next? Build a system that predicts which customers are likely to churn?

Those are different problems. They require different capabilities. Yet companies often start somewhere else. They decide they need a Data Scientist, then look for Data Science work.

Start with the decisions the business needs to make and the uncertainty preventing it from making them well. Then determine the capability you need, whether your data is ready to support it, and whether the problem is important and recurring enough to specialize around. Only then decide what role to hire.

Start with the problem. Let that define the role. Worry about the title later.

A framework for deciding what data capability you need

When I think about building a data organization, I ask three questions:

1. What problem are you trying to solve?

The first question is not “Do we need a Data Scientist?” It is: “What uncertainty is getting in the way of a better decision?”

Most data problems fall into a few broad categories:

• Understand: What is happening in the business? Where is it happening? For whom? Why might it be happening?

• Measure: Did something actually cause the outcome we observed? Did a product, pricing, marketing, or operational change work?

• Predict: What is likely to happen next? Which customers are likely to churn? What will demand look like next month?

• Optimize or automate: Given what we know, what decision should we repeatedly make at scale?

• Enable: Can people reliably access and interpret the data at all? Are the underlying data, definitions, and infrastructure trustworthy enough to support the other questions?

That last category is easy to overlook. Sometimes your most important data problem is not analytical sophistication. It is that nobody agrees on the denominator.

Start with the decision

Imagine customer retention has declined. If you do not know where, descriptive analysis may be enough. If you know where but not why, investigate the drivers. If you suspect a recent product or pricing change, causal analysis may be appropriate. If you have an intervention, test it. And if that intervention works but cannot be targeted efficiently, prediction may finally create leverage.

Each method can be valuable. But sophistication is not the objective. The most valuable method is the one appropriate for the uncertainty standing between the business and a better decision.

This is how I think about Data Science broadly: its job is to reduce uncertainty around important decisions. Sometimes that requires a simple query. Sometimes it requires causal inference, forecasting, or machine learning. The method should follow the problem, not the other way around.

2. Is your organization ready to use that capability?

The next question is whether your data and organization can actually support the work you want someone to do.

Companies often hire for the version of themselves they hope to become. They recruit a machine learning specialist because they believe machine learning will matter eventually. Then that person arrives and discovers that event tracking is unreliable, metric definitions are inconsistent, and nobody agrees on what counts as an active customer!

Instead of building ML models, they spend six months reconciling dashboards and fixing data tables. None of that work is beneath them. But it may not be the work they wanted to do, and it may not be the person you actually needed to hire.

Before adding a sophisticated capability, ask:

• Is the necessary data captured?

• Can we trust it?

• Are the core entities and metrics defined?

• Can people retrieve the data without heroic effort?

• Do we have enough history or volume for the methodology we want to use?

• Will the business actually use the output to make a decision?

If not, your constraint may be foundational rather than analytical.

Match the hire to the data you actually have, not the model you wish you had the inputs for.

3. Is the problem important and recurring enough to specialize around?

This is where I think organizations often specialize too early.

A capable generalist can solve an enormous range of analytical problems. I would specialize when a class of work becomes important, recurring, and complex enough that the generalist model itself starts creating a bottleneck: quality becomes uneven, the same infrastructure keeps getting rebuilt, or demand is persistent enough to justify dedicated ownership.

Roles should separate when specialization solves a real problem, not simply because the company has become large enough to draw another box on the org chart.

The answers also tell you what kind of person to hire. Early on, that is often a broad, hands-on generalist. As the work changes, the team should change with it.

Of course, we did not sit down at early DoorDash with this framework and design the organization perfectly. Much of this became clear in retrospect, as we saw which problems kept recurring and where the generalist model started to strain.

What this looks like as a company grows

There is no magic employee count for any of this. But company size can still be a useful shorthand because the nature of the problems tends to change as organizations grow. I would think about the progression in stages, not rules.

Very early: the business is still learning what matters

In many companies, the very early stage looks roughly like 10–50 people. At that point, a specialized data organization is usually premature, although a data-intensive product, marketplace, fintech, or highly regulated business may need dedicated expertise earlier. For most companies, founders and operators may still be able to understand the most important metrics directly.

The signal to hire is not simply that the company has accumulated data. It is that important decisions are repeatedly constrained by the company’s ability to trust, retrieve, or interpret it. You start hearing the same symptoms repeatedly: teams disagree on metrics, nobody knows why an important number moved, simple questions require an engineer, or the same analysis gets rebuilt from scratch.

That is when a dedicated data owner starts to become valuable.

At this stage, I would generally bias toward one senior, hands-on generalist. The problems are still broad, changing quickly, and often poorly defined. Range matters more than specialization.

At DoorDash, this was essentially my role after transitioning from a General Manager. As we began building the team, the sweet spot was often around an L6 Data Scientist. The level itself is not the point, and levels vary enormously across companies. What mattered was the shape: senior enough to independently own an ambiguous business problem and work with senior stakeholders, but still hands-on enough to write the query, inspect the data, and build the analysis themselves.

That hands-on requirement matters whether this person is the first member of the team or the person leading it. Building a data function from zero to one is a very different job from leading a mature organization. There may be little infrastructure, few established processes, and nobody to delegate the hard work to.

I have seen companies hire a Director+ leader too early because they are optimizing for the person who might eventually run a large organization. Early on, I would optimize instead for a player-coach: someone senior enough to set direction and build credibility with the business, but willing and able to roll up their sleeves and build alongside the team.

Growing: one generalist can no longer absorb everything

As the company grows beyond 100 people, more teams rely on data, and one person can no longer absorb all the demand. That does not necessarily mean it is time to specialize. Often, the right next step is simply to build a team of strong generalists.

At early DoorDash, that is largely what we did. Data Scientists might support different parts of the business, but the shape of the role remained broad. The same person could investigate a marketplace problem, define a metric, design an experiment, build a data table, and work directly with a business or product leader on next steps.

The first sign that one generalist is overloaded is usually a reason to add capacity, not necessarily a reason to specialize.

AI may allow this stage to last longer than it used to. A strong generalist can now write queries faster, prototype lightweight workflows, navigate unfamiliar code, and communicate findings more efficiently. If the problems are still broad and ambiguous, another strong problem solver may create more value than a specialist whose expertise applies to only a fraction of them.

At DoorDash, we started to specialize after hiring four generalists. We added a machine learning scientist to the Analytics team. We added another ML scientist and two BI engineers after we crossed ten people on the Analytics team. As the company crossed the 1,000-employee mark, the Analytics team was about 20 people.

Scaling: specialization starts to create leverage

Eventually, more demand becomes a different kind of problem. Certain types of work stop being occasional and become important, recurring, and complex.

At DoorDash, we started seeing the same kind of problems recur across more and more teams. Experimentation was no longer an occasional technique; it was becoming central to product decisions. Shared data models and metric definitions increasingly affected whether different teams reached the same answer. Forecasts became inputs into planning, and machine learning began moving from analysis and prototyping into systems that had to operate reliably in production.

The signal was not that our generalists had suddenly become incapable. It was that solving these problems well now required consistency, infrastructure, and depth that were hard to create one project at a time.

The question had changed. It was no longer “Can someone on the team solve this?” It was “Should we build a real capability around solving this repeatedly?”

That is when specialization starts to earn its keep. Shared models and definitions may justify dedicated Analytics Engineering. Experimentation may need common expertise and standards. Forecasting or Machine Learning may become critical enough to require specialized ownership. Our few specialists were overloaded, and they needed more support.

The trigger is the work, not the headcount.

At scale: specialized work becomes organizational capability

At scale, the specialist’s job changes too. They are no longer just solving the hard problem themselves. They are building the systems that let the company solve it reliably: experimentation infrastructure and standards, trusted data models and metric definitions, production systems that are monitored and maintained.

The progression is roughly:

No dedicated data team → first generalist → team of generalists → specialized capabilities → scaled systems

Company size can help you understand where to look. But the problems themselves should tell you when to move from one stage to the next.

Titles describe centers of gravity, not hard boundaries

The exact titles vary enormously across companies. That is part of the problem. One company’s Data Scientist is another company’s Data Analyst, Product Analyst, Decision Scientist, Applied Scientist, or Machine Learning Scientist.

I find it more useful to think of these titles as different centers of gravity. Some roles sit closer to understanding the business and improving human decisions. Others sit closer to building reusable data, infrastructure, or automated decision systems. Data Science can span a surprisingly large portion of that landscape.

The point is not to draw hard walls. Some crossover is healthy, especially while a team is exploring what is valuable. Once something becomes important, reusable, or business-critical, clearer ownership matters more.

Overlap in skills is healthy. Duplication in ownership is not. When role boundaries become confusing, I would inspect the roadmap rather than the org chart: What decisions does each team own? Where are multiple teams answering the same question? And where are important questions falling between them?

Design the organization around owned problems and decisions. Then decide where the role boundaries should sit.

Define the job before you recruit for the title

That ambiguity creates a very practical hiring problem. LinkedIn usually tells you someone’s title. It does not necessarily tell you what they actually did. Three people with the title of Data Scientist may have fundamentally different experience: one may build machine learning models, another may run experiments, and another may primarily do product analytics.

That is why the hiring manager has to define the job before asking a recruiter to source it. This is also where recruiter calibration matters. If the hiring manager says “find me Data Scientists” without explaining what that means in practice, the recruiter has little choice but to use titles as a proxy. Then, several interviews later, you discover the candidate pool is full of people with the right label but the wrong experience. The recruiter needs to know what evidence to look for beyond the title.

Before opening a req, write a one-page role brief that answers six questions:

The first five define the job. The last determines what to call it.

The title comes last

Data organizations should evolve because their problems evolve. Early on, the right hire may be a hands-on generalist. Later, the same company may need specialized experimentation, Analytics Engineering, forecasting, or Machine Learning. Those changes should happen because the work changed, not because the company crossed some arbitrary headcount threshold.

Company size can tell you roughly where to look. The problems tell you what to build.

The problem defines the capability. The capability defines the role. The title comes last.

Acknowledgements: The ideas and writing are mine, but they’ve been shaped by current and former teammates who challenged my thinking and helped evolve how we built and ran the Analytics team. Special thanks to my Chief of Staff, Anita Chan, for brainstorming, editing, and AI wizardry on the images, and to ChatGPT and Claude for serving as editorial critics.

A note before I start: AI is moving quickly, and this reflects my current point of view, shaped by what we’ve seen so far at DoorDash. I’ve seen meaningful productivity gains and teams answer questions they previously could not answer themselves. I’ve also seen incorrect analyses, weak assumptions, and false confidence. I expect this view to evolve as the technology, our capabilities, and our operating model evolve.

AI, Self-Service Analysis, and Accountability

AI is lowering the technical barriers to analytical work.

People who previously needed help writing a query, exploring a dataset, building a chart, or summarizing a result can increasingly do those things themselves.

That is a positive development.

More people can answer their own questions. Information becomes more accessible. Analytics teams can spend less time on mechanical requests.

But the fact that more people can perform analysis does not mean every analysis should be done by anyone with access to an AI tool.

Broader access creates two questions organizations need to answer:

Which analytical work should be distributed more broadly?

And:

Who owns the answer when that work is wrong?

Those questions are connected.

AI should broaden access to analysis. It should not eliminate standards, specialized expertise, or accountability.

Producing an answer is becoming easier

AI can increasingly generate queries, code, charts, summaries, hypotheses, first-pass analyses, and even recommendations.

That makes many parts of analytical production faster.

But as the cost of producing an initial answer falls, producing the answer itself becomes less of a differentiator.

The scarce parts of the work move elsewhere:

• Choosing the right problem

• Determining whether the data is appropriate

• Checking definitions and assumptions

• Distinguishing correlation from causation

• Applying business and operational context

• Understanding trade-offs

• Making a recommendation

• Knowing when there is enough evidence to act

• Learning whether the decision worked

AI can help with all of these things.

What it cannot do is own the quality of the work or the consequences of the decision.

That makes human judgment and accountability more important, not less.

Match the rigor to the consequence of the decision

I do not think the goal should be to distribute all analytical work equally across the organization.

The goal should be to distribute the right work.

Some questions are relatively low risk.

Someone wants a directional read on a metric. A team wants to explore why something might be changing. The answer will inform a discussion but is unlikely to trigger an expensive or difficult-to-reverse action.

AI lets many more people answer those questions themselves.

That is exactly the type of work I want to see move away from a centralized Analytics team.

Other questions are different.

A pricing change that will affect millions of consumers. A major product launch. A large investment decision. A change to an important customer experience. A strategic decision with significant downstream consequences.

In those cases, getting the analysis wrong costs much more.

Even when AI makes the technical execution accessible, I still want people with deep analytical expertise involved in that work.

Technical execution is only one part of the skill.

Experienced analytical practitioners are more likely to recognize when the data is incomplete, when definitions are subtly wrong, when the methodology doesn’t support the conclusion, when an apparent relationship isn’t causal, or when business context changes the interpretation.

The routing principle I would use is simple:

The higher the consequence of the decision, the higher the bar for analytical expertise and rigor.

Before self-serving an analysis, ask:

• What is the consequence if the answer is wrong?

• How costly or difficult is the decision to reverse?

• Does the work require specialized methodology or judgment to interpret correctly?

Low-risk, reversible, directional questions can increasingly be self-served.

High-risk, expensive, or strategically consequential decisions should involve people with the analytical expertise required to do the work responsibly.

In most organizations, much of that expertise will sit within Analytics.

This is not about protecting Analytics’ territory.

It is about putting expertise where the cost of being wrong is highest.

Accountability has to scale with access

Within an Analytics team, the chain of accountability is relatively clear.

The person doing the work is responsible for its quality. Their manager is responsible for maintaining the bar. Analytics leadership is ultimately accountable for the quality of work produced by the function.

We hire for the skills required to do this work well. We develop those skills over time. We use peer review and other quality checks where appropriate.

If an analysis is wrong because we used the wrong data, made a bad assumption, or applied an inappropriate methodology, we cannot blame the tool.

We own it.

As analytical capability spreads beyond Analytics, that accountability has to spread with it.

I cannot be accountable for every AI-generated analysis produced across an organization simply because it involves data.

If a Product, Operations, Marketing, Finance, or other team chooses to self-serve an analysis, the people producing that work and the leaders managing them need to own its quality in the same way I own the quality of work produced by Analytics.

AI makes that especially important because it can make weak analysis look polished and authoritative.

A query can run and still answer the wrong question.

A chart can look convincing and still use the wrong denominator.

A recommendation can sound coherent and still rest on weak evidence.

AI can produce. Teams must own. Leaders must decide.

The team producing the work is accountable for ensuring it is reliable enough for its intended use.

The leader acting on it is accountable for deciding whether the evidence is sufficient for the consequence of the decision.

And if a team cannot responsibly determine whether its own analysis is reliable, that signals the work may not be appropriate for self-service in the first place.

Self-service analysis must distribute capability and accountability together. “AI got it wrong” cannot become a substitute for human ownership.

Analytics should not become the homework grader

There is an obvious but wrong response to these risks: require Analytics to review or troubleshoot everything produced elsewhere.

That would recreate the exact bottleneck self-service is supposed to remove.

It would also put accountability in the wrong place.

Imagine the Analytics team has ten priorities and has deliberately chosen to focus this sprint on the top three.

A Product Manager decides to independently tackle priority nine using AI: an exploratory question about a recent conversion decline in one market.

That can be a great outcome.

If the PM can answer the question independently, work that otherwise would have waited gets done without consuming Analytics capacity.

But suppose the PM gets stuck, cannot explain why the result looks wrong, and ultimately needs a data scientist to spend their whole day debugging the analysis.

We have now effectively moved scarce Analytics capacity away from priorities one through three and redirected it to priority nine.

The operating model has broken down.

A healthy self-service model still needs an escape hatch. Occasionally, someone will uncover a real data-quality issue, ambiguous definition, or unexpected result that warrants Analytics involvement.

The failure mode is not escalation itself.

It is when escalation becomes the normal path for completing self-service work.

Self-service creates leverage when teams can complete lower-risk work with limited Analytics involvement. That requires trusted data, clear metric definitions, reusable capabilities, and accountability for the work they choose to self-serve. One of Analytics’ highest-leverage roles is to build those foundations, so other teams can answer more questions safely without requiring ongoing Analytics support.

The capacity created should then move Analytics closer to the higher-risk, higher-value decisions where specialized judgment matters most.

Self-service should remove lower-priority work from the Analytics queue, not quietly put it back through a different door.

Every tool raises the bar

I have seen versions of this transition before.

When I joined DoorDash, every new cut of data required help from an engineer, so I learned SQL.

Later, I learned enough Python to work around the limitations of our existing tools.

Neither technology made Analytics less valuable.

Each lowered execution costs and raised the bar for what Analytics could contribute.

AI will do the same, but on a much larger scale because it distributes analytical capability across the organization.

That should free Analytics to spend more time on the work where judgment matters most: framing important problems, designing stronger tests, working through causal questions, developing clearer recommendations, and helping leaders navigate difficult trade-offs.

If AI lets an Analytics team produce twice as many analyses but doesn’t improve the quality of important decisions, the team hasn’t become twice as valuable.

The opportunity is to turn speed into greater impact.

Putting this into practice

The bar

AI will make analysis more abundant.

That is not the same as making good judgment abundant.

The organizations that benefit most will not simply distribute analytical capability as broadly as possible.

They will know which questions can safely be decentralized and which decisions deserve specialized expertise.

They will distribute accountability alongside capability.

AI changes who can produce analysis. It does not change the fact that someone needs to own the answer.

Acknowledgements: The ideas and writing are mine, but they’ve been shaped by current and former teammates who challenged my thinking and helped evolve how we built and ran the Analytics team. Special thanks to my Chief of Staff, Anita Chan, for brainstorming, editing, and AI wizardry on the images, and to ChatGPT and Claude for serving as editorial critics.

What a team measures eventually becomes what it optimizes for.

Many Analytics teams measure their work through activity:

• Dashboards shipped

• Tickets closed

• Questions answered

• Analyses completed

Those measures may be useful when a team is diagnosing a specific operational problem. They are not measures of value.

A team can complete more requests, build more dashboards, and answer questions faster without improving the business.

I have always believed that this is the wrong scoreboard.

If Analytics exists to help the business make better decisions and improve measurable outcomes, its scorecard should reflect that purpose.

At DoorDash, we did not define the value of Analytics by the volume of work the team produced. We focused on whether the work improved how the business understood a problem, made a decision, took action, or achieved an outcome.

I would rather see one piece of work change an important decision than twenty pieces of work be delivered and forgotten.

The question is not: “What did the team produce?”

It is: “What changed because of the work?”

The Analytics impact ladder

Not every project will have a clean, causally attributable business impact.

But every important project should be explicit about the type of impact it is intended to create and, where possible, estimate the size of the impact.

I evaluate Analytics impact across four levels.

Acknowledgements: The ideas and writing are mine, but they’ve been shaped by current and former teammates who challenged my thinking and helped evolve how we built and ran the Analytics team. Special thanks to my Chief of Staff, Anita Chan, for brainstorming, editing, and AI wizardry on the images, and to ChatGPT and Claude for serving as editorial critics.

The step that is easy to skip.

Part 1 started with a simple principle: Analytics exists to help the business make better decisions and improve measurable outcomes.

Most Analytics teams already know this.

Yet many analyses still stop one step too early.

They explain what happened.

Sometimes they explain why.

Then they stop.

The most valuable question comes next: “What should we do?”

That’s the “so what?” and the difference between reporting and recommendation.

A good analysis helps people understand the business. A great analysis helps them decide what to do next.

What decision-ready analysis looks like

Every important analysis should answer five questions before it leaves your desk.

1. What happened?

State the facts clearly.

What changed? By how much? For whom? Relative to what baseline?
The audience shouldn’t need to interpret ten charts to understand the headline.

2. What does it mean?

Interpret the evidence.

Separate what the data shows from what you believe is the most likely explanation. Be explicit about whether you’re identifying a causal relationship, a likely driver, or simply a correlation.

Acknowledgements: The ideas and writing are mine, but they’ve been shaped by current and former teammates who challenged my thinking and helped evolve how we built and ran the Analytics team. Special thanks to my Chief of Staff, Anita Chan, for brainstorming, editing, and AI wizardry on the images, and to ChatGPT and Claude for serving as editorial critics.

The original spark for Analytics at DoorDash came from a simple question: “How do we know if a market launch is going well?”

At first, I thought this was a measurement problem.

We needed better metrics, better dashboards, and a consistent way to compare performance across markets.

Those things mattered. But they weren’t the hardest part.

The real challenge wasn’t measurement. It was decision-making.

We needed a shared definition of good performance. We needed to understand which outcomes mattered, which inputs teams could control, but most importantly, we needed to identify what leaders should do when performance moved off plan.

The question wasn’t simply “What should we measure?”

It became: “What decision are we trying to make, and how can data help us make it better?”

That question eventually became BizOps. Later, it evolved into Analytics.

What is Analytics?

People often ask me what an Analytics team does. My answer has stayed remarkably consistent: Analytics exists to help the business make better decisions and improve measurable outcomes.

Most Analytics leaders would probably agree with that statement. The challenge isn’t defining the purpose of Analytics. It’s building a team—and an organization—that consistently operates that way.

A useful Analytics team answers questions, builds dashboards, analyzes experiments, and makes information easier to access.

A great Analytics team goes further. They help define the problem, bring a point of view on the decision, and stay involved long enough to learn whether the decision worked.

That’s what I mean by owning the outcome.

It doesn’t mean Analytics owns the business result on their own. It means Analytics shares responsibility for the quality of the decision by ensuring the team:

• Asked the right question.

• Used the right evidence.

• Understood the relevant trade-offs.

• Made a clear decision.

• Learned from what happened next.

Four questions behind every Analytics request

I’ve found that nearly every Analytics request becomes better after answering four questions.

Acknowledgements: The ideas and writing are mine, but they’ve been shaped by current and former teammates who challenged my thinking and helped evolve how we built and ran the Analytics team. Special thanks to my Chief of Staff, Anita Chan, for brainstorming, editing, and AI wizardry on the images, and to ChatGPT and Claude for serving as editorial critics.

A couple of years ago, our team was asked a question that sounds simple but is very hard to answer: What is actually happening in local economies?

Not the national average. Not survey-based data that comes out on a lag. But what are people actually buying, at what price, in which neighborhoods, in real time, and how is that changing?

DoorDash has a unique lens into that question. Every day, people use our platform to buy meals, groceries, household goods, and everyday essentials across thousands of cities. That gives us a view into local commerce that is both broad and highly granular.

But having the data is not the same thing as knowing what to do with it.

The harder work was deciding which questions were worth asking, how to answer them consistently, and how to build something useful enough for researchers, policymakers, journalists, and local leaders to actually use.

That’s the work my team has been doing.

More specifically, this work has been led by Abhi, Anita, Cheryl, and Eli, with many others across the Analytics team contributing quarter after quarter to shape the methodology, pressure-test the findings, and turn the data into something people outside DoorDash can actually use.

One of the things I’ve always believed about great analytics teams is that the best ones don’t just answer the questions they’re given. They have a point of view on which questions matter.

The Cheeseburger Index is a good example.

It came out of a discussion about how to create a simple, intuitive proxy for local restaurant pricing. Something that could make price differences easier to understand. Something a journalist, a policymaker, or a curious person in Lincoln, Nebraska could look at and immediately grasp.

That is often what good analytics looks like. It’s not always about finding the most sophisticated answer, but finding the clearest one.

Here’s what the Q2 data shows:

• Everyday essentials remain essentially flat this quarter, with the range of household goods down just 0.6% overall compared to Q1 2026 across all categories. The largest mover in that category is diapers, down 2.4% this quarter.

• Some grocery prices have recently started climbing, even as the broader grocery basket remains below year-ago levels. Egg prices helped drive prices down substantially in Q1 2026, but this quarter avocado and milk prices are back up by 12.4% and 8.3%, respectively.

• The Restaurant Price Index and Cheeseburger Index both continued to rise at the pace of inflation, up 3.2% from this time last year, even though the underlying cost of a cheeseburger’s ingredients rose just 0.6%. This points to broader operating-cost pressures — energy, rent, and other overhead — as the likely driver of restaurant inflation, rather than commodity food prices.

One of my favorite parts of this project is exploring the city-level data.

There’s something genuinely fun about pulling up the rankings and seeing where different cities land, and how often they defy expectations. Take Austin, for example: while many people think of it as a city that’s getting more and more expensive, it ranked #1 on our Cheeseburger Index for affordability this quarter. As someone who has enjoyed meals at Whataburger and Hopdoddy Burger Bar, I know a great burger meal can be found there, and the data shows it.

The local variation is real, and it’s bigger than most people assume. Once you start looking at it city by city, the national average stops being very interesting. I’ve always preferred looking at the distribution over focusing on an average.

We’re still building. There are questions we want to answer that we can’t yet. There are categories we want to add. There are new ways to make this data useful to the people studying local economies and making decisions in their communities.

But I am proud of what the team has built so far.

The State of Local Commerce report is not just a data release. It is an example of the kind of work I think great analytics teams should do: take messy, complex, highly local data and turn it into something people can understand, trust, and use.

If you are a researcher, policymaker, journalist, or local leader using this data, I would love to hear what is useful, what is missing, and what you wish we could answer next.

The full Q2 dataset and city-level breakdowns are at: https://about.doordash.com/en-us/state-of-local-commerce

Subscribe now

I relocated to the Bay Area in the spring of 2015 to start my new role at DoorDash headquarters, a former animal hospital in Palo Alto. My role was undefined, my roadmap unwritten, and my title had been changed in our HR system to “Swiss Army Knife” by one of the engineers. It was a joke, but it was also accurate.

As I wrote in Part 4, I called the function BizOps after reading Dan Yoo’s description of similar teams at Yahoo and LinkedIn. The idea resonated immediately: generalists dropped into ambiguous business problems, figuring out what was going on, solving what they could, and then handing things off once the work became more repeatable.

That was exactly what DoorDash needed at the time. I did not set out to build an Analytics function. I was trying to answer the most important questions the business had, one at a time.

I had no formal background in analytics. No statistics degree, no data science training, and no SQL skills when I started. That didn’t matter; I just started.

The first thing I did was ask for all the data we had on business performance. Most of it sat with Finance and had been compiled for fundraising purposes. We had a few dashboards in Chart.io, built by two ops managers who knew SQL.

I spent my first week doing what I could: dissecting cohort retention curves in Excel. An engineer would pull a CSV file with the raw data, and I’d manipulate it from there. INDEX MATCH was my best friend. It was inefficient—not as inefficient as VLOOKUP, but inefficient—and I knew it. But any time I wanted a different cut of data, it required going to an engineer. Even less efficient.

So I spent two weeks heads-down teaching myself SQL. I completed 3 online trainings (my favorite back then was the one written by Mode) and then moved on to real data. I challenged myself to rewrite the queries powering various Chartio dashboards to see if I could get the same answers. I wrote queries, pulled data, and checked whether the results matched. If they didn’t, I tried to debug on my own, and if I was completely stumped, I would sit down with the original authors for help.

Creating a source of truth.

Before we could set goals, we needed to understand our performance at a more granular level. I started setting up dashboards to track the basics: order volume, new consumer acquisition, cohort retention, merchant selection, delivery quality, unit economics, etc.

It sounds obvious now, but at the time, even getting everyone aligned on what we should measure was a meaningful step. I created the DoorDashboard, which we emailed to the whole company each morning so everyone could see the prior day’s performance. We were growing quickly, launching new markets, and learning in real time which inputs moved the business.

DoorDashboard in 2015. It was simple, but it gave everyone the same daily view of the business: growth, profitability, reliability, and quality.

But even with my (now) intermediate-level SQL, not all the data I wanted was accessible in our dashboarding tool. I still frequently required an engineer’s help. And one of our early engineers, Peter Tseng, believed in what I was trying to do and offered to help me help myself.

Peter was genuinely interested in data science and put together a small syllabus to teach me the basics of Python for data analysis. It was just enough to be dangerous, which was exactly what I needed.

He introduced me to pandas, NumPy, and seaborn. The first script I wrote pulled cohort retention by city and visualized it as a triangle heatmap in aqua. It was beautiful.

That was a real unlock. And yes, for anyone wondering: our Substack logo is a little homage to those early cohort heatmaps.

Once I could see the data the way I wanted to, I stopped asking what was happening and started asking why. Why was retention increasing in one city and declining in another? Was it affordability? Selection? Quality? The launch strategy? The consumer mix? I read through consumer feedback, looked at trends by segment, and began identifying themes.

Each insight generated new questions. Each question led to a new analysis. Each analysis created new metrics we needed to track. The cycle didn’t stop—and honestly, it still hasn’t.

Building from zero.

For a while, I was the entire Analytics team.

A typical week might involve setting goals for a new market launch in the morning, digging into consumer retention in the afternoon, and making sense of consumer complaint data at night. There was no roadmap. The roadmap was whatever problem seemed most important to the business that week. I was, as I said at the time, a one-woman Swiss Army Knife playing whack-a-mole with an endless supply of business questions. It worked for a while, until it didn’t.

I knew things had to change when the problems started outpacing me and my skills. We needed geo-level pay optimization for Dashers. We needed to understand density, supply, demand, and unit economics with more precision. We needed simulations. The questions were getting harder, and they required skills I simply did not have—especially deeper statistics and stronger technical depth.

So I started hiring—deliberately, and for complementary skills. My strategy was simple: hire people who could do things I could not. I did not want a team of people who looked exactly like me. I wanted people who spiked in different areas and made the team collectively stronger.

While our strengths were different, our mindset was remarkably similar: we were entrepreneurial, pragmatic, curious, and deeply committed to helping one another succeed.

Barrett had a background in computer science and much stronger Python skills. David had a background in statistics and experience with logistics networks. Ryan had strong SQL skills and a consultant’s approach to problem-solving. Preston brought depth in machine learning and a teacher’s mindset. Hiring people whose strengths complemented my own was one of the most important decisions I made.

Much of what I know about data science, I learned from my own team. I still believe that is one of the most underrated forms of professional development available to any leader: surround yourself with people who are excellent at things you are not, and be humble enough to learn from them.

For a while, we used our real problems as interview questions. The cohort retention SQL query—the one I had struggled to write myself—became our standard coding exercise. The selection intelligence model was used as a case study. If a problem was hard enough to teach us something about the business, it was probably useful for understanding how a candidate thought. I’ll write more about hiring in future posts, but this was the beginning of my philosophy.

That was how the team grew: one business problem, one skill gap, one hire at a time.

When the team outgrew me.

In the early days, people came to us with questions, and we answered them. That worked when the company was small and everyone knew everyone. The first few people on Analytics each had their own reputations. The work spoke for itself.

But as DoorDash grew, the stakes got higher. That model wouldn’t scale.

As we got bigger, analysis started happening outside our team—by operators, by finance, by product managers. Some of it was good. Some of it wasn’t. I remember several instances of analysis reaching leadership that sounded confident but didn’t hold up under scrutiny. That was a problem. Bad analysis could lead to bad decisions. We needed a higher and more consistent bar. That was when I started to understand that Analytics could not just be a team that answered questions. We had to help define what good analysis looked like across the company.

The team shifted from a group of generalists dropped into whatever problem was most urgent to a set of more permanent business partners who could go deep on a particular part of the business. Instead of bouncing from problem to problem, people began developing real context in areas like Dasher supply, consumer retention, merchant selection, and customer support.

We stopped being the team that answered questions and started being the team that owned outcomes alongside our business partners. Those relationships changed the work. People stopped coming to us only when they needed data. They started coming to us when they needed a thought partner.

That shift did not happen because I announced it. It happened one project, one recommendation, and one hard conversation at a time.

However, not every structure we tried worked.

At one point, we experimented with separating product analytics and business analytics, one supporting PMs and the other supporting GMs. In theory, that made sense. Product teams and business teams often ask different types of questions. In practice, we ended up with two people working on similar problems simultaneously, each from a different angle. So we rethought the structure and created a single analytics role that had to bridge both. It was messy for a while. But as our partner teams became more aligned on our north star goals, it started to work.

We had a similar approach to our team structure as we did with our product culture: test and iterate. We would build what the business needed, and then, as the company changed, we had to ask whether the structure still made sense. Sometimes the answer was no.

More teams reporting to you does not automatically mean you are more important.

This was a hard lesson, one that took longer to fully absorb.

In the early days, when I saw a gap, I built the thing to fill it. Data Engineering, Business Intelligence, Machine Learning, Data Product, and Experimentation—at different points—all got started within the Analytics team because the business needed them, and someone had to get them going.

That was the right thing to do at the time. But not every function we started was meant to stay.

I remember when our VP of Engineering came to me and said he thought Machine Learning Engineering (MLE) should move into Engineering. My first reaction was no. Not because I had a principled argument, but because it felt like losing something: team members, scope, and a piece of what I’d built.

I knew moving MLE into Engineering was the right decision for the company. It gave that team the right technical home, the right management structure, and the right path to scale. It also made me better at my job, because it freed me to focus on what I was uniquely positioned to do. But it took me longer than I’d like to admit to fully internalize that lesson: more headcount does not automatically mean more impact.

Sometimes, giving something up is exactly what allows both the work and the leader to improve. I’ve tried to carry that lesson forward every time I’ve faced a similar decision since.

Analytics became more than a team of problem-solvers.

We started as generalists, jumping into whatever problem mattered most. As DoorDash scaled, that wasn’t enough—we also needed a consistent way to measure the business. Analytics became the company’s scorekeeper, defining metrics, building dashboards, and creating shared visibility into performance.

One important milestone was the creation of the Weekly Business Review (WBR). Early on, I pulled the data each week and assigned red, yellow, and green grades to each metric. It was a thankless job. Every leader thought their red should be yellow, and every yellow deserved to be green. But the exercise forced the organization to answer fundamental questions: What are we trying to achieve? How will we measure it? What does success actually look like?

While that brought discipline, it wasn’t the right long-term relationship between Analytics and the business. Being the company’s scorekeeper positioned us as the referee—evaluating performance after decisions had already been made.

Analytics earned a reputation across the company for sound judgment and the ability to solve hard problems. Even in our role as scorekeepers, people knew we cared about impact, not just accuracy. That credibility enabled the team’s next evolution and transformed how we worked with our cross-functional partners.

We stopped thinking of ourselves as the owners of the metrics and started acting as co-owners of the business problems. Instead of simply measuring outcomes, we helped define goals, shape strategy, pressure-test tradeoffs, and work alongside Product, Operations, and Engineering to achieve better results. Success was no longer something we reported on; it was something we helped create.

I remember Tony asking in meetings, “Has Analytics signed off on this?” That question stayed with me, not because it meant Analytics had veto power, but because it meant people believed the decision would be better if we were in the room.

That was when Analytics stopped being a collection of talented problem-solvers, or even the company’s scorekeeper, and became a true partner in building the business.

What I’d tell my earlier self.

If I could go back and talk to the younger version of myself, with no SQL skills, no team, no roadmap, and a “Swiss Army Knife” job title, I’d tell her this: do not let the absence of a credential, title, or prior experience stop you from trying.

Relevant experience matters less than you think. What matters is whether you are willing to figure things out and learn from the people around you.

I could not have articulated all of that in 2015. At the time, I was just treading water—trying to answer the next question, build the next dashboard, hire the next person, and identify the next problem.

But somewhere along the way, that undefined role became a career.

The path wasn’t linear, but it turns out the squiggly line was going somewhere after all.

This brings my career journey series to a close. Not my career, hopefully, just the series.

In the coming months, I’ll be sharing a more practical series on what it takes to build and lead a world-class Analytics team—hiring, structure, culture, measurement, and the role of AI in all of it.

I considered going back to finance. By then, the markets had recovered, and it seemed like a logical option. But deep down, I knew it still wasn’t the right long-term fit for me, and it felt like moving backward rather than building on everything I had just learned.

Around that time, a classmate of mine became a General Manager (GM) at Uber and described the role as a “CEO of your city.” It sounded like a great opportunity to combine the entrepreneurial spirit I loved with the support of a larger team. I was intrigued and wondered what other roles like this might exist.

Finding DoorDash was a little accidental.

Although I never raised any venture capital for GiftSimple, I had met a few folks at various VC firms. Jamie Bott, who was a talent partner at Sequoia Capital, first introduced me to Tony Xu. It was April of 2014, and Alfred Lin had signed a term sheet to lead DoorDash’s $17.3 million Series A funding round. DoorDash was looking to expand beyond Silicon Valley and needed its first General Manager to launch new markets.

At the time, almost no one knew what DoorDash was. I lost count of how often people thought I said I worked for “Jordache,” the 90s denim brand.

The interview process was informal. My first call with Tony took place while he was walking the streets in LA, visiting merchants ahead of the planned summer launch. I completed a take-home exercise analyzing some market data in Excel and had a video interview with co-founders Stanley and Andy, where we talked basketball and compared DoorDash’s assignment algorithm to a zone defense! In those days, Tony personally interviewed and reference-checked every hire. I received an offer pretty quickly after that—you don’t need many interview rounds when the final decision-makers are already involved. The process is much more structured now, but at the time, it reflected the company’s stage: small, fast, and founder-led.

Ultimately, I decided to join for two reasons:

First, I was impressed with Tony. He had a long-term vision for what he wanted to build—a local commerce platform—but was able to get down to the lowest level of detail about what needed to be done today, tomorrow, and next month. He had the unique ability to zoom in and out as needed, and he was incredibly smart yet humble. I met many founders at Wharton and while working on GiftSimple. It was rare to find someone who could operate at both levels so naturally.

Second, the opportunity sounded exciting. I would join as the first GM, head straight to Los Angeles to help launch the market, and then continue launching cities until I found one I wanted to run longer term.

Launching a market meant doing everything.

The job was all about hustle and rapid execution in those early days. There wasn’t much data to analyze, even if we’d had the time to try. Instead, it was a lot of trial and error—throwing ideas at the wall to see what worked.

Going door-to-door signing up merchants? Check.

Running twice-daily Dasher orientations? Check.

Writing handwritten thank-you notes to consumers to slip into delivery bags? Check.

Interviewing candidates for the open roles on the local team? Check.

Breaking down boxes and taking out the trash? Check.

Learning how to optimize Google Ad campaigns? Handing out promo codes at Santa Monica Pier movie nights? Unpacking boxes of doorhangers we’d hang in neighborhoods while doing deliveries? All done.

It was relentless, gritty, and wildly energizing.

We worked seven days a week, often crashing on air mattresses in the office or inexpensive Airbnbs. My first night in LA was spent in a tiny Venice apartment overrun by two cats and an unbearable stench. It was so bad that one teammate opted to sleep in the office on cardboard boxes instead. After pleading with Airbnb, we got a new place—only to discover it was crawling with ants. A quick trip to Ralph’s grocery store on Lincoln Ave for cans of Raid solved that problem, and we got back to work.

After launching LA and leaving the market in the hands of the permanent local team—shout out to Casey North—I moved on to Boston.

Boston would introduce three new challenges for us: the Eastern time zone (our team had only operated on Pacific time), cold weather (it was the fall of 2014), and bicycles (until this point, DoorDash was 100% car delivery). Boston was different.

I spent seven months in Boston, including the snowiest month on record in February 2015.

Back then, we were only open for lunch and dinner. We closed from 2 to 5 p.m., and ran Dasher orientations in our office. During dinner, from 5 to 10 p.m., we rotated manning our dispatching tool. We manually assigned Dashers to orders while our engineering team worked to build vehicle type into the assignment algorithm.

We had competitions over who could get to 0% lateness. I took this seriously and often won, which I’m sure will surprise no one who has worked with me. But the part I found most interesting was understanding why an assignment was good or bad in the first place.

I wanted to understand why.

We started manually scoring assignment quality and sending feedback to Rohan and the engineering team: where the algorithm was working, where it was struggling with bikes, and what seemed to be driving lateness. That tight loop between what was happening on the ground and what we could measure was my first glimpse of how I would think about analytics for the next decade.

I loved that part. In hindsight, that probably should have been a clue. I was most energized when there was a system to understand, a metric to improve, and a clear connection between the work and the outcome.

What caused lateness? What was in our control? Which actions actually moved the metric? Where was the bottleneck? How could we make the process better the next day?

The rest of the job was much less analytical and much more hustle. We woke up at 5 a.m. to stand outside various Boston T stations in the middle of winter, handing out KIND bars with promo codes to morning commuters. We took out the garbage to the dumpsters on Saturday nights and celebrated by playing dice games and eating ice cream in the office. In the evenings, we would send apology emails to everyone who had a late order. Every day was an opportunity to grow the business: sign new merchants, onboard new Dashers, acquire new consumers, fix whatever broke, and then do it all again the next day.

I was an average GM, but it wasn’t my superpower.

I worked hard, got the job done, and was willing to do whatever needed to be done. But the role—especially in those early days—did not play to my strengths.

The best early GMs were energized by the constant hustle: putting out fires, rallying teams, and making dozens of judgment calls with imperfect information. It was gritty, fast-moving work, and I had a lot of respect for the people who were great at it.

But what I gravitated toward was different.

I was more interested in zooming in. I wanted to understand the mechanics underneath the outcomes. Why was one assignment late and another on time? Which factors actually mattered, and which were just noise? What made one launch more successful than another? How could we compare Boston to LA or Chicago in a way that was fair and useful?

One of DoorDash’s operating instincts is to look beyond the averages and understand the outliers. That’s where I was naturally drawn. The exceptions were often where the best lessons were hiding.

I believe you can do almost any role reasonably well for a period of time, even if it is not the perfect fit. But eventually, you should seek out work that plays to your strengths. For me, that meant moving closer to the questions behind the work: what matters, how we measure it, and what “good” actually looks like.

The question that changed my career.

Around this time, Tony was managing several GMs and wrestling with a similar question: How do you hold GMs accountable when the markets they run are so different?

What does a “good” launch look like? Measuring GMs on raw activity was not enough. Signing restaurants mattered, but not all restaurants were equally valuable. Onboarding Dashers mattered, but only if we had the right supply at the right times and in the right places. Handing out promo codes mattered, but only if those customers actually ordered, retained, and helped build a healthy market.

At one point, Tony said something along the lines of, “I don’t know how to goal my GMs. Could you figure that out?”

That conversation changed my career. Instead of moving on to the next market launch, I moved into something much less defined: figuring out how to set the right goals, measure launch success, understand unit economics, think about Dasher supply, and identify the inputs that actually made the DoorDash flywheel work.

The role did not have a name at first. Around that time, I had read a piece by Dan Yoo about BizOps teams at Yahoo and LinkedIn—groups of generalists who acted like Swiss army knives, dropping into ambiguous business problems, figuring out what was going on, solving what they could, and then handing things off once the work became more repeatable.

That sounded a lot like what DoorDash needed. So I called my role BizOps.

The right move does not always look like a step up.

People often think about careers as a linear path: the next role, the bigger role, the one that looks more impressive on paper. This was not a promotion. I had expected to keep launching markets until I picked one to run permanently, but instead, I was joining Finance in a new role with no established team, no clear playbook, and no guarantee it would become anything meaningful. You could argue it was a step sideways. Maybe even a step down?

But it was the right move because it was the right fit. It was work I was excited about, work where I thought I could add real value to the business, and work that pulled me closer to the questions I could not stop thinking about.

Looking back, it is easy to make the story sound intentional and strategic. It was not. Living it felt much more like a squiggly line: a failed bank, a failed startup, a GM role that was not quite the right fit, and then an undefined problem that eventually became a function.

That was the turning point.

I had joined DoorDash to be a GM. I stayed because I found the work that actually fit me—and because I got to keep working alongside some of the best operators I had ever met.

Coming up in Part 5: how that undefined problem became the beginning of DoorDash’s Analytics function.

In addition to writing the financial section for a business plan for fashionable bike helmets with my classmates, I was introduced to other entrepreneurs’ stories through case studies. An academic paper we read, The Accidental Entrepreneur: The Emergent and Collective Process of User Entrepreneurship1, showed me a different kind of founder—the customer-turned-entrepreneur. I learned that there are many types of founders.

I enjoyed the introductory class so much that I took a second entrepreneurship class. It was in this class that I dreamed up what would become my own company: GiftSimple, a social gifting platform. I grew up saving the money my family gave me on my birthday for some larger purchase I was working toward. I thought others might be doing the same, and I saw an opportunity to make an existing offline behavior easier online: pooling money for a meaningful gift for birthdays, weddings, graduations, and other celebrations. I started GiftSimple in my final semester of business school and decided to spend the following year seeing if I could make it work.

A Crash Course in Building

For the next two years, I had a crash course in starting a company. Nearly everything I tackled was brand new, but I was fortunate to have guidance from my brother Marc, who had product management experience, and folks he trusted, like Jason and Russell. I started by registering a legal business entity and acquiring a domain—simple steps that felt monumental at the time. It was my first time working with a designer on UI/UX wireframes or thinking about how to set up web analytics and tracking—there was a steep learning curve! When the site launched, the focus shifted to customer acquisition. I developed social media campaigns, authored content for the GiftSimple blog, and launched paid advertising through Google AdWords. I’ll never forget the thrill of seeing the very first listing from a customer I didn’t know—it was a small, shining victory.

By the end of the first year, we had built a base of roughly 1,500 registered users, but growth had stalled. Instead of seeking feedback from customers (or potential customers), I doubled down on marketing tactics to reignite momentum. In hindsight, this was a mistake because I hadn’t found product-market fit. It wasn’t until I started preparing to pitch venture capitalists that I could see the flaws through their eyes—what I loved about the idea was also its biggest weakness: social norms around gifting were more deeply ingrained than I had assumed. I spent another year giving everything I had to GiftSimple before ultimately deciding to shut it down. It was a bittersweet decision, but the experience was transformative and taught me lessons that no textbook ever could.

Entrepreneurship isn’t as risky as it seems.

When I first imagined starting a company, I pictured entrepreneurs draining their life savings and living out of their cars. While that may be true for some, my experience was different. I started GiftSimple while in school, leveraging university entrepreneurship programs and a modest amount of startup capital to get it off the ground.

And if that was true then, it is even more true now. With AI, the cost of trying has never been lower. You no longer need the same level of engineering, design, or finance support to test an idea. You can get an MVP to market fast, pressure-test assumptions, and learn whether something has promise before committing years of your life to it.

GiftSimple failed, but so did Lehman Brothers. Nothing in life is guaranteed. The risk of not trying—of never knowing—felt greater to me than the risk of failure.

People don’t always act how you expect or how they say they will.

Social norms around gifting are deeply ingrained. Asking for money feels acceptable for charity or a wedding registry, but for birthdays or graduations? People hesitated. Despite what users told us in research—things like, “I’d love to use this for my next birthday!”—their actions said otherwise. Changing long-standing behaviors is hard, and what people say and what they actually do are not always the same! This lesson has stayed with me: qualitative research tells you what people think they want; quantitative research tells you what they actually do. You need both.

Loving an idea doesn’t make it a good business.

I loved the premise for GiftSimple. It took an existing offline behavior and made it more efficient using the power of social networks. But my excitement didn’t mean it was a good business. Passion is powerful, but it doesn’t automatically translate into a viable business. The VC pitch process was humbling in the best way—it forced me to stress-test my own assumptions and see the idea as an investor would, not just as a founder.

Decisions need to be made faster—and metrics make that possible.

I held onto GiftSimple far too long. Looking back, I knew it wasn’t working after the first year, but my determination and love for the idea kept me pushing forward. The core problem wasn’t just stubbornness—it was that I never set clear metrics or milestones up front. Without them, I had no objective trigger to act on. There was no number I could point to and say: “We said X, we got Y, it’s time to make a call.”

I’ve realized since then that delaying decisions often stems from the absence of a forcing function. When teams lack a clear goal, it becomes too easy for decisions to stall. Setting clear goals at the outset creates the structure teams need to make decisions with confidence. It’s a lesson I’ve carried into every team I’ve built since.

Failure isn’t the end—it’s part of the journey.

When I finally decided to shut GiftSimple down, I felt like I’d failed. As someone who’s always been goal-oriented, it was hard to accept that I’d poured so much into something and didn’t achieve what I set out to do. It felt public and embarrassing.

But over time, I’ve learned that failure isn’t something to hide from. Everyone experiences it in one way or another, and trying to avoid it only limits your opportunities. Failing at GiftSimple taught me that what matters most is what you take away from the experience and how you use it to grow.

What I took away was an operator’s mindset: a bias for action, a respect for data, and an instinct for when to move fast versus when to slow down and get the precise answer.

Those instincts didn’t come from a class or a framework. They came from two years of building something real, watching it struggle, and making hard calls with imperfect information.

As I’ll try to show in future posts, this setback didn’t just build character. It gave me an edge in analytics—and a set of principles I still apply in my work today. In a very real way, that failure became part of the foundation for what came next.

Coming up in Part 4: how I joined DoorDash as its first General Manager, and what I learned about building from zero.

I remember taking my father’s business cards, using Wite-Out® to remove his name, and replacing it with my own using a typewriter! I then moved up the ranks and asked the bank’s President for his business card so I could do the same—I was always ambitious! I made photocopies, cut them out, and handed them to people around the office. Even then, I knew that one day, I’d be a boss! However, I never thought I’d be leading a global analytics team.

From that little girl to a young adult, my career ambition remained the same. Fast forward to college. I attended Cornell University as an undergrad, and after graduation, I spent a year in capital markets before achieving my goal of becoming an investment banker at Lehman Brothers.

Unlike many others, I enjoyed my time in banking. I was an Analyst working in leveraged finance. Focused solely on debt issuance, I liked that this team allowed me to work across many industries, including consumer, retail, gaming, hospitality, technology, media, and healthcare. I learned how to pick apart companies, to always read the footnotes of financial statements (that’s where the good stuff is!), and became a pro at building financial models in Excel. I felt lucky to be surrounded by smart and highly motivated people, most of whom were quite nice.

At 23, I had access to CEOs and CFOs of Fortune 500 companies, and while I did my fair share of book-binding and coffee runs, I learned a lot from my interactions with these intelligent and accomplished executives. I learned that even in the same role, different executives could have widely different approaches. I gravitated towards the “operators,” specifically the ones who wanted to get into the details and knew their numbers cold. I found the Analyst role to be well-defined and a good fit for someone like me: able to function on little sleep, had a keen eye for formatting errors, and wouldn’t give up until all model errors were resolved. I was fortunate to experience the “heyday” of banking with lavish closing dinners and golf outings. And I admit the excess was fun. I remember flying from a deal-closing celebration in Vail, Colorado, directly to a golf outing in Scottsdale, Arizona, and thinking about how surreal my life seemed compared to my friends back home. But I also experienced the darker side - being asked to pick up a designer dress for a client’s mistress and being so exhausted from repeated all-nighters that I had to sneak a power nap in the stall of the ladies’ room, resting my head on the roll of toilet paper.

The problem brewing—besides the impending 2008 financial crisis, of course—was that I didn’t like my bosses’ jobs. Banking has a very clear career path, and this is comforting to folks who like to know the rules. But, if you don’t like where that path leads, there aren’t many alternatives. I didn’t think much about it at the time; I was enjoying my current role, and I was loyal. I decided to stay on for a third year at Lehman Brothers and go straight into the Associate program. After committing to the program, I had the opportunity to work from our Hong Kong office, and in 2007, a lot of deals were happening in Asia. So I packed my bags, ready for a new experience in China. The work was the same, but the environment was different. For the first time, I stuck out as “different.” I didn’t speak the language or look like I belonged. It was an adjustment initially, but I enjoyed my time in Hong Kong. I embraced being an expat, learning how to say “Mosque Street” in Cantonese and finding the most efficient route to work down the Mid-Levels escalator system. My time in Asia also sparked a passion for travel that continues to this day.

In the summer of 2008, I came back to a country where things were very different from when I had left. Bear Stearns had collapsed, the financial markets were depressed, and layoffs at Lehman had been ongoing. After completing the Associate training program, it was recommended that I rejoin my former group, where folks knew me, instead of starting my rotation in a new group. A few days later, Lehman Brothers went bankrupt and was bought by Barclays. What I remember most about the fall of 2008 was the overarching sense of anxiety around the office. The days were dull—no deals were being done—and there was so much uncertainty. Without work, all you could do was focus on the unknowns and take long lunches. Would we have jobs tomorrow? Health insurance? Who would be laid off next? Banking was no longer fun (or lucrative).

As the layoffs continued, only a handful of junior folks remained. It seemed inevitable that my name would be called at some point, and I started to think about what I would do if that happened. I thought of going to another financial institution or into private equity, but if I could even find someone hiring, I still had lingering doubts about whether this was the right long-term career for me.

What did I want to do when I grew up? I had no idea. I needed time to figure it out. So, I decided to take the socially acceptable “break” known as going to business school!

I attended The Wharton School at the University of Pennsylvania and naively thought that I would experience something akin to divine intervention while sitting in one of my classes, suddenly realizing my destined career. This did not happen. I took classes in marketing, sports management, operations research, strategy, and international finance. I tried consulting for the summer, but nothing fit. On a whim, a classmate of mine, Davis Smith suggested I take an entrepreneurship class, where the main project was to write a business plan for a startup idea. He already had an idea, and I would be responsible for writing the financial section. I was still trying to figure out my interests, and while I didn’t think that was entrepreneurship, I signed up for the class anyway.

On the first day, Professor Ethan Mollick asked the class how many people were interested in starting their own businesses at some point. Everyone’s hands went up except mine! He looked at me and smiled as if to say, “Challenge accepted.”

Click here for part three, the story of how I failed spectacularly as an entrepreneur. If you missed part one, you can find that here.

Subscribe now

I joined DoorDash over a decade ago as its first General Manager. I have no formal data science training, but today, I lead a global Analytics organization for a $40B+ public company. So, how did I end up here?

Tony Xu believes in superpowers and I don’t give up easily.

Tony believes that everyone has something that they’re uniquely good at. He encourages people to identify their superpower and look for opportunities to match that superpower with a company’s needs. He recognized my superpower before I did.

A few years into my tenure, I asked Tony why he hired me. It wasn’t surprising to hear that it was NOT my investment banking experience or my MBA. He used to tease a few of us early folks with MBAs about our Master’s degrees—which he also had!—because he saw a lot of resumés with similar credentials. What he found interesting about me was that I had tried to start my own company. Starting a company showed courage and demonstrated that I had the entrepreneurial spirit he was looking for in a General Manager (GM).

I’ll talk more about my startup, GiftSimple, and what its failure ultimately taught me about entrepreneurship and success, as well as my decision to join DoorDash and my experience as the first GM in subsequent posts. For now, we’ll start with my transition from the Operations team to Analytics. It was the spring of 2015, and after making it through the snowiest winter on record in Boston, I had hired and onboarded the permanent GM for the market. It was time to move on to the next city launch. During our conversation about which market I’d go to next, Tony noted my penchant for asking questions. With our future launch plans growing, we started to compile a launch playbook to establish what a good launch looked like. I asked a lot of questions and had a lot of opinions on how we should set goals for each launch.

I felt strongly that the goals for each market should be different—depending on factors like total addressable market and competition—and I wanted to set goals on the input metrics that the local teams could control. I had spent time trying to understand how the core fundamentals of the Boston launch—selection, quality, and price—drove growth. And I was determined to find a way to measure the ROI of our marketing efforts during the initial months of launch, so we could learn what tactics worked for the next one. Given all this, Tony suggested I pack up my suitcase, deflate the air mattress I’d been sleeping on in downtown Boston, and move to headquarters in California to help ask and answer these key questions, full-time.

Tony recognized that I could be more effective working across all geographies rather than focusing on one. He encouraged me to lean into my strengths: asking impactful questions, a love of complex problems, and a relentless drive to get the right answer. I saw an opportunity to both answer my own questions and uplevel the overall business by creating a new function. At first, I was hesitant to make the move, as the scope of the role was ill-defined and the goals unclear. The GM role was a known entity. Ultimately, what swayed my decision was excitement about the problems I’d be working on—and the promise that if I hated the new role, I could go back to being a GM. At the time. this felt like a major pivot, but in hindsight, it was a natural progression.

I called the new team BizOps (Business Operations & Analytics) after learning about a cool-sounding team at Yahoo and LinkedIn, through Dan Yoo. I was a jack-of-all-trades trying to identify and solve the most important problems for the company, whether that was setting the right goals for new market launches, digging into the drivers of consumer retention, or making sense of our customer complaint data. No matter the problem, I kept the “operator” mindset so core to DoorDash’s culture and focused on quickly driving business results.

I won’t pretend I had a grand vision for Analytics in the early days. That time was a chaotic scramble to solve problems, only to encounter new ones along the way. I was a one-woman Swiss army knife playing whack-a-mole with an endless supply of business questions. I got my first headcount when I showed Tony the backlog of work I wanted to get done—a list full of things that were also top of mind for him. For my first few hires, I wanted folks who were generalists, but who possessed complementary skills to me. Hiring folks who possessed skills I didn’t have was a key part of my success at DoorDash. Much of what I learned about data science, I learned from my team. I will talk more about my hiring philosophy and process in a later blog post, but I will say that I owe a lot of my success to the amazing folks who have surrounded me on the Analytics team over the years.

The complexity of the problems increased, requiring the sophistication of our analysis to increase in parallel. This meant hiring more specialists, including data engineers, machine learning data scientists, and statisticians. For me, success was always measured by impact, and I held my team to the same bar. I expected recommendations—not research—and that all of our work connects to a company goal we were trying to achieve. We used the power of analytics as a force to increase the speed and quality of our execution, and I believe this was a key part of DoorDash’s success in those fundamental years.

Today, I lead a 600+ person global Analytics team across DoorDash, WoIt and Deliveroo. As DoorDash, Inc., we operate in over 40 countries, worldwide. The team’s reach has expanded over the years—and the depth of our analysis has grown—but our goal to drive real business impact has not changed.

Over the last 12 years, I have been a GM and I have led teams across data engineering and business intelligence, experimentation, machine learning, data science, and bizops. My journey was not planned but came about organically as needs arose and opportunities presented themselves. I was intentional about never saying “I can’t do that” and replacing it with “How might I go about doing that?” —learning from the DoorDash value to “choose optimism, and have a plan.”

Click here for part two, how I started my finance career in the midst of the financial crisis.