If you missed the headlines a little while back, DoorDash is "forcing" all of its employees--everyone from their engineers to their CEO--to make deliveries on the platform. And some of the employees are "furious."
That's the headline, at least. The truth is a little more nuanced. And when you get to the truth, you'll understand why startups have been doing this kind of thing forever. Here are four truths:
- Truth: The DoorDash program has actually been around since the company started operations in 2013. Like a lot of other non-survival-related initiatives, it got derailed by the pandemic. In December, DoorDash announced internally that the program would resume in January. That's when things got furious, for various reasons, some of which probably felt like a blindside.
- Truth: Employees don't have to make deliveries. They can also shadow customer service or otherwise "support a merchant."
- Truth: As far as I can tell, from multiple stories, the "revolt" against the program is one (alleged) engineer griping on Blind.
- Truth: The program is part of a broader community and philanthropic effort intended to be baked into the culture of the company. But it's also a means for every employee, from the top down, to understand the product, the service, the customer, and every aspect of what goes into perfect order performance.
How Startup Leadership Works
The effort isn't about the task; it's about the knowledge.
Consider this anecdote. Over the December break, while a single DoorDash engineer was anonymously making headlines, I was on my hands and knees in my front yard quite a lot. When my home's 10-year-old outdoor-lighting system suddenly died, I decided to rewire and replace the entire system myself.
I know very little about electricity, transformers, and wiring, so as you might imagine, it took me longer than it should have, got me dirtier and colder (and swear-ier) than I'm used to being, and left me with all sorts of cuts and bruises, but thankfully no shocks or high falls.
About halfway through the project, one of my kids asked me why I was doing it. Why not just pay a professional to do it in half the time with fewer things going wrong along the way? It's not like I'd be wasting that time, because it'd be time I could devote to my job or my family or whatever, likely with a greater return on the investment of that time too.
I'm not cheap and I'm certainly not one of those HGTV DIYers. But the facts are that I had never done that exact kind of work before, that I knew nothing about it, and that I was at a total loss when the lights went dark. Those were the very reasons I took on the project.
I wanted to be able to build something better than what had been built before. I wanted to be in a position of knowledge if something like that ever happened again. As a bonus, I wanted the satisfaction of adding that knowledge to my book.
And I wanted things to go wrong along the way so I would have to figure out how to fix them, properly, not with a hack or a bridge.
I can't think of a better metaphor for startup leadership.
Hitting the Mark, Every Time
Success isn't about serving the customer--it's about delighting the customer.
Why is a lot of software, either traditional or software-as-a-service or mobile, clunky to learn and difficult to use?
Why do a lot of tools, physical or digital, work well the first time you use them but become cumbersome after repeated use?
Why does online ordering seem like magic the first time you use it but then seem like a waste of time when you show up to pick up an order that hasn't been started yet?
"Delighting the customer" has become an overused phrase lately, but its meaning still holds true. Where it gets misconstrued is when it's used to describe going "above and beyond" for every customer--mostly in an attempt to rectify poor or average service, especially when complaints happen.
But delighting the customer is, at its heart, about loyalty. And to achieve that level of loyalty, the kind that drives scale, a company needs to hit the right mark, every time. That comes from setting the proper expectations and executing to those expectations, every time.
You can't do this when you don't know what those expectations truly are.
You can guess, you can survey, you can aggregate, and you can assume. But until you actually get down on your hands and knees and see how the wiring should be connected, you're going to make potentially costly mistakes, at least some of the time.
If you're an engineer working on software that is either used by or is part of the system serving the customer, you should be at least a little aware of what happens when the customer finishes using the software and begins interacting with the service for which the software is setting the expectations.
All the user-acceptance testing in the world isn't going to uncover those flaws, whether the flaws are the software's fault or not. When you experience those flaws first-hand, you gain new knowledge, and you start thinking about how the software can help eliminate those flaws.
That's why every executive, every engineer, and in fact every employee should take time to help build, sell, and support their own product. It's not for a photo-op of the boss rolling up their sleeves. It's to actually help them do their job.