Explore DoorDash on Taro

I recently got feedback from my manager, and they mentioned that to start making progress to E6, I need to come up with new initiatives, which are big projects spanning across multiple teams. This is especially important for us as our team works in a way where we need to come up with the roadmap more on our own in a bottoms-up fashion.

This feedback is one of the core pillars I want to focus on going forward, but it's hard to make it actionable. What can I concretely do to start coming up with these projects?

A senior engineering manager (M2) was leading a discussion circle that I participated in. When it ended, he offered to mentor me with 30 min 1:1s every 2 weeks. He's not in my chain of command, but we are in the same org. He reached out to my skip-level (also an M2) for feedback on me to better coach me. In our first 1:1, he suggested some team activities I can take on to develop skills for getting to the next level.

• What's his incentive for doing this?
• How can I best utilize this time? Are there things that M2s are uniquely qualified to provide mentorship on?

I've seen multiple E6s point out flaws in others' proposals, but don't offer any alternatives of their own. What's a good way to navigate this? This is extra tricky when we're on the same team and they're the designated code reviewer for my work.

Example: I ran into a limitation with a 3rd-party SDK. I proposed 2 options as workarounds, but an E6 rejected both options due to their limitations. When I asked him for his recommendation, he could not provide any alternatives but still insisted that I find a solution without any limitations. Thankfully an E7 on another team helped me by providing a viable workaround after 3 E6s were stumped by this problem. What should I do if I'm not lucky enough to have an E7 help me next time?

My manager suggested that I work on the skills below to advance my career. Do you have any masterclasses or other resources to develop these skills? I added links to the resources that I know about.

* Stakeholder management
* Project management
* Design & architecture -
* Communication -
* Leadership -

My team made a ton of changes (e.g., different UI, different SDKs, etc.) when rearchitecting a large feature last year. When metrics were impacted during the rollout, we didn’t know what caused the metrics degradation due to all these changes and had to ramp down the experiment repeatedly last quarter. We’ll likely run into lots of unanticipated issues when ramping back up this quarter as well. Due to this uncertainty, what should we have as an OKR for this feature? Committing to a 100% rollout seems like setting the team up for failure. My team’s also working on another project this quarter, but we want to make some progress on this feature. Since it’s unlikely we can hit an OKR for 100% rollout, would it make sense to have an OKR for, say, committing X% time for feature Y? We’ll likely ramp up, discover some issues, ramp down, resolve the issues, then ramp back up repeatedly. Unfortunately we don't know what issues we'll run into ahead of time.

An E6 and I recently joined an existing team and are working with an E6 who has all the historical context on the project's requirements/limitations in his head. The PM is brand new to the team and the company. The EM and designer are also fairly new. The newer E6 often proposes architectural directions that the more tenured E6 shoots down due to this context. Is there a good way to extract all this context from the more tenured E6? I feel like we're often throwing things on the wall and just seeing what doesn't get shot down -- things get shot down more often than not, unfortunately. The more tenured E6 said it'll take too long to document all the context.

I worked on a large org-level, cross-functional project led by a TPM and an EM. Since there were so many engineers on this massive project, we were organized into smaller pods/subteams with pod leads. The TPM had standups 2x/week, and my pod had standups the other days of the week. My pod was loaned out to help a stakeholder team from another org. The TPM only attended his own standups and sometimes missed some. The EM attended most but not all my pod's standups as well as most but not all the TPM's standups. My pod lead attended most but not all of those same standups as well. The POC from the stakeholder team was not invited to any of these standups. Since the TPM's standups had so many engineers, we only gave high-level updates in that meeting.

In such a situation, how do you keep all the stakeholders (TPM, EM, pod lead, stakeholder team's POC) aligned and up-to-date with any challenges such as scope creep, bugs, delays, etc.? There was a slack channel for the overall cross-functional project and a separate one for my pod, but none for working with the stakeholder team's POC (all such communication was via DMs). When the stakeholder team's POC dropped the ball on things, how do you escalate in such an ambiguous situation? The TPM sent weekly "Weather Reports", but those emails were very high-level.

Sometimes people forget to follow up on their Action Items from meetings. They sometimes misremember meeting decisions as well. To mitigate this, I usually take detailed meeting notes in Google Docs and tag people on the Action Items they're responsible for. However, we don't always have meeting notes (e.g., for an ad hoc situation). What are some best practices for avoiding misunderstandings?

When I've been helpful in the past, word quickly spread and a bunch of random engineers started pinging me for help, sometimes aggressively. Sometimes people would delegate grunt work like asking me to test their PRs that do library upgrades instead of testing them themselves. Or asking me to debug their dev environments because they heard I fixed another engineer's dev environment. Sometimes it'll just be asking for expedited code reviews even though I have no domain knowledge on their PRs. We work on the same platform, but are not on the same team or often even the same org. There are only so many hours in the day and I need to get my own work done as well. How do you decide who to help and under what circumstances? Advice on how to push back without damaging the relationship? As far as I can tell, it looks like anyone from E4 through E7 are the ones making these requests.

I'm working on a cross-functional project with a backend DRI (E3) and Android engineer (E4?). I'm iOS, but have a backend background so I could easily code the backend portion if I needed to. The DRI reports to a different EM, who was on vacation for the first few weeks of the project. The DRI was struggling to get the backend piece working, so I spent extra time hand-holding him on how to debug it. I even researched how another feature in the iOS codebase used similar API calls and created a Postman collection for him to troubleshoot his APIs more easily. Is this a good use of my time? What percent of my time should I spend on helping others versus doing my own work? The Android engineer did not help the DRI because he doesn't know backend, so there was no one else to help the DRI.

DoorDash has a tradition where your manager sends a "Dashiversary" email to the entire company on your work anniversaries. The manager creates a Google doc and collects notes & photos from your colleagues and cross-functional partners, then adds his/her own note at the top of the email. Given the impact of Deep Thanks, what should I write in these notes to leverage these opportunities to build relationships?

Do you have examples of a problem, action, and impact for performance reviews? For example, I was working on a migration from a monolith to a BFF. I was loaned to a different team to help with their extractions. Their engineer gave me an API to use, but their API turned out to have serious shortcomings and I ended up working long hours to reimplement a lot of the monolith’s logic in the BFF. Despite this, we still slipped our timelines. How do I describe the impact of my actions in this case? I feel like my actions had “no impact” because we slipped our deadlines regardless.

I spend a lot of time on oncall. There's just 3 engineers on the oncall schedule (2 other back-end engineers and myself), so we're all oncall once every 3 weeks. We hired 2 people and are looking to onboard them into the rotation later in the summer, so it will become once every 5 weeks for oncall soon-ish.

Psychologically, the oncall is very draining as I'm constantly fearing what’s going to happen. For example, I can't work out at the gym in peace as I'm constantly on high-alert in case an issue pops up. How can I have better work-life balance and less stress with this situation?

I'll be starting at DoorDash relatively soon, and I was wondering what 1 on 1s I should set up on top of the one with my manager. More specifically, are there meetings I should make recurring vs. 1-time ad-hoc? For context, I'm an iOS engineer.

A fellow senior engineer on my team is leading a large multi year project that involves rewriting a significant portion of the codebase. He came up with the proposal, design doc, everything. A couple of team members are already helping him in the project, but since the project's scope is so big, he needs more help.

There is also a backlog of other projects that haven't been prioritized for several quarters. These include stuff like migrations, enabling CD (we still deploy manually taking up plenty of oncall engineer's time everyday) for our service, etc.

I feel like I would get more credit and build trust towards moving to E6 by leading one of the projects in the backlog as opposed to helping out the other engineer in his project. What do you recommend?

My team is kind of crazy - My manager has 30 direct reports and this craziness reflects in my oncall as well. Here's how my oncall is currently:

• It's made up of 3 engineers, 2 other back-end engineers and myself. This means I'm oncall 1/3 of the time.
• Around 15% of the time is spent actually resolving issues. For the remaining 85%, we focus on operational excellence (improving oncall documentation, adding tests, etc).
• There is no agreed upon SLA time. So we just push ourselves to respond to all issues ASAP.
• We aren't fully equipped to solve a lot of the issues our rotation gets. The oncall often has to rope in another team/oncall to fix the issue.