The DoorDash Operating System, part 1.
How you hit the number.
This whole blog is nothing if not one giant, mostly-accurate subtweet of all the various models, processes, and principles that comprised what you could call the DoorDash Operating System1. And arguably no part of that system was more important - and deserving of being part 1 - than how it set and then methodically worked to hit its incredibly ambitious goals.
1. Annual clarity
I remember sitting in a ballroom at a Lake Geneva, Wisconsin resort in 2006 for one of Bain & Company’s annual summer meetings (this was only a few hours before our analyst class decided to go swimming in one of the golf course’s water hazards; it was a different time). Anyhow, the firm’s worldwide managing director had flown in to give a window into the company’s strategy, and had just thrown up - pun so much intended - an overview slide on the room’s massive projector screen.
It had thirteen strategic priorities. Thirteen! I can barely remember my cat’s birthday2, let alone thirteen strategies for how to sell expensive PowerPoint decks to the least cash-strapped people on planet Earth.
DoorDash was, in every way, completely different. My first year there I remember Tony sharing, at that January’s all-hands, our 2017 strategy. And it was effectively just a single number:
We’re going to do x many deliveries
[And as a constraint, we’re not going below $y in unit economics]
The end. That was the strategy.
Years later, in a similar town hall meeting, Tony was asked if he had an expansive product vision to share or if he could elaborate on his top strategic pillars for the year. The answer?
“No, let’s just go out and hit the number.” His point was the right one, in that his job was, among other things, to set our objective in the clearest possible terms and it was our job to go figure out how to use the resources we were given to get as close to that number as possible. And that if there were ever trade-offs to be made, you didn’t have to waste one second on which option to choose; you picked the one that got you closest to hitting the number.
2. Quarterly rigor
There’s a classic South Park episode called Underpants Gnomes. In this episode, as far as I can recall, there are a group of gnomes who steal underpants, with the explicit business model of:
Phase 1: Collect underpants
Phase 2: ?
Phase 3: Profit
This is basically many growth companies’ approach to planning. They have clarity on the outcome they want to achieve (profit), they have clarity on all the random initiatives they want to run (collect underpants), they just have no idea whether the latter will ultimately accomplish the former.
And I’m sure you’ve lived this at some point in your career. Your boss lays out an ambitious goal, and then you immediately run out the door to start doing stuff. You train your sales team, you run some ads, you tighten up your onboarding, you make sure your service quality’s really good. You do a bunch of very sensible things.
And then you fail.
What went wrong? Well, to start, you didn’t have a rigorous, high-confidence plan, or a plan that explains all the logical assumptions that connect your initiatives to moving your output metric (and why you’re confident that those assumptions are likely to play out).
A high-confidence plan starts with a kind of metric tree, which effectively unpacks your desired output metric into descending levels of input metrics. This is to 1. help identify what lowest-level inputs need to change to hit your goal, and then 2. sense-check whether you believe your initiatives - the improvements you’re going to make to your business - are likely to move those inputs.
An example of how this works:
Let’s say your sales team’s output goal for the quarter is adding gross new revenue of $1M
The first mathematical level of inputs is “number of sales reps” x “average deals closed per rep” x “average annual recurring revenue (ARR) per deal closed”
The second level of inputs, and let’s just focus on “ARR per deal closed”, is “average user licenses per deal closed (i.e. deal size)” x “average price per user license”
And so on.
You can do the easy math here to figure out what permutation of all these metrics ladders up to the $1M goal. And, assuming you do that, you find out that if you set every other input to a reasonable goal, the “price per user license” you need to achieve is 200% higher than the the highest price you’ve ever sold. Given you don’t have even one instance of a customer paying such a steep price for your software, you’ve effectively determined that hitting $1M with your current plan is impossible, and you need to go back to the drawing board (which is far preferred over sending your sales team out on a suicide mission).
Next, you ladder your initiatives - and their owners - under the metrics you expect them to move, to ensure you’re putting your energy behind the right things (if an initiative doesn’t obviously ladder to moving an input metric, why are you doing it?)
We start at $0 in incremental revenue
Then we’re going to increase our number of reps from 5 to 7, adding $200k in ARR
Hire 2 new experienced sales rep by [date] - Jim from recruiting
Then we’re going to increase deals closed per rep from 10 to 12, adding $300k in ARR
Implement new autodialer by [date] - Pam from sales ops
Launch new promotion strategy by [date] - Oscar from marketing
Then we’re going to increase deal size from 30 to 50 licenses, adding $200k in ARR
Garner x new y+ size leads from attending z enterprise conferences by [date] - Angela from enterprise sales
Launch new enterprise feature y by [date] - Dwight from product
Finally, we’re going to increase price from $50 to $75 per license, adding $300k in ARR
Launch pricing change for bottom x% of tail customer accounts with only y% churn by [date] - Toby from operations
If this all works, we land at an increase in ARR of $1M, with the following risks (risk 1, 2, 3)
Finally, let’s assume you’ve done the above exercise, and ultimately believe that your prescribed initiatives will work, either because they’ve done so in limited tests or because you’ve so successfully identified the biggest blocker to a metric moving that you know your solution will work.
The last step, then, in assembling a rigorous quarterly plan is a walk, which is basically just a waterfall chart that visualizes how you’re going to execute the fewest3, most impactful initiatives possible to get to your goal.
It looks something like this:
[Note: Very often - if you have a hardcore/ good finance team - the initiatives won’t initially ladder to the goal, and there will be a ‘gap’ bar. In that case, the planning conversation is largely around what you need to change, how much more money you need to spend, or how much the goal needs to come down, to get to a solution.]
Quarterly plan approved, now go forth and be awesome.
3. Weekly execution
Arguably the cornerstone of the DoorDash OS was the weekly cadence. Every week had the same flow, and it was incredibly effective. I cannot recommend this model strongly enough for pretty much any business.
Monday was essentially “figure out what happened last week”. You rocked up Monday morning and took stock of whether you hit or missed your North Star metrics from the prior week (you hoped and prayed they’d hit).
Given our goals were always hard, at least some number of your metrics probably missed, so you spent much of Monday figuring out what assumptions in your plan had been wrong to get that result. Could have been that a product launch was delayed, could have been that there was a bug, outage, or some other technology issue, could have been that some customer behavior was not as expected, could have been that there was a snowstorm, could have been that you and your team just weren’t executing very well.
By Tuesday you and your team had crafted your ‘what we’re going to do about it’ plan, for how you were going to get back on track, and had reviewed it at your own team weekly business review (WBR). Maybe you needed to change priorities, accelerate execution, or increase investment, but one way or another, you’d put together a rundown for how you were going to make your numbers turn from red back to green.
Wednesday was the company WBR. This meeting was the cornerstone of the week, wherein the company’s CEO and other C-level execs were able to drill into the 3-4 biggest areas where the business was missing plan and then kick the tires on 1. whether the corresponding teams had plans to fix and 2. whether they might need greater resourcing to accomplish their objectives. Importantly, the reliance on a single meeting - and a corresponding single Google Doc - helped focus the entire business, and make better, collective decisions. In essence, if it was a part of that meeting/ document, it was important, and if it wasn’t, it probably wasn’t.
Immediately following was the company’s very small management team meeting to review [I assume, since I was never once in that room], 1. business performance, 2. the previously discussed changes in resourcing, and 3. their prior weekend’s trip to the annual Golden Ferret Derby in San Sebastián (or whatever else it is that that Illuminati squad does when it’s not running a very successful 3rd party delivery marketplace).
Thursday and Friday were then reserved for uninterrupted execution (with the obvious point that most of the team was executing in the background the entire week).
While this all may seem like overkill it achieved a number of amazing things:
Maximum accountability: You ideally did not want to go to the WBR on Wednesday to explain how you were missing goal for the 5th straight week, thus worked like a maniac every week to ensure you hit.
Continuous learning: By digging deeply into performance each week (with your analytics partner) you were able to learn what was/ wasn’t working, expose what assumptions had/ hadn’t been right, and then course correct to improve going forward.
Iterate to hit the number: This cadence gave the management team ~12 opportunities each quarter to adjust their resource allocation in service of hitting their single, top-line objective.
4. Daily 1% improvement
Finally, outside of all the annual, quarterly, and weekly structure, there was a broadly-understood norm around the speed at which each of us was expected to work. That progress was not just made in big chunks as we hired new people, launched new markets, and released new features. It was also, perhaps more importantly, made in small, rapid, almost unnoticeable daily improvements.
That daily execution came in a few different flavors:
A culture of “we hit our goals”: You can imagine a company that’s at 90% of its goal with 3 days left in Q1 already focusing on Q2. Not DoorDash. No, if there were 3 days left, even if it was Saturday morning, the question was “what can we do, what levers can we pull, what money can we deploy in the next 3 days to close the gap.” You played until the clock ran out.
Small improvements matter: The placement of a button. The retention of one customer. The fixing of one bug. The hiring of one new person. Companies don’t become great just by the 2-3 big rocks they execute each year, but also from the compounding of all the tiny, seemingly inconsequential wins that every teammate accrues over the course of a year.
You can fix faster: It was always fun watching a new employee, who’d just missed their weekly goal, hear the phrase, “great, let’s start a daily stand-up and meet back tomorrow with an update”. Teams were expected, especially if they were underperforming, to make not just weekly but daily improvements toward their goals, which not only increased their annual reps from 52 to 365, it made them question assumptions about how much could be done in a short, 24 hour period.
DoorDash was many great things. One that stands out, chief among them, was that it was ruthless in prioritization; it trained maximum energy on only those things of maximum impact. And it was the above structure that was able to take a single, lofty objective and tie it directly down to what every single employee thought about and did, every single day.
Next time on Missing & Incorrect: Who sets the number?
Which was arguably just an evolution of the Amazon Operating System (which, conversely, if you go back far enough, was itself a derivative of the original 1876 Hokkaido Squid and Bicycle Concern Operating System).
That’s a lie, I totally can.
An evergreen note from our COO, and one I got at least a few times, was “if there are too many steps in the walk, you don’t understand the problems well enough yet.”