As any engineer will tell you, the culture of an engineering team has a big influence on day-to-day work. That’s why Ryan Sokol, VP of Engineering at DoorDash, built a culture focused on transparency and the ability to ship fast. And that flexibility is important, given that DoorDash is tackling some of tech’s most challenging logistics. DoorDash is the number one food delivery app in the United States, with over 18 million users and 45% of the American food delivery market share. Their engineers are tasked with anticipating and mapping every possible scenario in the physical world to provide users with reliable, timely service.
So how do you build a remote engineering culture to make all of this possible? In our most recent Tech Talk, Terminal’s co-founder Dylan Serota sat down with Sokol to find out. We’ve pulled together some highlights from the discussion below. Be sure to watch the full 34 minute recording.
Sokol: Our CEO says this one thing all the time: “Culture is 80% of who you are and 20% of what you want to be.” We’re a culture that’s light on rules. We try to create frameworks rather than processes so that it’s easier for engineers to do the right thing, though we’re not always perfect there. And we’re a culture that really values transparency. And to achieve true transparency, people have to be able to talk openly about failure, so we’re as blameless as we possibly can be. We’re very retrospective and always looking back to try to learn from that failure and be transparent about it, but we’re never there to blame the individual.
Sokol: DoorDash maps the physical world, and mapping the physical world is very, very difficult, so there are a ton of challenges around that. Think about the average DoorDash transaction. Think about everything that goes into that. Take, for example, predicting how long it’s going to take to get the user their food. It’s one of the hardest predictions to make in all of tech, because you have to map the physical transport of that food, you have to map its preparation, you have to map parking, you have to map Dasher understanding. So it’s a really difficult thing to do, and that’s just one part of our logistics network that is super exciting.
We’re transitioning into the world of convenience and grocery stores where there are hundreds of thousands of items that are not categorized canonically like they are in a restaurant menu. So we’re getting into this SKU-based world, which transforms our search problems. It’s a super interesting set of things to work on as we try to move through that.
Sokol: We’re a microservices-based company. We have about a hundred microservices across a thousand engineers, and the vast majority of them, about 99% of them, are written in Kotlin. We chose Kotlin (or rather, my engineers chose Kotlin) because it was a bridge between the world of Python and Java, and where we wanted to be. So we chose it, and we’ve been able to create a big piece of our developer stack around it. We also use Cassandra and a database called CRDB, or CockroachDB. We use gRPC for transport, and a lot of Kafka for async stuff. We use a lot of things that begin with a “K” sound.
Sokol: We have three different operating and engineering cadences. We have a pure product cadence, which basically means we plan for the quarter and execute sprint by sprint, two weeks at a time. We release features constantly, and we’re not afraid to blow everything up and change plans in the middle of a quarter. About half of our engineers work on this cadence.
There’s a second operating cadence, which is more of an engineering or a product platform cadence, for folks who are creating software for other engineers. That includes things like search, discovery, ranking, shopping cart, payment, logistics, and mapping. We plan quarterly there, too. There’s a lot of product involvement in what we’re going to build, but we don’t really blow these roadmaps up. The reason is there are so many people in the company who are dependent on the product platform cadence.
And then the last cadence is the infrastructure cadence, which we plan six months at a time. These goals are bigger and they don’t necessarily fit into sprints or quarters, but we still release at milestones every couple of weeks and we track goals that way. We change these plans even less if we can. Sometimes, 20% of the plan gets all blown up in any quarter.
Sokol: COVID has taught us a lot about what we’re capable of. I haven’t seen most of the engineers on my team in person for 18 months. That experience has opened up a ton of geographies for us, specifically geographies to the north and south of the United States. We’re excited to get down into Mexico, which is timezone-friendly with our east coast team specifically. And we’re excited to tap the top tier of engineers in Mexico.
Sokol: In the end, I want a technologist. I want somebody that likes to write quality software that meets customer needs, and not just science experiments. I want somebody that looks beyond the boundaries of their existing team, and really understands the inputs and outputs of what they do. I want someone who is very business-minded, very business-focused. We’re really trying to move things forward for the business, so that’s essential.
DoorDash is going through a period of rapid growth and change, and it’s an exciting opportunity for Mexican engineers who want to work for a Silicon Valley tech company without having to relocate. Mexican engineers working remotely will be able to help DoorDash expand and move into the next stage of its company goals. “We’re in a transition phase in the company. We’re really good at food delivery, specifically in the US, Canada, and Australia, but we’re trying to be much more,” says Sokol. “We’re trying to be the app for absolutely everything.”
DoorDash is teaming up with Terminal to launch a remote engineering team in Mexico. If you or someone you know is interested in learning more about joining DoorDash’s first Mexican Engineering team, apply today. There are open roles for both Front End and Back End positions.