Highly Paid DoorDash Engineers Have to Deliver Food, and They’re Not Having It

Here’s why they should suck it up and do it anyway.

The DoorDash Dilemma

What’s this, you’re a DoorDash engineer making hundreds of thousands of dollars annually and you have to deliver food?

It’s recently come to light, that once a month, the company encourages, nay, forces all employees to pull out the app they created and make a delivery or two. The internal program is called “WeDash.”

The internal uproar has been exposed as of late, and the general dissent has been made public. DoorDash employees are not on board with this company practice, despite it being a performance metric.

Is their reluctance ego driven? I’m an engineer, I don’t deliver food. Is it a time constraint? I already have a fulltime job. I don’t need to make any deliveries. Although, almost undoubtedly, making deliveries as part of the program would be considered “on the clock.”

Or is it simply “this is not what I signed up for.”

However, for the creative team, especially the developers, there are untold benefits to using the app as a Dasher, a delivery person. Having created the app, it’s almost a certainty that some of these developers have placed orders for themselves at work, or to their homes. As such, they would have exercised only half of the app’s functionality.

What about the other half that the Dasher uses?

Use It or Lose (at) It

One of the most unsung benefits of software development is the personal satisfaction of seeing products you created in actual use.

I remember visiting a client where my company had installed several hundred licenses of our software. I recall standing behind dozens upon dozens of users, each one visibly using our application. I watched as they clicked through the windows, clicking buttons and entering information into text boxes.

These were buttons I created, text boxes I had lovingly positioned, and windows I had carefully crafted with precision. I could predict the error messages that would pop up if users entered wrong values. I knew which windows would be displayed when certain actions were taken.

I literally knew the software inside and out.

On this particular product, I had spent 18 months, day in and day out, laying down every piece of code, every error message, and everything that the user interacted with.

Yet, as I watched these users, they were flying through the boxes and the screens. They were seemingly much more adept than I ever was. If I thought I knew what windows would ensue on clicking a button, these users knew even more so. They also knew exactly where to click next, which text boxes to fill, how to fill them and how to efficiently sidestep niggling little flaws, flaws that were never apparent when I was doing the clicking.

When I used my software, I simply clicked through the screens to test functionality. I was entering mostly garbage data. These users were entering real data. Real data of real people. Entering incorrect information would result in real consequences.

My usage of the software never measured up to how much the actual users used the product I created. I never actually used my software. Thus, I never personally encountered the nuanced flaws inherent in any piece of software. After all, I entered mostly test data, and mechanically clicked through the screens to ensure that everything simply worked.

Watching actual users click through screens, I was immediately conscious of how certain actions seemed painful, convoluted and intricately more difficult than necessary.

Dog Fooding

“Dog fooding” is a term used in software development circles that explore the idea that the developers themselves must be active users of their own software.

The term itself did not originate in the software industry, but it gained a popular foothold from there. In the late 80s, Microsoft espoused the idea of dog fooding, encouraging their employees to use their own products.

As a dog food manufacturer, how would you know if the food was actually tasty? The dogs certainly couldn’t tell you. Dogs chowing down enthusiastically on the food was not an accurate measure of its taste. The only way to know was to sample it yourself. That’s the sentiment behind dog fooding.

The Gemba Walk

Genba, as it is originally spelled from its Japanese roots, is a similar idea. The word Genba refers to “the place where value is created.”

In my example above, this would be the floor where my dozens of users interacted with my software. The Gemba Walk is the act of visiting my users, watching them in action, taking notes of their efficiencies as well as their inefficiencies.

Ideally, taking the Gemba Walk leads to improvements in the observed products and processes. And conversely, not taking the walk could inhibit any possible improvements that would otherwise be undiscovered.

DoorDash Redux

If I were a DoorDash developer, I would leave my ego at my workstation, pull out the app, and hit the streets. It would be a welcome break to get out in the open and catch some rays.

I’ve been doing this for far too long. My egos no longer exist. I’ve been coding for more than half my life. I know it’s never enough to create the product purely based on specifications, blueprints and project charters.

There is inherently a human element that comes with software development. It’s called users.

I know this now. I know this after watching dozens of my users stumble through my software, while making a mental note at the same time, that an easy fix would be made for them in the next version. They didn’t even know to ask for a fix. Taking my Gemba Walk was a revelation on how I could make their daily working lives just that much more enjoyable using my software.

Users will find all your errors. Users will expose the developer’s shortcuts. Users will either sing your praises or down-rate your creations to oblivion. Be nice to your users.

DoorDash developers, suck it up. Go be a user. Eat your own dog food. Take your Gemba walk. Remember that without your users — those who order and those who deliver — you wouldn’t even have your highly-paid job. If you truly care about your app, your Dashers and your company’s whole raison d’etre, my order will be waiting for you.

I’ll also leave you this tip: “You build your app for your users, not for yourself.”