Senior Software Engineer [E5] at DoorDash

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?

How to best utilize a Senior EM's mentorship?

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?

How to handle an E6 who shoots down your ideas but doesn't offer any alternatives?

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** - <https://www.jointaro.com/playlist/dChIyTQcu2Ct5VC70lki/>\
\* **Communication** - <https://www.jointaro.com/question/3VNPK7wol76s89EkgFeW/what-are-software-engineering-fundamentals/>\
\* **Leadership -** <https://www.jointaro.com/lesson/X8vpfJooDpsX915ouC00/session-3-becoming-a-tech-lead-again-in-just-1-month-after-joining-robinhood-from-meta/>

How to develop soft skills like leadership, stakeholder management, etc.?

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.

How to write an OKR for something with a lot of risk/uncertainty?

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.

How to extract project requirements and historical 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.

How to align multiple cross-functional stakeholders & keep them updated?

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?

How to hold people accountable for Action Items/decisions from meetings?

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.

Who do you help, given there are only so many hours in the day?

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.

How much should I hand-hold an E3 DRI that's struggling?

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?

How to write an amazing work anniversary email?

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.