Prioritizes projects at DoorDash

Tell us about your current role and the team you lead.

‍Marco: I’m the engineering manager for two teams at DoorDash — the Developer Console and Test Platform teams. They’re both part of the Developer Platform organization that sits under the wider Infrastructure organization.

Do you have a charter for your team specifically? How would you define the mission of your team?

Each of the two teams have well-defined charters. Actually, the reason why these teams were born in the first place is because I wanted to have well-defined charters and an ownership model for both of them.

Initially, there was just one team which was called Developer Productivity, and the problem I saw was that the charter was too wide. So I decided to split the team into two smaller teams that had a more focused set of concerns and ownership.

The mission for the Developer Console is to build a one-stop-shop portal that can be the center of everything engineering at DoorDash. And the Test Platform team’s mission is to promote testing as one of the core tenants of DoorDash engineering.

And could you share the origin story of this team? When was the team formed?

So, as I said before, originally there used to be just one team that was called Developer Productivity. It was formed because as you know, companies go through different stages and each stage has a set of priorities.

When I joined DoorDash, it was very much in a startup-like stage, meaning the priority was to deliver value to our customers quickly. When that happens, you can hire more people and that contributes to delivering more value. Knowledge is mainly tribal because nobody has time to properly document stuff. Testing is not done, or everybody has their own ways of testing. And there is no well-defined tech stack. There are no well-defined processes. There are no well-defined frameworks. So with time and as people come and go, that situation gets worse — up to the point where hiring more folks actually slows everybody else down.

That’s when a company needs to focus on guidelines, patterns, and standards. And that’s the situation that I found DoorDash in. So we started a Developer Productivity team.

You were essentially employee number one on the Developer Productivity team, so what were some of the very initial projects you took on?

Yeah, the early projects of a team like this are often reactive. The first project we took ownership of specifically was around incidents: there was an incident in which we had a big problem because we were starting our deployments with rolling updates, but we didn’t have an instant rollback. And so we introduced Blue-Green as the solution to this problem.

Another problem we had at that time was there was no external monitoring of user behavior. Like there was no in terms, golden workflows in tests. So that was another project we took on.

These are just two examples of things that had a very high impact.

As you mentioned earlier, with startups especially, there’s pressure to have everyone focused solely on shipping features to customers. I’m curious, when you started the Developer Productivity team and focused on these early projects, did you get any pushback on allocating time towards that?

No, that wasn’t a problem. DoorDash leadership historically has always been very in favor of investing folks’ time and effort into making the productivity of developers better. We demonstrated that what we were working on was worth investment, and jump to today, we have an entire Developer Platform org.

One thing you mentioned earlier was that initially when the team was founded, you jumped into problems that were mainly reactive. As your group has evolved, how have you evolved the way you decide what to tackle and what to focus on?

In the last three years, we’ve evolved from spending 99% of our time firefighting and solving problems reactively, to now where we have a very well-defined process and a very well-defined team, and we can actually be proactive. Also the amount of incidents that we now experience is orders of magnitude smaller than what it used to be.

Today we figure out what to work on by taking signals from different sources, bringing them together, and prioritizing. Some of the sources we look at:

• Surveys. We send out regular surveys to our engineers asking them how they’re doing and asking them what can we do to improve their life, what their pain points are. Now, personally, I’m not a big fan of most surveys because they ask questions at times when I’m not experiencing the issue.
• Slack channels. Every customer-facing team at DoorDash has an “ask channel” (“customer-facing” in our case meaning our customers are DoorDash’s engineers). Other teams can open the channel, ask questions or say “I’m stuck, please help me out.” What we hear in those channels can be a good signal for areas of friction developers are experiencing.
• Our ambassador model. One thing that’s historically been hard to solve is getting to know our customers properly. (Again, “customers” meaning the engineers.) Sometimes we develop things for our customers, deliver them and they tell us “Yeah, this is not useful to us.” Or, “This is not really what we want or what we need.” So one of the things we started was an ambassadorship model, and this was specifically for the test platform team. Every quarter we dedicate one person to establish a well-defined relationship with another team. We started with the teams that were more distant from us. It’s amazing the results you can see by having these folks collaborate together.
• Doing roadshows. We also started to promote roadshows where we were going to each and each and every team in a popcorn-style fashion, just presenting ourselves. It was like, “This is who we are. This is what we do. Who are you? What do you do? And how can we work together towards the next milestone in your project?” Or how can we put your needs in our roadmap?" And so these also created a bidirectional channel that’s pretty much used daily now. That’s the beauty of it.

I’d love to dig into some of those strategies a bit more, starting with the ambassadorship program. How does that work?

There are many different orgs at DoorDash that tackle different use cases, very different workflows. There’s not just food delivery. For example, there is DoorDash Drive. There is DoorDash for Work. There is Storefront. So what happens is that, for example, when you start developing a testing solution ten to prioritize actors and use cases for the main workflow because that’s what covers most of the business.

So when we started the Ambassadorship program, we started with the folks that were left out previously by our plans just because of priorities. We got them in a room with our engineers and pretty much asked, “What can we do for you?”

And some of them were actually… I wouldn’t say angry, but they were frustrated by the fact that they weren’t given attention when developing such solutions.

Then we started having weekly meetings where I was not in the room. Only my ambassador was in the room. I was also giving the ambassador full leadership over the matter. They were sitting down and coming up with a list of requirements and deliverables. So that way it was them working together, for example, to create a new test of actors for their workflow or a new feature in one of our portals.

There was also this shared Slack channel where they could drop questions. So that was just the start: weekly meetings, Slack channels, give them instructions to have clear deliverables and clear timelines.

And actually, one of these interactions helped us deliver the first pilot of our new sandboxes, which was a huge milestone for Testing at DoorDash.

You mentioned that Slack channel again. That’s a strategy we’ve heard from other teams as well. I’m curious, what kind of engagement do you see in that Slack channel? And has that been a challenge for you to make sure developers are aware of that channel?

So the Slack channels that I just mentioned would be for the two teams interacting: my team and the counterpart team we were working with.

The ask channels that I mentioned before, those have been part of DoorDash’s culture since before the Developer Productivity team was created. We are very Slack-centric. So the first thing a DoorDash engineer thinks about when they have something to ask is to go and drop a question in one of the ask channels. So discoverability or having folks be aware about them is not a problem.

So the discoverability is a DoorDash-wide thing where it’s a convention developers are already used to.

Right.

Earlier you talked about some of the challenges or gripes you have with surveys. Can you share more about how you run surveys? What’s worked well and what hasn’t?

We usually do one survey per quarter. We send the survey out to the entire engineering org. And one of the problems I see with surveys is it’s very hard to tune the questions.

If they’re too generic, folks end up saying, “Okay, but what do I really need to write here?” Or, “Nothing comes to mind.” If they’re too specific, you might leave out signals that might actually matter.

If there’s too many questions, folks are like, “I’m not going to spend half an hour on a survey.” If there’s not enough, again, you risk not capturing what you want to.

So we’ve tried separate things. The first one was a bit more complex. The second one was slightly less complex and we got a slightly better set of signals through these surveys. I think they work up to a certain point, they need to be complemented, which is what I was mentioning before.

When you run these surveys, are the results for your teams or are you sharing the results back to all the managers of the individual teams?

Usually you send out these surveys for a specific team. For example, I send out one for Developer Console and the other one for Test Platform. And what we do is sit down with all the managers in the Developer Platform org, because sometimes there are signals from the surveys that can be useful to more than just one team.

I also sit down with the team and show them the results of the survey. We discuss what we can do in the next quarter to address some of the pain points or concerns that are coming from the survey. I shared the results when folks say we’re doing a great job because that’s good as well.

That makes sense. Switching topics a little bit. How do you approach measuring your team’s success?

Yeah, we’re doing something that one of my peers, Gergely, should take all the credit for. He started an internal research document that aims at giving us a well-defined framework to measure how we’re doing and to measure the productivity of our engineers, which I believe in the end, will also lead us to be more data-driven in the decisions we make in the planning phase. His proposal has been to use the SPACE framework.

So there are five categories in the SPACE framework, and they’re very high level. So our job has been to take these five categories and try to match all of them with specific metrics, so we’re bringing them to be more actionable and measurable values in the DoorDash ecosystem.

To do so, we’ve split the software development life cycle in all of its phases from onboarding to deployment, maintenance, and so on. We’ve put on one axis all the phases of the SDLC. And on the other axis are the SPACE framework categories. And each cell at the intersection of the tool, we’ve put one or more metrics.

So for example, “satisfaction” in the development phase might be how satisfied somebody is with the tooling or how satisfied you are with the documentation. So this is still coming out of some sort of survey, but there are things that are way more measurable, like performance in onboarding. How long does it take for a new hire to land their 10th PR?

For all of these metrics, we have established SLOs. So now we have a status for each of these metrics, which is either red or green or yellow, which also lines up with the way we think about OKRs.

So this is the way in which our thinking process has evolved. At the end of the day, what we want to have is metrics where we have colors that tell us where we need to invest the most or where we’re doing well.

Who’s the primary customer of these metrics? Is it primarily your teams or are these metrics being propagated to all managers across the org and all teams?

Initially this is going to be how the Developer Platform org evaluates their job and how they plan for the future. But I think everybody can benefit from these metrics.

One of the things that I think we will work on in the future is how to make these metrics widely available to everybody without giving anybody the chance to gamify them. Or, keeping them completely blameless, for example. Because this is not the way in which I’d like somebody to say, you’re not doing a good job. These metrics serve the purpose of saying, this is where we need to invest so that everything on the dashboard can be green.

For other companies that might be trying to adopt the SPACE framework, how are you actually collecting all these different signals? And what tools are you using to build this dashboard?

We haven’t gotten to that phase yet, but the way in which we’re collecting the majority of the metrics is by actually running some periodic jobs that collect these data across all of our tech stack. These metrics then can be emitted, for example, to our dashboards. I think in the end what we’ll do is collect these metrics and show them in our own developer console, which will also allow us to tune the view according to the role of the user. If you’re a manager, if you’re an IC, if you’re a director, here’s the data that you want to see.

‍