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

First, I highly recommend checking out this discussion about best supporting slow learners. Since this person is an E3, it's very relevant as they will (obviously) require the most support compared to other engineers.

To directly answer the question, my answer is: Enough to make sure your project is in a good state. You're a senior engineer at a large tech company I consider very to FAANG in terms of expectations: This means that your responsibility is to own entire projects and do whatever it takes to fill in the gaps and ship them. If this project slips due to the E3 back-end engineer struggling, you can't pin it on them as an E5 - The buck stops with you as L5 engineers at FAANG-level companies are supposed to be project leads.

That being said, there are other ways to solve this problem besides hand-holding them directly like:

1. Finding an E4/E5 back-end engineer to support them and maybe mentor them formally (this is the best solution IMHO)
2. Extending the deadline or reducing scope

Is this a good use of my time?

This depends on whether this engineer is worth mentoring and how well they are responding to your support alongside what the other options of addressing the problem are. That being said, if the project would be in a bad state without this time investment, even if it wasn't the best option, I feel like it's at least a decent use of your time.

What percent of my time should I spend on helping others versus doing my own work?

This really depends on what the expectations are for you come performance review, and you should have this conversation with your manager (I recommend our performance review masterclass for advice on how to do this).

That being said, I actually encourage you to think more about this question as helping others is your own work a lot of the time as an E5. As mentioned before, E5s are often project leads, which means that they're a force-multiplier and own projects holistically. Your own work isn't just coding up your iOS portion anymore - It's anything that moves projects forward, whether it's mentoring other engineers or having complex discussion with XFN.

Thanks, Alex!

Finding an E4/E5 back-end engineer to support them and maybe mentor them formally (this is the best solution IMHO)

Where would I find such a person? Wouldn't they be incentivized to focus on their own deliverables instead of mentoring an E3 on a different team and project? I asked the E3 if he has a backend mentor, but he said his entire team's too busy to help him.

Extending the deadline or reducing scope

I ended up working extra hours to make up for the time I spent hand-holding the E3.

If this project slips due to the E3 back-end engineer struggling, you can't pin it on them as an E5 - The buck stops with you as L5 engineers at FAANG-level companies are supposed to be project leads.

Does this apply even if the E3 is the project's DRI ("Directly Responsible Individual") / official project lead? The Android engineer and I were loaned to his team because they lacked mobile resources. The E3's team owns this feature.

My EM told me to just focus on my iOS deliverable and not worry about the backend portion since the other EM should be responsible for the E3's success. Is this the correct way of thinking about this? My EM is incentivized for me to finish the project ASAP so I can help him with our team's own projects.

Where would I find such a person?

I would look around the org and talk to your manager (and maybe theirs too). There's a good chance this person doesn't exist, but I think it's worth thinking about for 10-15 minutes.

Wouldn't they be incentivized to focus on their own deliverables instead of mentoring an E3 on a different team and project?

It depends on the culture of your org, but I've generally seen E5s (and E4s pushing for E5) get rewarded for bringing up other engineers to achieve multiplicative impact. Like with my prior point, you can talk to your manager more about this (i.e. how much is mentorship rewarded in performance review).

Does this apply even if the E3 is the project's DRI ("Directly Responsible Individual") / official project lead? The Android engineer and I were loaned to his team because they lacked mobile resources. The E3's team owns this feature.

Ah, if you're a loan, it's completely different then. You shouldn't get dinged for this. Things may be different if you were E6 though, as E6s are always held heavily responsible for XFN impact.

My EM told me to just focus on my iOS deliverable and not worry about the backend portion since the other EM should be responsible for the E3's success. Is this the correct way of thinking about this?

I can see where your EM is coming from, and I think they're correct overall. You shouldn't get a project you were loaned to turn into a time black hole and weigh you down from your own team's core roadmap work.

That being said, you should always be looking to achieve maximum impact for the time you spend, especially with performance review season coming up.

• To me, it seems like a waste to put in the effort to save the iOS portion of the project, just to have it potentially collapse due to a gap in the back-end.
• You don't need to solo-carry that portion yourself, but as an E5, I think you should at least call it out across your manager and the other team's manager and try to suggest some high-level solutions.
• You'll be surprised at how often simply calling things out can earn a ton of credit. Many times, issues like these slip under managers' radars, so adding the visibility is a huge value add for them.
• In fact, taking the more "diplomatic" approach and bringing people together is usually the best route for an E5 as it's the kind of behavior I would expect from a senior engineer in these situations. While brute forcing a solution by carrying the effort yourself is admirable, it's a more "naive" solution and doesn't demonstrate higher-level engineering behaviors (i.e. communication and leadership).

I would look around the org and talk to your manager (and maybe theirs too).

My EM told me to not worry about it because it's the E3's EM's problem to deal with. The E3's EM ended up hand-holding the E3 after he returned from vacation and got the backend working.

It depends on the culture of your org, but I've generally seen E5s (and E4s pushing for E5) get rewarded for bringing up other engineers to achieve multiplicative impact.

Wouldn't I get credit for hand-holding this E3 then, since I'm E5? Or is it different because I'm on working on iOS and he's backend?

Ah, if you're a loan, it's completely different then. You shouldn't get dinged for this. Things may be different if you were E6 though, as E6s are always held heavily responsible for XFN impact.

What would be the E6 expectation in this scenario?

You don't need to solo-carry that portion yourself, but as an E5, I think you should at least call it out across your manager and the other team's manager and try to suggest some solutions.

I called this out to my EM & skip-level and volunteered to hand-hold the E3 as a solution. They told me that's not my responsibility. My skip-level said he'll talk to the other team's EM about it -- I think that's why the other team's EM hand-held the E3 after returning from vacation.

In fact, taking the more "diplomatic" route and bringing people together is usually the best route for an E5 as it's the kind of behavior I would expect from a senior engineer in these situations. While brute forcing a solution by carrying the effort yourself is admirable, it's a more "naive" solution and doesn't demonstrate higher-level engineering behaviors (i.e. communication and leadership).

Since I communicated the concern to my EM & skip-level and the latter arranged for the other EM to hand-hold the E3, does this count as higher-level engineering behavior? Or was I supposed to reach out to the other EM myself for this arrangement to "get credit" for this?

Now that we got the iOS and backend pieces working, there's a problem with the Android release. There's a degradation in crash-free rates in the Android release, so the rollout was blocked. I looped in my EM, my TPM, the DRI, the DRI's EM, my Android engineer, and the crash-free rate TPM in the slack thread. The other team's EM scheduled a meeting with everyone to discuss it. Did I demonstrate higher-level engineering behavior here? Or was I supposed to schedule that meeting as well? I was surprised that the Android engineer didn't drive the discussions because this has nothing to do with iOS, but maybe that's because he's E4? Do you have a framework for understanding what's your responsibility or not? This is something I struggle with a lot.

My EM told me to not worry about it because it's the E3's EM's problem to deal with. The E3's EM ended up hand-holding the E3 after he returned from vacation and got the backend working.

Ah okay, that works out then. The EM being a last line of defense is interesting, haha.

Wouldn't I get credit for hand-holding this E3 then, since I'm E5? Or is it different because I'm on working on iOS and he's backend?

You should unless your org is really individualistic (should be pretty rare). The question is how much. I imagine this is something you can write on your performance review. You should get more credit traversing across stacks as it shows that you add value to the team more holistically.

What would be the E6 expectation in this scenario?

From my experience, an E6 is generally held responsible for the success of all projects underneath a senior engineering manager or even director level. This means that they would be much more involved saving a sister team's project (maybe even commandeering it temporarily to lead) as they need this very broad scope.

I called this out to my EM & skip-level and volunteered to hand-hold the E3 as a solution. They told me that's not my responsibility. My skip-level said he'll talk to the other team's EM about it -- I think that's why the other team's EM hand-held the E3 after returning from vacation.

Nice, looks like this all worked out. I think simply calling it out is all that's expected - Personally, I would stick to just this for similar future situations instead of stretching yourself thin to solo carry. You have to take care of yourself!

Since I communicated the concern to my EM & skip-level and the latter arranged for the other EM to hand-hold the E3, does this count as higher-level engineering behavior? Or was I supposed to reach out to the other EM myself for this arrangement to "get credit" for this?

I think this counts! Escalating to the skip and roping them in is a good move as well.

Now that we got the iOS and backend pieces working, there's a problem with the Android release. There's a degradation in crash-free rates in the Android release, so the rollout was blocked. I looped in my EM, my TPM, the DRI, the DRI's EM, my Android engineer, and the crash-free rate TPM in the slack thread. The other team's EM scheduled a meeting with everyone to discuss it. Did I demonstrate higher-level engineering behavior here? Or was I supposed to schedule that meeting as well? I was surprised that the Android engineer didn't drive the discussions because this has nothing to do with iOS, but maybe that's because he's E4?

Yes to higher-level engineering behavior - I don't think the formal owner of the meeting is super important. If you have higher-level crash knowledge with iOS that can be applied to Android, you can try to get more credit by being at that meeting and sharing those insights. But I think just starting the thread and helping galvanize the team around it is a great value add! That's what I would expect from an E5.

Do you have a framework for understanding what's your responsibility or not?

Go through from top to bottom. Only seriously invest in lower tiers when upper tiers are in good shape.

1. Make sure projects you're directly on are doing well on all fronts (E5 core responsibility)
2. Make sure projects your direct team owns are doing well (puts you on growth path from E5 -> E6)
3. Be a major player supporting/driving projects underneath skip-scope (E6 core responsibility)

Another important thing to remember is how you administer support when doing #2 and #3 in particular:

• In order to scale yourself (very important as E5 and especially as E6), you should solve problems by being a "connector" as much as possible as opposed to just dropping in and writing all the missing code yourself.
• Example: When it comes to a project lacking resources, you can solve it by procuring an engineer loan (connect with manager/TLs to coordinate) or reducing scope (connect with PM/designer to figure out which scope to cut).
• The overall principle is to figure out how you can solve as many problems as possible without directly putting your skin in the game with additional raw execution work. This is what it means to truly expand your scope.