The DoorDash Operating System, part 3.
Who drives the bus?
Have you ever been to a kid’s birthday party?
It’s a dozen small children imbued with the energy of a meth-addled Sonic the Hedgehog and the impulse control of peak-tiger blood Charlie Sheen. You could basically tell this group of lunatics to “go play” and each of them would do something different. You’d get one kid smashing skulls in the bouncy castle, you’d get one drawing a crayon self-portrait on your kitchen floor, and you’d get one who just really wants to tell you a story (and the story sucks, because they’re 3 and they have no life experiences).
A kid’s birthday party is a lot like a modern tech company.
Think about your company. You’ve got sales. You’ve got marketing. You’ve got product, engineering, operations, people, analytics, communications, legal, and more. You’ve got all these different functions wherein if you told the head of each to “go hit the number” they’d all probably do something different. Your sales team would go start selling to larger, enterprise accounts. Your product team would start building a mass-market consumer product. Your engineering team would spend 99% of its effort implementing Kubernetes1. And in the end, with all the good intentions in the world, your teams would all turn in fantastic work, and you would all miss your company plan by about a zillion miles. Worse, you as founder/ CEO, would be spending a large and growing amount of your time trying to get all your disconnected VPs to play nicely with one another, until you completely lose your mind and have a 10x menty b.
This gets at a core problem - if not the core problem - in organizing a complex, modern technology company. It’s not enough to hire talented functional leaders and leave them to execute as they each see fit. No, all your different functions need to work cohesively together, focused on achieving a single, shared business output. Said differently, at the end of the quarter, who cares if marketing hits its new users goal if engineering lets your site crash at 5pm everyday such that no one can buy anything.
Enter my #1 favorite topic: pods.
The pod.
As a founder, you already implicitly understand the idea of pods. When you started your company it was just you, an engineer, a sales person, and a marketer. So when it came time to create a plan, you wrote it, you reviewed it, you assigned marching orders to your team, and you made sure you hit your goal. Pods are no different, save for the fact that you, founder, aren’t leading them anymore. They are simply cross-functional units, with one top-line business objective, and a single, ultimate owner.
If there was one thing that I would point to as the single underlying reason for DoorDash’s ultimate success it was this operating structure. So let’s unpack how these pods were built, and, more importantly, why.
The bus driver: ops.
You can imagine that there are a great many pure-play technology companies in which each product’s product manager ‘drives the bus’, owning their product’s business goal, and making all key decisions to hit it. They understand the customer, they understand the problems they’re trying to solve, so they set the roadmap for what ultimately gets built and sold.
Similarly, there are a lot of businesses where revenue/ sales drives the bus, in that every function simply does whatever sales needs, so that it can sell more. A prospective customer wants x feature, you go build x feature.
Or, sometimes even engineering drives the bus, focusing simply on building better and better technology (see: Berry, Black; c. 2007).
With the above options, who do you, founder, ultimately put in place to run your business?
The solution, and a sometimes controversial one at that, is a fourth option: operations leads, with a single operator ‘directly responsible individual’ or ‘DRI’ running each pod. This person is appointed by management to oversee a key business metric, and coordinate a cross-functional team to execute a plan to get that metric to goal.
Let’s unpack why operators are uniquely positioned to play this position.
First, skills. What makes you a great product visionary or slinger/ slanger of deals might not make you expert at crafting a high quality plan and working deftly across functions to hit it. Operators, based on their profiles (very often as business generalists/ former management consultants2), have a depth of experience in the above, and slot in quickly managing a large, complex team. Oh, and they’re very often ultra-competitive loons who’ll sooner throw themselves in a volcano than miss a goal.
Second, bandwidth. If you’re on the hook to deliver a 10x product or a couple of massive enterprise deals, you don’t have spare capacity in your week to also make sure everyone else delivers on their inputs. Operators, given this is essentially their full-time job, do.
And finally, agility. Many business functions operate on long time horizons, with new product development, engineering investments, marketing programs and sales deal cycles being measured in quarters or even years. These teams need breathing room to learn, think, build, and iterate without the week-to-week grind of hitting an immovable business goal. Operators, in contrast, can make decisions and pull short term levers at daily intervals, meaning they are more responsive to getting a goal from 92% to 100% just as the quarter runs out.
The artillery: product & eng.
Product is a pod’s artillery, in that, in a given quarter, it has the potential to deliver a few initiatives that will have a massive impact on the business. Case-in-point: whereas we, a dozen local DoorDash operators, spent a quarter tinkering with our markets to bring down delivery times 2%, product, with a single change to driver assignment logic, brought that number down 20% overnight.
It was for this reason - the incredible value that product delivers - that DoorDash explicitly chose not to have product lead its pods. No, given that product needs time to study, build, and iterate on its 10x deliverables, it made no sense for it to also have to lead and police every other function. Instead, product was evaluated narrowly on whether each of their product releases succeeded in changing customer behavior in the direction and amount that they were supposed to, as key inputs to the overall plan.
This sometimes feels counterintuitive: why isn’t technology leading if it’s a technology company?
Imagine this scenario. You’re a SaaS product manager, it’s 3 weeks into a 12 week quarter, and you’re 35% off your pod’s revenue goal. If you’re the pod DRI, are you now going to drop executing your quarter’s two most important new features to go deep on fixing your pod’s sales team? Are you the most qualified to do that and, even if you are, is that really the best use of your valuable time?
The referee: analytics.
Analytics in startups is very frequently built wrong. So many companies treat analytics (or sometimes ‘bizops’) as the analysis and decks people. You can ask them a specific question, and they’ll give you a specific answer. The result, with this kind of passive analytics team, is that individual functions often end up creating their own reporting, effectively policing themselves on whether or not they’ve hit their metrics. This leads to a constant second-guessing of reporting across the company, and lower quality decision-making.
Imagine the following situations:
It’s Monday morning and one of your company’s North Star metrics - user engagement - is 15% off goal. Operations, finance, and product all retreat to figure out why, with each coming to a different conclusion. Who’s right?
An ops-DRI shows up to your company’s weekly business review with all green metrics, which they pulled from dashboards they themselves created. Are those dashboards right? Is that team really on-track?
A new product is launched, with its product manager reporting that ‘customers love it!’ Do they really? How do we know that? Did the product measurably change customer behavior?
Analytics at DoorDash, built and led by a rockstar of the discipline, Jessica Lachs, was different. It served as the global source of truth for the business, and operated as a sort of independent referee or umpire, calling balls and strikes for every other internal team. You’re a PM and you launched a new product? Analytics ran its A-B test and would ultimately tell you (and everyone else) if your product did the thing it was supposed to. You’re a GM and you want $2M to run a local market promotion? Analytics would tell you (and your boss and their boss) whether that $2M was a worthwhile allocation of resources. You’re an operator and your North Star metric tanked over the weekend? Analytics was responsible for figuring out why that happened such that ops had a good idea what to do to fix it.
The guest stars: sales, marketing, talent, et al.
I can feel it. You marketers, sellers, communicators, resourcers of humans, thinking that, well, you’re not really in the pod. And that’s true to an extent: you’re not in every pod. For obvious reasons, at DoorDash there was no sales member of the customer experience pod, and there was no marketing member of the logistics pod. But there was of course a marketing member of the consumer growth pod, and a sales member of the restaurant selection pod.
The point here - a fairly basic one - is that central functions could be drawn when needed to contribute specific inputs to a given quarterly plan, while still being managed centrally for maximum efficiency.
Your parents: finance & legal.
Finally, everyone’s favorite buzzkills: finance and legal. Both had small but important roles in pod life, and those were ensuring that the right amounts of money went out and came in, and that no one got the company sued into oblivion.
Finance, for its part, allocated finance business partners to each pod, to essentially keep tabs on pod progress such that there was a real-time view of where the company’s P&L was likely to land for the quarter. And as an operator, chats with your local finance goon came in one of only two flavors: if you were off goal, what were you going to do about it, and if you were on goal, can you do even more.
Legal at DoorDash, to its immense and enduring credit, was not the typical ‘no squares’. Instead they served more as a ‘yes, and’ function, helping each pod navigate their unique legal requirements such that they could achieve their business objectives while not breaching any laws or regulations. To this day some of my fondest memories were working with my early legal partner, having conversations that were some version of, “So no, you definitely can’t do that, however you can do any number of other much more sane things to achieve the same result.”
Everyone on the bus.
While much of the above focuses a pod’s static structure, its ultimate working output is a high-confidence plan that articulates exactly who in the pod needs to do what to hit your given business objective.
At DoorDash these plans typically looked something like the snapshot below, clearly outlining the DRI, each initiative (scoped, sized, with a named owner), and the quantitative ‘walk’ to the pod’s goal:
If you hire great people into product, engineering, operations, and revenue, those people, at some point, are all going to want to lead. Unfortunately, given that multiple leaders effectively means no leaders, you, as a founder, are going to have to eventually make a hard decision about who sets the plan and is ultimately held accountable for hitting it. For better or worse, my lived experience is that an ops leader and an integrated pod structure around them is the absolute best way to ensure your disparate functions are working together effectively to achieve your most important objectives.
I have no idea what Kubernetes is but an engineer friend told me this joke would crush.
Hold for applause.