Tell us about your background and why you joined DoorDash.

I started learning about logistics and scaling a business very early on, because my parents were entrepreneurs in the auto parts industry. For a while, when I was three or four, they were storing parts in my room! Eventually they got a warehouse, and as I got older, I would go with them to work. There were a lot of challenges—trying to predict traffic in the New York City area, where we lived; managing inventory; figuring out how to keep up with customer calls before we could afford to hire a full-time salesperson or driver or pay for another van and insurance.

Then I studied mechanical engineering in college and got my first job on the operation production line for a defense company, which was another logistics lesson. We had software to help us, but it just wasn’t robust enough to handle the complexity of what was essentially a Lego set with hundreds of thousands of pieces. 

At the time, I was also getting really interested in mobile software engineering, and after a while I decided to take some time off to study iOS development. I worked at a software consultancy where clients were tech companies in the Bay Area, and then I applied to DoorDash a few years ago. I felt like I really understood the problem this team was solving because it was so similar to what my parents had gone through and what I’d seen in my first job. And then once we started talking about a role, the company was just incredibly accommodating.

I’d been planning to move to the East Coast because my wife was starting school in Philadelphia, and this was before DoorDash had a New York office. So we came up with a schedule where I could work remotely, on East Coast time, for one week every month. I couldn’t say no.

What’s the team culture like?

One thing I like is how much ownership we have. Anyone can raise their hand and take responsibility for something they’re interested in; you’re trusted to solve problems here whether you’re a principal engineer or a new grad. And while no one expects you to get a feature right the first time, you’re held accountable for following a good process—asking the right questions, building something, and iterating from there.

Each project has what we call a “directly responsible individual,” or DRI, who attends meetings, reports up, and manages documentation, and we all take turns in that role. We want to make sure everyone else on the team has time to focus on coding—and on whatever else is happening in their life; during this cycle, for example, I’ve been busy helping my mom consider moving to Europe, so one of my teammates is the DRI. But we also want to make sure everyone gets a chance to grow their skill set. DoorDash is a very collaborative place, and the DRI gets to work with all kinds of different stakeholders—designers and product managers, senior engineers, data scientists, marketing and comms, you name it. You learn a ton about how different functions work and about how to communicate, whether it’s getting a new team member up to speed or explaining a technical project to someone in a non-technical role.

What projects have you been working on recently?

We’re always making tweaks, but our contactless delivery project wrapped up not long ago—that was a massive effort, the biggest problem I’ve ever worked on. Before COVID-19, most deliveries were handed directly to the customer, so we had high confidence that they actually got what they wanted. We had to figure out how to maintain reliability with deliveries being left on porches and outside doors, and how to handle exceptions—like orders that require age verification, where you have to show ID.

As with every project, we got things wrong at first. We started providing photos of the delivery drop off location to customers, for example, but then the files were too big and took forever to load, so we started working on image compression. But that’s the great thing about DoorDash—we’re constantly getting feedback, whether it’s through user research or from our beta community and talking to Dashers directly, and it all helps us make the products better. 

It was the same thing with another project we just launched last week, a rebuild of a feature called Hotspots, which helps Dashers find areas where lots of orders are being placed. I thought we nailed it—but of course there were font sizes and all kinds of things to tweak. Our work takes patience, and we often realize the timeline we threw on the road map will have to be extended in order to release a feature, get good feedback, and then get the engineers back from whatever else they were working on so they can make improvements. But we always try to put in the time we need to build things right.

Tell us about a challenge you’ve faced in your role.

Not long after I joined, my team was working on a project with a major retailer—creating a pop-up in the app that would appear when a Dasher got close to the store, to tell them exactly where to park when picking up their order. Because this was a major merchant, our VP of Product Management, Rajat, was involved, and our team met with him to answer questions. I wasn’t happy with my performance when I came out of that meeting—I hadn’t really known how detailed or high-level to be with someone so senior, and there were some questions, especially around metrics, that we just didn’t have answers for.

But we followed up on those things, and it turned out to be a really valuable experience. Rajat’s feedback helped us make tons of quick improvements on things like language, readability, and timing, and I learned to always keep track of how a feature is performing—or to do the engineering work to make sure our partners on other teams can access that information directly.

I’ve been able to pay it forward and help other engineers on my team prepare for similar situations. We’ve done exercises in one-on-ones where we go through every internal audience for a project, from our teammates to designers to the VPs and CEO, and talk about what information they need and the best way for us to share it with them.

What are you looking forward to as DoorDash grows?

There’s so much! In part, that’s because of our fantastic Strategy and Operations team. They’re constantly talking to people and doing experiments before a project ever gets to Engineering—they basically deliver every single detail about a problem to us on a plate, and we just have to figure out how to fix it. So there’s never any shortage of improvements we can make.

One thing I’m especially interested in as we grow is making sure we’re tuned into the rules and cultures of each new location. I got to be part of our launch team in Melbourne, Australia, for example, and it was an eye-opening experience; a simple thing like being allowed to park scooters on the sidewalks has a huge impact on delivery times. Knowing all those little nuances of policy and even language really helps us work effectively in new places.

And every time we hit the next level of scale in one of those communities, it’s a chance to go back and make things better one more time—shave off a couple more seconds from the delivery experience, make something more clear, throw out anything that’s not helpful. When a million people are seeing a feature we’ve built, an improvement of even a tenth of a second will save them, collectively, thousands of hours every week. Each iteration makes their lives a little easier, and that makes me really proud.